[c-nsp] Maximum Full tables on GRP-B

[Lasher, Donn]

Due to the way that BGP works, you won't end up with "full" tables from each
one. The router will work out a single table out of all the speakers once
the route processing  has settled down. That single table will be the memory
pig... (well BGP + CEF together...)

That being said, I'd be surprised if (5) full feeds plus other peers gave
you any trouble at all. If they all cleared at once, it might get ugly, but
the differing rates of routes flowing in should buffer most of that.

Here's a GRP-B/512M running (4) upstreams and 90+ peers:

231762 network entries using 26420868 bytes of memory
815105 path entries using 42385460 bytes of memory
293340/40734 BGP path/bestpath attribute entries using 38720880 bytes of
memory
135251 BGP AS-PATH entries using 3723510 bytes of memory
6455 BGP community entries using 426114 bytes of memory

Processor Pool Total:  433270272 Used:  313667300 Free:  11960297


And I sure wouldn't try that on a 256M GRP-B....

 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dan Armstrong
Sent: Monday, April 30, 2007 4:04 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Maximum Full tables on GRP-B

As a rule of thumb, how many peers with full routing tables do you think you
could put on a GRP-B with 512M or RAM?

Would it be suicide to do 5 full feeds + some smaller peering?


_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3742 bytes
Desc: not available
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20070430/f31b34d8/attachment-0001.bin