cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1805
Views
0
Helpful
14
Replies

Floating static or reliable static routing?

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

1 Accepted Solution

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

View solution in original post

14 Replies 14

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

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

HTH

Rick

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

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.

Don't forget to rate helpful posts.

Hi Alain,

Is this true for all backup connections or only for those using the "backup interface" command?

Hi Katerina,

As far as I know it is true for backup interface and ddr.

Regards.

Alain.

Don't forget to rate helpful posts.

Don't forget to rate helpful posts.

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

HTH

Rick

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

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 Overview

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,

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,

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

handoko wiyanto
Level 3
Level 3

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,

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

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

HTH

Rick
Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco