PBR next-hop failure detection question

[g.andrus]

I am considering a PBR solution for a 4500 series switch to selectively forward packets to a directly connected Cisco WAAS box. I need to know how PBR will detect if the next hop (WAAS) is unavailable in failure scenarios. My research shows that the verify-availability parameter is not yet available for the 4500. I need to know that packets are not going to be dropped if the WAAS fails

[a.alekseev]

untill you have the arp entry in arp cache on your 4500 for the WAAS box.

[g.andrus]

I cannot make sense of this response. Please elaborate on your comment.

[a.alekseev]

hi,

set ip next-hop a.a.a.a

if a router has arp entry in ARP cache for a.a.a.a then it will forward traffic to a.a.a.a.

if the arp entry in ARP cache for a.a.a.a expire then the router will stop forward traffic to a.a.a.a.

[limtohsoon]

Hi,

I tested it in a lab.

I shutdown the next-hop router and clear ARP cache on the local router. The ARP cache for a.a.a.a therefore expires. However the router continues to forward traffic to the PBR next-hop a.a.a.a despite not getting ARP reply from the next-hop router. You can observe the behavior by doing "debug ip policy" and "debug arp" (see below):

*Mar 28 18:57:56.309: IP: s=1.1.1.1 (GigabitEthernet1/0), d=5.5.5.5, len 100, FIB policy match

*Mar 28 18:57:56.313: IP: s=1.1.1.1 (GigabitEthernet1/0), d=5.5.5.5, len 100, policy match

*Mar 28 18:57:56.317: IP: route map TESTPBR2, item 10, permit

*Mar 28 18:57:56.317: IP: s=1.1.1.1 (GigabitEthernet1/0), d=5.5.5.5 (GigabitEthernet2/0), len 100, policy routed

*Mar 28 18:57:56.321: IP: GigabitEthernet1/0 to GigabitEthernet2/0 172.16.23.3

*Mar 28 18:57:56.325: IP ARP: sent req src 172.16.23.2 ca03.0b74.0038,

dst 172.16.23.3 0000.0000.0000 GigabitEthernet2/0

*Mar 28 18:58:00.301: IP ARP throttled out the ARP Request for 172.16.23.3

Please comment if you tested otherwise.

Thank you.

B.Rgds,

Lim TS

[rpfinneran]

Lim,

What IOS is running on the 4500? You could try configs similar to these...NOTE: Apparently Cisco has decided consistency on these features is not important across IOS boundaries, so you will probably have to question mark it until you figure out the exact configuration required.

ip sla monitor 1

type echo protocol ipIcmpEcho 8.0.0.1

timeout 1000

threshold 1000

frequency 2

exit

ip sla monitor schedule 1 life forever start-time now

!

ip sla monitor 2

type echo protocol ipIcmpEcho 9.0.0.1

timeout 1000

threshold 1000

frequency 2

exit

ip sla monitor schedule 2 life forever start-time now

!

track 1 rtr 1 reachability

!

track 2 rtr 2 reachability

!

route-map NEXT-HOP-FAIL permit 20

set ip next-hop verify-availability 8.0.0.1 1 track 1

set ip next-hop verify-availability 9.0.0.1 2 track 2

exit

!

interface Gi0/1

ip policy route-map NEXT-HOP-FAIL

end

You may have to use the "rtr" command instead of sla, depending on IOS. Just question mark it out and get something similar to what I have above. You can tweak threshold etc. to match topology, depending on interface types.

HTH,

Ryan

[surasitjumroonsiriwattana]

in cat4500-entservicesk9-mz.122-52.SG.bin on 4506 V-10GE

the command set ip next-hop verify-availability not available

please share the another solution thank you.