Re: bridged vlan interfaces

Grant Taylor wrote:
> On 11/17/07 15:17, Jonathan Thibault wrote:
>   
>> I managed to get rid of the SRW2024, so now my network looks like 
>> this:
>>
>> (40xSM)<-T->(AP)<-T->(BH)<-T->o
>> (20xSM)<-T->(AP)<-T->(BH)<-T->o
>> (30xSM)<-T->(AP)<-T->(BH)<-T->o(PlainSwitch)o<-T->(in.2-br0-out)<-P->(gateway)
>>             ...               o             o<-T->o(SRW208)o(mgmt)
>>        (SRW208)o<-T->(BH)<-T->o
>>
>> The The SRW208 are just there to put some equipment that doesn't 
>> speak vlan onto the right vlans, so they couldn't affect the groups 
>> of subscriber modules.
>>     
>
> *nod*
>
>   
>> The exact same customers exhibit the exact same problem when I add, 
>> say in.4 to the bridge.  Again, I haven't actually enabled vlan4 on 
>> anything but the linux box.  APs and SMs only have vlans 1 and 2 
>> configured.  BackHauls do not even understand vlans at all, they're 
>> just ethernet bridges.  Yet when I add in.4 or in.3 to the bridge, my 
>> phone rings.
>>     
>
> <Heavy Sigh>  (Obviously)  Something is wrong here.
>
> Do you have another physical interface in your Linux bridge?  I'm 
> starting to wonder if there is not something odd about the configuration 
> that you have (unintentionally) not portrayed.  If you have another 
> interface other than in and out, try adding it (say eth2) to the bridge.
>   
There is one, but it is currently being used to speak to some other 
equipment. I'll have to schedule some downtime to test that. Basically, 
you just want to know if the problem shows up as soon as I ad anything 
else to the bridge? Back when I had the 'smarter' switch inbetween the 
linux box and the customer network, I could add an extra vlan to the 
bridge without any problems so long as that vlan was not configured on 
the ports to the customer network.

I've run the system for days having 'out', 'in.2' and 'in.3' on the 
bridge without any problems, but the trunk port on the SRW2024 to the 
Linux box only passed vlan 2 tagged packets. I guess this is starting to 
sound like it's some equipment between the customer and the linux box 
being buggy, which I was hoping to be the switch :(
>> Doing a 'tcpdump -i in.2 -n ether host <mac-of-customer>' shows me a 
>> string of arp requests and replies for the gateway but practically no 
>> other traffic.  Then, I 'brctl delif br0 in.4' and traffic 
>> instantaneously flows, and the customer says their internet is back.
>>     
>
> Is Spanning Tree (Protocol) (a.k.a. STP) turned on on br0?  I feel like 
> there is something else going on here.
>
>   
No, that was my first thought when I noticed the problem too. I disabled 
STP everywhere actually, and our radios do not support STP. In fact, 
here's what the manufacturer states about them:

Radios support VLAN functionality as defined in the 802.1Q 
specification, except for the following aspects of that specification:
◦ the following protocols:
− GARP GARV
− STP
− MSTP
− GARP GMRP
◦ priority encoding (802.1P)
◦ embedded source routing (ERIF) in the 802.1Q header
◦ multicast pruning
◦ flooding unknown unicast frames in the downlink
As an additional exception, the AP does not flood downward the unknown
unicast frames to the SM.

That last line has me curious, but if the bridge and vlan interfaces 
function properly, the ARP replies should be properly tagged before they 
get sent out to the SM.

Also of note that I forgot to mention above: The customer gets their 
internet back the moment I remove the extra vlan interface from the 
bridge, *but* if I re-add it immediately after, their traffic keeps on 
flowing... So I'm assuming this issue is mostly ARP related. A bug that 
prevents the bridge from learning new MACs in this situation maybe?
>> I'll have other customers happily surfing away through the whole 
>> process, this only affects some of them.  I've noticed no 
>> similarities in MAC addresses, and they all run on identical 
>> equipment to that of working customers (same firmware, etc.)
>>     
>
> Do your tests reliable / predictably effect the same customers?  Are you 
> sure that there is not any thing on the customers equipment that is 
> messing with things?  If you provided the customer equipment (part of 
> your service agreement?) can you trade out the equipment for testing and 
> / or an ""upgrade to facilitate growth of the network?
>   
I've identified a group of about 5 customers whom I can reliably assume 
to be affected. Given the nature and size of our service, I'd suspect 
the actual number to be a fair bit larger. 99% of our customers either 
have home routers (d-link, linksys, etc) or are hooked directly from the 
ethernet jack of their PC. Basically, we don't get much control past the 
cable that comes out of their SM.
>   
>> Since I'm only using plain switches now, I can't easily 'sniff' 
>> traffic beyond the linux box until I build myself some sort of 
>> portable little bridge box that I could place at different points on 
>> the network, so if you guys have any other ideas, please share.
>>     
>
> A simple hub and a notebook with a single ethernet card and TCPDump will 
> suffice just fine for testing.  Disconnect a cable between two pieces of 
> equipment, connect said cable in to a hub, connect the hub to where the 
> cable was originally connected.  Plug your notebook in to the hub and 
> sniff away.
>   
Heh, silly me... I guess I'm too young to remember that hubs do exist! 
I'll have to find one first though ;) And some sort of little linux box 
that won't trim VLAN tags (WRT54G routers do for some reason) that I 
could put in the somewhat remote and computer nerd-hostile environments 
inbetween my linux box and customers. This is not a problem I'm too keen 
on solving at -20C while standing on a stepladder, laptop in hand in the 
middle of the great Canadian woods with coyotes gnawing at my boots... 
Not if I don't win that sysadmin of the year contest! ;)

(okay, I dramatized a bit there)

Jonathan


-------------------------------------------------------------------------
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/
_______________________________________________
Ebtables-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ebtables-user