Issue with Frame Relay and Backup ISDN

[mwalcott]

Hello all,

I have a dilemma that I need some second opinions on. I have a customer who has three routers, ’A’ is connected to ‘B’ which in turn is connected to ‘C’ over their serial lines using frame relay EIGRP and static routes. Routers ‘B’ and ‘C’ have a backup ISDN line between them (‘passive interface’ enabled on this interface). ‘B’ and ‘C’ are remote routers.

Everything works fine when frame relay is up and running. When we shut down the frame relay interface on ‘B’ which goes to ‘C’ and we could not ping to the Ethernet interface of ‘C’ from ‘A’. We then found that we could ping from ‘B’ to ‘C’ with no problem (ISDN line came up OK). However when we used an enhanced ping to change the source address of the packets leaving ‘B’ we found that it failed.

I figure that the normal ping worked because it used the source address of the interface it left to get to the destination (the serial link) thus router ‘C’ knew exactly where to send the packets back to and the other pings failed because they were unknown networks.

This is the most interesting part of the

configuration that led me to that conclusion:

ip route 0.0.0.0 0.0.0.0 10.10.8.x

ip route 0.0.0.0 0.0.0.0 10.10.10.x 200

! 10.10.8.x points to the next hop frame relay ip address

! 10.10.10.x points to the next hop ISDN ip address

I believe the first default route command on ‘C’ causes the router to send off the packets to a non-existent destination (interface shutdown at the other end). Because it is Frame Relay, the interface of router ‘C’ stays up even though the next hop is down thus the 10.10.8.x stays in the routing table.

This issue was fixed by my colleague who did the following:

ip route 0.0.0.0 0.0.0.0 Serial 0/0.1

ip route 0.0.0.0 0.0.0.0 10.15.10.1 200

! He then added framerelay map-class commands to routers ‘B’ and ‘C’:

map-class frame-relay stayintouch

frame-relay end-to-end keepalive mode bi-directional

This seems like overkill to me.

Are the mapclass commands necessary???

It should have worked by removing “ip route 0.0.0.0 0.0.0.0 10.10.8.x” and letting “ip route 0.0.0.0 0.0.0.0 10.10.10.x 200” stay put. Is this the case???

Thanks in advance for your comments and replies.

Michael Walcott

[nuno.morais]

Hi.

Your colleague is using a fairly recent feature (released on 12.0(5)T), which solves the problem we usually face with Frame-Relay when the VC goes down but the interface is kept "up".

Yes, that command is configured under a Frame-Relay map class. If you use it in bidirectonal mode, the other side (router B in your case) should also have this command configured. You have to apply that map-class to the Frame-Relay interface/subinterface.

As an alternative you can use dialer-watch on router C.

Hope it helps.

NM