[rbridge] Traffic storms

[Gideon Kaempfer]

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> 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
> >http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061103/0fb6bdf5/attachment-0001.html