cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
653
Views
0
Helpful
5
Replies

set ip next-hop

cajones
Level 1
Level 1

We are using IP SLA with our SilverPeak devices.  We use the verify-availability to make sure traffic is not black-holed.  The problem arises with 2 offices that do not support this command.  (I'm not sure why this one command is not available but it isn't.)  TAC told us in those locations to just add a second address and it would function the same.....but it doesn't.  When the primary next-hop is gone all the traffic is black-holed.  Does anyone have any ideas on what other options might be available to keep the traffic from being sent to the SilverPeak address when it is no longer reachable?

This is what we use that DOES work.

access-list 102 permit ip any any

ip sla 1
 icmp-echo x.x.x.x
 frequency 30
ip sla schedule 1 life forever start-time now

ip device tracking
track 102 ip sla 1 reachability
!

route-map SilverPeak permit 20
 match ip address 199
 set ip next-hop verify-availability x.x.x.x 1 track 102

This is what TAC told us to use that DOES NOT work.

ip sla 1
 icmp-echo x.x.x.x
 frequency 30
ip sla schedule 1 life forever start-time now

access-list 102 permit ip any any

ip device tracking
track 102 ip sla 1 reachability

route-map SilverPeak permit 10
 match ip address 199
 set ip next-hop x.x.x.x y.y.y.y

If you look at the ip sla summary on this one it doesn't show the second address.

CatSGBBone#sho ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID           Type        Destination       Stats       Return      Last
                                           (ms)        Code        Run
-----------------------------------------------------------------------
*1           icmp-echo   x.x.x.x        RTT=4       OK          5 seconds ago

Thank you.

5 Replies 5

Philip D'Ath
VIP Alumni
VIP Alumni

I would try and keep all your configs the same.  So I would be interested in why two of your sites don't have the commands.

Try comparing software versions between a site with the command and one without.  More than likely you are a simple software upgrade away from resolving the issue.

So in all but these 2 locations we have 6509E as our backbones running IPServices.  In these locations (due to the size) we are using 4510R+E with EntServices as the backbones.  TAC said you can't run this command on a 4500.

So the platform difference explains why the two offices do not support the verify-availability command. I am really disappointed that the 4500 does not support a command that can be so important in the implementation of PBR.

HTH

Rick

HTH

Rick

It is very disappointing as we have no other option in those locations.  If I can't find a way to make this work then we will not be able to use WAN Acceleration in those offices and we really need it.  I'm not sure why they would have some portion of PBr available and not all of it.  There must be a reason but it doesn't make sense to me.

Richard Burts
Hall of Fame
Hall of Fame

There is no reason why the ip sla summary would show the second address. You have not told ip sla to track the second address. ip sla is tracking a single address and showing a single address, as it should.

In the first (working) example you are configuring Policy Based Routing and using the verify-availability which uses ip sla to determine whether the address specified is working. And if the address is not working according to ip sla then PBR does not set the next hop.

It appears that two offices do not support the verify-availability perhaps it is due to the type of device or to the version of code running on it. So TAC has suggested an alternative approach. In PBR when you set ip next-hop x.x.x.x y.y.y.y then PBR will attempt to use the first address and if PBR recognizes that the first address is not working then it will use the second address. The tricky part here is whether PBR will recognize that the first address is not working. Given your symptoms I am guessing that PBR does not recognize when x.x.x.x is not working and this is pretty common when x.x.x.x is using an Ethernet interface. Unfortunately it is easier to explain why the second example does not work as desired but difficult to provide an alternative that does work. The best alternative would be to upgrade to the version of code (or to the platform) that does support verify-availability for PBR.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card