From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:40:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E80D16A4CE; Mon, 8 Nov 2004 17:40:12 +0000 (GMT) Received: from expert.ukrtel.net (expert.ukrtel.net [195.5.6.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3162143D58; Mon, 8 Nov 2004 17:40:08 +0000 (GMT) (envelope-from astesin@ukrtelecom.net) Received: from hoexch005.sl.ukrtelecom.net (sltrans.ukrtel.net [195.5.37.133]) by expert.ukrtel.net (Netscape Messaging Server 3.5) with ESMTP id AAA2B26; Mon, 8 Nov 2004 19:40:46 +0200 Received: from hoexc010.ho.ukrtelecom.net (hoexc010.ukrtelecom.net [10.10.1.10]) by hoexch005.sl.ukrtelecom.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WP8G8CZ0; Mon, 8 Nov 2004 19:42:56 +0200 Received: by hoexc010.ukrtelecom.net with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Nov 2004 19:39:55 +0200 Message-ID: <1152675CA9EDD71187130002B3CE5ADA10660F56@hoexc010.ukrtelecom.net> From: astesin@ukrtelecom.net To: rwatson@freebsd.org Date: Mon, 8 Nov 2004 19:39:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain cc: freebsd-current@freebsd.org cc: mib@wnet.ua Subject: Re: em0, VLAN and bpf(?) trouble w/RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 17:40:12 -0000 > > The problem. From time to time, vlan0 stops passing packets > > at all. At > > this moments, Catalyst stops seeing MAC of vlan0 (it's the > > same MAC as > > em0) in the mantione VLAN (untagged VLAN is also configured > > at em0 and > > works fine!). This means that `show mac-address-table vlan XX' > > command on Catalyst don't show the MAC. > > > > The problem can be easily repeated manually. It's enough > > just to issue > > a command like `trafshow -I vlan0' of `tcpdump -I vlan0' and voila! > > vlan0 is out of business, no packets are going through. > > Hmm. Could I get you to try/investigate a few things: > > (1) If you run tcpdump on the em0 interface itself, does the > same thing happen? Hmm... Tried this; yes the connection freeze. (The box is remote, and I'm accessing it through the same vlan0; it's a bit boring). Oopps, when ssh connection hangs up, tcpdump gets SIGHUP, and... everything works nice again. Can it happen that way that bpf (or maybe it's promiscuous mode?) just "eats" all packets without returning them back into network stack? (Our local Ukrainian FreeBSD people suggested trying -p switch to trafshow - means "don't put interface into promiscuous mode" - but I didn't try this yet, I think it shouldn't behave *this* way anyway). > (2) When vlan0 wedges, do you still see traffic on em0, and can you > generate traffic on em0 that's picked up by the switch? When I tried that from the console, being locally near the box (now I'm at remote location) - yes, em0 was working Ok (in untagged VLAN) while vlan0 was already "frozen". > (3) Do other vlan pseudo-interfaces wedge under similar circumstances? Will check this in a while... > (4) Could you try running with "debug.mpsafenet=0" in > loader.conf (reboot for it to take effect) and see if that makes a difference? `mpsafenet' is now off, because kernel is compiled with IPSec > (5) Does it matter whether you enter promiscuous mode using > BPF -- i.e., > "tcpdump -p -i vlan0" vs w/o the -p flag? Will try this later. My collegue (sysadmin) occasionally started a long fetch operation (Xorg) and I just don't want to interrupt it... > (6) When vlan0 is in the wedged condition, how "no packets" > is it? Can you send packets but not receieve, or receive packets and > not send? AFAIK nothing goes through both ways. I can't check this for sure just now, because Cisco router at the other end isn't under my responcibility. > Thanks! Thank you for your attention! I'll try all the other tests later this night. WBR, Andrew