Subject: [rbridge] Traffic storms

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 3 Nov 2006 15:11:47 -0500

Joel,

	These are techniques for preventing the formation of temporary
loops during a routing change.  Ordered FIB updates does not seen to
address the potential for dealing with a loop introduced through an
agency outside of routing.  For one thing, such loops exist before a
router can detect them, hence there is nothing a router can do to 
prevent them.

	Order FIB updates is a reasonable technique for avoiding loops
in reconstructing route entries after a purge, however, and this is 
something we should consider.  However, in the RBridge case, I think
FIB entries will be naturally ordered (once we are sure of a stable
bridge topology in attached LAN segments) by the process in which 
MAC address learning information is distributed - via IS-IS - from 
egress toward ingresses.

	Is that not true, or are there specific cases in which it might
not be true?

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joel M. Halpern
--> Sent: Friday, November 03, 2006 11:21 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Traffic storms
--> 
--> If we need to make the link state algorithm 
--> converge without introducing loops, the 
--> techniques for loop avoidance being discussed in 
--> the routing area may be of relevance.
--> In particular, ordered fib convergence seems quite suitable.
--> Yours,
--> Joel M. Halpern
--> 
--> At 10:31 AM 11/3/2006, Silvano Gai wrote:
--> 
--> >The examples from Gideon and Guillermo deal with 
--> >the interaction between STP/RSTP and TRILL and point one 
--> weakness of TRILL.
--> >
--> >There will be another cause for Broadcast storm 
--> >that does not involve STP/RSTP interaction, i.e. 
--> >a simple topology change in the TRILL network.
--> >
--> >Djikstar will run in an asynchronous way on the 
--> >different RBridges and the trees used to 
--> >distribute broadcast/multicast/unknown will 
--> >potentially have loops during the transition.
--> >
--> >TTL will be of limited help since the traffic 
--> >will replicate. For example, if the loop is 
--> >between two RBridges with 256 ports each, 
--> >assuming a TTL of 64, each broadcast present on 
--> >the link at the time the loop will cause a storm 
--> >of 16,000 frames. If the loops involve more 
--> >switches and links millions of copy will be 
--> >create. For Enterprise/Datacenter RBridges the 
--> >forwarding delay is less than 5 microseconds, 
--> >therefore the storm will reach its peak in 300 
--> >microseconds, well before any software intervention can 
--> break the loop.
--> >
--> >-- Silvano
--> >
--> > > -----Original Message-----
--> > > From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> > > Behalf Of Guillermo Ib??ez
--> > > Sent: Friday, November 03, 2006 12:36 AM
--> > > To: Developing a hybrid router/bridge.
--> > > Subject: Re: [rbridge] Traffic storms
--> > >
--> > > 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
--> > > >
--> > > _______________________________________________
--> > > 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
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->