2 Gateways, route-map and OSPF

Answered Question

Hi!

We have an office location (Building1) that is connected to the main location (Building2) via radio. Since this radio connection isn't always the best to use with VoIP, we decided to establish another link, this time via modem.

And the plan is to let all Voice traffic go via the modem, and all other traffic will use the radio link.


We use OSPF all throughout our network.


So I made the following configuration (see attached drawing):


Building1:

router ospf 1

log-adjacency-changes

network 10.0.0.0 0.255.255.255 area 0


access-list 106 permit ip any any dscp ef

access-list 106 permit ip any any dscp cs7


route-map IP-Telefon permit 10

match ip address 106

set ip next-hop 10.11.1.1


interface Vlan640

ip address 10.10.89.1 255.255.255.0

ip policy route-map IP-Telefon

--------------------------------------

Building2:

interface Vlan3

bandwidth 2048

ip address 10.11.1.1 255.255.255.0


router ospf 1

log-adjacency-changes

network 10.0.0.0 0.255.255.255 area 0


access-list 106 permit ip any 10.10.89.0 0.0.0.255 dscp ef

access-list 106 permit ip any 10.10.89.0 0.0.0.255 dscp cs7


route-map IPTelefon-Building1 permit 10

match ip address 106

set ip next-hop 10.11.1.2


interface Vlan207

description * Incoming Interface *

ip address 10.10.70.34 255.255.255.252

ip pim sparse-dense-mode

ip policy route-map IPTelefon-Building1

---------------------------------


This configuration works, and all is well.

BUT; now I have introduced a static route into the world of OSPF.

So what happens when the modem link stops working? Building1 will not have the ability to use VoIP at all. Because route-maps has higher priority than routing protocols and static routes, am I right?


So what I'm looking for is a way to let the VoIP traffic defined in ACL 106 use the radio link if the modem link for some reason should be gone.


There surely must be a way to do this, even when the routing table is dynamically built?


Thank you.



Attachment: 
Correct Answer by rpfinneran about 7 years 12 months ago

Hello Oystein,


As Giuseppe said... you need to modify your route-map to have a secondary next-hop, then enable "verify reachability" on the primary next hop. Fortunately, I had just wrote similar configs a few days ago for someone else


It would look something like this...


ip sla monitor 1

type echo protocol ipIcmpEcho 10.11.1.1

timeout 1000

threshold 1000

frequency 2

exit

ip sla monitor schedule 1 life forever start-time now

!

track 1 rtr 1 reachability

!

route-map IP-Telefon permit 20

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

set ip next-hop 10.10.83.1

exit

!



You would implement the opposite at Building 2. Now, you may have to modify the above. For some reason SLA monitoring, tracking, and rtr objects are not real consistent across IOS. Let me know if you have any questions.


I am not sure if you need the secondary next hop. I don't know what the behavior of a route map is when using verify reachability with only one next hop...Giuseppe do you know?


HTH,


Ryan

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.7 (3 ratings)
Loading.
Giuseppe Larosa Mon, 03/30/2009 - 01:38
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Oystein,

if the next hop is not reachable the destination based routing table is used.


To speed up detection of next-hop unreachability if your routers support it you can use the following:


set ip next-hop verify-availability [next-hop-address sequence track object]


see


http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_pi2.html#wp1012541


you need to track the next-hop defining a tracking object.

The latter can be defined with an rtr or ip sla object (depending on IOS version)


without tracking the next-hop is regarded as available until the link is up or ARP entry expires (on lan interfaces)


Hope to help

Giuseppe




Correct Answer
rpfinneran Mon, 03/30/2009 - 02:35
User Badges:
  • Bronze, 100 points or more

Hello Oystein,


As Giuseppe said... you need to modify your route-map to have a secondary next-hop, then enable "verify reachability" on the primary next hop. Fortunately, I had just wrote similar configs a few days ago for someone else


It would look something like this...


ip sla monitor 1

type echo protocol ipIcmpEcho 10.11.1.1

timeout 1000

threshold 1000

frequency 2

exit

ip sla monitor schedule 1 life forever start-time now

!

track 1 rtr 1 reachability

!

route-map IP-Telefon permit 20

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

set ip next-hop 10.10.83.1

exit

!



You would implement the opposite at Building 2. Now, you may have to modify the above. For some reason SLA monitoring, tracking, and rtr objects are not real consistent across IOS. Let me know if you have any questions.


I am not sure if you need the secondary next hop. I don't know what the behavior of a route map is when using verify reachability with only one next hop...Giuseppe do you know?


HTH,


Ryan

Giuseppe Larosa Mon, 03/30/2009 - 02:47
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Ryan,

it is possible to track reachability of primary next hop only.

if that next-hop fails standard destination based routing is used instead of sending packets to the next hop.


So I would use your config template but without specifying a second next hop.


Hope to help

Giuseppe


rpfinneran Tue, 03/31/2009 - 04:06
User Badges:
  • Bronze, 100 points or more

Thanks Giuseppe, I wasn't 100% sure

Hello again.


This is excellent news!

Interesting to know that traffic falls back to the other link automatically.

What if the radio link goes down? Will all other traffic be routed through the modem then?


I'm sorry I forgot to say what hardware I'm using, it is a C3550 on Building1 and a C3560 on Building2.

And I cannot see there is a command called set ip next-hop verify-availability there :(

So what can be used as alternative?

hclisschennai Mon, 03/30/2009 - 01:40
User Badges:

Hi,


Eventhough route-map is having higher priority than route is routing table as soon as next-hop 10.11.1.1 is unreachable due to link failure, the traffic destined to Building 2 will look into Route table and traffic flows.


Hope this helps you as i am also having the similar setup with me too


R.B.Kumar

Ok, a little update on this:

I have entered this information into the C3560 in Building2 now:


ip sla 1

icmp-echo 10.11.1.2 source-ip 10.11.1.1

timeout 5

frequency 2

ip sla schedule 1 life forever start-time now


track 1 rtr 1 reachability


route-map IPTelefon-Emblem permit 10

match ip address 106

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


But when using sh route-map and sh track, it sometimes reports the other side as down. Even though I have a steady ping on the modem from my PC.


BlindheimHS#sh route-map

route-map IPTelefon-Emblem, permit, sequence 10

Match clauses:

ip address (access-lists): 106

Set clauses:

ip next-hop verify-availability 10.11.1.2 1 track 1 [down]

Policy routing matches: 3 packets, 318 bytes


BlindheimHS#sh track

Track 1

Response Time Reporter 1 reachability

Reachability is Down

64 changes, last change 00:00:03

Latest operation return code: Timeout

Tracked by:

ROUTE-MAP 0


What can cause this?

Is it better to maybe use the patch-echo instead of the icmp-echo command in the IP SLA config?

What is the difference between those commands?


And one other thing; Building1 has a C3550 and it does not seem to have the set ip next-hop verify-availability command, even though it runs the same version of the OS as the C3560 on Building2.

Is there an alternative I can use on the C3550?


Thanks again.

Actions

This Discussion