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

[Eric Gray (LO/EUS)]

Radia,

	There is an interesting problem that might arise out of
a router receiving VLAN tagged frames without being aware that
they are tagged.  

	A router is a MAC termination point - i.e. - it is an 
end-station at the MAC layer.  But it is also a forwarding
device.  Hence the slack that might apply to a host receiving
a MAC frame with "stuff" in the header it doesn't understand,
shouldn't be allowed for a router.

	Also, many routers do understand that it is possible to
have the same IP subnet connected to multiple logical interfaces.
That was where the original "Bridging Router" (or BRouter) came
from.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Monday, April 02, 2007 4:10 PM
> To: Eric Gray (LO/EUS)
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> Importance: High
> 
> My understanding is that shared VLANs assume
> IP routers are not aware of VLANs.
> 
> My understanding is that the way it would work if the IP 
> router R *was* 
> aware of
> VLANs, is that R would treat the link as 4 separate links (by using 
> VLANs), and then the IP addresses
> on the 4 different links (VLANs A, B, C, and D) would have to have 
> different IP prefixes.
> 
> So therefore, I am assuming that the IP router is not 
> supposed to know 
> that the link is subdivided into VLANs.
> 
> So my understanding of the problem in this case is:
> 
> a) single IP address block shared by different communities
> b) desire to isolate these communities from layer 2 broadcast traffic 
> from each other
> c) desire to share some services (like DHCP and IP routers), without 
> those services being aware
> that the communities are separate
> 
> As for my question about proxy ARP, to further add
> to the confusion -- some people are assuming the 
> bridge/RBridge will be 
> doing
> the proxy ARP, and some others are assuming the router is.
> 
> And actually, after talking offline with Joel Halpern, I'll 
> send another 
> note with two different proposals
> (one just a cleanup of what I originally wrote, and the other a 
> different approach) for solving
> that vaguely stated problem.
> 
> Radia
> 
> 
> 
> 
> 
> Eric Gray (LO/EUS) wrote:
> 
> >Radia,
> >
> >	Let me try to re-state your explanation to see if I understand 
> >it...
> >
> >	You believe that the problem that shared VLAN learning is used
> >to solve is conservation of IP addresses used in a single IP subnet, 
> >and that it is necessary to use shared VLAN learning to keep routers 
> >(in the subnet) from having to re-learn MAC+IP associations across a
> >set of VLANs in that same IP subnet, is that correct?
> >
> >Thanks!
> >
> >--
> >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
> >>
> >>    
> >>
> 
>