kern/160442: Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish.

[Ian]

>Number:         160442
>Category:       kern
>Synopsis:       Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 03 23:40:00 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Ian
>Release:        8.2-RELEASE-p2
>Organization:
-
>Environment:
FreeBSD 8.2-RELEASE-p2 i386
>Description:
When using a vge(4) physical interface for an 802.1Q trunk, packets sent via the vlan(4) interfaces tied to it seem to disappear.

When debugging this, I came across a few curious things.  The physical interface receives the packet, as reported by tcpdump.  Then, the tagging is stripped off, and it's handed to the vlan interface, where tcpdump again sees the packet, unencapsulated, as one would suspect.  Replies sent back out can be seen on the vlan interface, but tcpdump never sees any packets being sent back out the parent interface, and they never are!

To illustrate, here's a DHCP request, as it appears on the physical interface:

07:57:13.147576 00:11:43:f6:00:28 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 410: vlan 3, p 0, ethertype IPv4, (tos 0x0, ttl 128, id 35779, offset 0, flags [none], proto UDP (17), length 306)
    0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from 00:11:43:f6:00:28, length 278, xid 0x52525230, secs 2868, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address 00:11:43:f6:00:28 [|bootp]

This is then received on the vlan interface, and a reply is sent back out on the vlan interface:

07:58:25.142617 00:11:43:f6:00:28 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 406: (tos 0x0, ttl 128, id 13346, offset 0, flags [none], proto UDP (17), length 306)
    0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request from 00:11:43:f6:00:28, length 278, xid 0x52525230, secs 2940, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address 00:11:43:f6:00:28 [|bootp]
07:58:25.146633 00:40:63:e6:8d:a5 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x52525230, secs 2940, Flags [Broadcast] (0x8000)
          Your-IP 192.168.0.193
          Client-Ethernet-Address 00:11:43:f6:00:28 [|bootp]

..but no reply is ever seen on the physical interface dump, and nothing hits the wire.  This happens with all packets sent, including ARP replies.

Without any vlans configured, the interface itself works well.  I have not yet tested configuring vlans on it and then attempting to just use the native vlan on the interface itself, but I'm willing to if it would help.

Strangely, if I disable HW VLAN tagging, the incoming packet can still be seen with tcpdump on the vge and vlan interfaces.  However, I don't then see a reply on either interface, vlan or vge.

Also, even though polling is being used in my case, disabling/enabling it seems to have no effect on the situation.
>How-To-Repeat:
Configure a vge interface with one or more vlan like so:

vge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=38db<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:40:63:e6:8d:a5
        media: Ethernet autoselect (1000baseT <full-duplex,master>)
        status: active
vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether 00:40:63:e6:8d:a5
        inet 192.168.0.222 netmask 0xffffffe0 broadcast 192.168.0.223
        inet 192.168.0.221 netmask 0xffffffff broadcast 192.168.0.221
[...]
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 3 parent interface: vge0

Attempt to ARP any of the addresses on the vlan interface, and you will see no reply.  Check for the odd behavior with tcpdump in the full description of the problem.
>Fix:
None known.

>Release-Note:
>Audit-Trail:
>Unformatted: