cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1680
Views
5
Helpful
18
Replies

Default Route Problem

shufordm
Level 1
Level 1

We are using 3750G switches to route traffic through our Metro Ethernet network. We have a hub and spoke topology but a few of our sites have secondary links to other sites for redundancy. The physical switch ports are all setup as layer 2 trunk links and we emplement layer 3 using vlan interfaces. We are also using EIGRP for routing. The default-route on each 3750G points back to the hub via the VLAN 21 interface.

Now here is my problem. We setup secondary links between some of the sites for redundancy so that traffic can get back to the hub in case the main link goes down at that site. When the actual physical Metro E link goes down I am finding that traffic for unknown networks are not being routed.

If I do a trace route the packets never leave the originating L3 switch. If I take down the physical link "and" shutdown the corresponding vlan interface the default route traffic will then go out the backup link.

What I need to figure out is how to get it to failover to the backup link when the physical link to Metro E goes down. Does anyone have any ideas that I can try?

Thanks!

2 Accepted Solutions

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame

If you're using the default-route by hard-coding it on each spoke device (e.g. ip route 0.0.0.0 0.0.0.0 x.x.x.x), you might consider advertising it within EIGRP from your hub instead. Another option might be the usage of enhanced object tracking to track the next upstream device. (Unsure how much of this feature the 3750 offers.)

View solution in original post

Richard Burts
Hall of Fame
Hall of Fame

Mark

The issue that you describe about not failing over to a secondary default route is fairly common when using static default routes. But your description indicates that you are using EIGRP for routing. EIGRP is usually quite good about detecting failed links and switching to a secondary path. Do you perhaps have static default routes configured in the spoke switches?

If you do have static default routes then I would suggest that the optimum solution would be to remove the static default routes and to let EIGRP advertise the default route.

If you do not want to give up the static default route then there is a feature i IOS for Reliable Static Routing Backup Using Object Tracking. This link will give some information about it:

http://www.cisco.com/en/US/docs/ios/12_4/dial/configuration/guide/hdbackup.html

HTH

Rick

HTH

Rick

View solution in original post

18 Replies 18

Joseph W. Doherty
Hall of Fame
Hall of Fame

If you're using the default-route by hard-coding it on each spoke device (e.g. ip route 0.0.0.0 0.0.0.0 x.x.x.x), you might consider advertising it within EIGRP from your hub instead. Another option might be the usage of enhanced object tracking to track the next upstream device. (Unsure how much of this feature the 3750 offers.)

Richard Burts
Hall of Fame
Hall of Fame

Mark

The issue that you describe about not failing over to a secondary default route is fairly common when using static default routes. But your description indicates that you are using EIGRP for routing. EIGRP is usually quite good about detecting failed links and switching to a secondary path. Do you perhaps have static default routes configured in the spoke switches?

If you do have static default routes then I would suggest that the optimum solution would be to remove the static default routes and to let EIGRP advertise the default route.

If you do not want to give up the static default route then there is a feature i IOS for Reliable Static Routing Backup Using Object Tracking. This link will give some information about it:

http://www.cisco.com/en/US/docs/ios/12_4/dial/configuration/guide/hdbackup.html

HTH

Rick

HTH

Rick

Thanks for the help guys. I'll give that a try at the end of the day report back.

"If you do have static default routes then I would suggest that the optimum solution would be to remove the static default routes and to let EIGRP advertise the default route."

Richard we are using static default routes on each spoke. Are you saying that I should issue the ip default-network command on the hub or the redistribute static command. I'm not quite following you.

Thanks for the help.

Mark

Assuming that your hub router does have a default route I would suggest redistributing that default route into EIGRP.

HTH

Rick

HTH

Rick

I removed the default route from the spoke router and and made sure the hub was redistributing it's default route and everything worked fine. My routing table on the spoke looked like this:

Gateway of last resort is 10.7.0.11 to network 0.0.0.0

172.20.0.0/24 is subnetted, 2 subnets

D EX 172.20.113.0 [170/3072] via 10.7.0.11, 00:00:01, Vlan21

D 172.20.118.0 [90/3072] via 10.7.0.11, 00:00:01, Vlan21

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

D 10.10.0.0/16 [90/3072] via 10.7.0.10, 00:00:01, Vlan21

D 10.11.0.0/16 [90/3072] via 10.7.0.11, 00:00:01, Vlan21

D 10.9.1.0/30 [90/3072] via 10.8.1.2, 00:00:01, Vlan22

