[c-nsp] ibgp on 6509 with sup2?

[Gert Doering]

Hi,

On Tue, Feb 10, 2015 at 03:42:23PM -0800, Joe Pruett wrote:
> with bgp filtering might i be able to install just routes of /20 or
> shorter (hoping that is a small enough number of routes). or would bgp
> still consume all the routes before it filters and thus run out of ram?
> i'd don't think i want to experiment with this in production :-).

The easiest way is to filter on *export* from the 7200s, so the 6509
has no chance to see the refused routes at all :-)

Seriously: unless you configure "soft reconfiguration" on your peers, a
route that is dropped will go away, without any traces.  But it *will*
consume CPU (some tiny amount), so if you already know what the downstream
router wants, just not sending it from upstream is easier.

If I remember right, Sup2 had 256k FIB, going to half that if you enable
uRPF.  So if you set your iBGP-sessions to "max-prefix 230000" (or 115000),
and then experiment with feeding it more and more routes, you should
be fairly safe...

[..]
> and from my reading it sounds like even going to a sup 2t wouldn't
> really solve the problem? although most of that discussion seems to be
> external bgp, maybe ibgp wouldn't run into issues?

A sup2t(-xl) can handle 1 million routes, so that's plenty, but most
serious overkill to get it only for the routing table memory.

> oh, and i run full ipv6 as well, just to make it interesting.

Sup2 and IPv6 is software forwarding, so that might be some reason to
upgrade eventually...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 291 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20150211/5e0ef796/attachment.sig>