[rbridge] it's time to summarize things

[Saikat Ray]

> 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 :)

>
>
>  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
>