Hi Alex,
Thanks for the reply. Please see my answers inline.
Regards,
Pranjal
On 5/19/06, Alex Zeffertt <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.
>
> 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/9012c942/attachment.html
