Subject: [rbridge] Traffic storms

From: gidi at gidik.com (Gideon Kaempfer)
Date: Fri, 3 Nov 2006 01:07:54 +0200

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 02 Nov 2006 22:25:06 -0800

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:

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

---

From: gidi at gidik.com (Gideon Kaempfer)
Date: Fri, 3 Nov 2006 08:40:25 +0200

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

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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 03 Nov 2006 09:35:49 +0100

This comment is just to signal that the behaviour must be analyzed also 
assuming that B1 and B2 execute the (current standard) RSTP protocol.  
There is no forwarding delay in RSTP when the links are dedicated (point 
to point).
If B1 and B2 execute RSTP protocol and B1 has best priority, before  
link B1-B2 being enabled, B2 will block its designated ports  and stop 
forwarding  to RB2.  The process will repeat later  for next stage 
downstream links like B2-RB2 and so on, one level at a time.
The trend is to uses RSTP instead of STP. Root bridge election is likely 
much faster  than DR election. Setting timers at RBridges to stop 
forwarding may be a solution but it slows reconfiguration speed.
Guillermo

> 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