Getting pretty close to default IPv4 route maximum for 6500/7600routers.

Bryan Tong contact at nullivex.com
Mon Jun 9 19:27:21 UTC 2014


The IPv6 table will not be as big as the v4 table even after full
acceptance. Given that most providers will be advertising a single /32 and
then rest will be some /48 routes for multi-homed scenarios.

My router looks like this

FIB TCAM maximum routes :
=======================
Current :-
-------
 IPv4                - 600k
 MPLS                - 32k
 IPv6                - 160k
 IP multicast        - 32k

Probably a little heavy on MPLS considering we dont use it. With the
current level of exhaustion I dont think IPv4 will make it past 600k.

We are currently seeing 520,000 routes.

There are currently 107M IPs left globally.

If those all went to /21's that would require 26,255 prefixes.
If those all went to /22's that would require 52,510 prefixes.
If those all went to /24's that would require 105,021 prefixes.

So even the most conservative maximum should be no more than 626K





On Mon, Jun 9, 2014 at 1:09 PM, Jon Lewis <jlewis at lewis.org> wrote:

> Why, in your example, do you bias the split so heavily toward IPv4 that
> the router won't be able to handle a current full v6 table?  I've been using
>
>
> mls cef maximum-routes ip 768
>
> which is probably still a little too liberal for IPv6
>
> FIB TCAM maximum routes :
> =======================
> Current :-
> -------
>  IPv4                - 768k
>  MPLS                - 16k (default)
>  IPv6 + IP Multicast - 120k (default)
>
> given that a full v6 table is around 17k routes today.
>
> A more important question though is how many 6500/7600 routers will fully
> survive the reload required to affect this change?  I've lost a blade
> (presumably to the bad memory issue) each time I've rebooted a 6500 to
> apply this.
>
>
> On Mon, 9 Jun 2014, Pete Lumbis wrote:
>
>  The doc on how to adjust the 6500/7600 TCAM space was just published.
>>
>> http://www.cisco.com/c/en/us/support/docs/switches/
>> catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html
>>
>>
>> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis <alumbis at gmail.com> wrote:
>>
>>  There is currently a doc for the ASR9k. We're working on getting on for
>>> 6500 as well.
>>>
>>>
>>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-
>>> series-aggregation-services-routers/116999-problem-line-card-00.html
>>>
>>>
>>>
>>>
>>> On Tue, May 6, 2014 at 1:34 PM, <bedard.phil at gmail.com> wrote:
>>>
>>>  I would like to see Cisco send something out...
>>>>
>>>> -----Original Message-----
>>>> From: "Drew Weaver" <drew.weaver at thenap.com>
>>>> Sent: яя5/яя6/яя2014 11:42 AM
>>>> To: "'nanog at nanog.org'" <nanog at nanog.org>
>>>> Subject: Getting pretty close to default IPv4 route maximum for
>>>> 6500/7600routers.
>>>>
>>>> Hi all,
>>>>
>>>> I am wondering if maybe we should make some kind of concerted effort to
>>>> remind folks about the IPv4 routing table inching closer and closer to
>>>> the
>>>> 512K route mark.
>>>>
>>>> We are at about 94/95% right now of 512K.
>>>>
>>>> For most of us, the 512K route mark is arbitrary but for a lot of folks
>>>> who may still be running 6500/7600 or other routers which are by default
>>>> configured to crash and burn after 512K routes; it may be a valuable
>>>> public
>>>> service.
>>>>
>>>> Even if you don't have this scenario in your network today; chances are
>>>> you connect to someone who connects to someone who connects to someone
>>>> (etc...) that does.
>>>>
>>>> In case anyone wants to check on a 6500, you can run:  show platform
>>>> hardware capacity pfc and then look under L3 Forwarding Resources.
>>>>
>>>> Just something to think about before it becomes a story the community
>>>> talks about for the next decade.
>>>>
>>>> -Drew
>>>>
>>>>
>>>>
>>>
>>
> ----------------------------------------------------------------------
>  Jon Lewis, MCP :)           |  I route
>                              |  therefore you are
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>



-- 
eSited LLC
(701) 390-9638



More information about the NANOG mailing list