[90/3072] via 10.7.0.145, 00:00:01, Vlan21

[90/3072] via 10.7.0.45, 00:00:01, Vlan21

C 10.8.1.0/29 is directly connected, Vlan22

D 10.3.0.0/24 [90/28416] via 10.7.0.11, 00:00:01, Vlan21

D EX 10.255.255.0/24 [170/28416] via 10.7.0.11, 00:00:01, Vlan21

C 10.7.0.0/16 is directly connected, Vlan21

D 10.30.0.0/16 [90/3072] via 10.7.0.30, 00:00:01, Vlan21

C 10.70.80.0/24 is directly connected, Vlan80

D 10.20.0.0/16 [90/3072] via 10.7.0.20, 00:00:01, Vlan21

D 10.40.0.0/16 [90/3072] via 10.7.0.40, 00:00:03, Vlan21

C 10.70.104.0/24 is directly connected, Vlan104

C 10.70.105.0/24 is directly connected, Vlan105

C 10.70.106.0/24 is directly connected, Vlan106

C 10.70.107.0/24 is directly connected, Vlan107

D 10.45.0.0/16 [90/3072] via 10.8.1.2, 00:00:01, Vlan22

[90/3072] via 10.7.0.45, 00:00:01, Vlan21

C 10.70.100.0/24 is directly connected, Vlan100

C 10.70.101.0/24 is directly connected, Vlan101

C 10.70.102.0/24 is directly connected, Vlan102

C 10.70.103.0/24 is directly connected, Vlan103

D 10.60.0.0/16 [90/3072] via 10.7.0.60, 00:00:03, Vlan21

D 10.50.0.0/16 [90/3072] via 10.7.0.50, 00:00:03, Vlan21

D 10.70.0.0/16 is a summary, 1d03h, Null0

C 10.70.1.0/24 is directly connected, Vlan1

D 10.90.0.0/16 [90/3072] via 10.7.0.90, 00:00:03, Vlan21

C 10.70.31.0/24 is directly connected, Vlan31

C 10.70.20.0/24 is directly connected, Vlan20

D 10.80.0.0/16 [90/3072] via 10.7.0.80, 00:00:05, Vlan21

D 10.110.0.0/16 [90/3072] via 10.7.0.110, 00:00:03, Vlan21

D 10.100.0.0/16 [90/3072] via 10.7.0.100, 00:00:03, Vlan21

C 10.70.60.0/24 is directly connected, Vlan60

D 10.120.0.0/16 [90/3072] via 10.7.0.120, 00:00:02, Vlan21

C 10.70.205.0/24 is directly connected, Vlan205

C 10.70.206.0/24 is directly connected, Vlan206

C 10.70.207.0/24 is directly connected, Vlan207

C 10.70.200.0/24 is directly connected, Vlan200

D 10.140.0.0/16 [90/3072] via 10.7.0.140, 00:00:03, Vlan21

D 10.130.0.0/16 [90/3072] via 10.7.0.130, 00:00:03, Vlan21

D 10.135.0.0/16 [90/3072] via 10.7.0.135, 00:00:03, Vlan21

D 10.145.0.0/16 [90/3072] via 10.7.0.145, 00:00:03, Vlan21

D 10.150.0.0/16 [90/3072] via 10.7.0.150, 00:00:03, Vlan21

C 10.70.208.0/24 is directly connected, Vlan208

C 10.70.209.0/24 is directly connected, Vlan209

C 10.70.210.0/24 is directly connected, Vlan210

C 10.70.211.0/24 is directly connected, Vlan211

D 10.170.0.0/16 [90/3072] via 10.7.0.170, 00:00:05, Vlan21

D 10.160.0.0/16 [90/3072] via 10.7.0.160, 00:00:03, Vlan21

D 10.180.0.0/16 [90/3072] via 10.7.0.180, 00:00:03, Vlan21

D 10.5.203.0/24 [90/3072] via 10.7.0.145, 00:00:03, Vlan21

C 10.70.150.0/23 is directly connected, Vlan150

D*EX 0.0.0.0/0 [170/28416] via 10.7.0.11, 00:00:03, Vlan21

As you can see the external route was redistributed via eigrp. But when I take down the physical Metro Ethernet link the routing table changes and everything is routed through vlan 22, which is what I want to happen, but their is no candidate for a default route listed and only packets that are going to known networks are getting out.

Mark

