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.
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
I think there is no hardware support on this platform for 'verify-availability'.
set ip next-hop 10.82.6.26 1 track 1
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
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
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...
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.
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.
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...
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...
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.
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.
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=188.8.131.52, 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=184.108.40.206 (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
So we know its down to your tracking , have you tried changing this to a ip sla based track using scr/dst ip addresssing
ip sla 1
icmp-echo xxxxx source-ip xxxx
ip sla schedule 10 life forever start-time now
track 1 ip sla 10