Re: PBR not working with the track - Page 2

Difan Zhao · ‎10-22-2019

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

Difan Zhao · ‎10-23-2019

Nope

track 2 ip sla 2
!
ip sla 2
 icmp-echo 10.82.6.26 source-interface TenGigabitEthernet1/7
 vrf SAT
 threshold 500
 timeout 1000
 frequency 3
!
ip sla schedule 2 life forever start-time now
!
route-map PROV_USSATS permit 10
match ip address PROV_USSATS
set ip next-hop verify-availability 10.82.6.26 1 track 2
!

wsw01-07r1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 2
        Latest RTT: 1 milliseconds
Latest operation start time: 09:54:40 MDT Wed Oct 23 2019
Latest operation return code: OK
Number of successes: 57
Number of failures: 0
Operation time to live: Forever

!
wsw01-07r1#show track 2
Track 2
  IP SLA 2 state
  State is Up
    1 change, last change 00:02:45
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    Route Map 0
!

wsw01-07r1#debug ip policy
Policy routing debugging is on
wsw01-07r1#ter moni
Oct 23 09:53:51.756 MDT: IP: s=172.22.128.178 (TenGigabitEthernet1/1), d=4.2.2.1, len 64, policy match
Oct 23 09:53:51.756 MDT: IP: route map PROV_USSATS, item 10, permit
Oct 23 09:53:51.756 MDT: IP: s=172.22.128.178 (TenGigabitEthernet1/1), d=4.2.2.1 (TenGigabitEthernet1/7), len 64, policy routed
Oct 23 09:53:51.756 MDT: IP: TenGigabitEthernet1/1 to TenGigabitEthernet1/7 10.82.6.26

Same symptom. Debug says it is policy-routed, however, traceroute says otherwise...

paul driver · ‎10-23-2019

Hello

curious- you are trace route within vrf and sourced from the pbr interface?

Do you get the same trace route result from a host behind the pbr interface

Can you post results of trace-route with-without track please and also

Show Ip cef exact-route (sip) (dip)

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Difan Zhao · ‎10-23-2019

Hi Paul,

I do traceroute from a linux host that has the IP in the matched ACL. This is when it is working (without the track). The highlighted IP is the next-hop IP in the PBR config.

Even without track, with the PBR working, the "show ip cef exact-route" still reports that it is going by the routing table

wsw01-07r1#sh ip cef vrf SAT exact-route 172.22.128.178 4.2.2.1
172.22.128.178 -> 4.2.2.1 =>IP adj out of Vlan986, addr 192.168.250.70

wsw01-07r1#sh ip route vrf SAT 0.0.0.0

Routing Table: SAT
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 64610", distance 20, metric 0, candidate default path
  Tag 64700, type external
  Last update from 192.168.250.70 1d01h ago
  Routing Descriptor Blocks:
  * 192.168.250.70, from 192.168.250.70, 1d01h ago
      Route metric is 0, traffic share count is 1
      AS Hops 4
      Route tag 64700
      MPLS label: none

Georg Pauwen · ‎10-23-2019

Hello,

I did (another) pretty extensive search, and it actually looks like the tracking option in conjunction with the verify-availability is not supported on any of the Catalysts...

The document below seems to confirm this (scroll down to the bottom)...

-->2. Tracking options are not available for Cisco Catalyst Switches. However, there's an advanced workaround available to achieve the same behavior.

https://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/118156-configure-wsa-00.html

Difan Zhao · ‎10-23-2019

Thanks Georg. That's what suspected too. I will try to use EEM to accomplish it. Thank you for your effort into this.