>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:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
