Re: bridged vlan interfaces

Grant Taylor wrote:
> On 11/20/07 09:21, Jonathan Thibault wrote:
>   
>> 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.
>>     
>
> So are you saying that if a customer has a given VLAN configured on 
> their equipment and you tried to add that VLAN to your equipment the 
> customer would go down?  Or are you saying that if you added VLAN 3210 
> to the bridge customers would still go down?
>   
Well, vlans stop at the SM, which is still our equipment.  The customers 
sees a plain ethernet wire with no vlans (the SM ethernet port is set 
'untagged only').  What I am saying is that if I add in.3 to the bridge, 
but I do not add vlan3 to the SRW2024 port connected to the bridge, I do 
not see the problem.  I guess to clarify the previous paragraph...  By 
'customer network' mean network going to the customer (between the linux 
box and the customer), not the network that belongs to the customer.
>   
>> 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 :(
>>     
>
> Right.  I'm wanting to see if the problem is bridging related or related 
> to something else.
>
>   
Okay.  And what should I plug the third nic to once it's on the bridge?  
Given that I can add another vlan interface to the bridge without 
problems, I don't think a real interface will give me much trouble 
either unless it goes to an access port for say vlan3, but it's a worthy 
test.
>> 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:
>>     
>
> *nod*
>
> If you are using STP, don't forget to turn it back on when things are 
> all said and done.
>
>   
We might eventually, but right now the network is more of a tree/star 
with few opportunities for redundancy loops.
>> 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.
>>     
>
> This sounds like a form of VLAN pruning and should not be a problem.
>
>   
>> 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.
>>     
>
> Agreed.
>
>   
>> 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?
>>     
>
> If this issue was ARP related they should not go down as soon as you add 
> the interface to the bridge in the first place as their MAC address 
> should already be in the ARP cache.  That is unless something is 
> flushing the ARP cache when you add interfaces to the bridge.  However 
> the fact that you can re-add the interface after the fact with out a 
> problem tends to fly in the face of this ARPing type issue.  On the 
> surface I agree that this looks like an ARP issue, however deeper (at 
> this moment) does not look like ARP.
>
>   
The linux bridge does not keep a table of *all* the MAC addresses on 
customer network.  It only keeps a table of the active ones.  Perhaps I 
haven't made clear that if I add the interface to the bridge *while* the 
customer has active traffic through the bridge, they do not loose net 
access.  From what I've observed the bridge table timeout on the radios 
is 25 minutes.

I haven't fully tested that, but it definitely looks that way.  I can 
schedule a test with one of them and have a definitive answer pretty 
soon.  The way I see it right now, as long as the customer has the 
gateway's MAC address in *their* ARP cache, they work, regardless of 
what vlans I have added to the bridge.
>> 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.
>>     
>
> *nod*
>
> Could you for the sake of troubleshooting put a bridging system at the 
> customers for a short while?
>   
Already looked into that.  They're all private residences so far so it's 
a diplomatic effort but I'll get to it eventually.  The SM radios have 
somewhat primitive packet capture capabilities.  I'm not entirely sure I 
set things right but fiddling with it, I only saw the ARP requests from 
the client on them, never the reply.  That could be me configuring my 
capture settings wrong though.
>> 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! ;)
>>     
>
> Eh, I say forgo the sysadmin of the year and come in second and stay 
> nice and warm.
>
>   
So far, we seem to be at a 'needs more tests' point but this has given 
me a much better idea of just what I should be testing.
>
> 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/
> _______________________________________________
> Ebtables-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
>   


-------------------------------------------------------------------------
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/