[rbridge] Traffic storms

Fri Nov 3 11:54:06 PST 2006

Gideon,

    "Drop BPDUs" is not (exactly) the same as ignore them.  We use the term 
as short-hand for the one of three options we considered for handling BPDUs:

    Drop (do not participate actively in STP, and do not pass BPDUs
through), 
    Transparent (pass BPDUs through - potentially altering them in some
way),
    Participate (have each RBridge participate in STP as if it were a
bridge).

Hence, when we say "Drop BPDUs" we are not saying that we cannot look 
at them, we are just saying that we're not doing one of the other two
choices.

--
Eric

  _____  

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Gideon Kaempfer
Sent: Friday, November 03, 2006 1:40 AM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] Traffic storms

Radia,
Wouldn't this create a link between TRILL and STP we are trying to avoid?
Relying on the fact that a LAN segment has some kind of unique identifier
(such as the root bridge ID) seems like a very practical solution to me, but
strongly reliant on the fact that the Rbridges actually process BPDUs. I
thought they were just meant to discard them. Is this acceptable? 
Regrads,
 Gidi

On 11/3/06, Radia Perlman <Radia.Perlman at sun.com
<mailto:Radia.Perlman at sun.com> > wrote: 

The simplest way to put it, I think, is that in certain transitory
situations there might be two
RBridges that both think they are Designated RBridge, and that is bad, 
but should stop
as soon as a single Hello is received by the RBridge who should not be
Designated.

I think PIM has similar transitory situations that can occur, and
bridges can also have (hopefully
temporary) problems if a repeater came up and merged two LANs. I think
such things are
annoying but not fatal. But I think it's possible we can with little
effort avoid this problem.

However, with RBridges, because the bridge spanning tree algorithm 
elects a Root, there's
really a way of uniquely identifying a LAN (where "LAN" is a bunch of
links connected with
bridges). The unique identifier is the root bridge.

When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
separate links, and each
one will have a distinct spanning tree Root bridge (RB1 will see B1, and
RB2 will see B2 as the root).

When the B1-B2 link comes up, the bridges will first merge the two
links, and either RB1 or RB2 will 
see that the bridge spanning tree root has changed. This will be
discovered before B1 and B2 forward
traffic across the link because of the bridge forwarding delay.
If B1 has better priority as bridge spanning tree root than B2, then RB1 
will not notice anything
different when the B1-B2 link comes up. But RB2 will notice
something different; the spanning tree root has changed identities from
"B2" to "B1".

Given this, RB2 could temporarily stop forwarding to or from the link 
when the Root bridge
changes identities, though it should definitely immediately send IS-IS
Hellos (either RB1 or RB2 will
be elected Designated Router in the IS-IS election for that link). If
RB2 has better prioirty for 
root, the RB1 will immediately stop forwarding to or from the link when
it sees the Hello from RB2.
If RB2 has better priority in the IS-IS election, then RB1 should
immediately send an IS-IS Hello
when it sees a Hello from a new RBridge on the link. 

So I think this is not a big deal, and that if we are worried, we can
specify that an RBridge should
stop acting like the Designated RBridge for a few seconds after the
identity of the Root in the spanning 
tree algorithm changes.

Or we could be even fancier and have each RBridge announce in its IS-IS
Hellos which LAN IDs it
is Designated for, where a LAN ID is the MAC address of the Root bridge.
So RB1 continue 
forwarding if the identity changes from B1 to B2 provided no other
RBridge has claimed to be connected
to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop
forwarding for enough time
for the IS-IS election to sort itself out and choose a Designated RBridge. 

Radia

Gideon Kaempfer wrote:

>Following mention by Silvano of broadcast and multicast storms (and the
need
>to protect against them), I played around with different scenarios and came

>upon one I would appreciate your comments on (in the hope I am pointing out
>a non-existent issue with TRILL). I believe a broadcast and even a unicast
>storm could be created as the result of a loop that isn't protected by TTL 
>nor by STP in the case of a link connecting two separate LAN segments
coming
>to life.
>
>- RB1 ---- RB2 -
>   |        |
>-  B1 --x-- B2 -
>   |        |
>   H1       H2
>
>1. The network (segment) involved consists of two Rbridges (RB1, RB2), two
>bridges (B1, B2) and two hosts (H1, H2). They are physically connected as
>depicted.
>2. State A: the direct link between B1 and B2 is down. B1 and B2 find 
>themselves on different LAN segments and hence different spanning trees.
RB1
>and RB2 are both designated Rbridges (each for the segment of the
>corresponding bridge).
>3. State B: the direct link between B1 and B2 goes up (someone connects a 
>cable). B1 and B2 discover each other and establish a common spanning tree.
>RB1 and RB2 both find themselves attached to the same LAN segment and hence
>RB1 (without loss of generality) will eventually become the designated 
>Rbridge for it.
>4. Just before RB1 and RB2 identify that they are both on the same segment
>and RB2 stops functioning as a designated Rbridge the following scenario
>seems possible:
>  a. H1 sends a broadcast frame. 
>  b. B1 receives it and forwards to RB1 and B2.
>  c. RB1 (encapsulates and) forwards to RB2.
>  d. B2 forwards to RB2 and H2.
>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2 to RB1). 
>  f. (RB1 forwards to B1.)
>  g. B2 forwards (again) to H2 and to B1.
>  h. B1 forwards to H1 (see remark below regarding filtering table
>contamination) and to RB1.
>  i. Etcetera etcetera. 
>5. A broadcast storm is born, created by a loop that is not protected by
TTL
>(due to the fact that forwarding between the Rbridges is only across a
>single hop) nor by STP (due to the fact that Rbridges do not participate in

>STP).
>6. If forwarding commences at the hardware level and no broadcast rate
>limiting is in place, the storm may cause severe damage in a very short
time
>(note that replicated frames are sent to H1 and H2 (or any network they 
>could represent).
>7. Another unfortunate effect of this storm is that B1 and B2 no longer
know
>where H1 is located (due to the contamination of their filtering tables by
a
>frame from H1 that arrives from the wrong direction (and in fact from 
>multiple directions). As a result, a possible unicast frame from H2 to H1
>will just join the storm over the loop at least in one direction (RB2 will
>forward it to RB1) but will not arrive at H1...
>
>One possible solution could be for RB2 to identify the fact that it is
>receiving a frame from a host with a MAC address that is associated with a
>segment it thought it isn't connected to. Hence, it may trigger an
immediate 
>neighbor discovery / designated Rbridge election. However, because Rbridges
>should allow host mobility, this frame may need to be forwarded (and hence
>the storm commences).
>
>As mentioned above, any comments are welcome. 
>  Gideon Kaempfer
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org <mailto:rbridge at postel.org> 
>  <http://mailman.postel.org/mailman/listinfo/rbridge>
http://mailman.postel.org/mailman/listinfo/rbridge
>
>

_______________________________________________
rbridge mailing list
rbridge at postel.org <mailto:rbridge at postel.org> 
http://mailman.postel.org/mailman/listinfo/rbridge
<http://mailman.postel.org/mailman/listinfo/rbridge> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061103/d2e21105/attachment-0001.html