Ethernet Bridge development
 help / color / mirror / Atom feed
From: Jonathan Thibault <jonathan@navigue.com>
To: bridge@lists.osdl.org
Subject: [Bridge] bridge, vlan and *no* stp/bpdu
Date: Fri, 07 Mar 2008 14:47:21 -0500	[thread overview]
Message-ID: <47D19BC9.6060702@navigue.com> (raw)

Hello list,

I've posted here about this before, but I realise that it may have been 
assumed that the bridged vlans simply put a switch port in a blocking 
state and left my question ignored.  So to recap.

I have two tg3 interfaces named 'in' and 'out' and a bridge named 'br0'

My vlan trunk is on the 'in' side of the network, and set as in.2, in.3 
...  The 'out' side goes straight to an ipv4 gateway on untagged plain 
ethernet.

Putting 'in.2' and 'out' on the bridge works quite well and is roughly 
what I've been using so far.

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00e081342870       no              out
                                                        in.2

If I add in.3 to the bridge, trouble starts.  The bridge keeps 
forwarding packets just like it should, with the exception of ARP 
replies from the gateway to machines in vlan 2.  Machine that had ARPed 
the gateway prior to adding in.3 to the bridge keep working fine.

Here's the strange thing however.  Running a tcpdump on 'out' 'br0' or 
in.2 shows me the arp requests *and replies* for the machines that do 
not work, however, if I look on the wire leaving the 'in' interface 
itself (using a hub and another box), the arp replies are nowhere to be 
found.

So the arp replies get eaten *before* they make it onto the wire, but 
*after* tcpdump saw them on in.2.  It's driving me nuts...  I thought it 
might have to do with the tg3 hardware doing some funky vlan 
acceleration, but I've seen the same on plain dumb NICs too.

I'm willing to pay for a solution to this...  Or even for just someone 
knowledgeable enough with the code taking interest in the issue.

Thanks,

Jonathan

             reply	other threads:[~2008-03-07 19:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-07 19:47 Jonathan Thibault [this message]
2008-03-07 20:08 ` [Bridge] bridge, vlan and *no* stp/bpdu Andy Gospodarek
     [not found]   ` <47D1B45F.7020409@navigue.com>
     [not found]     ` <bdfc5d6e0803071423ia2c794fn662a6e875ffafe09@mail.gmail.com>
2008-03-08 16:26       ` Jonathan Thibault
2008-03-09  7:36         ` richardvoigt
2008-03-09 15:53           ` Jonathan Thibault
  -- strict thread matches above, loose matches on Subject: below --
2008-03-11  0:43 Leigh Sharpe
2008-03-11 15:44 ` Jonathan Thibault
2008-03-11  0:43 Leigh Sharpe
2008-03-11 22:07 Leigh Sharpe
2008-03-12 17:43 ` Jonathan Thibault
2008-03-18  2:38 Leigh Sharpe
2008-03-18  4:38 ` Malcolm Scott
2008-03-19 14:58 ` Jonathan Thibault
2008-04-11 18:04   ` Jonathan Thibault
2008-04-13 10:59     ` Malcolm Scott

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=47D19BC9.6060702@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