Re: Route table growth and hardware limits...talk to the filter

On 9/20/07 2:03 PM, "Jon Lewis" <jlewislewis.org> wrote:

> 
> On Thu, 20 Sep 2007, Matt Liotta wrote:
> 
>> I was playing with a sup2 adding in extra routes to
the point that it ran out
>> of memory. Unfortunately, it didn't just drop
routes like I thought it would.
>> CEF disabled itself as well, which on a busy box
would be a disaster.
>> 
>> Is this what people expect will happen in a few
months to people using sup2s?
>> Or am I missing something else?
> 
> That's not good.  What software version was it
running?


While it is not good, the alternative approach would leave
an indeterminate
routing table in hardware. Would you like the packets to go
to randomized
directions?

The box is trying to do the right thing by turning off CEF
and switching
everything in software since in this case software is the
only entity in the
system with a consistent FIB.

An alternate would be to use the hardware forwarding tables
as a limited
size cache (similar but not exactly as in the 7000 router).
I am sure that
this is a large software effort and whether the hardware can
support this is
questionable.

SUP2 was a great RP with a really long life, but maybe it is
time to move on
to a SUP720 with the large table option and then grab a cold
one 

Cheers,

Bora

On Thu, 20 Sep 2007, Bora Akyol wrote:

>>> I was playing with a sup2 adding in extra
routes to the point that it ran out
>>> of memory. Unfortunately, it didn't just drop
routes like I thought it would.
>>> CEF disabled itself as well, which on a busy
box would be a disaster.
>>>
>>> Is this what people expect will happen in a few
months to people using sup2s?
>>> Or am I missing something else?
>>
>> That's not good.  What software version was it
running?
>
> While it is not good, the alternative approach would
leave an indeterminate
> routing table in hardware. Would you like the packets
to go to randomized
> directions?

No, but someone previously posted that with later software
versions, when 
TCAM runs out, packets for those routes that fit in TCAM are
hardware 
switched, and only traffic for the remaining routes that
didn't fit are 
software switched.  That could potentially go unnoticed for
some time, 
while software switching all traffic is likely be impossible
on many 
installations.  I kind of doubt the MSFC2 can software
switch gigabits/s 
of traffic (or anything close to gigabits/s).

> SUP2 was a great RP with a really long life, but maybe
it is time to move on
> to a SUP720 with the large table option and then grab a
cold one 

Or start filtering some of the twit networks that totally
deagg their 
CIDRs.  I see a game of internet chicken in the near
future...only some of 
the players don't realize they're playing.

------------------------------------------------------------
----------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org
/~jlewis/pgp for PGP public key_________

> No, but someone previously posted that with later
software versions, when
> TCAM runs out, packets for those routes that fit in
TCAM are hardware
> switched, and only traffic for the remaining routes
that didn't fit are
> software switched.

that would have been me.  and the comments on the logic
still stand (as
correct) provided you are running the appropriately
non-ancient release of
code.


cheers,

lincoln (ltdcisco.com)

On Fri, 21 Sep 2007, Lincoln Dale wrote:

>> No, but someone previously posted that with later
software versions, when
>> TCAM runs out, packets for those routes that fit in
TCAM are hardware
>> switched, and only traffic for the remaining routes
that didn't fit are
>> software switched.
>
> that would have been me.  and the comments on the logic
still stand (as
> correct) provided you are running the appropriately
non-ancient release of
> code.

Do you know in what version this behavior was changed?  At
the very least, 
people are going to want to upgrade IOS, as it'll likely
mean the 
difference between slightly increased MSFC CPU and a switch
that can't 
cope.

------------------------------------------------------------
----------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org
/~jlewis/pgp for PGP public key_________

Jon Lewis wrote:
> Do you know in what version this behavior was changed? 
At the very 
> least, people are going to want to upgrade IOS, as
it'll likely mean the 
> difference between slightly increased MSFC CPU and a
switch that can't 
> cope.
> 
I looked at the IOS version I ran the test on it was quite
old (12.1). I 
am happy to rerun the test with other versions of IOS. Any
suggestions?

-Matt

> Jon Lewis wrote:
> > Do you know in what version this behavior was
changed?  At the very
> > least, people are going to want to upgrade IOS, as
it'll likely mean the
> > difference between slightly increased MSFC CPU and
a switch that can't
> > cope.
>
> I looked at the IOS version I ran the test on it was
quite old (12.1). I
> am happy to rerun the test with other versions of IOS.
Any suggestions?

i'd suggest the most recent 12.2(18)SXF (its 12.2(18)SXF11)
or 12.2(33)SXH.
i think you'll find you get different results than your
original test.


cheers,

lincoln. (ltdcisco.com)