Hi Alex,
Thank you very much for the clarification. Generally in
commercial multi-layer switches by bridging we mean the entity is capable of
separating the vlan domains and does switching within specific the vlan
domain. So I got the confusion. In Linux implememtation a bridge means a
broadcast domain, so for example if I need to support all 4096 vlans then I
need to create 4096 bridging entities and attach the specific subports like
eth01.2, eth01.3 etc to bridge for that vlan. So the forwarding rules of
bridge (br_handle_frame) needn't take care of vlan encapsulation if any as
vlan tags (packet type 0x8100) will be processed before bridging code
analyzes it and vlan layer will pass the sk_buff to the specific bridge
that is attached to that vlan subport (ethx.y). Am I right?
Thanks,
Pranjal
On 6/5/06, Alex Zeffertt <ajz@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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
>
> _______________________________________________
> Vlan mailing list
> Vlan@xxxxxxxxxxxxxxxxxxx
> http://www.candelatech.com/mailman/listinfo/vlan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns2.lanforge.com/pipermail/vlan/attachments/20060605/048d2525/attachment.html
