Old problem still present on 11-ALPHA1 - Pi2

Karl Denninger karl at denninger.net
Tue Jul 12 14:54:04 UTC 2016


On 7/12/2016 02:40, Hans Petter Selasky wrote:
> On 07/12/16 03:28, Karl Denninger wrote:
>> It *only* happens if I have the VLANs enabled.  If I am running a single
>> network on an interface it's fine.
>
> Did you check the interface statistics? You can also try to enable
> debugging for the ethernet interface: "hw.usb.xxxx.debug=16" where
> xxxx is smsc or something like that.
>
> Are you sending very big packets? Did you try to set the MTU lower?
>
> --HPS

There is no indication of trouble and the devices it is talking to are
all MTU 1500, as is this unit.....

root at IPGw:/etc/mail # netstat -i -b -n -I ue0
Name    Mtu Network       Address              Ipkts Ierrs Idrop    
Ibytes    Opkts Oerrs     Obytes  Coll
ue0    1500 <Link#2>      b8:27:eb:be:e6:f8   174327     0     0 
186606323    80559     0    6306399     0
ue0       - 192.168.1.0/2 192.168.1.200       134293     -     - 
181992609    77276     -    5049273     -
root at IPGw:/etc/mail # netstat -i -b -n -I ue0.2
Name    Mtu Network       Address              Ipkts Ierrs Idrop    
Ibytes    Opkts Oerrs     Obytes  Coll
ue0.2  1500 <Link#3>      b8:27:eb:be:e6:f8    25926     0     0   
1562248     1245     0      55796     0
ue0.2     - 70.169.168.0/ 70.169.168.97           76     -     -      
5634     1240     -      86378     -
root at IPGw:/etc/mail # netstat -i -b -n -I ue0.3
Name    Mtu Network       Address              Ipkts Ierrs Idrop    
Ibytes    Opkts Oerrs     Obytes  Coll
ue0.3  1500 <Link#4>      b8:27:eb:be:e6:f8      431     0     0     
74658      174     0      33422     0
ue0.3     - 192.168.4.0/2 192.168.4.200           85     -     -     
30260       85     -      27880     -

Note that this CLAIMS no errors and very low traffic levels (as
expected; this is just a DHCP server machine and an "emergency" way into
the KVM on the servers if they blow up for some reason, as those KVMs
are not exposed to the Internet for obvious reasons.)

> It's interesting that it flapped down (and then back up) three times
> and you have three interfaces. Does it do that consistently? Does it
> do it twice if there is only two interface (base plus a vlan)?
That's just a function of when I looked since boot.  All three "flap" at
the same time but the "flap" is fictitious in that the switch never sees
the carrier drop on the port.  Now, a day later, there are dozens of
"flaps" in the dmesg output (in fact that's ALL that's there having
rolled the buffer off!)
>
> Can you share the interface configuration source? Have you checked
> your system resources close to an expected flap to see if there is
> ballooning resources somewhere? Brendan Gregg has some fantastic
> tracing resources. Here are a couple of my favorites (not that I
> profess to know anything about dtrace...)
Nothing complicated...

ifconfig_ue0="inet 192.168.1.200 netmask 255.255.255.0"
#
# VLAN for inside subnet
#
vlans_ue0="2 3"
ifconfig_ue0_2="inet 70.169.168.97/25"
ifconfig_ue0_3="inet 192.168.4.200/24"
defaultrouter="70.169.168.1"

That's it....

There's no system resource issue; the machine has plenty of RAM and
mbufs; and no denied requests being logged anywhere.

What this *looks like* is that something in the network stack thinks the
interface state has gone down but it in fact has not (the switch doesn't
see anything wrong.)  As evidence that FreeBSD thinks it has, however,
is that it *does* (sometimes) disrupt the snmpd client on this host and
unless it is restarted it will stop talking to my network monitor for
statistics, so I have to have a cron job that restarts snmpd every few
hours or eventually I'll flat-line all the stats out of that host on the
monitor console.

The machine itself is extremely stable; it has run for months without a
crash, only being interrupted by my intentional act (such as a software
upgrade.)  Then again it rarely is asked to do much since it's purpose
in life is to provide a means of setting up a tunnel to internal KVMs in
the event that one of the machines behind the Internet gateway (or the
gateway itself!) blows up and requires attention from a remote (e.g.
using ssh as a tunnel once you're signed into this machine.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160712/f23541b7/attachment.bin>


More information about the freebsd-arm mailing list