Ethernet Bridge development
 help / color / mirror / Atom feed
From: Jonathan Thibault <jonathan@navigue.com>
To: bridge@lists.osdl.org
Subject: Re: [Bridge] Bridged vlan issue.
Date: Tue, 05 Feb 2008 14:55:53 -0500	[thread overview]
Message-ID: <47A8BF49.2020004@navigue.com> (raw)
In-Reply-To: <47A0D6F8.5010600@navigue.com>

Anybody with input on this?  We're certainly willing to pay to get this 
one fixed if that's an incentive.

Jonathan
> I have a strange issue with bridged vlan interfaces.  I've discussed 
> it at length in the ebtables mailing list and have gotten a fair bit 
> of valuable feedback from there.  It is still a bit unclear where the 
> problem resides but it definitely seems ARP related.
>
> First of all, this is kernel 2.6.23.  I have two tg3 gigabit 
> interfaces on the box, conveniently named:  'out' and 'in'.  The vlans 
> are on the 'in' side of the bridge, so in.2, in.3, in.4 ... in.6 while 
> the 'out' interface is plain untagged ethernet.
>
> As it is now, I only use ebtables to filter out anything that isn't 
> ipv4 or arp, I do the rest of my filtering through iptables.  There is 
> also no STP on the bridge or anywhere in our network, though we might 
> use it once I get this fixed.
>
> In its current, working condition, the bridge (br0) has interfaces 
> 'in.2' and 'out' with the clients on the 'in' side of the bridge, and 
> the internet gateway on the 'out' side.  Does the job brilliantly.
>
> I start having problems when in.3 is added to the bridge (it exists 
> and is up on the box, just not on the bridge).  There are still no 
> clients in vlan 3, but when I add it to the bridge, the bridge won't 
> relay ARP replies from the gateway to some of my clients in vlan2, 
> effectively disabling their internet.
>
> The strange thing is that I see the reply come into the 'out' 
> interface (with tcpdump), I see it on the 'br0' interface, and I also 
> see it on the in.2 interface where it should be on its way to the 
> customer.  But putting a hub between the customer and the bridge box, 
> I never see it.  It's as if the arp reply just vanished just before it 
> got fed to the ethernet cable.  To the linux box, it's been sent, but 
> it never shows up on the trunk.
>
> I've also validated this by testing when only 'in.2' and 'out' are on 
> the bridge, I see both requests and replies for affected customers go 
> through the hub and everything works.
>
> I know the tg3 driver does some vlan acceleration of sorts, that might 
> have something to do with it, but something tells me I'd have the same 
> problem with just one vlan interface on the bridge then.
>
> As I said before, this only manifests in our production environment, 
> so I have to be pretty careful with scheduling tests and what not, but 
> I'd very much love some ideas to figure out where the vanishing 
> packets go.
>
> Jonathan
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge


      reply	other threads:[~2008-02-05 19:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-30 19:58 [Bridge] Bridged vlan issue Jonathan Thibault
2008-02-05 19:55 ` Jonathan Thibault [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47A8BF49.2020004@navigue.com \
    --to=jonathan@navigue.com \
    --cc=bridge@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox