[rbridge] (no subject)
eric.gray at ericsson.com
Tue Dec 4 10:57:50 PST 2007
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
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.
More information about the rbridge