[rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Eric Gray
eric.gray at ericsson.com
Mon Dec 10 06:42:08 PST 2007
By the way, there is definitely something wrong with the mailing
list. The mail below was not received until 12 hours after it
was sent. This is particularly annoying since I was getting ready
to pack for my return trip when I sent it, but I was in an airplane
at probably about 30,000 feet when people started receiving it.
Is it possible to determine what is causing the posting delay?
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: rbridge-bounces at postel.org
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray
> Sent: Thursday, December 06, 2007 9:53 PM
> To: Anoop Ghanwani; Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned
> VLANs on a cloud
>
> Anoop,
>
> The picture is a direct variation from the access-like
> network picture you drew on a napkin in whatever restaurant
> it was that we started talking about this in.
>
> The aggregation bridges - according to your description
> would assign VIDs to aggregated subscribers. Let us ignore -
> for a while (as we did during that discussion) that this is
> very explicitly not in scope for the chartered objective and
> pretend that this type of deployment is common (or, at least,
> not unheard of) in a large enterprise network.
>
> As I was then, I am still prepared to stipulate that may
> be the case - at least somewhere in the universe.
>
> In your example, the aggregation bridges would have many
> (as in a thousand or more) down-link interfaces which they are
> aggregating onto a much smaller number of up-link interfaces.
> Your claim at the time was that most such deployments wouldn't
> trunk (Q-in-Q) these VIDs - hence all of them would be visible
> to the RBridges (RB-1 and RB-2 in my example). This was the
> basis for your claim that per-VLAN peering of IS-IS instances
> could produce serious scalability issues.
>
> This is a not-unreasonable claim to make and a hard claim
> to argue against, especially given the already deep level of
> suspended disbelief involved at this point in our discussion.
>
> Now, you propose that I should label the interfaces I've
> adopted from your example with VLAN IDs? Are you sadistic, or
> just having a mean moment? :-)
>
> Frankly, given the nature of the problem, I can't imagine
> why you really need to have that information. What is important
> is that there are two VLANs (A and B) that are being routed in
> some special way (shown in the diagram) and an arbitrary number
> of VLANs (but necessarily at least 1 and not more than 4092) of
> other VLANs that are also present in the network (as shown - and
> described - in my diagram).
>
> --
> Eric Gray
> Principal Engineer
> Ericsson
>
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > Sent: Thursday, December 06, 2007 9:33 PM
> > To: Eric Gray; Radia Perlman
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Orphaned endnodes with partitioned
> > VLANs on a cloud
> > Importance: High
> >
> >
> > (There was some problem with the outgoing
> > alias of my email and as a result my posts
> > haven't been making it to the list; just
> > to private parties listed in the recipient
> > list. Hopefully that should be fixed at
> > the time I send this message.)
> >
> > Hi Eric,
> >
> > I can't fully remember the example. Would it
> > be possible for you to put the VLAN memberships
> > on the various ports in your figure? That would
> > help me understand the picture better.
> > (I know I may be asking for much but please
> > be patient with me because I'd like to address
> > all your concerns.)
> >
> > It is possible to misconfigure bridged LANs
> > so that VLANs end up getting partitioned.
> > The automated way to avoid that is using
> > MVRP.
> >
> > Anoop
> >
> > > -----Original Message-----
> > > From: Eric Gray [mailto:eric.gray at ericsson.com]
> > > Sent: Wednesday, December 05, 2007 2:25 PM
> > > To: Anoop Ghanwani; Radia Perlman
> > > Cc: Developing a hybrid router/bridge.
> > > Subject: RE: [rbridge] Orphaned endnodes with partitioned
> > > VLANs on a cloud
> > >
> > > Anoop/Radia,
> > >
> > > This is not exactly the note on which we left off in
> > > the off-line discussion. As I recall (isn't E-Mail great!),
> > > I replied to this with the following:
> > >
> > > ============================================================
> > > If the RBridges were inserted to replace 802.1Q
> > > bridges, and each was configured as I've described for access
> > > to both VLAN A and B, then the bridge failure I described
> > > would simply result in a different spanning tree for VLAN A.
> > > VLAN A would not be broken, it would simply be (potentially)
> > > less optimal.
> > > ============================================================
> > >
> > > This was specifically in response to your comment (to
> > > the effect that this wouldn't have worked in an 802.1Q LAN -
> > > so it would have been a misconfiguration there as well).
> > >
> > > In response to the above observation you said that you
> > > agreed that this would not have been a misconfiguration error
> > > in that case. Aactually, what you said exactly was "Yes, you
> > > are right."
> > >
> > > More on this in a separate mail message response to Radia...
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > > > -----Original Message-----
> > > > From: Anoop Ghanwani [mailto:aghanwan at brocade.com]
> > > > Sent: Tuesday, December 04, 2007 11:27 PM
> > > > To: Radia Perlman; Eric Gray
> > > > Cc: Developing a hybrid router/bridge.
> > > > Subject: RE: [rbridge] Orphaned endnodes with partitioned
> > > VLANs on a
> > > > cloud
> > > > Importance: High
> > > >
> > > >
> > > > Radia,
> > > >
> > > > This is what I told Eric during the offline discussion as
> > > well - that
> > > > this is a misconfiguration and as long as bad things aren't
> > > happening,
> > > > it's up to the administrator to configure things so that
> > they work
> > > > correctly when such failures happen.
> > > >
> > > > It is no worse than what can happen in a misconfigured bridged
> > > > network.
> > > >
> > > > Anoop
> > > >
> > > > > -----Original Message-----
> > > > > From: rbridge-bounces at postel.org
> > > > > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> > > > > Sent: Tuesday, December 04, 2007 7:15 PM
> > > > > To: Eric Gray
> > > > > Cc: Developing a hybrid router/bridge.
> > > > > Subject: [rbridge] Orphaned endnodes with partitioned VLANs
> > > > on a cloud
> > > > >
> > > > > Putting in a subject line since Eric didn't.
> > > > >
> > > > > To restate Eric's concern -- it is possible that VLAN A
> > might be
> > > > > partitioned on a link, and since the DRB selects only
> a single
> > > > > VLAN-A-forwarder, some VLAN A endnodes on the cloud might get
> > > > > orphaned (since they are on the other side of the
> > > partition from the
> > > > > appointed VLAN A forwarder on the link).
> > > > >
> > > > > And that is correct.
> > > > >
> > > > > So, what is the alternative? Everything is an engineering
> > > tradeoff.
> > > > > We could run DRB elections on every possible VLAN, and with a
> > > > > partitioned VLAN, wind up with multiple DRBs for that VLAN.
> > > > > If there were n VLANs, we'd wind up with n DRBs (one
> > per VLAN), n
> > > > > pseudonodes, n times as many Hello messages, etc.
> > > > >
> > > > > We chose to consider a partiitoned VLAN, caused by bridges
> > > > > configured to not pass data traffic for a particular
> VLAN, as a
> > > > > misonfiguration. This can happen with bridges anyway, if
> > > you mark a
> > > > > bunch of your potential through links as not being
> > > allowed for VLAN
> > > > > A transit. The solution in the current spec is low
> > > overhead (at most
> > > > > one pseudonode per link, one Hello per RBridge except for
> > > the DRB)
> > > > > and relatively simple.
> > > > > Hopefully eventually more bridges will be replaced by
> > > RBridges and
> > > > > this sort of thing won't happen.
> > > > >
> > > > > Radia
> > > > >
> > > > >
> > > > > Eric Gray wrote:
> > > > > > Folks,
> > > > > >
> > > > > > Here is the problem that occurs when VLAN state is
> > > > > inferred for one
> > > > > > VLAN from connectivity provided by another. This is
> > a general
> > > > > > problem, but has specific applicability to the
> current set of
> > > > > > assumptions used in the protocol specification. This
> > > came up in
> > > > > > off-line discussions with Anoop Ghanwani (and others)
> > > at an IEEE
> > > > > > meeting a couple of weeks ago.
> > > > > >
> > > > > > A key thing to understand in looking at this
> > > problem is it is a
> > > > > > comparison between how a network works with 802.1Q
> > > > bridges and the
> > > > > > same network after some 802.1Q bridges have been
> > replaced with
> > > > > > RBridges. The example shows a partial RBridge deployment
> > > > > and this is
> > > > > > compared with how it will have worked with 802.1Q bridges
> > > > where the
> > > > > > example shows RBridges (i.e. - it is an after- the-fact
> > > > > comparison of
> > > > > > L2 forwarding functionality).
> > > > > >
> > > > > > The network looks like this (initially):
> > > > > >
> > > > > > \\\\|//// \\\\\|||///// \\\|///
> > > > > > __|__ __|__ __|__
> > > > > > | B-1 | | B-2 | | B-3 |
> > > > > > |_____| |_____| |_____|
> > > > > > | \ / \_____ / |
> > > > > > | \_____/ | B-5 | |
> > > > > > | | B-4 | |_____| |
> > > > > > | |_____| | |
> > > > > > __|__ \ | |
> > > > > > | B-6 |_______\ _______| __|__
> > > > > > |_____| \___________| B-7 |
> > > > > > | |_____|
> > > > > > | |
> > > > > > __|___ __|___
> > > > > > | RB-1 | | RB-2 |
> > > > > > |______| |______|
> > > > > > \ _ /
> > > > > > \__ __( )___ _/
> > > > > > \_( Core )_/
> > > > > > (_ RBridge _)
> > > > > > (_ Cloud _)
> > > > > > (_ _)
> > > > > > (_)
> > > > > >
> > > > > > In this figure, B-1, B-2 and B-3 are
> > > aggregation bridges with
> > > > > > multiple (lots and lots) of VIDs.
> > > > > >
> > > > > > B-4 is a special purpose bridge used for VLAN-A only,
> > > > > and B-5 is a
> > > > > > special purpose bridge used for VLAN-B only.
> > > > > >
> > > > > > All remaining bridges are configured to participate in
> > > > > VLAN-A, VLAN-B
> > > > > > and an arbitrary set of zero or more other VLANs. Since
> > > > > B-4 and B-5
> > > > > > are configured for specific VLANs only, the ports on
> > > > their adjacent
> > > > > > bridging peers are configured only for those VLANs.
> > > > > >
> > > > > > To be clear, the links between B-4 and B-7, and between
> > > > > B-6 and B-5
> > > > > > are not connected (they merely overlap in the drawing).
> > > > > >
> > > > > > In this network, RB-1 and RB-2 are both RBridges and
> > > > > both have access
> > > > > > to VLAN A and VLAN B and each other (via both VLAN
> A and VLAN
> > > > > > B) - as well as the same arbitrary set of zero or more
> > > > > VLANs that any
> > > > > > of the other bridges in the drawing have. However, the two
> > > > > RBridges
> > > > > > use another VLAN - say VLAN C - to exchange hellos. Under
> > > > > the normal
> > > > > > operating conditions intended, this works fine and RB-1 and
> > > > > RB-2 may
> > > > > > separately be elected DRB for either of VLAN A or VLAN B.
> > > > > >
> > > > > > If bridge B-4 fails, then VLAN A would be
> > > segmented, at least
> > > > > > temporarily. Hellos continue to work, however, so the 2
> > > > > RBridges do
> > > > > > not discover the partition and the DRB election remains
> > > unchanged.
> > > > > > In this case, part of the VLAN is orphaned - particularly
> > > > from the
> > > > > > perspective of any locally attached end-stations.
> > > > > >
> > > > > > However, this is not acceptable behavior. No
> > > > > misconfiguration exists
> > > > > > and the ideal (and reasonably expected) behavior would
> > > be for the
> > > > > > RBridges to discover the partition and redo the DRB
> > > > > election - making
> > > > > > RB-1 the DRB for one partition and RB-2 the DRB for
> the other
> > > > > > partition.
> > > > > >
> > > > > > If (when) RB-1 and RB-2 were 802.1Q bridges, using MSTP
> > > > > for multiple
> > > > > > VLANs (in particular, for VLAN A and B), this failure
> > will have
> > > > > > resulted in re-running (M)STP for the affected VLAN
> > > > > connectivity and
> > > > > > the segmentation (partitioning) would be healed. In the
> > > > > same way, if
> > > > > > the status of VLAN's A and B were derived directly from
> > > > > messages that
> > > > > > use VLAN A and VLAN B (as opposed to using VLAN C), this
> > > > > same robust
> > > > > > behavior would occur.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Eric Gray
> > > > > > Principal Engineer
> > > > > > Ericsson
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > >
> > >
> >
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
More information about the rbridge
mailing list