route-map with next-hop verify-availability

Unanswered Question
Apr 8th, 2008

I currently have the following two static routes:

ip route 10.185.165.0 255.255.255.0 192.168.52.33

ip route 10.185.165.0 255.255.255.0 13.76.181.228 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:

myswitch<->ISPSwitch<-ethernetLink->ISPswitch<->farendswitch

I basically want to check the availibility of "farendswitch"

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Tshi M Tue, 04/08/2008 - 07:09

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

rtr 1

type echo protocol ipicmpecho 192.168.52.33

!

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 192.168.52.33 10 track 192

!

ip route 10.185.165.0 255.255.255.0 192.168.52.33 track 192

ip route 10.185.165.0 255.255.255.0 13.76.181.228 254

royalblues Tue, 04/08/2008 - 22:12

Yes looks good.

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

Narayan

Tshi M Wed, 04/09/2008 - 07:53

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

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

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?

Thanks

Victor

Tshi M Thu, 04/17/2008 - 08:29

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.

US<->Provider_switch<-Ethernet->Provider_switch<->Clients

lamav Fri, 04/18/2008 - 05:14

Etienne:

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 (192.168.52.33) 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 (192.168.52.33) 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 (192.168.52.33)<--METRO ETHERNET FIBER-->SP-edge_switch<->clients

Victor

Tshi M Fri, 04/18/2008 - 05:27

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 192.168.52.33.

See below

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

lamav Fri, 04/18/2008 - 05:38

OK, I understand now.

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

Thanks

Victor

Tshi M Fri, 04/18/2008 - 05:44

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

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?

Victor

Tshi M Fri, 04/18/2008 - 06:15

LOL!!!

Not yet...my switch is not taking the command

ip route destination_address 255.255.255.0 track 192

I need to do some more homeworks....

Actions

This Discussion