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> 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>> 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.
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
> http://www.lanforge.com/mailman/listinfo/vlan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns2.lanforge.com/pipermail/vlan/attachments/20060519/352696cd/attachment-0001.html
