Route map debug output

[Chris Schroeder]

Ok, so my route-map isn't working.  I'm trying to redirect traffic from a single source IP to a different destination on a single 6504 switch (enterprise featureset).

I have some route map debug output....

I turned on debugging:

show debug
Route-map:
Routemap related IPC debugging is on
Routemap related API debugging is onRouting, route-map, vrf

I then deleted the route-map I created (named "voip" with an match ACL of 25) and got this in the debug output:

Nov 29 18:33:19: RM-IPC: Batched del routemap voip(seq:not specified); n_len 5; len 17

I then recreated my route map and got the following debug output:

Nov 29 18:33:19: routemap_rp_push_xdr:Pushed to XDR -> t:Name l:17 slots:no slots (0x0)
Nov 29 18:33:54: RM-IPC: Batched add routemap voip(seq:10); n_len 5; len 17
Nov 29 18:33:54: routemap_rp_push_xdr:Pushed to XDR -> t:Name l:17 slots:no slots (0x0)
Nov 29 18:33:54: RM-IPC: Batched add acl 25 of routemap voip(seq:10); len 21
Nov 29 18:33:54: routemap_rp_push_xdr:Pushed to XDR -> t:Match ACL l:21 slots:no slots (0x0)
Nov 29 18:33:54: RM-IPC: Batched add vrf (2/65535) of routemap voip(seq:10);len 33
Nov 29 18:33:54: routemap_rp_push_xdr:Pushed to XDR -> t:Set VRF l:33 slots:no slots (0x0)
Nov 29 18:33:55: RM-IPC: Batched add nexthop 10.6.1.1 of routemap voip(seq:10); len 23
Nov 29 18:33:55: routemap_rp_push_xdr:Pushed to XDR -> t:Set nexthop l:23 slots:no slots (0x0)
Nov 29 18:33:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface VRF_2_vlan1060, changed state to up

.... it appears that the route-map works very briefly, then stops working almost immediately:

show route-map
route-map voip, permit, sequence 10
Match clauses:
ip address (access-lists): 25
Set clauses:
vrf inet-nia
ip vrf inet-nia next-hop 10.6.1.1
Policy routing matches: 341 packets, 315033 bytes

.... there are no matches after the first 341 packets.   The route map simply does not function or change after that.

I do not know exactly how to interpret the debug information above?   Can someone assist?

Additional information:

I'm having an issue getting policy based routing to work on a single switch. We run OSPF as a routing protocol but the routing change is self-contained in this switch - the interfaces it would reroute to are all local. In any event I've also included the relevant OSPF configuration. The problem is the PBR named "voip" never catches the traffic and translates the route to my intended target. It keeps going through the default 0.0.0.0 route for vrf inet-nia, and I do not know why. It SHOULD catch the source IP in the intended packet as coming from 10.105.0.242 and then instead of letting it go out the default route for vrf "inet-nia" through 10.6.0.62, it should push it through 10.6.1.1 which is a different locally connected interface.

6504-E Switch
Running image: sup-bootdisk:s72033-adventerprisek9_wan-mz.122-33.SXI10.bin

(Yes, I know this is old)

Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
1 Policy Feature Card 3 WS-F6K-PFC3A 2.7 Ok
1 MSFC3 Daughterboard WS-SUP720 2.12 Ok
2 Policy Feature Card 3 WS-F6K-PFC3A 2.7 Ok
2 MSFC3 Daughterboard WS-SUP720 2.12 Ok
3 Centralized Forwarding Card WS-F6700-CFC 4.2 Ok
4 Centralized Forwarding Card WS-F6700-CFC 4.1 Ok
---- --------------------------- ------------------ ----------- ------- -------

Relevant configuration:

ip route vrf inet-nia 0.0.0.0 0.0.0.0 10.6.0.62 permanent
ip route vrf inet-nia 10.6.0.64 255.255.255.252 10.6.1.1 permanent

interface GigabitEthernet3/20
ip vrf forwarding inet-nia (should this be "ip vrf receive inet-nia" instead? it doesn't work that way either though)
ip address 10.6.1.2 255.255.255.252
logging event link-status
logging event spanning-tree status
end

interface Vlan305
description INET-NIA transit to Internet
ip vrf forwarding inet-nia
ip address 10.6.0.57 255.255.255.248
ip policy route-map voip
end

access-list 25 permit 10.105.0.242
access-list 25 deny any

route-map voip permit 10
match ip address 25
set vrf inet-nia
set ip vrf inet-nia next-hop 10.6.1.1

router ospf 305 vrf inet-nia
router-id 192.168.0.9
log-adjacency-changes
redistribute connected subnets
passive-interface default
no passive-interface GigabitEthernet3/15.1505
no passive-interface GigabitEthernet3/48.505
no passive-interface GigabitEthernet4/15.1705
no passive-interface GigabitEthernet4/21.705
network 192.168.0.0 0.0.0.15 area 0
network 192.168.0.0 0.0.0.31 area 0
default-information originate metric 30 metric-type 1

#show route-map
route-map voip, permit, sequence 10
Match clauses:
ip address (access-lists): 25
Set clauses:
vrf inet-nia
ip vrf inet-nia next-hop 10.6.0.65 10.6.1.1
Policy routing matches: 0 packets, 0 bytes
-------------------------------------------------------------------------------

Ideas? Any help is appreciated.

[Richard Burts]

My first question is about the host specified in acl 25. Where is 10.105.0.242? Does it arrive at the switch on vlan 305?   

HTH

Rick

[Chris Schroeder]

That's a great question, burt.    Vlan305 is the second layer 3 interface I have attempted to use the policy on.   It's a virtual interface of course, so is not the actual physical source of the inbound packets from 10.105.0.242

There are two possible inbound sources (spanning tree blocks one) of packets from 10.105.0.242.   They are:

interface GigabitEthernet3/48.505
description inet-nia APN drain
bandwidth 10000
encapsulation dot1Q 505
ip vrf forwarding inet-nia
ip address 192.168.0.2 255.255.255.252
ip ospf hello-interval 1
ip ospf dead-interval 3
end

interface GigabitEthernet4/21.705
description inet-nia APN drain
bandwidth 1000000
encapsulation dot1Q 705
ip vrf forwarding inet-nia
ip address 192.168.0.6 255.255.255.252
ip ospf hello-interval 1
ip ospf dead-interval 3
end

I have tried using the line:

"ip policy route-map voip" 

...on both of these interfaces instead of using it on Vlan305.   The results are exactly the same as if I use it on Vlan305.   It doesn't work except for a few packets right after I paste in the route-map configuration.

[Richard Burts]

Thanks for the information. If vlan 305 is not the interface where the traffic from that host arrives then I am surprised that your route map got any hits. It is a basic principle of PBR that you apply the route map to the interface where the traffic arrives (or you configure PBR local where the route map is applied on a interface and catches traffic that is generated locally). There must be something else going on in this switch that we do not know about that is impacting PBR.

HTH

Rick

[Chris Schroeder]

Thanks Burt!  Like I said, Vlan305 was my second choice.   It didn't work on the actual inbound interfaces (pair, not etherchannel) either.  Same results on those.

Do you have any commands you'd like me to run to show you more information from the switch that might provide more clues?

Thanks in advance.

[Richard Burts]

My first suggestion would be to put the route map assignment on both interfaces where the traffic from that host might arrive. It might be helpful to see the output of show ip interface brief from the switch. The debug output from while you were rebuilding your route map is not very helpful - it just verifies that it recognizes the commands to configure the route map. It might be helpful to enable debug for PBR and then to make sure that some traffic from that host does get to the switch. And that makes me think that it might be helpful if you could get results of traceroute from that host toward some destination that would take it through this switch. And that makes me think to ask whether you are sure that traffic from that host is routed through this switch?

HTH

Rick

[Georg Pauwen · Accepted solution]

Hello,

on a side note, after looking at the configuration guide, it appears that the line 'set ip vrf inet-nia next-hop 10.6.1.1' is not supported on the 6500, only the first one is ('set ip vrf inet-nia').

Have a look at the section 'Restrictions for PBR':

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/policy_based_routing_pbr.pdf

[Chris Schroeder]

That is the solution, Georg.   Based on this information we changed the concept of what we were doing from a route-map to a different method altogether.

It's a bit frustrating that the 6500 platform accepts the route-map vrf next hop command but it doesn't actually work.   But that was the roadblock I was running into and I thank you for finding the answer.  It is much appreciated.