From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 13:01:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91E2216A419 for ; Wed, 30 Jan 2008 13:01:06 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp810.mail.ird.yahoo.com (smtp810.mail.ird.yahoo.com [217.146.188.70]) by mx1.freebsd.org (Postfix) with SMTP id EF3E513C4D9 for ; Wed, 30 Jan 2008 13:01:05 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 22155 invoked from network); 30 Jan 2008 13:01:03 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.239.10 with plain) by smtp810.mail.ird.yahoo.com with SMTP; 30 Jan 2008 13:01:03 -0000 X-YMail-OSG: PH_LkMoVM1kgA_R2xfrN8VwR_8FwS8EzAs9slN5q.t2QXtwZoF7Ef4W_heHI4wKk2g9YbjO8ng-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47A07525.9080201@tomjudge.com> Date: Wed, 30 Jan 2008 13:01:25 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> <479F7C7A.5080605@tomjudge.com> <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> In-Reply-To: <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 13:01:06 -0000 Alexandre Biancalana wrote: > On 1/29/08, Tom Judge wrote: >> Alexandre Biancalana wrote: >>> Hi Tom ! Thanks for your help! >>> >>> I had to step back the chance an put the "old" gateway back, the >>> performance was unacceptable :-( >>> >>> Looking closer I see that still have the problem using the old gateway >>> too, in a small scale because I only use vlan to external links. >>> >>> This old gateway is running 6.2-STABLE and have 4 network interfaces: >>> fxp0, fxp1, sk0 and sk1. >>> >>> fxp0, sk0 and sk1 are no parent of any vlans, are connected to >>> internal networks and work without problems, follow the ifconfig >>> ouput: >>> >>> fxp0: flags=8843 mtu 1500 >>> options=8 >>> inet 10.11.0.1 netmask 0xffff0000 broadcast 10.11.255.255 >>> ether 00:02:a5:41:c6:b2 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> sk0: flags=8843 mtu 1500 >>> options=b >>> inet 10.2.0.36 netmask 0xffff0000 broadcast 10.2.255.255 >>> ether 00:0a:5e:5c:9e:2e >>> media: Ethernet autoselect (1000baseTX ) >>> status: active >>> sk1: flags=8843 mtu 1500 >>> options=b >>> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >>> ether 00:0a:5e:5c:27:ef >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> fxp1 is parent of 7 vlan interfaces: vlan16, vlan20, vlan200, vlan201, >>> vlan202 and vlan205 that connect my internal network to some external >>> links, follow the ifconfig output: >>> >>> vlan200: flags=8843 mtu 1500 >>> inet 10.200.0.1 netmask 0xfffffffc broadcast 10.200.0.3 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 200 parent interface: fxp1 >>> vlan201: flags=8843 mtu 1500 >>> inet 10.200.0.5 netmask 0xfffffffc broadcast 10.200.0.7 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 201 parent interface: fxp1 >>> vlan202: flags=8843 mtu 1500 >>> inet 10.200.0.9 netmask 0xfffffffc broadcast 10.200.0.11 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 202 parent interface: fxp1 >>> vlan205: flags=8943 mtu 1500 >>> inet 10.0.0.9 netmask 0xfffffffc broadcast 10.0.0.11 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> Like seen before netstat -niW show output errors in vlan interfaces >>> >>> # netstat -niW >>> Name Mtu Network Address Ipkts Ierrs Opkts >>> Oerrs Coll >>> vlan201 1500 00:0c:f1:ac:91:09 53524 0 52234 >>> 63 0 >>> vlan202 1500 00:0c:f1:ac:91:09 5907 0 4421 >>> 4 0 >>> vlan205 1500 00:0c:f1:ac:91:09 9728659 0 9373148 >>> 87025 0 >>> (the vlan205 is the most used and the output error is increasing...) >>> >> Taking a quick look through if_vlan.c it seems that the output error >> counter (ifp->if_oerrors) is only incremented in 3 places: >> >> 1) Then padding short frames that are valid with the vlan tag but runts >> when they have the tag stripped. >> >> 2) When inserting the VLAN tag in to the packet when the underlying >> interface does not support vlan hardware tagging. >> >> 3) When IFW_HANDOFF fails to hand the packet off to the parent interface. >> >> Do you have any error messages on the console in dmesg? ('cannot pad >> short frame', 'unable to prepend vlan header' for example). > > no :( Sorry I'm fresh out of ideas now... Unless you could be should of ram what does netstat -m look like? Also you could look at changing if_vlan.c to print the error number of the error if IFQ_HANDOFF fails. Tom