[rbridge] Traffic storms

[Guillermo Ibáñez]

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

Radia Perlman escribió:
> 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
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>  
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>