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