Re: 802.1Q + Briding + one NIC (or one LAN)

Jesse Gordon wrote:
> Grant: Many thanks for your insightful response.

You are welcome.

> I was a little confused by your suggestion (last large paragraph.)
> Due to my own lack of knowledge, some of your suggestion seemed ambiguous.

If the problem (or it's root cause) that you are running in to is the fact that you are having both (802.1Q) tagged traffic and untagged traffic on the same port is confusing equipment I think you need to get either all tagged or all untagged traffic on any given port.  To do this you will need to establish trunks between all pieces of equipment that can support it.  For the equipment that does not support tagging you will need to configure the port that it is plugged in to as a member of a given VLAN.   The traffic entering or leaving said port will have to be untagged to speak to the equipment that does not support VLANs natively.  If all your ""core equipment (all the inside switches from one end of your network to the other) are VLAN capable I would configure them as such, or at the vary least as having trunk connections to equipment to the VLAN capable equipment that connects to it.
 

As far as having a VLAN dedicated to your default untagged network goes, set aside a VLAN that you will use to pass what is ultimately untagged traffic in to your VLAN capable equipment.  This way you can have a VLAN interface on your Linux Bridge that is for this ""untagged traffic as well as the VLAN interfaces for all your tagged traffic.  You can then establish a bridge with all the VLAN interfaces as members and you will not be having tagged and untagged traffic appearing on the same port of various equipment.

> I think you were suggestion that I do this:
> 
> ifconfig eth0 0
> vconfig add eth0 1
> vconfig add eth0 3 (changed 2 to 3)
> brctl addbr br0
> brctl addif br0 vlan1
> brctl addif br0 vlan3
> 
> Did I understand correctly?
> In theory, this would bridge together vlan3 and vlan1 which we suppose 
> to be the same as non-trunked traffic.
> (since vlan1 is the default vlan.)

*nod*  This is what my idea was.

> This probably won't work because cisco catalyst 2950 series (and 
> probably all cisco) do not allow vlan1 to trunk.

Hmm, I was not aware of that fact.

> But I'll try that anyway and let you know how it works out.

I have seen that Cisco is picky about VID 1 in the past but I did not think about this as I can use VID 1 on HP ProCurves any way that I want to.

> Of course, this just dawned on me: "I could change all of the ports 
> assigned to vlan1 to 10 or something, then use that as my "default" 
> vlan. Then the linux box could access the non trunked data through 
> vlan10, and trunks through other vlan devices."
> 
> (This brings up another problem: It seems that our cat 2950 won't pass 
> tagged frames for vlans with which it's not associated. In other words, 
> if you're trunking between two cat 2950s, don't ask them to do so while 
> passing trunk data through another uninvolved cat 2950...)

Well my gut reaction is involve the middle cat 2950.  My other solution would be to see if the CDP protocol could be of any help here to at least make the middle cat aware of the VLANs and let them pass.  If not then just add the VLANs to all the cats.

> Everybody:
> 
> I did try "vconfig add eth0 3" and it creates a vlan3 but the trunk 
> doesn't pass any data.
> However, this works:

Did you bring up vlan3 unnumbered?  I think you can add an interface to a bridge even if the interface is down.  Sorry for asking the obvious but I do have to ask b/c I've shot my self in the foot with this one.

> ifconfig eth0 0
> brctl addbr br0
> brctl addif eth0
> ifconfig br0 10.0.0.155
> vconfig add br0 3
> 
> That creates a vlan3, and using
> ping 10.0.0.4 -I vlan3
> I can indeed ping 10.0.0.4 which is plugged into the catalyst 2950 on a 
> port assigned to vlan3.
> (If I add vlan3 to eth0 I can't ping it if eth0 belongs to a bridge.)

Hmm.  I could see how you could have a VLAN interface on top of a bridge that would ultimately send the traffic out eth0 which I'm going to presume was connected to a switch to allow trunking on the port that eth0 is connected to.  Am I correct?

> Now so far, this is what I want: To be able to have one NIC in the linux 
> box, carrying both the trunked data and non trunked.

I don't know if you will be able to do this with your switches in the configuration they are in.

> But when I then type:
> brctl addif br0 vlan3
> dmesg fills up with errors about dead loops on virtual device vlan3 -- 
> even with nothing plugged into the linux box's NIC.

What other interfaces were configured as members of the bridge?

> On another note, I found that one of our cat 2950 series happily allows 
> trunked and non trunked data on same port
> (The port can be set to trunk, trunk desirable, and static access among 
> others) while our other cat 2950 just doesn't allow any non trunked data 
> on a port set to trunk (and the settings do not include 'trunk 
> desirable,').
> (By Happily, nothing showed up in the log except notices when ports 
> changed from up to down and the like.)
> (The two switches are slightly different, and most importantly probably 
> have different versions of IOS.)

This could indeed be part of the problem.  I'm betting the switch that will not do "trunk desirable" is an older version of IOS.  I know that it is not exactly legal, but could you upgrade the IOS on the switches that have an older version by copying it from a switch with a newer version?

> I suspect that the solution to my problem if trunking and vlanning all 
> on one LAN lies in ebtables and two NICs.
> 
> Doing it with one NIC would be fine, but it may not be possible to 
> prevent with ebtables rules that entirely internal "dead loop."

I think you *SHOULD* be able to do it with one NIC.

> But lets say I have two NICs:
> 
> ifconfig eth0 0
> brctl addbr br0
> brctl addif br0 eth0
> ifconfig br0 10.0.0.155
> ifconfig eth1 0
> vconfig add eth1 3
> brctl addif br0 vlan3
> 
> Then I could plug both ethernet cards into the same LAN. Of course Linux 
> will complain about receiving packets from it's own address. (And packet 
> loops could also slow down the network.)

I would check to see why the loops are coming in like you think they will b/c I don't think they should be.

> Would it be possible to use ebtables to prevent any trunk packets from 
> entering the eth0 non trunk port, and prevent any non trunk packets from 
> entering the eth1 trunk port?

It should be able to do so.  I think you might have to look for trunk packets and watch for specific MAC addresses and filter them.  I don't know for sure.



Grant. . . .


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf