Hi Pranjal, Sorry for the delay. I've been away, see answer below. Pranjal Kumar Dutta wrote: > Hi Alex, > Thanks for the explanation. Now its pretty much clear > to me. I hope rest I can extract from the codes. Please refer inline. > > Regards, > Pranjal > > > On 5/19/06, *Alex Zeffertt* <ajz@xxxxxxxxxxxxxxxxxxxxxx > <mailto:ajz@xxxxxxxxxxxxxxxxxxxxxx>> wrote: > > Pranjal Kumar Dutta wrote: > > Hi Alex, > > Thanks for the reply. Please see my answers inline. > > > > Regards, > > Pranjal > > > > On 5/19/06, Alex Zeffertt <ajz@xxxxxxxxxxxxxxxxxxxxxx > <mailto:ajz@xxxxxxxxxxxxxxxxxxxxxx> > > <mailto: ajz@xxxxxxxxxxxxxxxxxxxxxx > <mailto:ajz@xxxxxxxxxxxxxxxxxxxxxx>>> wrote: > > > Pranjal Kumar Dutta wrote: > > > > Hi, > > > > I have some problems in understanding some parts > of the > > > > (802.1q )vlan module in linux kernel and its interaction > with linux > > > > bridging code. > > > > > > > > I have the following problems in understanding the codes. > > > > > > > > 1. In linux 802.1q code a vlan is characterised as a generic > > > > net_device. Every real net_device (Ethernet NICs e.g) has a > vlan_group > > > > attached to it to identify the port's membership of vlans. A > > > > vlan_group contains an array of pointers to all vlan_devices > (in the > > > > form of net_devices) to which the real device is member of. > As per my > > > > understanding goes here whenever a vlan is attached to an > interface > > > > the following is called. > > > > > > > > static struct net_device *register_vlan_device(const char > *eth_IF_name, > > > > > > > > unsigned short VLAN_ID) > > > > Inside this function I could see that a new net_device is > created for > > > > the corresponding vlan attched to it. So that means a VLAN > domain in > > > > the box is NOT represented by a single net_device, rather it is > > > > interface specific. For the same vlan X every interface will > be having > > > > its own net_device for X in its vlan_group. Then how the > vlan layer > > > > glues all the vlan_devices > > > > (in the form of net_devices) for a particular vlan X into a > domain? > > > > Because theoretically speaking while bridging ethernet flows MAC > > > > Learning and forwarding should be based on vlan domains. > > > > > > > > > > I'm not sure I understand your question fully, but I think > this info may > > > be helpful: > > > > > > When 8021q.o is isnmodded it calls > > > > > > dev_add_pack(&vlan_packet_type); > > > > > > which registers the function vlan_skb_recv() as a handler for > the vlan > > > dix type, namely 0x8100. > > > > > > The code in net/core/dev.c which dequeues frames - queued by > device > > > drivers using netif_rx() - uses a hash table to find the > handler for > > > each frame by dix type. After 8021q.o is insmodded > net/core/dev.c will > > > send all frames with dix type 0x8100 to vlan_skb_recv(). > > > > > > vlan_skb_recv() checks to see if the originating device ( e.g. > eth0) has > > > a vlan device with the correct vid on top of it ( e.g. > eth0.10). If it > > > has then it passes the frame up through this device (i.e. changes > > > skb->dev, rearranges the header if neccessary, and calls > netif_rx()). > > > If not, it frees the skb and returns a failure code. > > [Pranjal] : I undestand the above part. here vlan modules registers a > > packet-type with dev layer so that it vlan_skb_recv function will > get > > called when packet type matches at dev layer. > > My confusion is what happens within vlan_skb_recv()? If the box is > > configured for vlan based switching/bridging then further MACs on the > > skb should be learned and forwarded to other ports in the SAME > vlan. But > > I couldn't come across any learning process in the vlan module. > However > > I am finding some code in bridge netfilter (ebtables) where bridge > > module interacts with vlan, but I am not clear about it. I am not > clear > > about how the bridge and vlan modules interact with each other. > Because > > in bridge module in net_bridge_fdb_entry I couldn't see any vlan > info ( > > Pls refer to > http://lxr.linux.no/source/net/bridge/br_private.h#L45 ). > > So I am confused about how vlan specific MAC > learning/forwarding takes > > place. > > > > > Consider this hypothetical bridge > > +---------------------------------+ > | br0 | > +------+--------+--------+--------+ > | eth0 | eth1.5 | eth2.5 | eth2.6 | > +------+--------+--------+--------+ > | eth1 | eth2 | > +--------+--------+--------+ > > > br0 will treat all its interfaces the same, whether they are ethernet > devices (like eth0) or vlan devices (like eth1.5, eth2.5, eth2.6). > > The reason there is no mention of vlans in the bridging code is the > vlan > module implements a net_device in just like an ethernet device driver > does, and the bridge module does not need to know that how the > net_devices under it are implemented. > > > [Pranjal] Understood, so that means when vlans ports (et.2.5..) are > added to bridge the net_bridge will point to the net_device of the vlan > , not the > physical net_device. So when a MAC is learnt it will be associated with > thet vlan device (that is the br_fdb_entry->net_device). > > Frames sent down eth0 by this bridge have their vlan headers stripped. > Frames bridged from eth0 have a vlan header added. > Frames bridged between eth1.5 and eth2.5 are not changed. > Frames sent between eth2.5 and eth2.6 have their VIDs swapped. > > [Pranjal] et.2.5 is in vlan 5 and at.2.6 is in vlan 6, then why the > frames from vlan 5(et.2.5) will be sent to vlan 6 (et.2.6) ? Ecah vlan > is in their own broadcast domain right? Pls let me know if I am missing > something. > In linux each bridge device (br0, br1, etc.) is a broadcast domain. If you want to have vlan 5 and 6 in seperate broadcast domains you need two bridges, like this: +---------------------+---------------------+ | br0 | br1 | +--------+------------+---------------------+ | eth1.5 | eth2.5 | eth2.6 | +--------+------------+---------------------+ | eth1 | eth2 | +--------+----------------------------------+ It there is only one bridge there will be only one broadcast domain, and tags will be stripped going up the stack and (possibly different) tags added going down the stack. Alex > > The bridge will get confused if it sees the same source MAC address > arrive on two of its ports. Therefore, although you may trunk multiple > vlans between two bridges (as with eth2), each host on your network > should only exist on one vlan. > > HTH, > > Alex > > _______________________________________________ > Vlan mailing list > Vlan@xxxxxxxxxxxxxxx <mailto:Vlan@xxxxxxxxxxxxxxx> > http://www.lanforge.com/mailman/listinfo/vlan > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Vlan mailing list > Vlan@xxxxxxxxxxxxxxx > http://www.lanforge.com/mailman/listinfo/vlan
