Subject: [rbridge] loops in trill networks

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Tue, 11 Oct 2005 14:13:01 -0700

Joe,

As far as I know, all variations of STP guaranteed that bridged networks
never have temporary loops, so existing bridges never have this problem.
If they did, then I'd agree that it is no different. 

 - Larry

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 1:47 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

Yes - but I think Radia pointed out that this is no different than how
existing bridges would behave in that circumstance.

joe

Larry Kreeger (kreeger) wrote:
> Joe,
> 
> The context was that during a topology change, there could be a 
> temporary loop.  While this temporary loop exists, 
> multicast/broadcasts would duplicate to edge ports each time they came

> around - until the TTL reaches its limit.
> 
>  - Larry
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] 
> On Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 1:02 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] loops in trill networks
> 
> 
> 
> Larry Kreeger (kreeger) wrote:
> 
>>>OK, I can see how a TTL will stop loops, and would prevent duplicate 
>>>known unicasts from being delivered, but how does a TTL stop 
>>>broadcast/multicast/unknown unicast frames from being duplicated to 
>>>edge ports each time the frame comes round the loop?
> 
> 
> The multicast/broadcast packets are forwarded by one or more spanning 
> trees. There should never be loops in those anyway as a result.
> 
> Joe
> 
> 
>>>Or is this considered
>>>OK behavior in an RBridge network compared to an 802.1 bridged
> 
> network?
> 
>>>New to all this...  - Larry
>>>
>>>-----Original Message-----
>>>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>>On Behalf Of Joe Touch
>>>Sent: Tuesday, October 11, 2005 7:07 AM
>>>To: Developing a hybrid router/bridge.
>>>Subject: Re: [rbridge] loops in trill networks
>>>
>>>There is, and that's what it's there for.
>>>
>>>Joe
>>>
>>>Mike Hughes wrote:
>>>
>>>
>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa at pi.se> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>this might be an old discussion, but it is some time since it look 
>>>>>at
> 
> 
>>>>>it. What do we do in trill networks about transient loops, i.e. if 
>>>>>use
>>>
>>>
>>>>>link state protocols there is a possibility that we have transient 
>>>>>loops. With no TTL mechanisms those looping frames could cause 
>>>>>quite a
>>>
>>>
>>>>>bit of problem.
>>>>
>>>>
>>>>Unless I've missed something, or things have changed overnight, 
>>>>there is a TTL provided in the SHIM header.
>>>>
>>>>Mike
>>>
>>>_______________________________________________
>>>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
_______________________________________________
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

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 14:22:01 -0700

> If they did, then I'd agree that it is no different. 

I'm confused. We are using STP for multicast/broadcast inside the
campus. Why then will that STP cause loops whereas current bridges do not?

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 14:47:43 -0700

There was never a "guarantee" in STP that there not be loops. STP 
attempted to
avoid them by waiting before turning ports on. RSTP, instead of waiting 
before turning on ports,
attempts to avoid loops by using local information to turn some links on 
while turning others off.

Although it's certainly good to try to avoid temporary loops, it's never 
possible to *guarantee*
no temporary loops. These can be caused by misconfiguration (someone 
claiming a port will
only have endnodes, whereas it actually does get connected to a switch), 
by bringing up
a repeater, or having enough consecutive BPDUs lost for whatever reason 
(congestion on
the link causing packets to not reach a bridge, or the bridge not being 
able to keep up
with worst case wire speed).

The thing that got me interested in this again is finding out that 
bridge meltdowns (due to
temporary loops) do occur, and apparently with increasing frequency with 
new features that
have been added to bridges that involve configuration that can be 
disastrous if set incorrectly,
or with bridges deployed that can't keep up with wire speeds.

So the idea is that although it's certainly good to try to avoid 
temporary loops, we want to make
it not a disaster if they do occur.

Radia