Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Bronze

route-map with next-hop verify-availability

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"

14 REPLIES

Re: route-map with next-hop verify-availability

Have a look at Reliable Static route with object tracking

http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html

Narayan

Bronze

Re: route-map with next-hop verify-availability

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

Re: route-map with next-hop verify-availability

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

Bronze

Re: route-map with next-hop verify-availability

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

Re: route-map with next-hop verify-availability

Do a show sdm prefer and see what template the switch is running

you need to change the template to routing for PBR to work

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swsdm.html

HTH

Narayan

Bronze

Re: route-map with next-hop verify-availability

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?

Blue

Re: route-map with next-hop verify-availability

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

Bronze

Re: route-map with next-hop verify-availability

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

Blue

Re: route-map with next-hop verify-availability

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

Bronze

Re: route-map with next-hop verify-availability

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

Blue

Re: route-map with next-hop verify-availability

OK, I understand now.

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

Thanks

Victor

Bronze

Re: route-map with next-hop verify-availability

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.

Blue

Re: route-map with next-hop verify-availability

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

Bronze

Re: route-map with next-hop verify-availability

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

2940
Views
0
Helpful
14
Replies