From Radia.Perlman at sun.com Sun Apr 1 00:02:38 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Sun, 01 Apr 2007 00:02:38 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D034B9F9F@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <460F590E.5010207@sun.com> Argh! I'm really confused. We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D), it would be forwarded by the IP router R. And that the RBridge is not doing this. Though someone could build a project that was a combined router/RBridge. But Sanjay -- I think you misunderstood my question. So let me restate it. Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D, all in the same IP subnet. The router R is in VLAN Z. The VLAN grouping is {primary=Z, secondaries = A, B, C, D}. Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a secondary in the group goes to all links in *that* secondary, plus Z. Do we all understand and agree so far? So now my question. a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged with VLAN A. The RBridges forward it to all links in A, as well as Z (the VLAN tag of the primary in the group {Z, A, B, C, D}. R, with MAC address r, responds to the ARP with a reply saying "ip-D has MAC address r". So ip-A1 and ip-D talk through R. b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which is tagged with VLAN A. The RBridges forward it to all links in A as well as Z. But now both the real target, ip-A2, as well as the router R see the ARP. If R replies, then ip-A1 and ip-A2 will be talking through R. My question was -- how does R know *not* to respond to the ARP? Or does sometimes R wind up forwarding between endnodes in the same VLAN unnecessarily and we don't care because it's not *incorrect*, it's just suboptimal? Even if R sees an ARP reply from ip-A2, I don't think R can tell what VLAN ip-A2 is in. Because the packet, once it gets to R, either doesn't have a VLAN tag on it, or the VLAN tag says Z. So...I'd really like to understand this... Radia Caitlin Bestler wrote: >rbridge-bounces at postel.org wrote: > > >>To answer your quiz: the "enhanced" proxy arp feature is to >>be supported by the router, NOT by the switch. The >>enhancement is essentially to be able to proxy arp for local >>hosts, i.e for those hosts which are on the same subnet as >>the router interface. This is the "ip local proxy arp" >>supported feature at least in Cisco implementations. >> >>This way, the L3 communication between the hosts belonging to >>different secondary vlans, is achieved *only* via the router. >>i.e. if host ip-A >>(vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops: >>mac-A --> mac-router >>mac-router --> mac-D >>I think we should preserve this behavior with rbridges. >>Changing the vlans of the packet should NOT be done by rbridges, imo. >> >>-Sanjay >> >> >> >> >> >I would agree that 'routing' between VLAN-A and VLAN-D >should only be done as a result of an explicitly created >'route', and that this is part of being a proxy ARP. > >I don't see any real problem with an RBridge doing so, >as long as it only does so based on explicit instructions >from the network administrators. It definitely must not >just assume that it is ok to forward packets between >two VLANs based upon their both using the same subnet. > >While this functionality is certainly more natural >in a router, is there any reason to forbid explicitly >delegating this task to RBridges? It could save a few >hops on the end-to-end path. > > > > From sgai at nuovasystems.com Sun Apr 1 07:53:47 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sun, 1 Apr 2007 07:53:47 -0700 Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning: What is it and why should wecare?) In-Reply-To: <460F53B1.6080103@sun.com> References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com> <460F53B1.6080103@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014673A8@nuova-ex1.hq.nuovaimpresa.com> I changed the subject because I want us to clarify one of the confusions: "It is not possible to configure an RBridge to act as a transit node for a particular VLAN". In other words: "an RBridge that does not have any port/node in VLAN A MUST act as a transit for VLAN A if other RBridges require so". This is different from IEEE 802.1Q in which you can decide which switch act as transit for which VLAN. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Saturday, March 31, 2007 11:40 PM > To: Russ White > Cc: rbridge at postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > I don't understand a lot of what's being said on this thread, and I > suspect everyone is > talking about subtly different solutions to a fairly esoteric set of > somewhat related problems (sharing > an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, > ...). As Dale Carder mentioned, > and gave us some pointers, there are several somewhat overlapping > proposals floating around the industry. > I believe there isn't a single cleanly stated problem, or a single > cleanly statable solution. > > So TRILL should do something. Whatever it is, I want to be able to > understand what it is that RBridges should do. > > But to answer Russ's questions (see at bottom of this note) -- the > current RBridge protocol > spec assumes that *all* RBridges filter based on VLAN tag. > So an RBridge in the core, even if it doesn't attach to VLAN A, knows > which other RBridges do. This > allows efficient distribution of VLAN A traffic, for instance, the IS-IS > announcements of VLAN A endnode > information. > > The reason we need to let all the RBridges know what VLANs are in a > group, say {Z, A, B, C, D}, > where Z is the primary, is so that an RBridge in > the core knows that something tagged with VLAN Z needs to be transmitted > to all links in any of the > 5 VLAN tags {Z, A, B, C, D} and something tagged with one of the > secondaries, say A, needs to go to > A and Z. > > An example -- suppose there is an IP router R on VLAN Z (the primary). > When R does an ARP for an > endnode "d" in the IP subnet, R has no idea about VLANs, and the RBridge > RB1 that R attaches to, although > RB1 might know that there's a grouping of VLANs, doesn't know which VLAN > to transmit the ARP to. > Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a > copy to each of {Z, A, B, C, D}. > > So RBridges in the core have to know to send the ARP along the > distribution tree to all ports that are > in any of the VLANs in the set. > > In theory we could ignore VLAN tags, except at the final hop, and then, > as Russ said, it > would be just an optimization for the RBridges in the core to know about > the groupings. But I still think things would be weird > if the final RBridges had inconsistent configurations of the VLAN > groupings, so I think it's a good idea to > make sure all the RBridges agree on the groupings. > > To summarize, it's good for them to agree because of three reasons: > a) we can do optimal delivery of multicasts, filtering within the core > rather than just at the final hop > b) we detect misconfiguration > c) we allow more central configuration (we don't need to configure all > the RBridges, though that's a bit > dangerous if all the RBridges that have been configured go down, since > suddenly the groupings might disappear) > > Radia > > > > As for Russ's last questions: > > >> 3. Does this have a larger impact on multicast, or smaller? > > I don't understand the question, though given that he put a smiley face > in, perhaps > it was a joke. I'm hoping that someone, tomorrow, will inform me that all > this > SVL/FID stuff was a joke... > > Radia > > > > > Russ White wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > > > > > > > > > >>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. > >> > >> > > > >I'm trying to sort through this entire thing, and I wanted to ask: > > > >1. The reason we'd want to configure this on all rbridges would be to > >optimize traffic flow? > > > >2. If 1 is true, and we didn't do the configuration on all rbridges, how > >much less efficient would the rbridge network be? > > > >3. Does this have a larger impact on multicast, or smaller? > > > >:-) > > > >Russ > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.3 (Darwin) > >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > >iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg > >DSuMdrc10XgRmx8w4PdN/f4= > >=ItDw > >-----END PGP SIGNATURE----- > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From sgai at nuovasystems.com Sun Apr 1 08:07:37 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sun, 1 Apr 2007 08:07:37 -0700 Subject: [rbridge] Other reason for Confusion (RE: Shared VLAN learning: What is it and why should wecare?) In-Reply-To: <460F53B1.6080103@sun.com> References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com> <460F53B1.6080103@sun.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014673A9@nuova-ex1.hq.nuovaimpresa.com> The other reason for confusion is that SVL exists also without Private VLANs. IVL and SVL are internal switch operation mode. Se IEEE 802.1Q-2005 Section 7.4 and the begging of Appendix B. IMHO they don't pose any particular requirement on the IP routers. Each VLAN maps to a router sub-interface, that maps to an IP subnet. SVL is used by Private VLANs, but there is much more to Private VLANs that just SVL. IEEE 802.1Q has the similar concept of Asymmetric VLANs, see EEE 802.1Q-2005 B.1.3 Asymmetric VLANs. In future posting, please clarify if what you are stating applies in general to SVL or it is specific of Private VLANs. -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Radia Perlman > Sent: Saturday, March 31, 2007 11:40 PM > To: Russ White > Cc: rbridge at postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > I don't understand a lot of what's being said on this thread, and I > suspect everyone is > talking about subtly different solutions to a fairly esoteric set of > somewhat related problems (sharing > an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, > ...). As Dale Carder mentioned, > and gave us some pointers, there are several somewhat overlapping > proposals floating around the industry. > I believe there isn't a single cleanly stated problem, or a single > cleanly statable solution. > > So TRILL should do something. Whatever it is, I want to be able to > understand what it is that RBridges should do. > > But to answer Russ's questions (see at bottom of this note) -- the > current RBridge protocol > spec assumes that *all* RBridges filter based on VLAN tag. > So an RBridge in the core, even if it doesn't attach to VLAN A, knows > which other RBridges do. This > allows efficient distribution of VLAN A traffic, for instance, the IS-IS > announcements of VLAN A endnode > information. > > The reason we need to let all the RBridges know what VLANs are in a > group, say {Z, A, B, C, D}, > where Z is the primary, is so that an RBridge in > the core knows that something tagged with VLAN Z needs to be transmitted > to all links in any of the > 5 VLAN tags {Z, A, B, C, D} and something tagged with one of the > secondaries, say A, needs to go to > A and Z. > > An example -- suppose there is an IP router R on VLAN Z (the primary). > When R does an ARP for an > endnode "d" in the IP subnet, R has no idea about VLANs, and the RBridge > RB1 that R attaches to, although > RB1 might know that there's a grouping of VLANs, doesn't know which VLAN > to transmit the ARP to. > Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a > copy to each of {Z, A, B, C, D}. > > So RBridges in the core have to know to send the ARP along the > distribution tree to all ports that are > in any of the VLANs in the set. > > In theory we could ignore VLAN tags, except at the final hop, and then, > as Russ said, it > would be just an optimization for the RBridges in the core to know about > the groupings. But I still think things would be weird > if the final RBridges had inconsistent configurations of the VLAN > groupings, so I think it's a good idea to > make sure all the RBridges agree on the groupings. > > To summarize, it's good for them to agree because of three reasons: > a) we can do optimal delivery of multicasts, filtering within the core > rather than just at the final hop > b) we detect misconfiguration > c) we allow more central configuration (we don't need to configure all > the RBridges, though that's a bit > dangerous if all the RBridges that have been configured go down, since > suddenly the groupings might disappear) > > Radia > > > > As for Russ's last questions: > > >> 3. Does this have a larger impact on multicast, or smaller? > > I don't understand the question, though given that he put a smiley face > in, perhaps > it was a joke. I'm hoping that someone, tomorrow, will inform me that all > this > SVL/FID stuff was a joke... > > Radia > > > > > Russ White wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > > > > > > > > > >>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. > >> > >> > > > >I'm trying to sort through this entire thing, and I wanted to ask: > > > >1. The reason we'd want to configure this on all rbridges would be to > >optimize traffic flow? > > > >2. If 1 is true, and we didn't do the configuration on all rbridges, how > >much less efficient would the rbridge network be? > > > >3. Does this have a larger impact on multicast, or smaller? > > > >:-) > > > >Russ > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.3 (Darwin) > >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > >iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg > >DSuMdrc10XgRmx8w4PdN/f4= > >=ItDw > >-----END PGP SIGNATURE----- > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From sgai at nuovasystems.com Sun Apr 1 08:52:37 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Sun, 1 Apr 2007 08:52:37 -0700 Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning:What is it and why should wecare?) In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2014673A8@nuova-ex1.hq.nuovaimpresa.com> References: <460B6304.3020507@sun.com> <460D54BB.1010504@cisco.com><460F53B1.6080103@sun.com> <34BDD2A93E5FD84594BB230DD6C18EA2014673A8@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014673AC@nuova-ex1.hq.nuovaimpresa.com> I said it wrong, sorry, retrying: "It is not possible to configure an RBridge to NOT act as a transit node for a particular VLAN". In other words: "an RBridge that does not have any port/node in VLAN A MUST act as a transit for VLAN A if other RBridges require so". This is different from IEEE 802.1Q in which you can decide which switch act as transit for which VLAN. There is only one topology in RBridges, i.e. the core topology. In Spanning Tree potentially there are many active topologies. In RBridge the per VLAN instance only acts as "VLAN Pruning". -- Silvano > -----Original Message----- > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On > Behalf Of Silvano Gai > Sent: Sunday, April 01, 2007 7:54 AM > To: Radia Perlman; Russ White > Cc: rbridge at postel.org > Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN > learning:What is it and why should wecare?) > > > I changed the subject because I want us to clarify one of the > confusions: > > "It is not possible to configure an RBridge to act as a transit node for > a particular VLAN". > > In other words: "an RBridge that does not have any port/node in VLAN A > MUST act as a transit for VLAN A if other RBridges require so". > > This is different from IEEE 802.1Q in which you can decide which switch > act as transit for which VLAN. > > -- Silvano > > > > -----Original Message----- > > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] > On > > Behalf Of Radia Perlman > > Sent: Saturday, March 31, 2007 11:40 PM > > To: Russ White > > Cc: rbridge at postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > > wecare? > > > > I don't understand a lot of what's being said on this thread, and I > > suspect everyone is > > talking about subtly different solutions to a fairly esoteric set of > > somewhat related problems (sharing > > an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs, > > ...). As Dale Carder mentioned, > > and gave us some pointers, there are several somewhat overlapping > > proposals floating around the industry. > > I believe there isn't a single cleanly stated problem, or a single > > cleanly statable solution. > > > > So TRILL should do something. Whatever it is, I want to be able to > > understand what it is that RBridges should do. > > > > But to answer Russ's questions (see at bottom of this note) -- the > > current RBridge protocol > > spec assumes that *all* RBridges filter based on VLAN tag. > > So an RBridge in the core, even if it doesn't attach to VLAN A, knows > > which other RBridges do. This > > allows efficient distribution of VLAN A traffic, for instance, the > IS-IS > > announcements of VLAN A endnode > > information. > > > > The reason we need to let all the RBridges know what VLANs are in a > > group, say {Z, A, B, C, D}, > > where Z is the primary, is so that an RBridge in > > the core knows that something tagged with VLAN Z needs to be > transmitted > > to all links in any of the > > 5 VLAN tags {Z, A, B, C, D} and something tagged with one of the > > secondaries, say A, needs to go to > > A and Z. > > > > An example -- suppose there is an IP router R on VLAN Z (the primary). > > When R does an ARP for an > > endnode "d" in the IP subnet, R has no idea about VLANs, and the > RBridge > > RB1 that R attaches to, although > > RB1 might know that there's a grouping of VLANs, doesn't know which > VLAN > > to transmit the ARP to. > > Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a > > copy to each of {Z, A, B, C, D}. > > > > So RBridges in the core have to know to send the ARP along the > > distribution tree to all ports that are > > in any of the VLANs in the set. > > > > In theory we could ignore VLAN tags, except at the final hop, and > then, > > as Russ said, it > > would be just an optimization for the RBridges in the core to know > about > > the groupings. But I still think things would be weird > > if the final RBridges had inconsistent configurations of the VLAN > > groupings, so I think it's a good idea to > > make sure all the RBridges agree on the groupings. > > > > To summarize, it's good for them to agree because of three reasons: > > a) we can do optimal delivery of multicasts, filtering within the core > > rather than just at the final hop > > b) we detect misconfiguration > > c) we allow more central configuration (we don't need to configure all > > the RBridges, though that's a bit > > dangerous if all the RBridges that have been configured go down, since > > suddenly the groupings might disappear) > > > > Radia > > > > > > > > As for Russ's last questions: > > > > >> 3. Does this have a larger impact on multicast, or smaller? > > > > I don't understand the question, though given that he put a smiley > face > > in, perhaps > > it was a joke. I'm hoping that someone, tomorrow, will inform me that > all > > this > > SVL/FID stuff was a joke... > > > > Radia > > > > > > > > > > Russ White wrote: > > > > >-----BEGIN PGP SIGNED MESSAGE----- > > >Hash: SHA1 > > > > > > > > > > > > > > > > > >>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. > > >> > > >> > > > > > >I'm trying to sort through this entire thing, and I wanted to ask: > > > > > >1. The reason we'd want to configure this on all rbridges would be to > > >optimize traffic flow? > > > > > >2. If 1 is true, and we didn't do the configuration on all rbridges, > how > > >much less efficient would the rbridge network be? > > > > > >3. Does this have a larger impact on multicast, or smaller? > > > > > >:-) > > > > > >Russ > > > > > > > > >-----BEGIN PGP SIGNATURE----- > > >Version: GnuPG v1.4.3 (Darwin) > > >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > > >iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg > > >DSuMdrc10XgRmx8w4PdN/f4= > > >=ItDw > > >-----END PGP SIGNATURE----- > > > > > > > > > > _______________________________________________ > > 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 From sanjays at cisco.com Sun Apr 1 16:54:08 2007 From: sanjays at cisco.com (Sanjay Sane (sanjays)) Date: Sun, 1 Apr 2007 16:54:08 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <460F590E.5010207@sun.com> Message-ID: <7178B7E237F45D45BE404AFF0AF58D8702C763D1@xmb-sjc-213.amer.cisco.com> Yep, there are cases of such sub-optimal routing with private vlan. Host can sometimes receive 2 arp responses, and then there is a chance of host caching the arp response from the router. In private vlan, there are isolated secondary vlans and community secondary vlans. Any port with isolated secondary vlan cannot tal to any other port with same isolated secondary vlan. However, ports within the same community secondary vlan can talk to each other. Of course, in addition, these ports can talk to port of primary vlan (typically going towards the router). So, in case ip-A1 and ip-A2 are sitting behind community vlans, hosts may receive 2 arp responses. -Sanjay -----Original Message----- From: Radia Perlman [mailto:Radia.Perlman at sun.com] Sent: Sunday, April 01, 2007 12:03 AM To: Caitlin Bestler Cc: Sanjay Sane (sanjays); rbridge at postel.org Subject: Re: [rbridge] Shared VLAN learning: What is it and why should we care? Argh! I'm really confused. We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D), it would be forwarded by the IP router R. And that the RBridge is not doing this. Though someone could build a project that was a combined router/RBridge. But Sanjay -- I think you misunderstood my question. So let me restate it. Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D, all in the same IP subnet. The router R is in VLAN Z. The VLAN grouping is {primary=Z, secondaries = A, B, C, D}. Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a secondary in the group goes to all links in *that* secondary, plus Z. Do we all understand and agree so far? So now my question. a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged with VLAN A. The RBridges forward it to all links in A, as well as Z (the VLAN tag of the primary in the group {Z, A, B, C, D}. R, with MAC address r, responds to the ARP with a reply saying "ip-D has MAC address r". So ip-A1 and ip-D talk through R. b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which is tagged with VLAN A. The RBridges forward it to all links in A as well as Z. But now both the real target, ip-A2, as well as the router R see the ARP. If R replies, then ip-A1 and ip-A2 will be talking through R. My question was -- how does R know *not* to respond to the ARP? Or does sometimes R wind up forwarding between endnodes in the same VLAN unnecessarily and we don't care because it's not *incorrect*, it's just suboptimal? Even if R sees an ARP reply from ip-A2, I don't think R can tell what VLAN ip-A2 is in. Because the packet, once it gets to R, either doesn't have a VLAN tag on it, or the VLAN tag says Z. So...I'd really like to understand this... Radia Caitlin Bestler wrote: >rbridge-bounces at postel.org wrote: > > >>To answer your quiz: the "enhanced" proxy arp feature is to be >>supported by the router, NOT by the switch. The enhancement is >>essentially to be able to proxy arp for local hosts, i.e for those >>hosts which are on the same subnet as the router interface. This is >>the "ip local proxy arp" >>supported feature at least in Cisco implementations. >> >>This way, the L3 communication between the hosts belonging to >>different secondary vlans, is achieved *only* via the router. >>i.e. if host ip-A >>(vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops: >>mac-A --> mac-router >>mac-router --> mac-D >>I think we should preserve this behavior with rbridges. >>Changing the vlans of the packet should NOT be done by rbridges, imo. >> >>-Sanjay >> >> >> >> >> >I would agree that 'routing' between VLAN-A and VLAN-D should only be >done as a result of an explicitly created 'route', and that this is >part of being a proxy ARP. > >I don't see any real problem with an RBridge doing so, as long as it >only does so based on explicit instructions from the network >administrators. It definitely must not just assume that it is ok to >forward packets between two VLANs based upon their both using the same >subnet. > >While this functionality is certainly more natural in a router, is >there any reason to forbid explicitly delegating this task to RBridges? >It could save a few hops on the end-to-end path. > > > > From caitlinb at broadcom.com Mon Apr 2 11:21:28 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 2 Apr 2007 11:21:28 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <460F590E.5010207@sun.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA613@NT-IRVA-0750.brcm.ad.broadcom.com> Radia Perlman wrote: > > My question was -- how does R know *not* to respond to the > ARP? Or does sometimes R wind up forwarding between endnodes > in the same VLAN unnecessarily and we don't care because it's > not *incorrect*, it's just suboptimal? > I'm not sure what the relevant specs are, but my understanding has always been that a Proxy ARP only answers an ARP request if it is somehow between the requester and the machine it is proxying for. My direct experience with this all relates to Cable Modems, so I haven't thought about corner cases where the "between" status might not be blatantly obvious. And in that case flooding irrelevant packets from every home network upstream was not "suboptimal", it would have been a network killer. So luckily the distinction between the home network and the cable network was easily made. From eric.gray at ericsson.com Mon Apr 2 12:05:30 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Mon, 2 Apr 2007 14:05:30 -0500 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <460B6304.3020507@sun.com> References: <460B6304.3020507@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> 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 > From jrrivers at nuovasystems.com Mon Apr 2 12:15:49 2007 From: jrrivers at nuovasystems.com (J. R. Rivers) Date: Mon, 2 Apr 2007 12:15:49 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D034BA613@NT-IRVA-0750.brcm.ad.broadcom.com> References: <460F590E.5010207@sun.com> <1EF1E44200D82B47BD5BA61171E8CE9D034BA613@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014675DA@nuova-ex1.hq.nuovaimpresa.com> More importantly is that sometimes R does reply to local ARPs and sometimes it doesn't... as part of system vendor feature definitions. Generally, I've always thought of ARP as a router/host function. As the lines blur between routers and switches, there have been many features introduced into "switches" based on router functionality. I'd argue that this is one great reason to leave ARP out of TRILL so that any of these extensions can continue to work based on their expectations of the underlying L2 network. JR > -----Original Message----- > From: rbridge-bounces at postel.org > [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler > Sent: Monday, April 02, 2007 11:21 AM > To: Radia Perlman > Cc: rbridge at postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should we care? > > Radia Perlman wrote: > > > > > My question was -- how does R know *not* to respond to the > > ARP? Or does sometimes R wind up forwarding between endnodes > > in the same VLAN unnecessarily and we don't care because it's > > not *incorrect*, it's just suboptimal? > > > > I'm not sure what the relevant specs are, but my understanding > has always been that a Proxy ARP only answers an ARP request > if it is somehow between the requester and the machine it > is proxying for. > > My direct experience with this all relates to Cable Modems, > so I haven't thought about corner cases where the "between" > status might not be blatantly obvious. And in that case > flooding irrelevant packets from every home network upstream > was not "suboptimal", it would have been a network killer. > So luckily the distinction between the home network and > the cable network was easily made. > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From Radia.Perlman at sun.com Mon Apr 2 13:10:04 2007 From: Radia.Perlman at sun.com (Radia Perlman) Date: Mon, 02 Apr 2007 13:10:04 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> References: <460B6304.3020507@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> Message-ID: <4611631C.4090500@sun.com> 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 >> >> >> From caitlinb at broadcom.com Mon Apr 2 13:11:05 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 2 Apr 2007 13:11:05 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA688@NT-IRVA-0750.brcm.ad.broadcom.com> Eric Gray 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? > It's a more fundamental problem that re-learning, and the goal could more properly be stated as avoiding the neccesity of creating distinct subnets. Sharing the IP subnet does conserve IP Addresses, but more importantly it conserves the effort of dividing the IP addresses up into VLAN specific portions, and of updating DNS entries when a host migrates to a new VLAN, etc. There was actually a very good summary of the usage of such a feature on a BSD list in 2005: http://lists.freebsd.org/pipermail/freebsd-net/2005-November/009064.html Different switches having different VID/FID mappings is confusing, but ultimately it isn't that bad, especially since global MAC addresses do tend to be unique within a campus even when they are being assigned by decidedly non-global techniques. But the associated ARP Proxy has a totally different problem. Specifically, the scenario is where the *same* IP subnet is used for two or more VLANs. Or to be more precise, what is to *appear* to be one IP subnet to the outside world is actually two or more VLAN divided subnets, and the assignment of specific IP addresses to specific VLANs is dynamically learned rather than administered. So if RBridges scope the MAC/IP learning to a VID specific instance then two RBridges can have contradictory information about the meaning of an IP address. In fact, a single RBridge could have contradictory information in two VID-specific instances about the same IP address. This creates a severe problem for the router (existing router, mind you) that is the ingress point to this shared IP subnet. When it has a received IP datagram to x.y.z.1, and no entry in its ARP table, it will have no idea which VLAN the datagram belongs to. Therefore it will ARP on all VLANs to see where it goes, and it expects to get at most one reply because an IP address is only supposed to be assigned to a single host. Not that the router will get upset or have a fault. It will more likely assume to all replies are redundant and therefore it can always just use the most recent one without bothering to remember any prior ARP responses. So, when a host migrates from VLAN A to VLAN B, we have a problem if the RBridge on VLAN B does not share its discovery with the RBridge on VLAN A (and the two are part of a group / share the same IP subnet). If the discovery is shared, then the RBridge on VLAN A will delete its entry for the IP address, and when the Router next ARPs it will only get a response from VLAN B. So while the groups that Radia describes will solve the problem, the fundamental justification for the solution arises when the semantics of an IP subnet span multiple VIDs. When the IP Address retained for Proxy ARP purposes has a wider scope that the VLAN dissemination of discovery cannot be confined to the VLAN. And while I could see actually making the determination based on IP Addressing, I don't see any real advantage to doing so. While we've been refining the examples, the underlying problem remains as originally stated. Since RBridges provide a distributed Proxy ARP service they simply must avoid having contradictory information held by different RBridges (they can and should have different subsets of the entire picutre, but no RBridge should ever have data that contradicts the data that other RBridgess have). From eric.gray at ericsson.com Mon Apr 2 13:50:05 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Mon, 2 Apr 2007 15:50:05 -0500 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <4611631C.4090500@sun.com> References: <460B6304.3020507@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se> <4611631C.4090500@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> 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 > >> > >> > >> > > From sgai at nuovasystems.com Mon Apr 2 14:05:47 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 2 Apr 2007 14:05:47 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should wecare? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> Eric, > -----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 1:50 PM > To: Radia Perlman > Cc: rbridge at postel.org > Subject: Re: [rbridge] Shared VLAN learning: What is it and why should > wecare? > > Radia, > > There is an interesting problem that might arise out of > a router receiving VLAN tagged frames without being aware that > they are tagged. > This is not the case, unless there is a misconfiguration. A Router has a concept of an interface (e.g. eth0, the Ethernet port) and of sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit or implicit, is used to select a sub-interface. The sub-interface has an IP address and a netmask. -- Silvano > 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 > > >> > > >> > > >> > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From eric.gray at ericsson.com Mon Apr 2 14:08:23 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Mon, 2 Apr 2007 16:08:23 -0500 Subject: [rbridge] Shared VLAN learning: What is it and why should we care? In-Reply-To: <460B6304.3020507@sun.com> References: <460B6304.3020507@sun.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> 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 > From eric.gray at ericsson.com Mon Apr 2 14:15:35 2007 From: eric.gray at ericsson.com (Eric Gray (LO/EUS)) Date: Mon, 2 Apr 2007 16:15:35 -0500 Subject: [rbridge] Shared VLAN learning: What is it and why should wecare? In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> References: <460B6304.3020507@sun.com><941D5DCD8C42014FAF70FB7424686DCFACAD96@eusrcmw721.eamcs.ericsson.se><4611631C.4090500@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAEA5@eusrcmw721.eamcs.ericsson.se> <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <941D5DCD8C42014FAF70FB7424686DCFACAED4@eusrcmw721.eamcs.ericsson.se> Silvano, Uhhhh, yes, but that makes the router aware of VLANs - doesn't it? Getting back to Radia's statement (below) - "So therefore, I (Radia) am assuming that the IP router is not supposed to know that the link is subdivided into VLANs." I think you need to review the order of the dialog. I was pointing out that Radia's assumption of router ignorance of VIDs would be a problem. You apparently would argue that routers are not ignorant of VIDs. So, unless I am misunderstanding you, I believe we are in agreement. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Silvano Gai [mailto:sgai at nuovasystems.com] > Sent: Monday, April 02, 2007 5:06 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? > Importance: High > > Eric, > > > -----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 1:50 PM > > To: Radia Perlman > > Cc: rbridge at postel.org > > Subject: Re: [rbridge] Shared VLAN learning: What is it and > why should > > wecare? > > > > Radia, > > > > There is an interesting problem that might arise out of > > a router receiving VLAN tagged frames without being aware that > > they are tagged. > > > > This is not the case, unless there is a misconfiguration. A > Router has a > concept of an interface (e.g. eth0, the Ethernet port) and of > sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to > sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit > or implicit, is used to select a sub-interface. The > sub-interface has an > IP address and a netmask. > > -- Silvano > > > > 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 > > > >> > > > >> > > > >> > > > > > > > > > > _______________________________________________ > > rbridge mailing list > > rbridge at postel.org > > http://mailman.postel.org/mailman/listinfo/rbridge > From caitlinb at broadcom.com Mon Apr 2 14:37:29 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 2 Apr 2007 14:37:29 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should wecare? In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA201467667@nuova-ex1.hq.nuovaimpresa.com> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D034BA738@NT-IRVA-0750.brcm.ad.broadcom.com> rbridge-bounces at postel.org wrote: > Eric, > >> -----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 1:50 PM >> To: Radia Perlman >> Cc: rbridge at postel.org >> Subject: Re: [rbridge] Shared VLAN learning: What is it and why >> should wecare? >> >> Radia, >> >> There is an interesting problem that might arise out of a router >> receiving VLAN tagged frames without being aware that they are >> tagged. >> > > This is not the case, unless there is a misconfiguration. A > Router has a > concept of an interface (e.g. eth0, the Ethernet port) and of > sub-interfaces (e.g. eth0/3). VLANs and subnets are associated to > sub-interfaces. When a frame arrive the VID (VLAN ID), either explicit > or implicit, is used to select a sub-interface. The > sub-interface has an > IP address and a netmask. > > -- Silvano > > If you review the email I cited previously, and then do some googling, you'll see that assigning each VLAN a recognizable IP subnet is merely the predominant technique -- it is not the only one, and it is not a requirement. Do you agree that when a router connects to multiple VLANs that share an IP subnet that having the RBridge generate a Proxied ARP response to the *same* IP address on each VLAN is a problem that needs to be solved? How do you prevent the incorrect Proxied ARP response without sharing the endnode discovery over the truly relevant span, rather than just within the VLAN? This is a more pressing issue than just Shared vs. Independent Learning. Mandating that all RBridges use Independent Learning is undesirable to the extent that specifications should be minimalistic and impose as few constraints as possible. But realistically I doubt that Shared Learning is really desirable for RBridges. The shared IP subnet issue, however, has nothing to do with RBridges. Forbidding sharing of IP subnets across VLANs would be considerably more drastic, and presumably outside the WG's scope. For one thing it would directly contradict RFC 3069: The VLAN [802.1Q] aggregation technique described in this document provides a mechanism by which hosts that reside within the same physical switched infrastructure, but separate virtual broadcast domains, may be addressed from the same IPv4 subnet and may share a common default gateway IPv4 address. ... Essentially, what occurs is that each sub-VLAN (customer) remains within a separate broadcast domain. One or more sub-VLANs belong to a super-VLAN, and utilize the default gateway IP address of the super-VLAN. Hosts within the sub-VLANs are numbered out of IP subnets associated with the super-VLAN, and their IP subnet masking information reflects that of the super-VLAN subnet. If desired, the super-VLAN router performs functions similar to Proxy ARP to enable communication between hosts that are members of different sub-VLANs. From sgai at nuovasystems.com Mon Apr 2 14:44:41 2007 From: sgai at nuovasystems.com (Silvano Gai) Date: Mon, 2 Apr 2007 14:44:41 -0700 Subject: [rbridge] Shared VLAN learning: What is it and why should wecare? In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> References: <460B6304.3020507@sun.com> <941D5DCD8C42014FAF70FB7424686DCFACAECC@eusrcmw721.eamcs.ericsson.se> Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2014676A2@nuova-ex1.hq.nuovaimpresa.com> 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 > > 1