netdev
[Top] [All Lists]

Re: Route cache performance under stress

To: Simon Kirby <sim@xxxxxxxxxxxxx>
Subject: Re: Route cache performance under stress
From: Florian Weimer <fw@xxxxxxxxxxxxx>
Date: Tue, 17 Jun 2003 22:58:31 +0200
Cc: ralph+d@xxxxxxxxx, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>, "linux-net@xxxxxxxxxxxxxxx" <linux-net@xxxxxxxxxxxxxxx>
In-reply-to: <20030609163010.GA11509@xxxxxxxxxxxxx> (Simon Kirby's message of "Mon, 9 Jun 2003 09:30:10 -0700")
Mail-followup-to: Simon Kirby <sim@xxxxxxxxxxxxx>, ralph+d@xxxxxxxxx, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>, "linux-net@xxxxxxxxxxxxxxx" <linux-net@xxxxxxxxxxxxxxx>
References: <20030608234926.GA9453@xxxxxxxxxxxxx> <001001c32e19$81bc7ea0$4a00000a@badass> <20030609064719.GA20613@xxxxxxxxxxxxx> <Pine.LNX.4.51.0306090918400.11389@xxxxxxxxxxxx> <20030609163010.GA11509@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux)
Simon Kirby <sim@xxxxxxxxxxxxx> writes:

> What Zebra quirks?

Zebra doesn't send BGP keepalives while updating the kernel's view of
the routing table.  If a configuration change results massive routing
table updates (e.g. changed LOCAL_PREF), it's quite likely that you
BGP peering sessions terminate because of a timeout.

Other "quirks" are just things that don't work as they should (mostly
Cisco incompatibilities, sometimes genuine bugs in route-map support
etc.).

It's not dramatic in most cases, but like any complex technology, it
takes some time to get used to.

(Disclaimer: I'm not a Zebra user. 8-)

> And I wouldn't exactly call it difficult to "squeeze" performance out of
> a PC when the 7206 VXRs have a 200 MHz processor.

You missed the NPE-G1 part.

cisco 7204VXR (NPE-G1) processor (revision A) with 245760K/16384K bytes of 
memory.
SB-1 CPU at 700Mhz, Implementation 1, Rev 0.2, 512KB L2 Cache

Probably still slow by x86 standards, and with a rather small cache,
but it's sufficient for a few kpps, I guess...

<Prev in Thread] Current Thread [Next in Thread>