The symptoms now sound like the default route is advertised via EIGRP on VLAN 21 but not on VLAN 22. I would have expected it to be advertised on both. I suspect that there is some config issue that is preventing the advertisement. Perhaps it is time to ask that you post the config - it would be helpful to see the config of this device and at least the EIGRP section of the config from its neighbor on vlan 22.

It might also help to post the output of show ip eigrp topology - at least the entries for the default route.

HTH

Rick

HTH

Rick

One thing that I noticed is the default route from the Hub (0.0.0.0 0.0.0.0 via 10.3.0.1) is not being distributed but all other static routes are. It's not flagging it as an external route but 10.3.0.0 is showing up in eigrp.

Do you want me to post configs from both spoke routers and the hub?

Mark

Since the default route does appear to be advertised ok by the hub I do not see much reason to need its config at this point. I am more interested why the default route is not advertised over VLAN 22. To understand this we may need this router and the neighbor on VLAN 22.

HTH

Rick

HTH

Rick

Here are the 2 spoke router configs. I have been working off of spoke-router1. It has a metro ethernet connection to the hub and a link to spoke-router2. Spoke-router 2 has a metro ethernet connnection to the hub and 2 backup links.

I forgot to add that the configs are before the changes we made earlier.

Mark

A config from before the change may not be so very useful in understanding a problem that developed after the change. I have looked at the config of router2 and I see that it was doing a summary address on VLAN 22 but otherwise not doing any route advertisement filtering. Perhaps you can get a copy of the config from after the change so we can see its current behavior. It may also be helpful if you would post the output of show ip eigrp topology from the router you are working on.

HTH

Rick

HTH

Rick

Ok I removed the static default route from both spoke routers and they pulled the redistributed default route. Here are the neighbor tables for each. The metro ethernet connection is up on both so they are not using their backup connections. I will show more in subsequent posts after we take down the main link.

Spoke-router1:

FDHS-MDF-3750G#sh ip eigrp neighbors

IP-EIGRP neighbors for process 2

H Address Interface Hold Uptime SRTT RTO Q Seq Typ

e

(sec) (ms) Cnt Num

21 10.7.0.90 Vl21 10 00:39:37 13 200 0 8465

20 10.7.0.130 Vl21 10 00:39:37 13 200 0 29626

19 10.7.0.20 Vl21 11 00:39:37 1 200 0 6787

18 10.8.1.2 Vl22 11 00:39:37 6 200 0 4362

17 10.7.0.180 Vl21 14 00:39:38 13 200 0 69988

16 10.7.0.150 Vl21 12 00:39:38 1 200 0 4786

15 10.7.0.60 Vl21 14 00:39:38 16 200 0 22625

14 10.7.0.40 Vl21 14 00:39:38 12 200 0 23253

13 10.7.0.80 Vl21 14 00:39:38 8 200 0 36479

12 10.7.0.100 Vl21 14 00:39:39 6 200 0 11680

11 10.7.0.11 Vl21 11 00:39:39 150 900 0 280623

10 10.7.0.120 Vl21 10 00:39:39 1 200 0 1745

9 10.7.0.160 Vl21 14 00:39:39 6 200 0 23924

8 10.7.0.140 Vl21 12 00:39:39 1 200 0 25432

7 10.7.0.145 Vl21 12 00:39:39 1 200 0 6099

6 10.7.0.50 Vl21 12 00:39:40 1 200 0 281351

5 10.7.0.135 Vl21 13 00:39:40 1 200 0 23261

4 10.7.0.110 Vl21 14 00:39:41 36 216 0 6344

3 10.7.0.10 Vl21 14 00:39:41 29 200 0 4122

2 10.7.0.30 Vl21 14 00:39:41 1 200 0 11987

1 10.7.0.45 Vl21 11 00:39:41 4 200 0 4364

0 10.7.0.170 Vl21 12 00:39:41 1 200 0 22387

Spoke-router2:

EES-MDF-3750G#sh ip eigrp neighbors

IP-EIGRP neighbors for process 2

H Address Interface Hold Uptime SRTT RTO Q Seq Typ

e

(sec) (ms) Cnt Num

16 10.8.1.1 Vl22 14 00:45:12 5 200 0 35

9 10.7.0.70 Vl21 11 00:45:14 14 200 0 34

1 10.7.0.90 Vl21 14 02:57:08 45 270 0 8465

12 10.7.0.120 Vl21 11 2d07h 38 228 0 1745

6 10.7.0.170 Vl21 11 4d23h 40 240 0 22387

22 10.7.0.140 Vl21 12 5d03h 36 216 0 25432

21 10.7.0.145 Vl21 13 5d03h 29 200 0 6099

20 10.7.0.20 Vl21 10 5d03h 30 200 0 6787

19 10.7.0.30 Vl21 13 5d03h 58 348 0 11987

18 10.7.0.110 Vl21 12 5d03h 35 210 0 6344

17 10.7.0.130 Vl21 14 5d03h 37 222 0 29626

15 10.7.0.135 Vl21 11 5d03h 35 210 0 23261

14 10.7.0.11 Vl21 10 5d03h 10 200 0 280623

13 10.7.0.50 Vl21 10 5d03h 30 200 0 281351

11 10.7.0.180 Vl21 14 5d03h 32 200 0 69988

10 10.7.0.100 Vl21 12 5d03h 39 234 0 11680

8 10.7.0.60 Vl21 14 5d03h 33 200 0 22625

7 10.7.0.40 Vl21 11 5d03h 32 200 0 23253

5 10.7.0.80 Vl21 11 5d03h 33 200 0 36479

4 10.7.0.160 Vl21 12 5d03h 27 200 0 23924

3 10.7.0.10 Vl21 14 5d03h 35 210 0 4122

2 10.7.0.150 Vl21 10 5d03h 40 240 0 4786

0 10.9.1.2 Vl23 10 5d03h 1 200 0 6100

Here are the configs with the static default route removed from both routers as well as the ip route.

Spoke-router1: Some of the output is removed so it fits in this post

Gateway of last resort is 10.7.0.11 to network 0.0.0.0

172.20.0.0/24 is subnetted, 2 subnets

D EX 172.20.113.0 [170/3072] via 10.7.0.11, 00:55:10, Vlan21

D 172.20.118.0 [90/3072] via 10.7.0.11, 00:55:10, Vlan21

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

D 10.10.0.0/16 [90/3072] via 10.7.0.10, 00:55:10, Vlan21

D 10.11.0.0/16 [90/3072] via 10.7.0.11, 00:55:10, Vlan21

D 10.9.1.0/30 [90/3072] via 10.8.1.2, 00:55:10, Vlan22

[90/3072] via 10.7.0.145, 00:55:10, Vlan21

[90/3072] via 10.7.0.45, 00:55:10, Vlan21

C 10.8.1.0/29 is directly connected, Vlan22

D 10.3.0.0/24 [90/28416] via 10.7.0.11, 00:55:10, Vlan21

D EX 10.255.255.0/24 [170/28416] via 10.7.0.11, 00:55:10, Vlan21

C 10.7.0.0/16 is directly connected, Vlan21

D 10.30.0.0/16 [90/3072] via 10.7.0.30, 00:55:09, Vlan21

C 10.70.80.0/24 is directly connected, Vlan80

D 10.20.0.0/16 [90/3072] via 10.7.0.20, 00:55:09, Vlan21

D 10.70.0.0/16 is a summary, 00:56:35, Null0

C 10.70.1.0/24 is directly connected, Vlan1

D 10.90.0.0/16 [90/3072] via 10.7.0.90, 00:56:30, Vlan21

D 10.140.0.0/16 [90/3072] via 10.7.0.140, 00:56:30, Vlan21

D 10.130.0.0/16 [90/3072] via 10.7.0.130, 00:56:30, Vlan21

D 10.135.0.0/16 [90/3072] via 10.7.0.135, 00:56:30, Vlan21

D 10.145.0.0/16 [90/3072] via 10.7.0.145, 00:56:30, Vlan21

D 10.150.0.0/16 [90/3072] via 10.7.0.150, 00:56:30, Vlan21

C 10.70.208.0/24 is directly connected, Vlan208

C 10.70.209.0/24 is directly connected, Vlan209

C 10.70.210.0/24 is directly connected, Vlan210

C 10.70.211.0/24 is directly connected, Vlan211

D 10.170.0.0/16 [90/3072] via 10.7.0.170, 00:56:30, Vlan21

D 10.160.0.0/16 [90/3072] via 10.7.0.160, 00:57:13, Vlan21

D 10.180.0.0/16 [90/3072] via 10.7.0.180, 00:57:13, Vlan21

D 10.5.203.0/24 [90/3072] via 10.7.0.145, 00:57:13, Vlan21

C 10.70.150.0/23 is directly connected, Vlan150

D*EX 0.0.0.0/0 [170/28416] via 10.7.0.11, 00:18:12, Vlan21

Forgot to attach the configs. Also if the only change made is taking down the physical link for metro ethernet the routing table will look the same except it won't have a default route.

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: