route-map with next-hop verify-availability

Unanswered Question
Apr 8th, 2008
User Badges:
  • Silver, 250 points or more

I currently have the following two static routes:

ip route

ip route 100

The first route goes over an Ethernet link that our switch connects to. If that link goes down, there is no way of us knowing so the second route will only work manually (i.e. if we either remove the first route or shutdown the interface connecting to the ethernet link).

I am thinking of implementing route-map with next-hop verify-availability. Does this option only work with CDP?

Below is our setup:


I basically want to check the availibility of "farendswitch"

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Tshi M Tue, 04/08/2008 - 07:09
User Badges:
  • Silver, 250 points or more

Thanks much for the quick reply. What do you think of this config?

rtr 1

type echo protocol ipicmpecho


rtr schedule 1 life forever start-time now


track 192 rtr 1 reachability


int vlan14

ip policy route-map vlan14


route-map vlan14

set ip next-hop verify-availability 10 track 192


ip route track 192

ip route 254

royalblues Tue, 04/08/2008 - 22:12
User Badges:
  • Green, 3000 points or more

Yes looks good.

What switch are you using... some switches like the 3750 would require you to chnage the SDM template to support PBR


Tshi M Wed, 04/09/2008 - 07:53
User Badges:
  • Silver, 250 points or more

Cisco IOS Software, C3750 Software (C3750-ADVIPSERVICESK9-M), Version 12.2(25)SED1, RELEASE SOFTWARE (fc1)

Copyright (c) 1986-2005 by Cisco Systems, Inc.

Compiled Tue 22-Nov-05 23:37 by yenanh

Image text-base: 0x00003000, data-base: 0x0119A6B0

ROM: Bootstrap program is C3750 boot loader

BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(25r)SE1, RELEASE SOFTWARE (fc)

NY45B3SEZ00 uptime is 2 years, 9 weeks, 5 days, 19 hours, 51 minutes

System returned to ROM by power-on

System restarted at 14:48:44 EST Tue Jan 31 2006

System image file is "flash:c3750-advipservicesk9-mz.122-25.SED1.bin

Tshi M Thu, 04/17/2008 - 05:12
User Badges:
  • Silver, 250 points or more

I tried to setup PBR but could not add the route using track:

ip route x.x.x.x x.x.x.x. track x.x.x

it seems that the switch will not take that command but it took all other commands.

Will changing the template affects my current configuation?

lamav Thu, 04/17/2008 - 06:35
User Badges:
  • Blue, 1500 points or more

Hi, Narayan:

Im just thinking out loud....

Im wondering what the benefit is of using PBR and object tracking in this particular case.

What's wrong with the static/floating static approach? The primary static goes down because the next hop fails, so the floating becomes the primary. What qualitative difference does object tracking really offer?

They seem to achieve the same thing, but PBR takes a lot more to get to work.

Am I missing something?



Tshi M Thu, 04/17/2008 - 08:29
User Badges:
  • Silver, 250 points or more

The problem is that if the Provider circuit goes down, we have no way of knowing it. We only can know it if the ping times out. Our provider uses Ethernet Link so our switch connects to their switch.


lamav Fri, 04/18/2008 - 05:14
User Badges:
  • Blue, 1500 points or more


I see.

So -- correct me if Im wrong -- it's not the next hop in your static route that you are afraid of losing and not being aware of, it's the Metro Ethernet link between the service provider's switches that you do not have visibility to. And that's why you want to do some object tracking. Correct?

I will further assume that the next hop address for your primary static route ( is also a directly connected interface. IOW, its L2 adjacent to an interface on your own switch. You don't have to depend on any recursive routing to take you to that next hop, right?

If all that is the case, why are you PINGing the next hop address in your static route ( as part of your RTR test? If you lose that next hop, since it is directly connected, your router will know about it and install the floating static in the routing table and use it as the primary route. You don't need object tracking to track a directly connected interface.

Isn't it an address beyond that provider's first hop that you want to be PINGing as part of your RTR test?

This is my mental picture of your network:

You<->SP_edge_switch (<--METRO ETHERNET FIBER-->SP-edge_switch<->clients


Tshi M Fri, 04/18/2008 - 05:27
User Badges:
  • Silver, 250 points or more

Hi Victor,

1. Yes, it is the Metro Ethernet link that I have no visibility to.

2. No, the next hop is located at the client site over the Metro Ethernet.

3. The address beyond the provider's Metro E is

See below

ME(VLAN14:<->SP_Edge_Switch)<-MetroE->SP_Edge_Switch<->( int x)Clients

lamav Fri, 04/18/2008 - 05:38
User Badges:
  • Blue, 1500 points or more

OK, I understand now.

[EDIT] Nevermind, I just answered my own question.[EDIT]



Tshi M Fri, 04/18/2008 - 05:44
User Badges:
  • Silver, 250 points or more

No worries Victor, I am here to find a solution so I welcome the questions.

Indeed it shows it as directly connected since they share the same subnet. But the problem is really because of the Metro E. Because the service provider does not give us a way of knowing when that circuit goes down, we have to ping the far end.

lamav Fri, 04/18/2008 - 06:09
User Badges:
  • Blue, 1500 points or more

Thanks, Etienne:

Yes, I realized the answers to my own questions as soon as I submitted them to you. :-) thats why I deleted them and did an "[EDIT]"

The fact that 52.44 is several L2 hops away, your 52.33 interface will always remain "up,up" and never expunge the routes from the routing table that point to it. Basic stuff, actually. Had a brain fart.

Have you ever been able to get this thing working?


Tshi M Fri, 04/18/2008 - 06:15
User Badges:
  • Silver, 250 points or more


Not switch is not taking the command

ip route destination_address track 192

I need to do some more homeworks....


This Discussion