Google
  Web www.spinics.net

[VLAN] Newbiew question: Need some clarifications in 802.1q and bridging code interaction in linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

[Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]     [Linux Resources]

Powered by Linux