I was wondering what the purpose if for disabling ip-route cache.
I was under the impression that fast switching will enhance netowork
performance. These configs are directly from a router on our network.
description Connected to ISP PVC
ip address xxx.xxx.0.2 255.255.255.252
no ip route-cache
no ip mroute-cache
description Connected to LAN Switch
ip address 192.168.1.245 255.255.255.0
ip nat inside
no ip route-cache
no ip mroute-cache
Traditionally people when something wasn't working, used to disable route-cache "as precaution". In most cases that wasn't necessary, yet the command was left there.
Noter I still have cases in which at least cef need to be disable to get things working.
actually ip route-cache is used when you are using the application services are it is advised if they are in the same ethernet pool then use the ip route-cache command.
In addition to the suggestions made in previous posts I will identify another reason why sometimes it is configured to have no ip route-cache. If you are running a debug, the debug can only report on packets that it sees. And debug runs in the processor. So any packet that is fast switched would not be seen by debug. So people would sometimes do no ip route-cache to be sure that the debug that they were about to run would see all of the traffic.
Your observation is correct that ip route-cache improves performance (no ip route-cache forces the router to process switch the packets and it does impact performance). So if someone has turned route-cache off in order to do a debug, then they should enable route-cache when the debug is completed. But I have seen a number of occasions when route-cache was disabled for a debug and then they forgot to enable route-cache when the debug was completed. I wonder if this might be the case on your router.
Agree with Rick, when we do "debug ip packet [detail]", then we issue "no ip route-cache" under the interfaces to enable process switching for the transit traffic, as only process switched traffic can be debugged (the packets must pass to the CPU in order for the debug to see it), i've also seen this with old codes where some features had problems with CEF or fast switching (i believe that i've seen this once with PBR on an old code). Finally you'll need to further investigate and tune this to enhance your router performance.
(Fast Switching), its a feature relies on route-cache which stores latest routes used by a router. (U can call it a legacy feature since CEF comes into the picture).
Process Switching or Fastswitching: each router has a FIB, Forward information base is consulted via normal routing lookup, to check the Exit interface of the desired destination after also consulting the routing table, this process is done in a software called (Process Switching) but it will cache a limited number of it as long as the router doing lookups for different destination.
CEF: its designed to replicate all routing table into the FIB database once the router starts up.
Hope its informative,
Since there is a number of people in this thread, let me take this opportunity to try bust a myth for the larger audience possible.
In all traditional architecture routers, from the smaller 851 to the 7200 NPE-G2, the process does see and process each an any packet no matter if you have configured process, route-cache, or CEF switching.
It is not like CEF or route cache are magic accelerators that do things in hardware. The only difference is that they handle the packet at interrupt time instead that process time.
To understand these terms you need to have a little understating of a typical OS architecture, however we can summarize saying that interrupt time is a routine that starts every single time a packet is received, and is supposed to end as fast as possible.
Process time is all the cpu time left when not doing interrupt-time.
In a very relaxed router there will be plenty of time for both levels, things change when router go under stress. You must prioritize still serve all interrupts to avoid drops, but you can't starve process time because that impacts the control-plane, basically what keeps the router together. That's why we can tune the "scheduler" parameter in some case.
Now that we've introduced interrupt and process level, let's go for an historical perspective.
When they invented the router at the beginning of the internet era, processors were slow and had little memory. So the trade-off was between having few features (to be fast) using a relative small cache of most used routes (to save memory and cpu cycles) versus doing things in a more exhaustive manner against the full route table - process switching exactly.
The idea was that complex features were not apt or too difficult to be implemented at interrupt time - or as you can hear sometime, in the fast path. Packet debug, as rick mentioned before, is one of these.
So they put everything not fitting the fast switching model in the process path, and cisco provided (sometime, not even all the time) a list of what was doable in route-cache, and what not.
Then the processors grew in performance, memory available, and customers wanted to have all features in the fast path, because process switching performances were very disappointing.
Circa the same time CEF was introduced, by some some smart guys that deserves a lot of appreciation. They not only made an infinitely better algorithm to scan an entire route table in less cpu cycles, but also provided programming hooks and restructured code so that most features could be done at interrupt time. So the current tendency of having almost everything done at interrupt time.
Well, I've summarized the matter a lot, I hope that helps understanding things better.
Interrupt packet processing isn't truly all done while servicing a physical interrupt, is it? I would expect interrupt processing to do the minimal amount of work to record what needs doing and clear the interrupt. Then expect the bulk of "interrupt" processing, or fast path switching, would be in the OS equivalent of the non-interrupt handler portion of a device driver or perhaps a portion of the kernel. (Likewise process switching might be like a kernel service.)
Agree with Joseph, excellent post and duly rated.
If possible could you elaborate on Joseph's questions.
Also are you saying in effect that most features can be "scheduled" at interrupt time rather than having to wait for process time because in most OS's as Joseph says interrupts are meant to be cleared as quickly as possible. Or have i misunderstood.
When a packet can be fully processed at interrupt time, IOS will do so. After things to do with the packets have been done, memory pointers are given to transmitting driver for immediate transmission, if that is not possible due to outgoing buys transmitting, packet is queued, but still it resides in I/O memory.
Instead, when it's not possible to handle the packet, it's said to be "punted", packet is copied form I/O memory to process memory, and the interrupt will clear. The process switching will now occur.
In fact, if you look at a stack decode for a crash happing in route-cache or CEF code, you will see that the top calling routine is the hardware rx handler.
Thank you for the appreciation. One thing must be said, these are very general concepts I gave.
Consider, the typical learning curve for a green IOS programmer can be as long as two years, with a lot of trial and error to get things right. IOS internals are *very* complex and fragile, in fact I think IOS is by far the most complex piece of software in wide circulation today.
Sometime, Cisco's developers give presentations about that stuff at networkers, or informally. Some stuff is also in the books, but you have to do your own research, it's not like linux where everything is explained and well-known.
Very nicely summarized indeed, and definitely deserves rating. Agree with you about the difficulty of finding IOS details, and i think that understanding the theory of the IOS helps us understand the router behavior. Thank you.