From owner-freebsd-bugs@FreeBSD.ORG Sat Sep 3 23:40:01 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E422106566C for ; Sat, 3 Sep 2011 23:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 47BBB8FC15 for ; Sat, 3 Sep 2011 23:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p83Ne1aX022766 for ; Sat, 3 Sep 2011 23:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p83Ne1GQ022765; Sat, 3 Sep 2011 23:40:01 GMT (envelope-from gnats) Resent-Date: Sat, 3 Sep 2011 23:40:01 GMT Resent-Message-Id: <201109032340.p83Ne1GQ022765@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ian Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72C551065672 for ; Sat, 3 Sep 2011 23:36:28 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 587368FC0A for ; Sat, 3 Sep 2011 23:36:28 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p83NaSfM015232 for ; Sat, 3 Sep 2011 23:36:28 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p83NaSdG015231; Sat, 3 Sep 2011 23:36:28 GMT (envelope-from nobody) Message-Id: <201109032336.p83NaSdG015231@red.freebsd.org> Date: Sat, 3 Sep 2011 23:36:28 GMT From: Ian To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/160442: Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 23:40:01 -0000 >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 metric 0 mtu 1500 options=38db ether 00:40:63:e6:8d:a5 media: Ethernet autoselect (1000baseT ) status: active vlan3: flags=8843 metric 0 mtu 1500 options=3 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 ) 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: