[c-nsp] ip route-cache

[Rodney Dunn]

The one gotcha here is that during the evolution
of the switching vectors in IOS at one point
we leveraged the netflow cache to accelerate
ACL lookups.  So that's why some people turned
it on and saw a performance increase even though
they didn't need the netflow data itself.

You can forget about it though because moving
forward that is removed because we have a faster
ACL lookup algorithm and netflow is being leveraged
for a lot of other things so it's relation to the
switching path to improve feature performance has (will
be) removed.

Post 12.2(25)S code is totally different from a switching
path perspective.

Before 12.2(25)S you have no way to debug packets in the
switching vector.  That's no longer true (at least in
the software swtiching path).

You can do it per interface and match on an ACL with
very little to no performance impact.  The other interfaces
that don't have the debug applied take *no* performance
hit with the debug enabled.  We view this as a small step
forward in helping the user debug packet forwarding problems.

You can test it out with:

debug ip cef packet ?

ie:

Router#debug ip cef packet ethernet 0/0 input 1 rate 2


This would dump packets coming in e0/0 matching ACL 1
and rate limit them to 2 per second.  I'm having this
enhanced to addd a count ability.  ie: dump the next two
packets that match the criteria and then disable the debug
versus the rate limiting concept.

Also in the new CEF rewrite code you can check the order
of operations of features by looking at 'sh cef int' on
the inbound and outbound side.

Router#sh cef int e0/0
Ethernet0/0 is up (if_number 2)
  Corresponding hwidb fast_if_number 2
  Corresponding hwidb firstsw->if_number 2
  Internet address is 1.1.1.1/24
  ICMP redirects are always sent
  Per packet load-sharing is disabled
  IP unicast RPF check is enabled
  Input features: Access List, Verify Unicast Reverse-Path
  Output features: QoS Classification
..

This tells you the first feature (it will only show the
ones that are configured) to be applied witll be
Inbound ACL, urpf, (then the FIB lookup in the middle).
You could then look at 'sh cef int' on the output side
to see the features that would apply to the packet
on the egress side.

If you have additional ideas on things that you think
would make the box more troubleshootable in production
feel free to forward the ideas to me.

The above is currently only in 12.2(25)S or later due
to the infrastructure required to do it.  

Rodney



On Thu, Oct 14, 2004 at 05:58:14PM +0100, Stephen J. Wilcox wrote:
> they're all variants of fast switching and you must use some form of it. netflow 
> is cool but if you're not going to use the data that is exported you may as well 
> not have it enabled and save your cpu cycles.
> 
> forget the routes. its about the actual switching of traffic from interface A to 
> interface B. with fast switching disabled (no ip route-cache/no ip cef) the 
> router will process switch each packet and you will not get very high throughput 
> before the cpu maxs.
> 
> as i say, always enable it!
> 
> Steve
> 
> On Thu, 14 Oct 2004, Brian Vowell wrote:
> 
> > What about "ip route-cache flow" 
> > 
> > I've never used NetFlow, and am not very familiar with it.  I thought it 
> > was mostly for reporting, but some of the CCO docs make it sound more 
> > than that.  Is there any benefit on a single static route?
> > 
> > 
> > --b
> > 
> > Stephen J. Wilcox wrote:
> > 
> > >you're process switching with it disabled - always enable ip route-cache and ip
> > >cef otherwise you will not use the full power of the router and it will quickly
> > >die from cpu usage.
> > >
> > >Steve
> > >
> > >On Thu, 14 Oct 2004, Brian Vowell wrote:
> > >
> > >  
> > >
> > >>I have a 7204 setup as an edge router with one inside interface and one 
> > >>outside interface.  Is there any benefit to enabling "ip route-cache" on 
> > >>the interfaces?  I've got just a single static route to my upstream, and 
> > >>only one inside network.
> > >>
> > >>
> > >>--b
> > >>
> > >>_______________________________________________
> > >>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/
> > 
> 
> _______________________________________________
> 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/