Subject: [rbridge] The "wiriding closet" problem

From: Radia.Perlman at sun.com ([email-masked])
Date: Wed, 29 Nov 2006 17:31:48 -0800

I've had a couple of people explain what the "wiring closet" issue is, and I have two potential pictures for it.
I think there's a reasonable solution for either picture, but it would be good if someone could define what the
problem is.

I will make an attempt, and that way you can correct me rather than trying to explain it from scratch, if that's easier.

The problem is to have a bunch of endnodes attached to the campus via multiple RBridges (for redundancy
as well as load splitting). So let's simplify it to two: R1 and R2 are attached to the campus, and to a bunch of
endnodes.

                  campus

                  |            |
                R1        R2
                  |            |
                B1 ------ B2
                |                 |
           --------           ---------
             E1 E2           E3 E4

Without thinking about this at all, the default would be that one of R1 or R2 would become DR, and the other
would not forward traffic to or from the campus. That means that if R1 was selected DR, traffic from E3 would
have to go via R1.

So the desire is to have the spanning tree break the B1-B2 link in the case where both R1 and R2 are up,
but have that link available in case either R1 or R2 fails.

This can be accomplished by configuring R1 and R2 to pretend they are one hop away from a fictitious Root spanning
tree bridge inside the campus.

*********
Another potential configuration I've heard of as the "wiring closet problem" is to do away with the bridges, and have
this topology:

                  campus

                  |            |         |
                R1        R2     R3
                  |            |        |
           ----------------------------
                   |    |        |         |
                 E1 E2    E3    E4

Again, the desire is to load split between R1,  R2, and R3, as long as they are both up.

This can be accomplished by configuring the RBridge which is DR to assign endnodes to other RBridges
on the link. R1 knows, based on the IS-IS router hellos, that R2 and R3 are also RBridges on the link, and
that R1 is DR. R1 could assign blocks of MAC addresses (I'd guess based on a mask) to each
of the other RBridges. If, for instance, it tells R2 to be in charge of odd MAC addresses, then only R2 learns
the location of odd-numbered MAC addresses on the link, announces those in R2's link state information, and
only R2 forwards packets from odd-MAC addresses off the link, and decapsulates traffic for odd-MAC addresses
onto the link. In essence it winds up looking like n different disconnected LANs, one that happens to have
odd MAC addresses, the others whatever partitioning R1 assigns.

Are there any other cases? Are these solutions to these cases OK with people?

Radia

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 29 Nov 2006 22:20:01 -0500

Hi,

Although the second example you give could be a problem, I'm not sure
with today's typical star configurations it would occur much.

What I have heard referred to as the wiring closet problem is your first
case. Typically described as B1 and B2 being in the closet, so they are
very close and high bandwidth communication between them is fairly easy,
while the B1-R1 and B2-R2 links are longer distance, higher cost, and
lower bandwidth, so you want to be sure to use them both if they are
both up to get the maximum bandwidth from the E* to the campus. The
scenario considered is usually the failure of the longer communications
links, rather than an Rbridge, although they are operationally pretty
similar.

Donald

PS: Of course, things work if you replace B1 and B2 with Rbridges but
that does not allow incremental deployment.

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia.Perlman at sun.com
Sent: Wednesday, November 29, 2006 8:32 PM
To: rbridge at postel.org
Subject: [rbridge] The "wiriding closet" problem

I've had a couple of people explain what the "wiring closet" issue is,
and I have two potential pictures for it.
I think there's a reasonable solution for either picture, but it would
be good if someone could define what the problem is.

I will make an attempt, and that way you can correct me rather than
trying to explain it from scratch, if that's easier.

The problem is to have a bunch of end nodes attached to the campus via
multiple RBridges (for redundancy as well as load splitting). So let's
simplify it to two: R1 and R2 are attached to the campus, and to a bunch
of end nodes.

           campus

         |         |
         R1        R2
          |         |
          B1 ------ B2
          |          |
    --------       ---------
     E1 E2           E3 E4

Without thinking about this at all, the default would be that one of R1
or R2 would become DR, and the other would not forward traffic to or
from the campus. That means that if R1 was selected DR, traffic from E3
would have to go via R1.

So the desire is to have the spanning tree break the B1-B2 link in the
case where both R1 and R2 are up, but have that link available in case
either R1 or R2 fails.

This can be accomplished by configuring R1 and R2 to pretend they are
one hop away from a fictitious Root spanning tree bridge inside the
campus.

*********
Another potential configuration I've heard of as the "wiring closet
problem" is to do away with the bridges, and have this topology:

           campus

       |         |      |
       R1        R2     R3
        |         |      |

Again, the desire is to load split between R1,  R2, and R3, as long as
they are both up.

This can be accomplished by configuring the RBridge which is DR to
assign end nodes to other RBridges on the link. R1 knows, based on the
IS-IS router hellos, that R2 and R3 are also RBridges on the link, and
that R1 is DR. R1 could assign blocks of MAC addresses (I'd guess based
on a mask) to each of the other RBridges. If, for instance, it tells R2
to be in charge of odd MAC addresses, then only R2 learns the location
of odd-numbered MAC addresses on the link, announces those in R2's link
state information, and only R2 forwards packets from odd-MAC addresses
off the link, and decapsulates traffic for odd-MAC addresses onto the
link. In essence it winds up looking like n different disconnected LANs,
one that happens to have odd MAC addresses, the others whatever
partitioning R1 assigns.

Are there any other cases? Are these solutions to these cases OK with
people?

Radia

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge