[rrg] an example of convergence

Pekka Savola <pekkas@netcore.fi> Tue, 16 March 2010 08:25 UTC

Return-Path: <pekkas@netcore.fi>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC363A68D1 for <rrg@core3.amsl.com>; Tue, 16 Mar 2010 01:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level:
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHb2zyqFV1EG for <rrg@core3.amsl.com>; Tue, 16 Mar 2010 01:25:15 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 951F93A67E9 for <rrg@irtf.org>; Tue, 16 Mar 2010 01:25:14 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id o2G8P902030919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 10:25:09 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id o2G8P84X030916; Tue, 16 Mar 2010 10:25:09 +0200
Date: Tue, 16 Mar 2010 10:25:08 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Tony Li <tony.li@tony.li>
In-Reply-To: <C7C3EEFA.604E%tony.li@tony.li>
Message-ID: <alpine.LRH.2.00.1003161007360.26291@netcore.fi>
References: <C7C3EEFA.604E%tony.li@tony.li>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: clamav-milter 0.95.3 at otso.netcore.fi
X-Virus-Status: Clean
Cc: RRG <rrg@irtf.org>
Subject: [rrg] an example of convergence
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2010 08:25:16 -0000

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/juniper-nsp@puck.nether.net/msg07663.html

A bit of continuation here:

http://www.mail-archive.com/juniper-nsp@puck.nether.net/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