[rbridge] Shared VLAN learning: What is it and why should wecare?

[Eric Gray (LO/EUS)]

Silvano,

	Possibly this was meant as a reply to a different message?

	If you look at the text below, one of my early paragraphs
(the one that starts "In one case, there may be a VLAN aware bridge 
between the IP router and the 4 VLANs ...") is nearly identical to
the illustration you describe.  So, I think we can assume we're at
least talking about the same thing.

	Which leaves me wondering what your point is...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Monday, April 02, 2007 5:45 PM
> To: Eric Gray (LO/EUS); Radia Perlman
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Shared VLAN learning: What is it and 
> why should wecare?
> 
> 
> Eric,
> 
> Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs.
> In figure B-4 assume a router instead of the Server.
> As you can see the link between the router and the Bridge is untagged.
> Being the link untagged the router will have a single sub-interface
> associated to a single IP subnet.
> 
> Nonetheless it will be on the Red, Blue and Purple Asymmetric 
> (Private)
> VLANs. The frames received by the router will be legal IP frames.
> 
> I don't know if we are in agreement, but this is the most pertinent
> example I am able to come out with.
> 
> -- Silvano
> 
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
> > Behalf Of Eric Gray (LO/EUS)
> > Sent: Monday, April 02, 2007 2:08 PM
> > To: Radia Perlman
> > Cc: rbridge at postel.org
> > Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should
> > wecare?
> > 
> > Radia,
> > 
> > 	WRT your quiz question:
> > 
> > 	To expand on Sanjay's earlier reply (assuming I've understood
> > your questions correctly), you've assumed an essentially broken IP
> > subnet configuration.  That doesn't mean that it wouldn't work with
> > today's devices, but it does mean that it is not working the way I
> > believe you have described it.
> > 
> > 	Sanjay is correct about ARP as a function of the IP router.  A
> > "smart bridge" may incorporate enough of the routing 
> function to help
> > out in this scenario, but is not a standards defined implementation
> > if it does.  There is a fairly long list of caveats that must apply
> > in that case, and this is not an area we want to explore - unless it
> > turns out to be the case that someone does this incorrectly and we
> > find that we need to be compatible with the incorrect 
> implementation.
> > 
> > 	In one case, there may be a VLAN aware bridge between the IP
> > router and the 4 VLANs you describe.  In implementations, this VLAN
> > aware bridge may actually be co-located with the IP router.  In this
> > case, the VLAN aware bridge may very well forward un-tagged 
> frames to
> > and from the (potentially co-located) IP router, across one 
> (possibly
> > logical) link, allowing the router to enjoy simplified ARP learning.
> > This VLAN aware bridge then provides the VLAN translation 
> function to
> > allow proper forwarding of data within the subnet.
> > 
> > 	Note that - in this case - the VLAN aware bridge is translating
> > untagged frames into tagged frames (and vice versa), but is 
> not doing
> > the similar translation (one tag to another) between distinct tagged
> > VLANs.  That function must be done by a router - hence the router is
> > supposed to handle ARP responses and associate IP-to-MAC so 
> that it is
> > in the forwarding path (much as Sanjay described).
> > 
> > 	Because you're assuming over-lapping assignments of IP
> > addresses,
> > this scenario causes problems for a standards defined IP router
> because
> > it will see all of the subnet-local IP destinations as 
> being part of a
> > single IP subnet, and will - most likely - try to force the 
> senders in
> > the IP sub-network to send directly to destination MAC 
> addresses - via
> > ARP responses (assuming single subnet) and IP re-directs.
> > 
> > 	As you probably realize, that situation would be pathological.
> > 
> > 	This situation arises in real networks, and has been addressed
> > in real implementations.  One approach blurs the distinction between
> > the VLAN aware bridging and standard routing functions.
> > 
> > 	For the co-located case, this is not hard: the router sees more
> > than one VLAN on a single physical interface, but is configured (or
> > learns) that these multiple logical interfaces are all part of the
> same
> > IP subnet.  In this case, the router is required to bridge 
> between the
> > multiple logical interfaces that are part of a single logical IP
> subnet.
> > 
> > 	An implementation may instantiate a VLAN-aware bridging instance
> > 
> > to handle this role.  In this case, the boundary between 
> bridging and
> > routing becomes blurred because the same physical device is involved
> > in both - making the handling of ARP and appropriate VLAN forwarding
> > work because the router can carefully choose which role it 
> assumes in
> > dealing with ARP and forwarding of traffic.  If this takes 
> place in a
> > single device, it is possible to avoid many of the caveats 
> that would
> > apply if this particular form of cheating was distributed.
> > 
> > 	In the non-colocated case, a bit more work is required to make
> > the scenario functional and a number of caveats cannot be completely
> > avoided.  For example, if there is exactly one VLAN aware bridge in
> > the local IP-subnet, it is possible for that bridge to "proxy" ARP
> > responses (as if it were a router) and forward frames between VLANs.
> > If there are multiple VLAN aware bridges, then it should be possible
> > to configure them so that only one of them performs this function.
> > A more complex configuration is possible, but such a 
> configuration is
> > workable only if there is no potential forwarding path 
> (including any
> > possible failure mode) which results in multiple VLAN ID 
> translations
> > - and forwarding - between multiple VLAN aware bridges, in a loop.
> > 
> > 	For RBridges, the situation we need to avoid is as shown below:
> > 
> >                  Host Group-P
> >                     A
> >                     |
> >              _____VLAN-A______
> >             |                 |
> >             V                 V
> >    R <---> VAB <--VLAN-B--> RBridge CRED/Campus <--VLAN-B--> Host
> >                                                             Group Q
> > 
> > 	If both the RBridges and the VLAN aware Bridge (VAB) are doing
> > Proxy ARP - and VLAN ID translation (cross-VLAN forwarding) - it is
> > possible for frames to be forwarded consistently back and forth
> between
> > the RBridge CRED/Campus and VAB.  Moreover, it is possible 
> for a host
> > in group P in this diagram, to get a copy of each frame each time it
> > goes around.
> > 
> > 	Still another alternative is that IP addresses are not assigned
> > as you suggest, and VLAN tags are used simply to share physical link
> > resources - while maintaining IP address space separation.  Many of
> > the router vendors today (I believe) would claim that the 
> alternative
> > is pathological...
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> > 
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org
> > > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> > > Sent: Thursday, March 29, 2007 2:56 AM
> > > To: rbridge at postel.org
> > > Subject: [rbridge] Shared VLAN learning: What is it and why
> > > should we care?
> > >
> > > Hopefully this explanation will be clear enough for people to
> > > at least
> > > figure out whether we
> > > are all talking about the same thing. Of course, feel free to
> > > correct me
> > > if my understanding is wrong.
> > >
> > > First we need to understand what problem it is trying to
> > > solve. This is
> > > my understanding of that:
> > >
> > > THE PROBLEM
> > > ------------------
> > >
> > > Someone has a block of IP addresses to divvy up among
> > > a set of different organizations. Let's say the address block has
> > > 100 addresses, and there are 4 organizations. One 
> strategy might be
> > > to give each organization 1/4 of the IP addresses each, and then
> > > possibly even
> > > wind up having separate IP subnets (if the addresses can 
> be assigned
> > > to be in different prefixes).
> > >
> > > The problem, though, is that you don't know in advance how
> > > many addresses
> > > each organization will need. Perhaps even the IP address block is
> > > oversubscribed,
> > > so that there are more potential switch ports than IP
> > > addresses, and you
> > > just hope that not everyone connects at once (or if they do,
> > > they don't
> > > get an IP address).
> > >
> > > So we're going to allow basically random assignment of IP 
> addresses
> > > within the IP address block to each of the four organizations.
> > >
> > > But you still want to keep the organizations separate, as in,
> > > they don't
> > > see each other's traffic. They
> > > don't get bothered with each other's ARPs and so forth. And you
> don't
> > > want to change the IP nodes
> > > (endnodes or routers)
> > > to know anything funny is going on.
> > >
> > > So you use VLANs to separate the communities. A particular port
> > > on a switch/bridge in a L2 cloud
> > > is configured as to what community the attached endnode 
> belongs to,
> by
> > > having it configured with a VLAN ID.
> > >
> > > But you'd like all the IP nodes in the cloud, even though in
> different
> > > communities, to share the same IP router, also possibly other
> > > services such
> > > as the DHCP server. And we don't want the IP router
> > > to have to know about the different communities. The IP 
> router just
> > > thinks the cloud is one big happy can't-we-all-just-get-along
> > > IP subnet.
> > >
> > > But the bridges inside the L2 cloud have to somehow do two things:
> > > a) enforce some sort of separation between the communities, and
> > > b) allow them all to talk to the IP router.
> > >
> > > So this is how they are doing this. Assign each of the 4
> > > communities a
> > > VLAN ID, say
> > > VLANs A, B, C, and D. Now what VLAN ID should the IP router
> > > belong to?
> > > You want it
> > > to be able to talk to nodes in any of the VLANs {A, B, C, or D}.
> > >
> > > The way this is done is to declare a VLAN group known as a
> > > FID (filtering
> > > ID for those that want to see an acronym expanded -- 
> personally, the
> > > expansion of that acronym didn't help me understand what 
> a FID is).
> > > So a FID is a group of VLAN IDs, say Z, A, B, C, D, with one
> > > of the IDs,
> > > say Z, being the "primary". The IP router that serves all the
> > > communities
> > > (in this case, A, B, C, D) will be assigned to the "primary" VLAN,
> in
> > > this case, Z. Endnodes
> > > will be in one of {A, B, C, D}. IP routers serving these
> > > communities will
> > > be assigned VLAN Z.
> > >
> > > To clarify, if there are n communities, there will be n+1 
> VLANs, one
> > > for each of the communities, and one for the IP router(s) serving
> > > the communities in that IP subnet.
> > >
> > > Switches are configured to know that {Z, A, B, C, D} is a special
> > > grouping of VLANs, such
> > > that something transmitted from a VLAN Z port goes to all
> > > ports in the
> > > group, i.e., all ports in
> > > Z, A, B, C, and D. However, something transmitted from a 
> VLAN A port
> > > goes only to ports in
> > > VLAN A and VLAN Z. Something from VLAN B goes to ports in
> > > VLAN B and VLAN Z.
> > >
> > > *************
> > > Now a little quiz...
> > >
> > > For those of you that are following-- and in case I actually have
> > > captured the concept,
> > > let me ask a question.
> > >
> > > How do two endnodes in the IP subnet talk to each other?
> > > The first case is two endnodes in VLAN A, say S and D.
> > > S, observing that D is in the same subnet, will ARP. Since D
> > > is in the
> > > same VLAN, it will receive
> > > the ARP request, and respond. Everything works fine.
> > >
> > > But how do two endnodes in different VLANs, but in the same
> > > IP address
> > > block communicate? S will
> > > ARP, like before, because IP nodes are (blissfully) unaware of
> VLANs.
> > > The answer people tell me
> > > is "in that case communication between S and D has to go
> > > through the IP
> > > router". OK. So how would
> > > that work? The
> > > answer I get is "the switch does proxy ARP on behalf of the
> > > IP router".
> > > I don't understand that. How does the
> > > switch know *when* to proxy ARP? The switch doesn't 
> necessarily know
> > > which VLAN node D is in.
> > >
> > > *******************
> > > Well, bravely continuing on...
> > >
> > >
> > >
> > > Endnode MAC address learning is done by VLAN as before. If a frame
> is
> > > received by bridge b on
> > > port p, with source S, from VLAN A, then bridge b 
> remembers that {S,
> > > VLAN A} is on port p.
> > >
> > > Furthermore, a Z-tagged unicast frame is checked against the
> learning
> > > tables of Z, A, B, C, D, to determine where to forward it. So
> > > if bridge
> > > b receives
> > > a frame with
> > > destination=D, bridge b checks for D in any of the VLANs Z,
> > > A, B, C, D, and
> > > forwards accordingly.
> > >
> > >
> > >
> > > &&&&&&&&&&&&&&&&&
> > > So, that's how bridges work (I hope). So how would we support this
> > > functionality in
> > > RBridges?
> > >
> > > As it turns out, despite the complexity of the concept,
> > > it will not be that difficult to support this with RBridges, and
> > > even in a somewhat more optimal way, since RBridges can 
> do multicast
> > > filtering within the core rather that just at the final port.
> > >
> > > RBridges, like bridges, would have to be configured with 
> FIDs, i.e.,
> > > VLAN groupings as described above.
> > >
> > > Let's call a FID by the name of the "primary" VLAN; in 
> our example,
> Z.
> > >
> > > RB1 would be configured that FID Z = {Z, A,B,C, D}, where Z,
> > > A, B, C, D are
> > > all 12-bit VLAN IDs.
> > >
> > > To avoid requiring configuration of all RBridges with these FIDs,
> and
> > > still allow multicast filtering, I propose we have RBridges
> advertise,
> > > in their IS-IS core instance, FIDs that they are configured
> > > with. So at
> > > least one RBridge will say "Hey guys,
> > > I think VLANs Z, A, B, C, and D form a FID with primary=Z"
> > > and the other
> > > RBridges will, I guess
> > > believe him.
> > >
> > > What to do if RB1 says that FID Z = {Z, A, B, C, D}, and RB2 says
> that
> > > FID Z = {Z,A,D, F} is an interesting question, but at 
> least there is
> > > enough information to log an error. Lot of possibilities for
> > > overlapping
> > > FIDs, inconsistent FIDs, etc.
> > > I assume all those will be errors. If there is a FID called "Z",
> then
> > > everyone better agree about what the
> > > VLAN membership of Z is, and none of the VLANs in Z 
> better be in any
> > > other FIDs.
> > >
> > > Once there is a FID of {Z, A, B, C, D}, there will no longer be
> > > a VLAN-A instance of IS-IS, or a VLAN-B instance of IS-IS, or C or
> D.
> > > Instead
> > > the Z-instance will announce VLANs A, B, C, and D membership
> > > as well as
> > > VLAN Z membership.
> > >
> > > The Z-instance of IS-IS will specify which MAC addresses are
> > > in which VLAN.
> > > So, RB1 might announce, in the Z-instance, {Z; a, b, q, d, f},
> > > {A; r, n, j}, {B; c, p, o, h}, {C; m,l}, {D;g, x, k}. The 
> lower case
> > > letters are endnode MAC
> > > addresses. The upper case letters are 12-bit VLAN IDs.
> > >
> > > Multicast packets marked as VLAN Z (inner VLAN) will be sent to
> > > all links in Z, A, B, C, or D. So the LSPs in the VLAN Z 
> instance of
> > > IS-IS will
> > > be delivered to all RBridges in Z, A, B, C, and D.
> > >
> > > That way RBridges with ports in Z, A, B, C, and/or D will
> > > learn all the
> > > endnode addresses
> > > in any of those VLANs (all the ports in FID Z).
> > >
> > > If ingress RB1 is attached to Z, and receives a packet with
> > > destination D tagged as Z, RB1 checks for D in VLANs A, B, C,
> > > D, and Z
> > > 's endnode
> > > membership. As soon as RB1 finds it, let's say, as reported by
> > > RB2 as being in VLAN D, RB1 tunnels the packet in TRILL to RB2,
> > > leaving the tag as Z. When RB2 decapsulates the packet, I
> > > assume it will
> > > rewrite the inner VLAN tag from "Z" to "D".
> > >
> > >
> > > &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
> > > Conclusions:
> > >
> > > The changes to the spec:
> > >
> > > a) announce in the core instance, FIDs as a set of VLANs, the
> > > first listed being the "primary".
> > >
> > > b) multicast forwarding: if the packet is (inner) tagged with
> > > the VLAN ID of a primary VLAN in a FID, forward the packet on
> > > all in the links in the selected tree that lead to any of 
> the VLANs
> > > in the FID. If the packet is tagged with the VLAN ID of a
> non-primary
> > > VLAN in a FID, forward the packet on all the ports that reach
> > > links in either that VLAN or in the primary VLAN for that FID.
> > >
> > > c) when ingressing a packet with destination D, tagged with a
> > > VLAN tag of a primary VLAN in a FID, check the endnode information
> > > for all the VLANs in the FID to determine the egress RBridge.
> > >
> > > d) when ingressing a packet with destination D, tagged with
> > > a VLAN tag of a secondary VLAN in a FID, check the endnode
> > > information for exactly two VLANs; the one the packet is
> > > currently tagged with, and the primary VLAN for that FID, to
> > > determine the egress RBridge.
> > >
> > > e) if two RBridges, in the core instance, report inconsistent FID
> > > membership, what should we do?
> > >
> > > (Note: There was a fortune cookie program in Unix, one of the
> > > fortunes
> > > being "Never check for an error
> > > condition that you don't know how to handle". For the record--I
> think
> > > that's a cute joke but really bad policy.).
> > >
> > > Radia
> > >
> > >
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > rbridge at postel.org
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
>