Backup Link Issues

[kradjesh13]

Thanks Palaniappan and Rick.

As it was mentioned in the previous post i am starting a seperate thread to discuss about my issue.

I have attached the configs which was added for the ISDN to act as a backup link.

Once again to make clear, the primary DSL connection will use the EIGRP. Though its a stub network, for monitoring purpose we are using EIGRP. When the primary link fails and ISDN comes up (though its comming up) it will be using the default route with higher AD and the head office will use floating Static which points to the site office.

The problem is, though the ISDN line comes up on DSL failure at site office, we can't able to ping the site office from the head office. I can see this by using show ISDN status and show ISDN history when the primary link comes up.

Thanks.

Rajesh

[Richard Burts]

Rajesh

I appreciate that you have opened a separate thread to discuss your issue. It will make it easier to focus on the particulars of your problem.

I have looked at the config file that you posted. The floating static for 192.168.40.0 at the head office looks right. And the floating static default route at the remote site looks ok, assuming that EIGRP would normally advertise a default route over the DSL when it is up.

From the fact that I do not see any dialing information in the config at the head office, would I be correct in assuming that you have set it up for the remote to dial the head office and for the head office to not dial at all?

I do see ppp authentication chap on the remote site and do not see any ppp authentication at the head office. I am not sure if that was an error in cut and paste of the config or if there is really no authentication configured at the head office.

From your mention that the connection was DSL and from the ip tcp adjust-mss 1452 configured at the remote site I wonder if IPSec tunnels are involved. Is there a possibility that one end is still trying to use IPSec when the DSL has failed? I also wonder whether Network Address Translation has been configured and whether it may be playing a role in this situation.

If I understand correctly when the DSL goes down the ISDN does dial. How long does it stay connected?

You state that the Head Office can not ping the remote site. Can the remote site ping the Head Office?

Perhaps you can clarify some of these things and we might get closer to a solution.

HTH

Rick

[kradjesh13]

Appreciated for your time in dealing with the issue.

You are right Rick, the remote site will be dialing the head office when ever it looses its primary DSL link.

PPP authenitcation chap is not configured in the head office. So, do i need to configure that line in the head office router (i think i configured but the IOS did not accept. Need to verify tomorrow onceagain).

Since its an MPLS connection and all the sites comes under one VRF, we never use NAT transulations.

When we did a test scenario before implementing in the real time using DSL as the primary and ISDN as the secoundary links, i removed the DSL link from the interface and tried to ping the head office's backup interface(that is,172.51.2.30). It worked and even went to the outside world and surfed the web.

But after implementing i having little issues and asking for your help to correct me if there is any issues in the config.

Thanks

Rajesh

[Richard Burts]

Rajesh

I believe that having ppp authentication chap configured on end but not on the other end is an issue. Please configure it on the Head Office and be sure that the passwords given match (it is frequently a source of confusion: the remote configures a username which the Head Office and the Head Office configures a username which is the remote and the password must be exactly the same on both).

Please configure this and see if the behavior changes. If it still does not work then please post the output of these commands while the DSL is down and the ISDN is active:

show isdn status

show dialer

show ip route

it would be helpful to see that output from both routers.

HTH

Rick

[jackyoung]

If one side do not support PPP Chap authentication, simply remove it first to test the connectivity then add it back to isolate the problem.

Hope this helps.