creating a standby route

garyrivers · ‎07-08-2009

i'm doing some old-school stuff here but for the life of me I'm not getting the routing correct.

i have a remote office RTR (1700 rtr) connected to the central office RTR (2851 rtr) via their fastethernet ports.

to setup a dial up back up solution i plugged in a modem into the 1700 rtr via the AUX port. it dials into a 8-port async card in the 2851.

in the remote RTR, under the fas0/0 i configed the AUX port as the standby port:

interface FastEthernet0/0

description Connection to KWCH

backup interface Async5

ip address 10.30.47.102 255.255.248.0

speed auto

full-duplex

and created the other needed dial ports

interface Async5

no ip address

encapsulation ppp

no ip route-cache cef

no ip route-cache

dialer in-band

dialer pool-member 1

dialer-group 1

async default routing

async mode interactive

!

interface Dialer1

ip address negotiated

no ip redirects

encapsulation ppp

no ip route-cache cef

no ip route-cache

dialer pool 1

dialer remote-name sdf;kasdfkj

dialer string ########

dialer-group 1

and at the central office RTR the appropriate interfaces were created, the routes created, etc.

well, each side can ping eachother when the main connection is up but when i kill the connection and the dialup comes up i can't ping the opposite side.

i'm sure it's a routing issue but i'm not sure which side is the problem.

thanks, gary

Richard Burts · ‎07-08-2009

Gary

It is difficult to know exactly what the problem is, especially since some information that would be helpful is hidden or omitted in the configs that you posted. But here are my observations, which might help to point toward at least some of the problem.

On the HQ router you have a static route to the remote router and a floating static for backup:

ip route 10.30.53.0 255.255.255.0 10.30.47.102

ip route 10.30.53.0 255.255.255.0 Async1 100

the floating static will be used only if the primary route is withdrawn from the routing table. That would generally be the case only if the interface of the next hop goes protocol down. Since you have hidden what interface would include 10.30.47.102 we have little way to know how failure would impact it. When you test and produce the failure, if you do show ip route on the HQ router is it using the normal route or is it using the floating static?

On the remote router you have a default route through Faste0/0. And you have another static route for the subnet of HQ using the Async:

ip route 10.30.40.0 255.255.248.0 Dialer1

However the prefix that you specify in the static route is exactly the same as the subnet on the FastEthernet interface. If the router has a static route for a prefix and the prefix exists as a connected route than the static route will not be used. In normal operation, on the remote router what is in the routing table when you do show ip route? And when you induce the failure what is in the routing table when you do show ip route?

If you answer the questions that I ask we may get closer to understanding what the problem is and what might be done to solve it.

HTH

Rick

HTH

Rick

garyrivers · ‎07-08-2009

Thanks for your help.

during a "failure" the central RTR is still using the normal route.

remote RTR routing table:

TestRTR#sh ip rout

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.30.47.254 to network 0.0.0.0

2.0.0.0/24 is subnetted, 1 subnets

C 2.2.2.0 is directly connected, Loopback100

10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks

C 10.254.253.6/32 is directly connected, Loopback0

C 10.30.53.0/24 is directly connected, Ethernet1/0

C 10.30.40.0/21 is directly connected, FastEthernet0/0

S* 0.0.0.0/0 [1/0] via 10.30.47.254

TestRTR#

during failure:

TestRTR#sh ip route

Gateway of last resort is 10.30.47.254 to network 0.0.0.0

2.0.0.0/24 is subnetted, 1 subnets

C 2.2.2.0 is directly connected, Loopback100

10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks

C 10.254.253.6/32 is directly connected, Loopback0

C 10.30.53.0/24 is directly connected, Ethernet1/0

C 10.254.253.58/32 is directly connected, Dialer1

C 10.254.253.60/32 is directly connected, Dialer1

S 10.30.40.0/21 is directly connected, Dialer1

S* 0.0.0.0/0 [1/0] via 10.30.47.254

TestRTR#

Richard Burts · ‎07-08-2009

Gary

The information in this post answers some questions and raises a new question.

If the central RTR continues to use the normal route during the failure then this is an indication that the interface does not change state to protocol down during the failure. This is not uncommon for Ethernet/FastEthernet/GigEthernet interfaces. Depending on the version of code you are running you might look into Object Tracking or IP SLA to determine reachability of the remote subnet and remove the normal route from the routing table. As it stands you have created a problem and the central RTR continues to send traffic over the normal route (which creates a black hole).

The interesting thing in the routing tables that you post is that in the first (normal) routing table that 10.30.40.0 is connected to FastEthernet and in the second routing table (during failure) it is connected on the Dialer interface. This shows that the FastEthernet interface did change state to protocol down. Which is quite different from the central RTR. Do we know why they react differently?

HTH

Rick

HTH

Rick

garyrivers · ‎07-09-2009

the test RTR in our lab is connected to the central RTR thru a switch so the central RTr will not see the connection actually go down.

Dang it!

But in the real world, that's how the remote RTR is connected.

Mmmmm, so how can i get around this issue without redoing the whole topology?

See attached for the layout.