Ticket #1514
Introduction
I have an acceptable workaround, so the problem is not urgent, but before i fiogured out the workaround, is was severely impacting performance (3 interfaces not operating). I am a network specialist and I am available to assist wherever possible. If the issue si considered seriousenough for a fix, I can assist in more detailed pinpointing using tcpdumps on test-platforms.
Symptoms
If a interface is using vlan tagging for virtual interfaces and also the untagged interface is using MAC address spoofing, communication fails on the tagged vlans.
Description
On interface rl1 is untagged the WAN connection. This requires a spoofed MAC address, eg using <spoofmac>00:03:6b:f7:3b:3f</spoofmac>. On interface rl1 is also a vlan/tagged interface, eg vlan0 using rl1 and vlan tag 5. The tagged interface vlan0 expects to use the original MAC address of the interface rl0. But the issue is that interface rl0 is only processing incoming packets with destination mac address spoof_mac_rl1.
Workarounds (no code change required)
acceptable configure the <spoofmac>00:03:6b:f7:3b:3f</spoofmac> on all vlan interfaces connected to interface rl1
funny start a tcpdump on the vlan interface. This will put the interface in promiscuous mode and it will process all packets. Now the packets destined for the original MAC address (and active on the vlan interface)
bypass Do not use tagged interfaces on a interface with spoofmac
Remarks
It is very confusing that when a vlan is created, the GUI a refernece shows to the physical/original MAC address, even when the MAC addres of the untagged interface is
drop one level of verbosity in tcpdump. Some protocols will still decode to multi-line message - not an easy fix. Doesn't appear to break non-raw log display
Add VRRP as a protocol type in the decode
Êbe in ticks "for algorithm stability" when originally committed, it turns
Êout that it has a significant impact in timing out connections. ÊWhen we
Êchanged HZ from 100 to 1000, this had a big effect on reducing the time
Êbefore dropping connections.
ÊTo demonstrate, boot with kern.hz=100. Êssh to a box on local ethernet
Êand establish a reliable round-trip-time (ie: type a few commands).
ÊThen unplug the ethernet and press a key. ÊTime how long it takes to
Êdrop the connection.
ÊThe old behavior (with hz=100) caused the connection to typically drop
Êbetween 90 and 110 seconds of getting no response.
ÊNow boot with kern.hz=1000 (default). ÊThe same test causes the ssh session
Êto drop after just 9-10 seconds. ÊThis is a big deal on a wifi connection.
ÊWith kern.hz=1000, change sysctl net.inet.tcp.rexmit_min from 3 to 30.
ÊNote how it behaves the same as when HZ was 100. ÊAlso, note that when
Êbooting with hz=100, net.inet.tcp.rexmit_min *used* to be 30.
ÊThis commit changes TCPTV_MIN to be scaled with hz. Êrexmit_min should
Êalways be about 30. ÊIf you set hz to Really Slow(TM), there is a safety
Êfeature to prevent a value of 0 being used.
ÊThis may be revised in the future, but for the time being, it restores the
Êold, pre-hz=1000 behavior, which is significantly less annoying.
ÊAs a workaround, to avoid rebooting or rebuilding a kernel, you can run
Ê"sysctl net.inet.tcp.rexmit_min=30" and add "net.inet.tcp.rexmit_min=30"
Êto /etc/sysctl.conf. ÊThis is safe to run from 6.0 onwards.
ÊApproved by: Êre (rwatson)
ÊReviewed by: Êandre, silby
