06-19-2012 11:03 AM - edited 03-04-2019 04:43 PM
Hello all,
I have a fairly simple need. I have a primary serial line connecting to a 3rd party. When this line fails, I want an ISDN line to be used as a backup.
Traffic to the 3rd party uses a static route pointing out the serial interface. Simple? Right?
My first try included configuring a dialer, access-list for the interesting traffic and a floating static with a metric of 180. After shuting down the serial interface I would have thought that traffic would be routed through the dialer... That didn't happen! I also got no matches on the access-list!
If the above configuration still fails, after retesting and debugging (although the ISDN connection is working), I want to try out reliable static routing...
After reading http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html#wp1071380 I have a few questions.
If I configure
ip sla monitor 1
type echo protocol ipIcmpEcho destination-ip-address source-interface serial0/0
(as a destination-ip-address I am going to use the ip address configured on the other side of the point-to-point connection)
do I still need to create a route-map so that icmp packets for the sla are always routed through the correct interface (serial 0/0)? And if I do, could someone please explain the purpose of the command "set interface dialer 0 null 0" in the following configuration? (As I mentioned, I am using a dialer).
access-list 101 permit icmp any host destination-ip-address echo
route-map MY-LOCAL-POLICY permit 10
match ip address 101
set interface dialer0 null 0
Shouldn't the interface be set to serial 0/0???
Thank you in advance,
Katerina
Solved! Go to Solution.
06-19-2012 01:10 PM
Hello Katerina,
I agree the route-map should use set interface ser0/0, because it should send the ICMP probe packets via the primary link, or if the primary link is down it should drop them so set interface ser0/0 null0 is also a possible configuration.
The DDR configuration on ISDN should work also without IP SLA. It is strange it didn't triggered in your test. debug dialer can be used to investigate this issue.
Hope to help
Giuseppe
06-19-2012 01:10 PM
Hello Katerina,
I agree the route-map should use set interface ser0/0, because it should send the ICMP probe packets via the primary link, or if the primary link is down it should drop them so set interface ser0/0 null0 is also a possible configuration.
The DDR configuration on ISDN should work also without IP SLA. It is strange it didn't triggered in your test. debug dialer can be used to investigate this issue.
Hope to help
Giuseppe
06-19-2012 01:24 PM
Katerina
I see in your original post that there were no matches in the access list for the dialer. This suggests that there are flaws in the creation of the access list. Can you supply some information about the network environment, including the addressing of the interfaces and of the devices that will be sending traffic over these links and post the configuration of the interfaces (serial and ISDN and dialer) and the access list.
HTH
Rick
06-19-2012 10:19 PM
Hello Richard & Giuseppe,
performing the tests with the ISDN, the only time I got matches on the access-list was when I tried to ping the ip-address of the remote-dialer interface (so, I wasn't 100% correct in my original post). This triggered the ISDN alright...
After shutting the serial interface (primary connection) and trying to ping an ip-address on the remote site, nothing happened (no matches etc).
I have two static routes configured
ip route remote-site-subnet mask serial 0/0 (primary)
ip route remote-site-subnet / mask dialer0 180 (backup)
The behaviour mentioned above is making me believe that the first route isn't removed from the routing table, even though the link has failed. As a consequence the second route isn't inserted into the routing table, resulting in lost packets and the ISDN not coming up. The weird thing is, that even if I trigger the ISDN manually (after shutting the primary) packets don't get across the dialer interface.
The configuration is really straight forward (but maybe I am missing something):
interface Serial0/0
bandwidth 128
ip address x.x.x.x 255.255.255.252
ip virtual-reassembly
encapsulation ppp
no fair-queue
serial restart-delay 0
interface BRI0/0
no ip address
encapsulation ppp
no ip mroute-cache
dialer pool-member 1
isdn switch-type basic-net3
isdn point-to-point-setup
ppp authentication chap
!
interface Dialer0
ip address y.y.y.y 255.255.255.252
encapsulation ppp
dialer pool 1
dialer enable-timeout 2
dialer string 123456789
dialer max-call 1
dialer-group 1
ppp authentication chap
ppp chap hostname
ppp chap password
access-list 101 permit ip any any
dialer-list 1 protocol ip list 101
ip route remote-site-subnet mask serial 0/0
ip route remote-site-subnet mask dialer0 180
Hopefully I am going to perform tests again today, and if all fails, I will try the reliable static routing solution to see if this helps.
Thanks in advance,
Katerina
06-20-2012 12:10 AM
Hi,
As far as I know you can't trigger the dialer inetrface by shutting down the primary interface as it the primary interface has to be up/down or down/down but not administratively down for the event to be triggered.
Regards.
Alain.
Don't forget to rate helpful posts.
06-20-2012 12:42 AM
Hi Alain,
Is this true for all backup connections or only for those using the "backup interface" command?
06-20-2012 02:39 AM
Hi Katerina,
As far as I know it is true for backup interface and ddr.
Regards.
Alain.
Don't forget to rate helpful posts.
06-20-2012 08:17 AM
Katerina
When I read the original post I thought about the possibility that shutdown of the interface might have been the problem that prevented failover to the ISDN. But then I realized that the restriction about not triggering if the interface is shut down is applicable only to backup interface. Since you are using floating static I do not see that interface shutdown would be any problem.
I agree that it would be very helpful if you would test again and would post the output of show ip route after the serial interface is down.
I have looked at the partial config that you posted and I notice this command under the BRI
isdn point-to-point-setup
I have experienced some odd behavior when that was in the config. Unless there is a particular reason to have it in the congig I would suggest that you remove it before you test again and see if that makes any difference in how the ISDN behaves.
HTH
Rick
06-20-2012 10:59 PM
Thank you Rick for your thoughts.
From what I've read, "shut down" cannot be used to trigger the backup interface. I haven't seen similar problems for DDR, but I will try out all mentioned solutions and troubleshooting tips.
Since this is a working environment, I have to find a maintenance window, to perform all the tests and debugging.
I will then update the post accordingly and rate the posts.
Thank you all for your ideas and help.
Katerina
06-20-2012 11:55 PM
hi Katerina,
this is why the dialer watch list become very handy (http://www.cisco.com/en/US/docs/ios/12_2/dial/configuration/guide/dafbakdw.html)
Dialer Watch is a backup feature that integrates dial backup with routing capabilities. Prior dial backup implementations used the following conditions to trigger backup:
•Interesting packets were defined at central and remote routers using dial-on-demand routing (DDR).
•Connection loss occurred on a primary interface using a back up interface with floating static routes.
•Traffic thresholds were exceeded using a dialer load threshold.
Prior backup implementations may not have supplied optimum performance on some networks, such as those using Frame Relay multipoint subinterfaces or Frame Relay connections that do not support end-to-end permanent virtual circuit (PVC) status updates.
Dialer Watch provides reliable connectivity without relying solely on defining interesting traffic to trigger outgoing calls at the central router. Dialer Watch uses the convergence times and characteristics of dynamic routing protocols. Integrating backup and routing features enables Dialer Watch to monitor every deleted route. By configuring a set of watched routes that define the primary interface, you are able to monitor and track the status of the primary interface as watched routes are added and deleted. Monitoring the watched routes is done in the following sequence:
1. Whenever a watched route is deleted, Dialer Watch checks whether there is at least one valid route for any of the defined watched IP addresses.
2. If no valid route exists, the primary line is considered down and unusable.
3. If a valid route exists for at least one of the defined IP addresses and if the route is pointing to an interface other than the backup interface configured for Dialer Watch, the primary link is considered up.
4. If the primary link goes down, Dialer Watch is immediately notified by the routing protocol and the secondary link is brought up.
5. Once the secondary link is up, at the expiration of each idle timeout, the primary link is rechecked.
6. If the primary link remains down, the idle timer is indefinitely reset.
7. If the primary link is up, the secondary backup link is disconnected. Additionally, you can set a disable timer to create a delay for the secondary link to disconnect, after the primary link is reestablished.
Dialer Watch provides the following advantages:
•Routing—Backup initialization is linked to the dynamic routing protocol, rather than a specific interface or static route entry. Therefore, both primary and backup interfaces can be any interface type, and can be used across multiple interfaces and multiple routers. Dialer Watch also relies on convergence, which is sometimes preferred over traditional DDR links.
•Routing protocol independent—Static routes or dynamic routing protocols, such as Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP) or Open Shortest Path First (OSPF) can be used.
•Nonpacket semantics—Dialer Watch does not exclusively rely on interesting packets to trigger dialing. The link is automatically brought up when the primary line goes down without postponing dialing.
•Dial backup reliability—DDR redial functionality is extended to dial indefinitely in the event that secondary backup lines are not initiated. Typically, DDR redial attempts are affected by enable-timeouts and wait-for-carrier time values. Intermittent media difficulties or flapping interfaces can cause problems for traditional DDR links. However, Dialer Watch automatically reestablishes the secondary backup line on ISDN, synchronous, and asynchronous serial links.
regards,
06-20-2012 11:59 PM
hi Richard,
the command point to point network means we have one isdn line on A site and one isdn line on B site.
for example, if site B having more than one ISDN line (in real network will be Disaster Recovery Site), means site B will handle more that one ISDN calls, then it will be point-to-multipoint.
regards,
06-20-2012 12:31 AM
Hi Katerina,
Please try this config. Or even ip sla would be a good option.
track 1 interface serial0/0 line-protocol
!
ip route remote-site-subnet mask serial 0/0 track 1
ip route remote-site-subnet mask dialer0 180
!
now
int s0/0
shut
would show the route entry through dialer 0.
If still no result then paste the output of "show ip route static" once you shut the serial0/0
Thanks,
Nandan
06-20-2012 04:23 AM
i did in the old times on production network, by using command dialer watch list. basically it monitors some destination network on the routing table, if the link going down, means no entry in the routing table, then the interface dialer wil start to dial
regards,
06-22-2012 03:30 AM
Hello to all,
Found the solution to the problem. Routing!!!!
As stated in the beginning of the post I had configuerd two static routes pointing to the 3rd party connection - one primary, and a backup with AD 180.
After shutting down the serial interface, the primary route was deleted from the routing table, but the second one was never inserted. When I removed the primary route from the configuration and only left the secondary ISDN triggering again failed. But when I removed the AD the ISDN connection came up and packets were succesfully exchanged (so there was no problem with the dialer config and admin shutting the serial interface didn't cause any problems).
And then it hit me!!!! All this had something to do with AD. The specific router also runs OSPF (AD 110) to learn routes from the internal network. A default route (0.0.0.0 0.0.0.0) is advertised to this router through OSPF. So when the primary route was deleted from the routing table, everything not in the routing table was sent into the internal network.
By lowering the AD on the backup route to something like 100, the problem was solved.
Thank you all for your interesting ideas!
The thing is that when I initially opened this discussion I had questions regarding reliable static routing, and to be more specific questions related to the route-map as described in this link: http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html#wp1071380. Giuseppe was kind enough to answer these questions for me. I wanted to try out reliable static routing in case all else failed.
Regards,
Katerina
06-22-2012 03:55 AM
Katerina
I am glad that you have solved the problem. It is very interesting that it turned out to be the AD of the floating static route. Thank you for posting back and telling us how you figured it out. You have provided an interesting of a problem and of how to troubleshoot it.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide