Re: vlan Q in Q - [WAS Re: Using a switch fabric to emulate multiple NICs]

Alex Zeffertt <[email protected]>
Newsgroups gmane.linux.drivers.vlan
Organization Cambridge Broadband Ltd.
Message-ID <[email protected]>
Ben wrote:
> If a packet with VID of 6 is to be transmitted on a vlan device with
> VID 7, we change the VID to match the vlan device.  This makes bridging
> work, I believe.

Hmmm, why does it do this?  This doesn't make sense to me.

Anyway, I've got Q in Q to work now but it's a complete hack and you probably won't like it much. 
I'm attaching the patch anyway in case anybody wants to look at it.

I've tested that pinging between devices terminating singly tagged frames works

    (machine1:                                 machine2)
             eth0.16   <---- ping ----> eth0.16
                 eth0                 eth0

I've also tested that pinging between devices terminating doubly tagged frames works


    (machine1:                                     machine2)
             eth0.16.5   <---- ping ----> eth0.16.5
                 eth0.16                eth0.16
                    eth0              eth0

And I've tested bridging still works in the following scenario


(machine0        machine1                                      machine2)
                     br0
  eth0 <-------  eth1 eth0.16.5  --------- ping ----------> eth0.16.5
                        eth0.16                           eth0.16
                          eth0                           eth0


I *haven't* tested how this interacts with hardware acceleration or the REORDER_HEADER flag though. 
I'm not really sure how to go about that!

The change is to simply use the real_dev's rebuild_header and hard_header, and *always*
add the 4 byte tag on transmit.

I'd appreciate any comments regarding how this should be done properly.

Alex

_______________________________________________
Vlan mailing list
[email protected]
http://www.lanforge.com/mailman/listinfo/vlan
patch-2005-07-27-vlan-q-in-q.1st-try (application/octet-stream, 1.8 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.