[rbridge] Traffic storms

[Gray, Eric]

Gideon,

	This is a good question.  Please see comments and responses 
below...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Gideon Kaempfer
--> Sent: Thursday, November 02, 2006 6: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.

This is exactly the reverse of the "chicken and egg" problem I mentioned
in dicussions of the "wiring closet" problem (note the similar topology)
with Guillermo (IBAÑEZ), back in July.

In the "wiring closet" problem, the intention is to "break" the link between
B1 and B2 so that - in normal operation - both links [B1<->RB1 and B2<->RB2]
are used, while link [B1<->B2] is not.

In this case, you're positing that the link becomes active.  I have seen - 
and studied - this scenario in analysis.  I am reasonably sure others have 
as well.

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

One thing that you're not considering is that both B1 and B2 will send out
"topology change" BPDUs when the link [B1<->B2) goes active.  I believe 
several of the WG members have pointed out that the idea that RBridges 
"drop BPDUs" does not mean they ignore them - in particular, in the case 
of a "topology change" BPDU.

Ignoring this for a minute, it is worth noting that - in this scenario - 
both RBridges are in position to "get a clue" about the problem.  The MAC 
SA on the broadcast frame (forwarded onto the segment including B2, for
example), is a MAC DA that it may know is present on that segment, by the
time it is deciding whether or not to forward it on that segment.  

Typically, bridges will perform a consistency check, when learning a new
MAC from a received frame.  There is no reason to suppose that RBridges
are unable to perform this same trick.  The consistency check is - when 
a new MAC SA is seen on a port, the "bridge" makes a new filtering DB
entry for that port (showing that MAC as reachable via that port); at the
same time, the bridge should check that a matching entry does not exist
on another port. 

In the scenario you pose, the same broadcast frame will arrive at both 
RBridges from different ports, resulting in an apparent need to "learn"
the same MAC SA on both ports (order is not important) - resulting in 
the finding of "matching entries" at each RBridge.

If a matching entry is found, a clue is born - even if the RBridge hasn't
already determined (by BPDU snooping) that a topology change is happening. 

This may happen because, at the same time B1 forwards the broadcast frame 
(from H1) to RB1, it forwards it to B2 as well (as you note above).  B2 is
also going to forward that frame to RB2, which will attempt to forward it 
to RB1.  Meanwhile, RB1 will try to forward the broadcast frame, it gets
from B1, toward RB2.  No matter what order this occurs in, one or both of
the RBridges are going to detect an anomaly.

Of course, this assumes that both RBridges did not snoop a topology change
BPDU from either B1 or B2 - which would have directly clued them in on the
potential problem.

As Silvano has already indicated (and - I believe - gotten full agreement),
broadcast, multicast and flooded traffic - at least - must stop during a
topology change (just as it would in 802.1D bridging).

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

Assuming reasonably "clueful" RBridge implementations, no storm will occur.

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

See above.

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

If RB1 and RB2 behave reasonably, this problem will either never occur, or
will be resolved as quickly as it would be in 802.1D bridging.

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

Yes, this is another approach.  Combine this with the fact that RB2 may also
have received a new reachability advertisement (via IS-IS) from RB1 (or have
one already from previous advertisements), saying that this MAC is reachable

via RB1 - just as RB2 should be considering make such an advertisement
itself.

This is an obvious inconsistency, and - while we do want to support mobility
- we do not have to optimize for it by assuming that all MAC "relocations"
are
automatically legitimate.

--> 
--> As mentioned above, any comments are welcome.
-->   Gideon Kaempfer
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->