Re: bridged vlan interfaces

Hello to Grant and the rest of you guys,

First of all, happy new year for all...  And now straight to business ;)

I finally hooked up the hub between our bridge and the main equipment
trunk, and also setup a dedicated linux box to have a peek at everything
that goes on through that trunk.  I actually had one of those Realtek
cards you mentionned laying around, so it has one dedicated to sniffing.
  The built-in e100 is for me to ssh into the box.

This is essentially what I have now:

          (main bridge box)
gateway<-->[out-br0-in.2]<-->hub<-->switch<-->all-our-network
                               |
                           [realtek]
                        (spy linux box)

Now I noticed something interesting which might turn out to be the
source of my problem.

If I tcpdump for arp on in.2, br0 or out, I will see customers arp for
the gateway and the gateway arp for customers just fine.  These all
involve our public IP addresses, which is to be expected.

However, if I tcpdump on in itself, I only see arp requests for our
underlying untagged (10.0.0.0/8) network ie: the equipment itself, not
the customers who are in vlan 2.

Now, I hop onto our little spy box and see if I can do this:

tcpdump -n -i eth1 vlan 2

Yup, a whole bunch of public network traffic, so, to be sure:

tcpdump -n -i eth1 not vlan

Yup, private network traffic.

Now, out of curiosity I do this:

tcpdump -n -i eth1 vlan 2 and arp

This is where things get interesting...  TCPdump says this would filter
out all traffic.  Implication:  arp requests shouldn't be tagged.

The bridge sure does seem to tag them.  So, am I wrong to tag them?  It
is my understanding that mac addresses are on the layer 'below' the vlan
tag, so in that sense, I understand why arp requests probably shouldn't
be tagged...  But IP sure is above and arp, as far as I'm concerned is
an IP concern, so it probably should get tagged.

I could use a bit of clarification there because at any rate, I can't
see any ARP requests at all in vlan2 from my spy box, which I figure I
would need to diagnose my issue when I add another vlan to the bridge.

Jonathan

Grant Taylor wrote:
> On 11/29/07 08:46, Jonathan Thibault wrote:
>>> s = switch port with out vlan 3
>>> S = switch port with vlan 3
>>> i = interface on linux box with out vlan 3
>>> I = interface on linux box with vlan 3
>>> b = bridge on linux box with out in.3
>>> B = bridge on linux box with in.3
>> sib = works
>> siB = (invalid)
>> sIb = works
>> sIB = works
>> Sib = works
>> SiB = (invalid)
>> SIb = works
>> SIB = nowork :(
> 
> Hum.  Well we know a couple of things:
>   1)  The Linux box with vlan 3 and in.3 in the bridge works as long as
> the switch port does not have vlan 3 assigned.
>   2)  The Linux box with vlan 3 and the switch port with vlan 3 works as
> long as in.3 is not in the bridge.
> 
> This means that the problem is only when all three aspects are in play
> at the same time:  switch port with vlan 3, the Linux box with vlan 3,
> and in.3 being in the bridge.
> 
>> The current active configuration is pretty much like SIb (using a 
>> plain switch) and it works.  Of course in.2 is on the bridge as my 
>> entire set of customers is in that vlan.
> 
> *nod*
> 
>> I toyed with tcpdump a bit and got slightly surprising results:
>>
>> 'tcpdump -n -i in.2' -> I see my customer's traffic.
>> 'tcpdump -n -i in' -> I see my customer's traffic.
> 
> I can't say as I'm completely surprised by this.  The ethernet frame is
> all that is different, so you would still be able to discern the traffic.
> 
>> 'tcpdump -n -i in.2 vlan 2' -> Nothing at all.  Obviously since in.2 
>> is untagged traffic.
>> 'tcpdump -n -i in vlan 2' -> Nothing at all.
> 
> I think you should see some traffic with your last test.
> 
>> Now that last case has me a bit perplexed...  Normally, the *tagged* 
>> traffic would enter/leave the physical interface itself.  It's a bit 
>> strange to me that both in and in.2 would show tcpdump only untagged 
>> frames.  Would this have something to do with the fact that the 
>> tigon3 driver/hardware has vlan support built-in?
> 
> Agreed.  I have had very good luck using low end Realtek 8139 NICs, you
> might want to spend $5 - $25 and try one out.
> 
>> I also managed to dig out an ethernet hub (a lot harder task than I 
>> thought) but haven't had the chance to take it to the datashed (5'x5' 
>> datacenter? ;) and sniff the backbone trunk itself for those elusive 
>> vlan tags.
> 
> *Chuckle*  Have fun with that.  I like the term "Data Shed".  :)
> 
>> Cisco equipment would likely provide better diagnostics tools in the 
>> radios.  This is Motorola, networking is one of their very many 
>> sidelines but it's hard to beat the actual radio performance for the 
>> price.  I guess building so many cell phones pays off ;)
> 
> *nod*
> 
> 
> 
> Grant. . . .


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/