Re: [rrg] an example of convergence

[Zied BEN HOUIDI <[e-mail]>]

Hi,

I see two distinct issues in your post. The time to receive/send routes and
the time to install them back to FIB.

The first post is about the FIB installing time (krt queue blocking).

In the older posts (three years ago), it was probably more about route
sending rate.

http://puck.nether.net/pipermail/juniper-nsp/2007-February/007655.html
http://puck.nether.net/pipermail/juniper-nsp/2007-February/007575.html
"7 minutes seems rather long as the links between peers are between 2.5G to
10G"

This looks like an issue with the slow BGP route sending rate that we
discovered on routers from three different vendors. In fact, the sending of
routes is one order of magnitude slower than it should be (despite the high
link capacity, the table transfer was slow and both routers, the sender and
the receiver, were almost idle during the table transfer).
We found that it is due to the timer driven implementation of the
interaction between BGP and TCP. We showed, using a software BGP speaker
(sbgp) that an event driven implementation can reduce transfer times from 4
minutes to 7 seconds (680,000 routes). We also opened a case with one of the
router vendors. The vendor confirmed that it was due to the timer driven
implementation and modified its BGP implementation to be event driven.
Convergence time in the vendor's set up went from 12minutes to 47 seconds
with the new implementation/fix.

Here is an experimental study that we've made on this issue and on BGP
routing table transfers in general (it appeared in the last Internet
Measurement Conference IMC2009).
http://delivery.acm.org/10.1145/1650000/1644935/p350-benhouidi.pdf?key1=1644935&key2=8304478621&coll=GUIDE&dl=GUIDE&CFID=82157635&CFTOKEN=81293083
You may find more details about different factors that impact BGP routing
table transfers (route sending, table size, route installing, number of BGP
sessions, router CPU).


Kind regards,
---
Zied Ben Houidi
Phd Candidate at Orange Labs


2010/3/16 Pekka Savola <[e-mail]>

> On Mon, 15 Mar 2010, Tony Li wrote:
>
>> <employer hat off>
>> Any operator who would like to stand up and embarrass their favorite
>> router
>> vendor by showing a graph of router boot convergence times is welcome to
>> do
>> so.  ;-)
>> </employer hat off>
>>
>
> Ok, I'll jump on my soap box.  In worst case, Juniper high-end routers have
> been demonstrated to take up to 10 minutes to install RIB to FIB. During
> this time, packets usually get blackholed (aka "krt queue blocking").  See
> thread in j-nsp in Dec 2009:
>
> http://www.mail-archive.com/[e-mail]/msg07663.html
>
> A bit of continuation here:
>
> http://www.mail-archive.com/[e-mail]/msg07833.html
>
> This is not a new issue;  It has started appearing over 3 years ago:
>
> http://puck.nether.net/pipermail/juniper-nsp/2007-February/007655.html
> http://puck.nether.net/pipermail/juniper-nsp/2007-February/007575.html
>
> I've personally pursued a case with Juniper TAC on this for a long time but
> eventually gave up.  One known architectural bottleneck is the slowness of
> RE-PFE IPC (unix socket), but I don't really belive in this being the root
> cause.  I know others have also tried to work with the vendor to get this
> fixed.
>
> Semi-relevant may also be a graph of BGP update sizes during a BGP DFZ flap
> event that I sent to idr list three years back, showing that of 87K BGP
> updates due to a single event, almost all of them are below 100 bytes in
> size.
>
> http://www.ietf.org/mail-archive/web/idr/current/msg02398.html
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg
>