[181724] in North American Network Operators' Group
Re: Route leak in Bangladesh
daemon@ATHENA.MIT.EDU (Mark Tinka)
Wed Jul 1 11:01:44 2015
X-Original-To: nanog@nanog.org
To: Nick Hilliard <nick@foobar.org>, Jared Mauch <jared@puck.Nether.net>
From: Mark Tinka <mark.tinka@seacom.mu>
Date: Wed, 1 Jul 2015 16:57:21 +0200
In-Reply-To: <5593FEB9.5090101@foobar.org>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On 1/Jul/15 16:52, Nick Hilliard wrote:
> This is a strange sort of thing really. There's no reason that a compiled
> prefix list of 250k entries should take up much RAM in a trie structure;
> there's no reason that a competently written parser shouldn't be able to
> handle 20 megs of prefix lists / sets in a trivial amount of time and
> there's no reason that writing a 20 meg configuration file should take long
> to write to disk / flash / etc.
>
> BIRD handles this in ultraquick time. Even recent versions of Quagga can
> now suck + parse 10 megs of prefix filters in a second or two and write
> them out in less.
>
> But Junos / IOS / XR puke horribly. What gives?
Nick, I think the concerns are two-fold:
1. The time it takes to process the trie.
2. How much physical space there is to support the configuration.
Remember some high-end Cisco routers only have 2MB of NVRAM. This could
get tested with a large prefix-list configuration. Junos may not have
much of a space issue since the configuration is stored on the compact
flash or HDD.
Trie compilation or process will be very OS-dependent, and how the
vendor has chosen to optimize that operation.
Mark.
