[rbridge] it's time to summarize things
Guillermo Ibáñez
gibanez at it.uc3m.es
Sun Dec 18 11:49:46 PST 2005
I was not aware of this mail. I am glad to know you see it in the same
way. I see it more than an optimization, a way to make consistent
operation, although very loosely coupled, between RSTP and RBridges IS-IS.
Guillermo
Saikat Ray wrote:
>This was also discussed :) I raised precisely the same issues. Please see
>
>http://www.postel.org/pipermail/rbridge/2005-October/000687.html
>
>Radia had sent a reply, which I couldn't find in the list. Anyway, it is
>sufficient that RBridges see the BPDU's to stop packet forwarding when a
>legacy spanning tree starts to change, they do not need to be a part of
>the spanning tree for this purpose. But I agree that merging the spanning
>tree root bridge selection process with DR selection seems to be a nice
>idea.
>
>On Sat, 17 Dec 2005, [ISO-8859-1] Guillermo Ibáñez wrote:
>
>
>
>>Saikat, see below
>>Guillermo
>>
>>
>>Saikat Ray wrote:
>>
>>
>>
>>>>Saikat Ray wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The simplest, if not the most rigorous, explanation is as follows. Replace
>>>>>each legacy part of the network by a hub (i.e., first remove all RBridges
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>from the topology. Then choose a legacy bridge and replace this bridge and
>>>>
>>>>
>>>>
>>>>
>>>>>all legacy bridges that have a path to it by a single hub, and let all
>>>>>end-hosts served by those legacy bridges be connected to this hub. Repeat
>>>>>this procedure until all legacy bridges are replaced. Then finally put the
>>>>>RBridges back.). Now, one and only one RBridge forwards and receives
>>>>>unencapsulated packets from each hub (through designated RBridge).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>But what happens when two separate hubs with separate RBridges
>>>>forwarding each one traffic are connected
>>>>by a link restoration between them?. A single "hub" will be created with
>>>>two Designated RBridges till the
>>>>detect the situation. How (and how fast), the DR election mechanims
>>>>should work in this situation?
>>>>Guillermo
>>>>
>>>>
>>>>
>>>>
>>>This was discussed long before. The frequency of RBridge hello messages
>>>will determine the length of transience (once a hello is sent, the
>>>presence of two RBridges on the same "hub" will be detected). Radia had
>>>some comments about the numerical value of the frequency, which I do not
>>>remember; it is in one of the emails on the list :)
>>>
>>>
>>>
>>>
>>>
>>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
>>
>>
>>
>>>>Thus for
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>a loop formation, a packet must loop back to a designated RBridge, which is
>>>>>not possible since RBridges use their own spanning tree for sending
>>>>>(encapsulated) broadcast traffic.
>>>>>
>>>>>Hope this helps.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>>>>>>Behalf Of Tim Shepard
>>>>>>Sent: Thursday, December 15, 2005 6:42 PM
>>>>>>To: Developing a hybrid router/bridge.
>>>>>>Cc: Radia.Perlman at Sun.COM; 'Joe Touch'
>>>>>>Subject: Re: [rbridge] it's time to summarize things
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Let us suppose that an RBridge is connected to a legacy bridge's port
>>>>>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>from
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>the perspective of the legacy brige, either (i) a single end-host (with
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>MAC address that of the RBridge) if the RBridge is not the designated
>>>>>>>RBridge, or (ii) a shared media (like a hub; is the standard term
>>>>>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>fact,
>>>>>>[....]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>So what exactly do you think is the problem with ARP?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>I'm not sure I follow all of the postings on this issue.
>>>>>>
>>>>>>But after reading through this thread, I'm still left wondering what
>>>>>>is supposed to make sure packets don't loop forever when there are a
>>>>>>mix of bridges and rbridges plugged together (in some crazy accidental
>>>>>>way, creating whatever kind of loop involving bridges and rbridges
>>>>>>that causes the most trouble).
>>>>>>
>>>>>>It seems to me that if rbridges block the spanning tree forming
>>>>>>packets, but do forward (e.g.) ARP traffic, then there could be loops
>>>>>>that are not broken by either the rbridge system or the usual bridge
>>>>>>spanning-tree-forming algorithm.
>>>>>>
>>>>>>Could someone explain succinctly (for someone who is just barely
>>>>>>following this thread) how a system (of mixed bridges and rbridges,
>>>>>>plugged together by some Byzantine net admin) will ensure that packets
>>>>>>are not forwarded in a loop?
>>>>>>
>>>>>>(And ARP is a good example, since it is supposed to go everywhere, but
>>>>>>not loop.)
>>>>>>
>>>>>>
>>>>>>Or will there be configuration rules that forbid some ways of plugging
>>>>>>together bridges and rbridges?
>>>>>>
>>>>>> -Tim Shepard
>>>>>> shep at alum.mit.edu
>>>>>>_______________________________________________
>>>>>>rbridge mailing list
>>>>>>rbridge at postel.org
>>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>_______________________________________________
>>>>>rbridge mailing list
>>>>>rbridge at postel.org
>>>>>http://www.postel.org/mailman/listinfo/rbridge
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Guillermo Ibáñez
>>>>Departamento de Ingeniería Telemática
>>>>Universidad Carlos III de Madrid
>>>>1.1.B.11 Colmenarejo 91-6241393
>>>>4.1.F.13 Leganés 91-6248794
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>--
>>Guillermo Ibáñez
>>Departamento de Ingeniería Telemática
>>Universidad Carlos III de Madrid
>>1.1.B.11 Colmenarejo 91-6241393
>>4.1.F.13 Leganés 91-6248794
>>
>>
>>
>>
>
>
>
--
Guillermo Ibáñez
Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Leganés 91-6248794
More information about the rbridge
mailing list