# Disappearing outgoing packets from 802.1Q to physical?



## Orum (Sep 3, 2011)

I have a switch that's trying to retrieve its address via DHCP, and a FreeBSD router that's running a DHCP server.  They're connected via an 802.1Q trunk.

If I tcpdump on the physical interface, vge0, I can see the incoming DHCP request:

```
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]
```
...and I can follow the request and the server reply by dumping 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 then that reply never exits the via physical interface!  It just disappears.

Any idea what's going on?  I'm stumped.  I've tried different clients, as well, including another FBSD client through the switch and over a different vlan on the trunking interface.  Still, there are 0 packets sent in reply.

Edit: Seems no traffic can travel out over the vlans, even ARP.  Like DHCP, it is received on the physical, and the logical (vlan), and sent out the vlan interface, but never makes it to the physical interface.

Edit2: Tried disabling HW vlan tagging, and then I didn't even see the outgoing packet on the vlan.  I reenabled it, and it was back.  FWIW, here's what the interfaces looks like in ifconfig:

```
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
        inet 192.168.0.220 netmask 0xffffffff broadcast 192.168.0.220
        inet 192.168.0.219 netmask 0xffffffff broadcast 192.168.0.219
        inet 192.168.0.218 netmask 0xffffffff broadcast 192.168.0.218
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 3 parent interface: vge0
```
I also thought polling might be causing issues, but I disabled it, and it had no effect.

Edit3: I should also mention that the interface itself, sans-802.1Q, works just fine.  The problem is definitely specific to vlans.  FBSD is FreeBSD 8.2-RELEASE-p2 i386.


----------



## aragon (Sep 3, 2011)

Looks like you should file a PR.

Try test with a different NIC (and driver) if you can...


----------



## Orum (Sep 4, 2011)

Yeah, I was afraid of that.  Was hoping someone else had found a workaround.

I have a similar setup on another machine with a different NIC, but it's also using lagg (has two vr NICs).  That machine is working flawlessly.

Well, I'll file a pr then.

*Update:* PR was submitted, and handled very promptly by the FreeBSD team.  Details can be found here, including a patch as well as a work around without patching.  Many thanks to the devs!


----------

