[rbridge] Existing issues in root bridge selection for LANs.

Greg Daley greg.daley at eng.monash.edu.au
Mon May 9 21:22:06 PDT 2005


Hi Erik,


Erik Nordmark wrote:
[cut]
>> Your diagram is a useful one, since it illustrates non-Trill capable
>> routers in the network.
> 
> 
> Yes, but my figure, repeated below, might not be that representative for 
> a real network:
>  >>     <rest of LAN up here>
>  >>      |                |
>  >>     RB1              RB2
>  >>      |                |
>  >>      -------------------
>  >>      |    |      |
>  >>     H1    H2     R1
> 
> I real enterprise LAN of reasonable size is probably going to have some 
> edge switches connecting to hosts, and a layer of distribution switches, 
> which connect to the routers. So a more natural picture would be with 
> the routers on "top", perhaps connected to the RBs without any 
> intervening bridges:
> 
>       R1        R2
>        |         |
>       RB3       RB4
>        | \     /  |
>        |  \   /   |
>      <rest of LAN up here, with additional "leafs" like the one below
>      attached to it>
>       |                |
>      RB1              RB2
>       |                |
>       -------------------
>       |    |
>      H1    H2
> 
>> In those situations the Internet Router is likely to be the best
>> root bridge of all, and its adjacent bridge is likely to not be a Trill
>> device, and is not likely to be able to automatically configure.
> 
> 
> But if the toplogy is more like the picture above, then there is no 
> issue with a 802.1D spanning tree between R1 and RB3 etc.
> You'd still have a bridge spanning tree for the ("----") bridged 
> sub-topology at the bottom, but for that one getting the root close/at 
> the RB is good enough.

Even if the lower topology is more complex (distribution switches,
redundant paths), the spanning tree rooted at the active Rbridge
is optimal for a stub LAN.

In fact, the more (simple) cycles in the bridges, the better the
performance is compared to other roots.

[cut]
> 
> 
> I'm still failing to draw the topology from your description. Sorry.
> (Perhaps you can glue me in off-line.)

I guess there's no rush yet.

I was just saying that negotiation can be explicit on the legacy LAN
(like OSPF Designated Router negotiation) or through voodoo which
doesn't exchange signaling on the legacy LAN (but uses rbridge
link-state knowledge).

>> I'm not sure if the RB as Root Bridge idea is always beneficial, but
>> would it be worth looking into?
> 
> 
> I think so.
> I think we also need to figure out how to get smooth failover when RB1 
> fails and we want the designed bridge for the sub-topology to become 
> RB2, and have the bridges quickly discard their learned information 
> which points at the dead RB1.
> Having the designated RB look like the root bridge to the rest of the 
> bridges (or look like the shortest cost to the root bridge) is one way 
> to make the failover smooth for the bridges.
> But there might be other ways to accomplish this.

It's fairly simple, with the way that root bridge selection works
in 802.1D, to just make the bridge ID preference higher
(making it slightly less desirable) for the backup.

The minor trick is to allow explicit configuration of other bridges
as root, where the automated root isn't going to be suitable (for
example, the 'top' network). This reduces the administrative load to
a single LAN though.

Greg


More information about the rbridge mailing list