Subject: [rbridge] Traffic storms

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 2 Nov 2006 18:37:59 -0800

Gideon,

You hit the nail on the head; this is one of the many examples in which
the current TRILL proposal will generate Broadcast Storm that will crash
any network.

This is the reason why, if we don't solve the Broadcast Storm, TRILL is
unusable and there is no point in building products.

I think we need to start to discuss possible solutions, since this can
influence also other aspects of the design.

Unfortunately I am more pessimistic than you: I think that TTL help very
little for Broadcast, since Broadcast replicate in HW. When TTL kicks
in, the storm has already happened.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Gideon Kaempfer
> Sent: Thursday, November 02, 2006 3:08 PM
> To: rbridge at postel.org
> Subject: [rbridge] Traffic storms
> 
> 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
> http://mailman.postel.org/mailman/listinfo/rbridge