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
Scale state table size with memory, never allocate more than 10% system ram, this leads to 12K states on 128M and 102K on 1G systems - this should be a good default
