Switch 4948 reboot after applying route-map

mataalfredo · ‎12-11-2011

Hello all,

I'm trying to apply the following policy route in my switch 4948, but it suddenly crash. Is anything wrong in my commands? The switch is rebooting with an error:

System returned to ROM by abort at PC 0x0

My commands are:

access-lists 7 permit 10.140.22.0 0.0.0.255

access-list 177 permit ip 10.140.22.0 0.0.0.255 100.220.24.0 0.0.0.255

access-list 177 permit ip 10.140.22.0 0.0.0.255 100.216.36.0 0.0.0.255

access-list 177 permit ip 10.140.22.0 0.0.0.255 100.216.38.0 0.0.0.255

route-map client1 permit 5

match ip address 177

set ip next-hop 10.1.20.158

!

route-map client1 permit 10

match ip address 7

set ip default next-hop 10.1.20.158

interface GigabitEthernet1/36

ip policy route-map client1

Thanks for your help.

Reza Sharifi · ‎12-11-2011

Hi,

Even if there was something wrong with your config, the switch should not reboot. It might be a bug in the IOS that triggers the reboot when you apply the access list. What version of IOS are you running?

HTH

mataalfredo · ‎12-11-2011

Here is the info of IOS version.

Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500-ENTSERVICESK9-M), Version 12.2(46)SG, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Compiled Fri 27-Jun-08 16:24 by prod_rel_team

Image text-base: 0x10000000, data-base: 0x11E3C0D8

ROM: 12.2(31r)SGA1

Dagobah Revision 226, Swamp Revision 5

Leo Laohoo · ‎12-11-2011

System returned to ROM by abort at PC 0x0

This information doesn't give much detail.

If the switch crashed and reboot, you should have a crashinfo file(s). Post these.

mataalfredo · ‎12-11-2011

Thank you, I will try to get the info from the crash file.

By the way is the route-map well configured?

mataalfredo · ‎12-12-2011

The route-map has been applied, but is not working. I can see matches in ACLs and also using route-map command but the router is ignoring the route map.

Edison Ortiz · ‎12-12-2011

Post the output from typing "show ip route 10.1.20.158, show ip route 10.140.22.0" and also "show run interface g1/36"

mataalfredo · ‎12-12-2011

Thanks for your help. Here is the info:

LAN network is 10.140.22.0

MAN-01#sh ip route 10.140.22.0

Routing entry for 10.140.22.0/24

Known via "static", distance 1, metric 0

Redistributing via eigrp 69, eigrp 502, eigrp 128, ospf 1

Advertised by eigrp 69 metric 1000000 1 255 1 1500

eigrp 502 metric 1000000 1 255 1 1500

ospf 1 subnets

Routing Descriptor Blocks:

* 10.1.10.186

Route metric is 0, traffic share count is 1

MAN-01#sh ip route 10.1.20.158

Routing entry for 10.1.20.156/30

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via Tunnel7

Route metric is 0, traffic share count is 1

MAN-01#sh run int gi 1/36

Building configuration...

Current configuration : 313 bytes

!

interface GigabitEthernet1/36

no switchport

ip address 10.1.10.185 255.255.255.252

ip policy route-map client1

qos trust dscp

tx-queue 3

bandwidth percent 33

priority high

shape percent 33

spanning-tree portfast

service-policy output VoIP-Qos-Policy

end

Edison Ortiz · ‎12-13-2011

Interesting.. multiple routing instances...

Redistributing via eigrp 69, eigrp 502, eigrp 128, ospf 1

Advertised by eigrp 69 metric 1000000 1 255 1 1500

eigrp 502 metric 1000000 1 255 1 1500

ospf 1 subnets

Your PBR config looks fine and I found some bugs affecting 12.2(46)SG which may be impacting you, here is one:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsr54959

Can you upgrade the code and try testing again?

I also wonder if the next-hop being a tunnel may be causing an issue here.

mataalfredo · ‎12-14-2011

Thank you Edison, let me check.

mataalfredo · ‎12-14-2011

The route map is not working with static IPs in the router.

Do you think is a bug or is a normal behavior?

Edison Ortiz · ‎12-15-2011

You mean the source subnets are known via static? I don't think it makes a difference how the source is known but it needs to ingress the interface where the PBR is applied to.

46SG has several PBR related bugs thus I recommend upgrading to a safer code such as 12.2(53)SGx where x represents the train revision.

Regards,

Alejandro Sanchez · ‎07-26-2012

Hi Edison,

Just suffered from the same bug in a C4507 platform. Cisco says it was resolved in

12.2(50)SG but they are not recommending any certain release. Do you still recommend 12.2(53)SG instead?

Thanks

Alex