[c-nsp] ip route-cache

[Rodney Dunn]

Sorry.  I don't know all of them off the top of
my head and I'd have to go through the code to
figure it out.

There are actually multiple CEF switching vectors.
One for features and one without.  I thin that is the turbo
vs. normal one if I remember right.

I don't know about the flags.

I've never seen a problem where it actually mattered.
Yet at least.  If it shows CEF is on that is what matters.

Rodney


On Thu, Oct 14, 2004 at 10:42:30AM -0700, Brian Vowell wrote:
> Ok, now you opened a can of worms.  Help me decipher this output of 
> "show cef int fa2/0" below:
> 
> FastEthernet2/0 is up (if_number 4)
>   Corresponding hwidb fast_if_number 4
>   Corresponding hwidb firstsw->if_number 4
>   Internet address is 69.50.224.230/30
>   ICMP redirects are never sent
>   Per packet load-sharing is disabled
>   IP unicast RPF check is enabled
>   Inbound access list is deny-in
>   Outbound access list is allow-out
>   Hardware idb is FastEthernet2/0
>   Fast switching type 1, interface type 18
>   IP CEF switching enabled
>   IP Flow switching turbo vector
>   IP Flow CEF switching turbo vector
>   Input fast flags 0x4021, Input fast flags2 0x8, Output fast flags 
> 0x81, Output fast flags2 0x0
>   ifindex 2(2)
>   Slot 2 Slot unit 0 Unit 0 VC -1
>   Transmit limit accumulator 0x0 (0x0)
>   IP MTU 1500
> 
> What is fast switching type 1?  I'm guessing this means that there are 
> different types of switching.  Also, what is IP Flow switching turbo 
> vector?
> 
> --b
> 
> 
> 
> Rodney Dunn wrote:
> 
> >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/