[rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Eric Gray
eric.gray at ericsson.com
Wed Dec 5 10:41:41 PST 2007
Radia,
I've been sort of wondering what the point is in having
a subject line anyway. After all, the subject surely must be
obvious from the text in the message, right? :-)
Thanks!
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> Sent: Tuesday, December 04, 2007 10:15 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Orphaned endnodes with partitioned VLANs on a cloud
> Importance: High
>
> 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
> >
>
>
More information about the rbridge
mailing list