From owner-freebsd-net@FreeBSD.ORG Thu Aug 14 19:04:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8328C44E for ; Thu, 14 Aug 2014 19:04:19 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42D8D2113 for ; Thu, 14 Aug 2014 19:04:19 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id k15so1330590qaq.13 for ; Thu, 14 Aug 2014 12:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9CGsOMmWj2dwIWG4W9R9y/XiXrlP1TlbNsIvRJD19XY=; b=kVd7Xm/r9HV2NFmbYBGn6G6gPTjMDuP61fcEXnLlDBPHTZJlMu3Ti6/699o+xKBLs3 3MTW8KQcw/La9I/mwsEqSB9IIRvKytIKlQF/OAB1EEs1y14ZGeIpA5hgmFMHhdl4x6OS 1JwRpFlstoJpzrEsKY3yfmOq+BfHQvG7RUkfQIQjufbRbWQXhPoqzwH+EvCN6l/W6Twq bcHjgfJpux1jhI6kHF4QrHMl80inkiiX1pZieL0PwTRXgeTf1r3vTiEcsXE8PNNF/HoX loxqvnk5GywCPkkfyAUhwvjb5+Y5fOCjNI6ONuC7Si+Al9bwxFqSBOhYdJk9RGufCKuP Y/CA== MIME-Version: 1.0 X-Received: by 10.140.23.37 with SMTP id 34mr19377342qgo.2.1408043058298; Thu, 14 Aug 2014 12:04:18 -0700 (PDT) Received: by 10.96.170.230 with HTTP; Thu, 14 Aug 2014 12:04:18 -0700 (PDT) In-Reply-To: <08f701cfb69e$1698e2c0$43caa840$@com> References: <08f701cfb69e$1698e2c0$43caa840$@com> Date: Thu, 14 Aug 2014 12:04:18 -0700 Message-ID: Subject: Re: SPAN port doesn't pick up locally generated traffic From: hiren panchasara To: Joseph Ward Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 19:04:19 -0000 On Tue, Aug 12, 2014 at 7:27 PM, Joseph Ward wrote: > I found a workaround that is acceptable. > > First, I want to thank Hiren Panchasara for recommending the work-around > that I hadn't thought about trying. > > For the archives and anyone struggling with the same issue: > > I altered the setup below by giving the LAN IP to the wired interface re1 as > opposed to bridge0. Doing that magically made the span port (re2) get all > the traffic, both passing through in re1 and out ath0 (and vice versa) as > well as the packets that originate inside the system and are passed to the > bridge. > > This isn't ideal as it means that if the physical interface re1 goes down, > clients on ath0 will lose connectivity to the system, and I had always > understood that when bridging it's ideal to give the IPs to the bridge > itself to protect against that possibility. However, I can give each > interface another IP on a different subnet that will at least allow for > remote connectivity in that scenario. > > Does anyone know if this is known/expected behavior? If no one knows I'll > file a bug ticket on the scenario as it certainly doesn't seem kosher to me. I am not sure if this one case of "packets originating from one of the bridge members not showing up on the bridge's span port" is the only one not getting handled correctly or there is more to it. Please file a bug with your testing scenarios and all the details. CC me on the bug and I'll try to take a look. cheers, Hiren [skip]