Re: bridged vlan interfaces

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?

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

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

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

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

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



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/