[c-nsp] BGP memory on a 6500

[David Sinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, lets break this down a little.

The DRAM on the MSFC is used for multiple things, including running  
all of your routing procotols.  Once the routing protocols have  
decide what routes they think are best and have pushed them to the  
routing table, CEF takes them and push them to the forwarding table  
on the PFC/DFC, along with mixing in any and all directly connected  
neighbors.  Directly connected neighbors are closely approximated by  
your ARP table.

In the specific case of BGP, depending on your BGP feeds, you may see  
some prefix's that have multiple possible routes to.  For the most  
part, BGP will select one it considers "best" (yes I'm  
oversimplifying some cases, but lets just go with it).  This "best"  
route is what is pushed to the routing table.  Thus you too can have  
300k (or more) possible BGP paths that will likely result in an  
actual routing table in the 180-200k range.  Only these "best" routes  
are pushed to the forwarding table on the PFC/DFC.

ACL's consume a totally separate section of memory on both the MSFC  
and the PFC/DFC's, be they "control plane" ACL's used to filter BGP  
routes, or "data plane" ACL's filtering packets.  Monitoring that is  
independent of how many forwarding entries you can have on your PFC.

Now, more to the point of your PFC2 and it's ability to hold your  
forwarding table.  You need to consider how many BGP routes you  
consider "best", how many IGP routes you will have and how many  
directly connected neighbors this box will talk to.  This is likely  
in the 200k prefix neighborhood which, as was pointed out below, is  
awfully close to the 256k max of a PFC2...  (Or the tangental case of  
PFC3B's with v6 stealing some table entries only giving you 192k  
entries, unless you tweak things.)

So when all is said and done, using a PFC2 or PFC3B with a full BGP  
routing table today is really cutting it close.  PFC3BXL's have a  
much better useful life.

David

On Sep 27, 2006, at 11:40 PM, Francois Corthésy wrote:

> Well, I'm no 6500 Guru, but my understanding of the TCAM is that it is
> used for *every* route, which in tunrs means that your internal  
> routing
> table/ARP count/BGP table all have to share the ~239'000 limit that  
> the
> TCAM has.
>
> Francois
>
>
> Rick Kunkel wrote:
>> Sakes alive, there's a snarl at every turn.  I appreciate every  
>> piece of
>> info though.
>>
>> Is the TCAM used for BGP?  Things I've read seem to indicate  
>> they're used
>> for ACLs.  Obviously, I'm bound to use some ACLs for BGP, but are  
>> there
>> other elements that the TCAM would be used for that woudl be  
>> limiting to
>> BGP?
>>
>> On another note, I've heard that the 7600 and 6500 are now almost
>> identical with the Sup720.  Is this true?
>>
>> Thanks much!
>>
>> Rick
>>
>> On Wed, 27 Sep 2006, Francois Corthésy wrote:
>>
>>
>>> Hi Rick,
>>>
>>> Might I point to this earlier discution :
>>> https://puck.nether.net/pipermail/cisco-nsp/2006-August/032822.html
>>>
>>> Essentially, If you plan on using anything else than a  
>>> Sup720-3BXL for
>>> Full BGP routing on a 6500 for more than 1 or 2 years you are stuck.
>>>
>>> Francois
>>>
>>> Rick Kunkel wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'm considering a 6500, and am trying to assemble a list of  
>>>> required
>>>> components.  I'm looking at the Sup2 with PSC2 and MSCF2.  You  
>>>> can get the
>>>> MSFC with 512MB of RAM.  Is THIS the RAM that the BGP routing  
>>>> table would
>>>> be used, or is that stored elsewhere?  If elsewhere, then where?
>>>>
>>>> THanks,
>>>>
>>>> Rick Kunkel
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
> _______________________________________________
> 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/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFHAgMLa9jIE3ZamMRAiAhAJ9N+dS+FRSFBB4EVFjc1q3ni3UgwwCaA+JF
0KHdZcve7opbXtxwcUz+L74=
=PBFh
-----END PGP SIGNATURE-----