PBR not working with the track

[Difan Zhao]

I have a C6816-X-LE running the latest IOS 15.5(1)SY4. Here is my PBR config

interface te1/1
 ip policy route-map PROV_USSATS
!
ip access-list extended PROV_USSATS
 deny   ip any 172.16.0.0 0.0.255.255
 deny   ip any 172.19.0.0 0.0.255.255
 deny   ip any 10.92.0.0 0.0.255.255
 deny   ip any 10.135.0.0 0.0.255.255
 permit ip host 172.22.136.226 any
 permit ip host 172.22.154.90 any
 permit ip host 172.22.128.178 any
!
route-map PROV_USSATS permit 10
 match ip address PROV_USSATS
 set ip next-hop verify-availability 10.82.6.26 1 track 1

The track is up

#sho track 1
Track 1
  IP route 198.18.4.212 255.255.255.255 reachability
  Reachability is Up (BGP)
    2 changes, last change 00:36:08
  VPN Routing/Forwarding table "SAT"
  First-hop interface is TenGigabitEthernet1/7
  Tracked by:
    Route Map 0

However, if I remove the "verify-availability" and the "track" (so it will be like "set ip next-hop x.x.x.x), it works. What did I do wrong?

The next-hop is directly connected. There is the ARP entry for it

#sh ip arp vrf SAT 10.82.6.26
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.82.6.26             52   a46c.2acf.4663  ARPA   TenGigabitEthernet1/7

Please note that all these are in one VRF. The PBR is not for the cross-VRF thing. It is for changing the next-hop within the same VRF. 

Thanks,

Difan

[Jaderson Pessoa]

Hello, please share configuration below;
show ip sla summ

show run | sec ip vrf
show run | sec ip sla
show run | sec track
show ip sla summ

[Difan Zhao]

Here they are

vrf definition SAT
 rd 64610:10
!
track 1 ip route 198.18.4.212 255.255.255.255 reachability
 ip vrf SAT
!

My track is to track a route in the routing table, not a SLA

Thanks

[Georg Pauwen]

Hello,

I think there is no hardware support on this platform for 'verify-availability'.

Does 

set ip next-hop 10.82.6.26 1 track 1

work ?

[Georg Pauwen]

Also, remove the 'deny' statements in the access list, they are not needed due to the implicit deny in an access list, and usually cause high CPU utilization...

ip access-list extended PROV_USSATS
--> no deny ip any 172.16.0.0 0.0.255.255
--> no deny ip any 172.19.0.0 0.0.255.255
--> no deny ip any 10.92.0.0 0.0.255.255
--> no deny ip any 10.135.0.0 0.0.255.255
permit ip host 172.22.136.226 any
permit ip host 172.22.154.90 any
permit ip host 172.22.128.178 any

[Difan Zhao]

Thanks Georg... I really hope it does though... However, you might be right. I will open up a ticket with the Cisco tech to confirm.

Also, I can't do "track" without the "verify-availability"...

wsw01-07r1(config-route-map)#set ip next-hop 10.82.6.26 ?
  A.B.C.D  IP address of next hop
  <cr>

wsw01-07r1(config-route-map)#set ip next-hop verify-availability ?
  A.B.C.D  IP address of next hop
  <cr>

wsw01-07r1(config-route-map)#set ip next-hop verify-availability 10.82.6.26 ?
  <1-65535>  Sequence to insert into next-hop list

wsw01-07r1(config-route-map)#$-hop verify-availability 10.82.6.26 1 ?
  track  set the next hop depending on the state of a tracked object

[Georg Pauwen]

Hello,

I am looking at the configuration guide (linked below)...

Try and configure the route map as:

route-map PROV_USSATS permit 10
match ip address PROV_USSATS

set ip next-hop 10.82.6.26
set ip next-hop verify-availability --> and try to tack the 'track 1' on to this line...

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-sy/iri-15-sy-book/iri-ip-prot-indep.html#GUID-113EDBA9-B09E-410F-989B-D82D9C5C67E3

[Difan Zhao]

Can't do with just the "verify-availability" with the track... I have to put in a next-hop IP here. 

wsw01-07r1(config-route-map)#set ip next-hop verify-availability  ?
  A.B.C.D  IP address of next hop
  <cr>

I have tried with both "set next-hop" lines

route-map PROV_USSATS permit 10
 match ip address PROV_USSATS
 set ip next-hop verify-availability 10.82.6.26 1 track 1
 set ip next-hop 10.82.6.26

However, even with track 1 down, the PBR still takes effect. Also, I can't seem to change the sequence of the two lines. 

[paul driver]

Hello

Can you see that attached rtr in cdp if not that’s a possible root cause - cdp needs to active on the interfaces and running on both rtrs for verify-availability to work so they both need to cisco rtrs.

[Difan Zhao]

Thanks Paul. I actually have read it somewhere too. I have confirmed that both sides have the CDP enabled and in the CDP neighbor output both can see each other... 

[Georg Pauwen]

Hello,

what does the rest of your configuration look like ? I have been going through numerous configuration guides, and it looks like the verify-availability track part is supposed to be used for (multiple) object tracking in combination with SLAs. Maybe TAC can confirm that it is not available for what you are trying to do...

[Difan Zhao]

I can try to have a ping SLA tomorrow. I highly doubt that it would make a difference though. Track simply returns the boolean values, up/down. Does the route-map care what it is under the hood?

The other configs are just BGP, EIGRP, nothing special at all... I will talk to the tech tomorrow.

[paul driver]

Hello Diffan

could you post the output of a couple of things please-

sh run inter xx

sh run | in route-map

debug ip policy

sh ip policy 

Also could you try testing without the track appended.

[Difan Zhao]

Without tracks, it works fine.

As per the debug, the traffic is correctly routed but they are not.

Oct 22 15:13:16.524 MDT: IP: s=172.22.128.178 (TenGigabitEthernet1/1), d=4.2.2.1, len 64, policy match
Oct 22 15:13:16.524 MDT: IP: route map PROV_USSATS, item 10, permit
Oct 22 15:13:16.524 MDT: IP: s=172.22.128.178 (TenGigabitEthernet1/1), d=4.2.2.1 (TenGigabitEthernet1/7), len 64, policy routed
Oct 22 15:13:16.524 MDT: IP: TenGigabitEthernet1/1 to TenGigabitEthernet1/7 10.82.6.26

Here are the other configs

wsw01-07r1#sho run interface te1/7
Building configuration...

Current configuration : 131 bytes
!
interface TenGigabitEthernet1/7
 description *
 vrf forwarding SAT
 ip address 10.82.6.25 255.255.255.252
 load-interval 30
end

wsw01-07r1#sh run | sec route-map PROV_USSATS
 ip policy route-map PROV_USSATS
route-map PROV_USSATS permit 10
 match ip address PROV_USSATS
 set ip next-hop verify-availability 10.82.6.26 1 track 2
 set ip next-hop 10.82.6.26
wsw01-07r1#
wsw01-07r1#sh ip policy
Interface      Route map
Te1/1          PROV_USSATS

[paul driver]

Hello

So we know its down to your tracking , have you tried changing this to a ip sla based track using scr/dst ip addresssing

example:

ip sla 1
icmp-echo xxxxx source-ip xxxx
vrf xx

ip sla schedule 10 life forever start-time now

track 1 ip sla 10