Re: bridged vlan interfaces

On 11/20/07 11:55, Jonathan Thibault wrote:
> 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.

*nod*

So if I understand you correctly, you can have as many VLAN interfaces 
on your Linux system with as many of those as you want in the bridge 
with out a problem.  The problem comes when you try to configure the 
SRW2024 with the extra VLANs?

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

Well, it sounds like you have already tested what I was wanting, adding 
another interface to the bridge.  If you still want to go forward, plug 
the NIC in to anything that will give link and bring the interface up 
(as in a spur network that has nothing on it).  If you have an ethernet 
loop back plug (1<->3, 2<->6), that will work too.

> We might eventually, but right now the network is more of a tree/star 
> with few opportunities for redundancy loops.

*nod*

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

Ok, this makes me think that this is indeed an ARP related problem.  I 
mis-took you to having meant that a client with current traffic that was 
working would stop if you made the change.

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

Based on what you said above, I agree that this probably is an ARP 
related issue and don't see much need for the test.  However if you want 
to run the test just to be sure, then by all means do so.

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

I understand and can sympathize with the politics.

The only thing I can offer is that I had an install years ago that did 
not have the trunking quite right between a Dell PowerConnect (really a 
Marvel) switch that would pass regular traffic but not DHCP requests. 
It turned out to be a problem that traffic would get tagged by the 
switch (I think) and the system would see the traffic on the raw 
interface but work with it any way despite the fact that it was tagged. 
  In short, raw traffic that is usable does not necessarily equate to 
untagged traffic.



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/