03-30-2009 12:31 AM - edited 03-04-2019 04:08 AM
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.
Solved! Go to Solution.
03-30-2009 02:35 AM
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
03-30-2009 01:38 AM
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
03-30-2009 02:35 AM
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
03-30-2009 02:47 AM
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
03-31-2009 04:06 AM
Thanks Giuseppe, I wasn't 100% sure
03-31-2009 02:06 AM
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?
03-30-2009 01:40 AM
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
04-01-2009 04:27 AM
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.
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: