'no ip route-cache' on Tunnel interfaces

[andy.taylor]

Hi,

A quick and hopefully simple question. Is there any reason why 'no ip route-cache' and 'no ip mroute-cache' should be configured on Tunnel interfaces?

Generally, when should 'no ip route-cache' be configured on an interface?

Many thanks,

Andy

[JORGE RODRIGUEZ]

Andy, no easy question, and prety much send some of us back to basics.. one have to take a deeper look at this command to barely get a good picture. See first link thread , good discussion on your question.. generaly no ip- route-catch improves performance for router forwarding processing desitions.

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&topicID=.ee71a06&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cbfa166

You can find more details on three types of switching methods such as ( fast switching by ip route catch command ), I believe it helps understand better the commands.

http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper09186a00800a62d9.shtml

Another instance where you would have IP route catch enable on an interface would be for the use of netflow, IP route-cacth command on an interface is requirement for implementing netflow .

Rgds

-Jorge

[andy.taylor]

Jorge,

I really appreciate the response. I had problems with the reply so sorry if you get two :-)

You mention that 'no ip route-cache' improves the performance, but if 'no ip route-cache' forces the packets to be process switched I would have thought that this would have a detrimental affect.

I can see why 'no ip route-cache' would be configured if you want packet info i.e. if you were running a 'debug ip packet detail' - I'm trying to understand under what other scenarios you would configure 'no ip route-cache' under an interface.

Many thanks,

Andy

[Farrukh Haroon]

Andy, its mostly done due to bugs on Cisco IOS : ). When Cisco initially introdced DMVPN Phase 1 on IOS 12.2(X)T, it had a lot of bugs. Spoke to spoke tunneling required CEF to be disabled on spokes (the default on 12.2(x)T ) and sometimes even disable fast switching on the hub's tunnel interface. Now we live in the CEF age, and the days for fast switching, processing switching are past us. There are other similar reasons for disabling it, but pretty rare.

Regards

Farrukh

[andy.taylor]

Farrukh,

Many thanks, disabling due to initial release bugs makes sense :-)

So if I'm reading this correctly, it sounds like it's best to leave CEF enabled on spokes and HUB as defaults will disable where required.

All the best,

Andy

[Farrukh Haroon]

Yes Andy your understanding is correct.

Regards

Farrukh

[andy.taylor]

Jorge/Farrukh,

Again many thanks for taking the time to post.

All the very best,

Andy