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

[Silvano Gai]

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