[rbridge] it's time to summarize things
Guillermo Ibáñez
gibanez at it.uc3m.es
Sat Dec 17 01:09:54 PST 2005
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
More information about the rbridge
mailing list