Subject: [rbridge] it's time to summarize things

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Sat, 07 Jan 2006 22:20:38 -0800

Guillermo Ib??ez wrote:

> Well, it seems then that we can have loops for all that time.  If
> subsecond intervals are needed, Hello Time must be
> lower than 1 second. I find this mechanism more costly than using RSTP,
> (already used by the bridges in the hub) to detect the double DR
> situation.  By using the Root bridge election mechanism of
> RSTP (via colocated bridge), the process uses the standard RSTP BPDUs
> and selects in a reliable form a unique Root bridge and DR, assuming the
> default bridge priority of bridges for election is worse than the
> default priority of Rbridges (this can be defined at will).  Although it
> means a small dependency on the 802.1D standard, it seems more advisable
> to rely in a standard mechanism to act in a consistent way than
> duplicate the mechanism and ignore RSTP protocol to obtain full
> independency.
> Rbridges ignoring fully RSTP BPDUs means all that means for knowing
> "link" and tree status are dropped, the risk for malfunction is
> increased as  long as Rbridges ignore BPDU information as useless.
> One difference is that if DR Hello messages are not received, or
> messages from new bridges appear, Rbridges might use received RSTP BPDU
> information to confirm the cause and motivation of messages, so
> decisions more consistent with RSTP can be taken.
> Perhaps the main argument is that Root bridge election stops inmediatly
> the frame forwarding in link (hub) blocking the loop, while via DR, the
> stopping is done by Rbridges election. That is not the case if spanning
> tree remains active while two DRs coexist on the link reinjecting the
> traffic in the link through the Rbridge campus. The process requires
> full communication between Rbridges through the link while there is a
> loop on it.  Root bridge election does not.

Guillermo,
There is one thing I don't understand.

Are you or are you not assuming that an RBridge (via the collocated 
bridge) will always be elected as a root for the above to work?
Even if the RBridges (well, their co-located bridges) have the highest 
root bridge priority, there could another legacy bridge in the network 
that has the same priority, in which case the root bridge election would 
use the MAC address as the tie-breaker. This means that there is the 
possibility that some other bridge will be elected the root. Then what 
happens?

    Erik

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sun, 08 Jan 2006 22:00:35 +0100

Erik Nordmark wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>
Erik,
       You are right, although I think it is not a realistic situation.
In the case you mention (maximum possible priority in both bridges, 
collocated and legacy ) the bridge with lower MAC will be elected root. 
But a legacy bridge with  maximum priority configured requires somebody 
that has configured it to be the root. This is in contradiction with  an 
environment where we are assuming selfconfiguration (i.e default values 
for priorities). I see this situation more likely produced as an 
intentional fault than a real possibility.
        The situation is identical to an standard spanning tree protocol 
attack (a bridge issuing fake BPDUs with very low priority and MAC). The 
standard STP protocol is vulnerable to such attacks.     

Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid