Dialing Two Different ISP (problem)

rszadkowski · ‎06-30-2004

Hi to Everyone,

I have a problem with dialing two different ISP.

They have different dialin numbers, different PPP authentication method and users/passwords.

Additionally one of these is free of charge, so this line/provider should be chosen first and the second one (GSM gate) we treat as a backup line to the Internet, when the first is down.

I cannot use two default routes to the internet with different metrics i.e.:

ip route 0.0.0.0 0.0.0.0 BRI0/0

ip route 0.0.0.0 0.0.0.0 Async65 2

because the Async will never be in ip routing table due to (spoofing) character of BRI --> BRI is always UP.

I cannot use the policy base routing (route-map).

The same reason - BRI 0/0 is always UP.

There is a another approach to this problem.

I can use dialer interface with two dialer strings.

I can use pool-member with priority (or rotary group with priority).

I can set the proper method of choosing order (to make decision which will be dial-out first).

But i still have problem with two types of PPP authentication.

ISDN is CHAP (only ISP requires authentication)

GSM/async is PAP (only ISP requires authentication)

Problem is that I cannot use two types of sending user names and passwords in dialer interface i.e.:

ppp chap hostname ppp

ppp chap password 7 08315C5E

ppp pap sent-username plusgsm password 7 <pass>

Why? Because GSM provider refuses PPP negotiation/authentication in the moment of sending from the router to this provider, PPP CHAP sequence (which is placed first).

The problem would be solved if the GSM/ISP ignored the CHAP sequence. But reality is different.

I was trying and testing many kind of configurations but I didn't find any proper solution of this problem.

I will be very grateful to you for your help.

Regards

Remik

tepatel · ‎06-30-2004

There is a solution for your problem. You need to use dialer profile for each of the physical interace. That way under dialer profile (dialer interace) you can configure authentication scheme etc..the way you want as its user specific. Here is the way

int bri0

dialer pool-member 1

interface async 1

dialer pool-member 2

interface dialer 1

dialer pool 1

ppp authenticatoin chap

interface dialer 2

ppp authentication pap

dialer pool 2

You can set the dialer priority now based on which dialer interface to use for dialout.

Somewhat similar config is discussed at following location

http://www.cisco.com/en/US/tech/tk801/tk133/technologies_configuration_example09186a0080093c2e.shtml

rszadkowski · ‎07-01-2004

Thans for your answer. But ...

... I've done many (really many) kind of configuration and this what you suggested me is obvious even for me. This is a basic knowladge for every CISCO-man. I've read many CISCO TAC examples and documents. There wasn't any good solution for me.

Always the BRI is treated as a backup for the permanent / serial interface.

It is simple -> when the serial is down the ISDN interface is the next into the routing table.

Of course we can use not only "ip route ..." command to distinguish which line is "main" and which is "backup".

But it is not a topic of my problem.

As you noticed I had written an information that problem is also in the IP routing table.

Why? Because I must manage with two spoofing interfaces. This is the problem. Both interfaces are always UP.

So, in your proposition I have two (spoofing) interfaces called "dialers". There is no possibility to set both interfaces as a default gateway i.e:

ip route 0.0.0.0 0.0.0.0 dialer1

ip route 0.0.0.0 0.0.0.0 dialer2

because both are "spoofing" and are present in the routing table simultaneously.

That means both interfaces will be chosen when the router tries go to the Internet. This is not a solution for me.

If you set i.e:

ip route 0.0.0.0 0.0.0.0 dialer1

ip route 0.0.0.0 0.0.0.0 dialer2 2

interface dialer 2 will never be set into the routing table because interface dialer 1 is allways UP.

Do you agree with me?

So that means it is not solution for my problem as well.

If the ISDN interface would be down when I unplug the phisical connector --> that will be superb.

But it isn't. ISDN is allways UP.

I need a constructive help. How can I set the configuration with two interfaces which are "spoofing"?

I remind you that one of these is FREE so this interface should be chosen first.

Regards for ALL.

Remik

tepatel · ‎07-01-2004

Looks like you have lots of experience with DDR and backup but there is no real way to fix your issue as you are trying to get a "backup for a dialer/dialup link". Those DDR links connects and disconnects based on traffic.. So all you are left with is "layer 1 and 2" backup on those links.

Close you can get is "object tracking" which is new feature discussed at

http://www.cisco.com/en/US/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html

But again..we can't help..as there is no real way to achive what you are trying to get..

tepatel · ‎07-02-2004

Have you tried that object tracking feature mentioned in ly last reply? That should be a solution for you..In that you need to track the object(ip address) on the internet via primary link, if it fails, router will activate backup link..that way the dependency over interface status has been eliminated.

rszadkowski · ‎07-09-2004

I will write when I complete all my config.

Regards

Remik

rszadkowski · ‎07-09-2004

I've tested RTR. It is very helpful IOS service.

But when you use NAT with RTR, then you have a problem.

Why? Answer is below.

R5 - remote router which is object tracked

R5#debug ip packet

IP packet debugging is on

R5#

*Mar 5 04:23:38.087: IP: s=10.21.1.1 (BRI0/0), d=192.168.221.1, len 64, rcvd 4

*Mar 5 04:23:38.087: IP: s=192.168.221.1 (local), d=10.21.1.1, len 64, unroutable

*Mar 5 04:23:48.087: IP: s=10.21.1.1 (BRI0/0), d=192.168.221.1, len 64, rcvd 4

*Mar 5 04:23:48.091: IP: s=192.168.221.1 (local), d=10.21.1.1, len 64, unroutable

*Mar 5 04:23:58.087: IP: s=10.21.1.1 (BRI0/0), d=192.168.221.1, len 64, rcvd 4

*Mar 5 04:23:58.091: IP: s=192.168.221.1 (local), d=10.21.1.1, len 64, unroutable

*Mar 5 04:24:08.087: IP: s=10.21.1.1 (BRI0/0), d=192.168.221.1, len 64, rcvd 4

*Mar 5 04:24:08.087: IP: s=192.168.221.1 (local), d=10.21.1.1, len 64, unroutable

As I said the R5 is a remote (i.e. Internet) router.

I've set ip packet debugging on this router to see what kind of source addresses are appeared there.

Packets above have been generated by RTR, when you use the LOCAL policy base routing:

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

!

ip local policy route-map MY_LOCAL_POLICY

!

route-map MY_LOCAL_POLICY permit 10

match ip address 103

set interface BRI0/0

!

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

When I set a default route:

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

!

ip route 0.0.0.0 0.0.0.0 BRI 0/0

!

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

source adress of RTR packets was OK.

*Mar 5 04:17:59.759: IP: s=192.168.121.2 (BRI0/0), d=192.168.221.1, len 60, rcvd 4

*Mar 5 04:17:59.759: IP: s=192.168.221.1 (local), d=192.168.121.2 (BRI0/0), len 60, sending

*Mar 5 04:18:00.763: IP: s=192.168.121.2 (BRI0/0), d=192.168.221.1, len 60, rcvd 4

*Mar 5 04:18:00.763: IP: s=192.168.221.1 (local), d=192.168.121.2 (BRI0/0), len 60, sending

I don't know why IOS with NAT treats the packets in that diffrent way.

Why the packets originated from the LOCAL policy base route path are treated so different.

I noticed that the packets which come on the FE (LAN inside interface) and are treated by policy base routing are OK - I mean they are going through the NAT and they have external NAT IP addres as a source addres. They are 100% OK.

Only LOCAL ip policy base routing is treated differently.

Conclusion: Probably I will have to give the NAT up.

What do you think?

Regards

Remik

rszadkowski · ‎09-15-2004

I solved the problem in this way - I wrote my own software (for Windows), which controls all Internet interfaces on the router. I can decide which interface will be active directly from the Windows. I make two clicks and I have what I need. Only one interfeace is active in the same time.

Regards

Remik