cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1246
Views
9
Helpful
14
Replies

EIGRP - Default Route - Design

sachinraja
Level 9
Level 9

I was designing a three tier network with EIGRP and wanted to discuss a very small thing. This is also related to default route advertisement, though my scenario is a little different.. The network looks like:

Corporate WAN -- Dual core routers -- Dual Core switches -- Dual Distribution switches -- access switches...

Core routers have default route towards POP segment which connects to Firewalls/internet etc.. There are actually two or three POP segments in the whole of the WAN, and hence this default route isnt redistributed onto the WAN.. There are some 50 static routes which point to different segments in POP, which is ONLY redistributed into EIGRP, using distribute list..

Now, am designing Core/distribution switches in this network. My question is:

1) Since the core router is redistributing only 50 odd static routes into EIGRP, my Core switch will not get a default route advertisement in.. and so do my distribution/access switches. will summary address or interface based distribute list work well here, just to inject the default route towards the LAN, and not on the WAN ?

The admin here have plans to use dual static default routes internally on the Core/distribution switches, to avoid all these filtering issues, which doesnt seem a good idea to me ! I think we should really avoid static routes, if we run a full fledged dynamic routing protocol like EIGRP..

Two solutions now:

1) take default route via eigrp, but have different filters at different places

2) have static routes on the core/distribution switches pointing to next hops

am trying to avoid the second solution.. if so, what is the best way to go about the first solution ?

Any comments ?

1 Accepted Solution

Accepted Solutions

Raj

Could you just clarify. You say

"There is a challenge doing the distribute list here.. Firstly I have a distribute list which disallows default route onto some 10 peers (p2p links) terminating on the core routers. There are 4 more p2p ethernet links connecting to distro switches.. Now, I need to define distro lists for these interfaces which allows 0.0.0.0 and all other networks ! "

If these P2P links terminate on the core routers not the core switches then you can simply add a very straightforward distribute-list to the core switches for the interfaces connecting to the core routers just denying 0.0.0.0 and permit all else.

Where i am a little confused is why you need to use distribute-lists at all on the distro switches. All we are trying to do is stop the default-route from getting up to the core routers. Unless i have misunderstood and you need to filter where the default-route goes from the core switches back into the LAN.

If you view the network you are designing in a very simple way, ie. core routers are WAN and core/distro/access-layer switches + anything hanging off them are LAN are we not just talking about propogating a default-route into the LAN without it affecting the WAN ?

If you need to filter within your LAN then yes building the distribute-lists is going to get complicated.

Could you clarify. Also, Giuseppe seems to be suggesting that the default-route with AD 5 will not get propogated to EIGRP neighbors (apologies if i misunderstood Giuseppe). Is there a reason you are not keen on 4 ?

Jon

View solution in original post

14 Replies 14

Jon Marshall
Hall of Fame
Hall of Fame

Raj

Firstly i agree that it is better to avoid adding static routes unless you have to when primarily using a dynamic routing protocol. Also i really am not keen on adding individual statics on both the core and distribution switches which is messy. The only reason i can think to do this would be for security reasons but then why use EIGRP !

Secondly if you already have a default-route, which you do, then i would use that one rather than using an "ip summary-address eigrp" on an interface. There are a couple of issues with doing that

1) Cisco themselves recommend against using the "ip summary-address eigrp" command to inject a default route

2) This command creates a route to Null0 with an AD of 5 on the local router/switch to which it has been applied. This can create problems of it's own.

I designed a L3 routed campus network where the access-layer ran EIGRP stub and the distribution layer advertised only a default-route to access-layer. I found using a distribute-list to only allow the default-route worked perfectly in this scenario. Admittedly your setup is different but i think the same rules apply.

So my choice would be to use the existing default-route and have distribute lists that stop it being advertised back into your WAN.

Jon

Jon

thanks for the exhaustive answer..

did you redistribute static default route from distribution to access , and applied distribute list on the distribution not to propogate to the core ? how about default originate option ?

Raj

Raj

Apologies for the delay in getting back. I did type up a rather long post this morning and then

lost it because it timed out so i'm doing this in wordpad :-)

Firstly i did a bit more searching yesterday on Cisco web site. When i designed the L3 routed campus

the advice in the documentation from Cisco was not to use "ip summary-address eigrp" to advertise a

default-route. However yesterday i found a Q&A that said the opposite altho it did warn about the Null0

route with AD of 5 -

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012dac4.shtml#def

Secondly, one of the key differences between what i did and what you are trying to do (i suspect) is that

i had a default-route coming in from the WAN so it was simply a matter of "allowing" just that through to

the access-layer switches. Because of the advice about the "ip summary-address .." command and because

i already had a default-route using a distribute list seemed the most elegant way. There are obviously issues in

that if you lose the WAN you lose internal access between each floor because the floors are routed access but this

can be mitigated in a number of ways eg. we used floating statics.

However, correct me if i am wrong but i'm assuming that the default route on the core routers is not at the moment

being redistributed into your EIGRP process. I'm also assuming that your site has all routes from the remote WAN

locations on both the core and distro switches. Let me know if either of these are incorrect assumptions.

So you have a number of options

1) Add static default-route (sdfs) to each core and distro switch with no redistribution into EIGRP.

2) Add sdfs onto the core switches and redistribute into EIGRP but only allow to distro switches

3) Redistribute sdfs from core routers into EIGRP and only allow to core switches.

4) Use "ip summary-address eigrp.." under the core router interfaces that connect to the core switches.

1 - we both agree we are not keen

2 & 3 will work but in addition to redistribution you need to use distribute-lists/route-maps

4 - key thing here is that a route to Null0 with an AD of 5 is added to core router(s). Now that is only an issue if the default-route these core routers are already using have an AD > 5. But as above i'm assuming the default-route on these routers has been statically entered on these routers so the AD should be 1. If this is the case then you should not have an issue. If it isn't you are going to be blackholing traffic.

The advantage of 4 is that the "ip summary-address .." command automatically suppress any more specific routes so no need for a distribute-list/route-map. So personally i think the most elegant solution is 4 but it is making a number of assumptions that need checking.

Let me know what you think.

** Edit - Raj, one other thing that occured (or rather i remembered from lost post !). You may still need to filter to the WAN because as i say "ip summary-address eigrp" does install a route into the routing table. I don't know whether this gets sent to other EIGRP neighbors - this would need testing but unfortunately i don't have routers to hand - so it may not be as elegant as i thought ! **

Edit no 2 - there is a useful discussion on this in the Netpro forums -

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&topicID=.ee71a04&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cbfebf2/17#selected_message

Jon

Hello Jon,

very good considerations

>> Raj, one other thing that occured (or rather i remembered from lost post !). You may still need to filter to the WAN because as i say "ip summary-address eigrp" does install a route into the routing table. I don't know whether this gets sent to other EIGRP neighbors - this would need testing but unfortunately i don't have routers to hand - so it may not be as elegant as i thought

this shouldn't happen for the DV nature of EIGRP that is able to create a per interface list of routes to be sent out it.

I have checked on my own tests I did some years ago: it was a an EIGRP summary route and was sent out only from the interface where the command is placed.

see

mclaren#conf t

Enter configuration commands, one per line. End with CNTL/Z.

mclaren(config)#int fas0/0.147

mclaren(config-subif)#$address eigrp 2004 192.168.37.0 255.255.255.0

mclaren(config-subif)#^Z

mclaren#

D 192.168.37.0/24

[90/33280] via 192.168.47.3, 00:00:07, FastEthernet1/1.147

r3725#

on the wan side I don't see it arrives because redistributed into OSPF on another interface (it was a lab)

Williams#sh ip route 192.168.37.0

Routing entry for 192.168.37.0/24, 4 known subnets

Variably subnetted with 2 masks

Redistributing via eigrp 2004

D 192.168.37.8/30

[90/2174976] via 192.168.244.5, 00:01:39, Serial3/0.111

D 192.168.37.4/30

[90/2684416] via 192.168.244.5, 00:01:39, Serial3/0.111

O E2 192.168.37.0/24 [110/700] via 192.168.64.2, 00:00:09, Ethernet1/1

D 192.168.37.0/30

[90/21026560] via 192.168.244.5, 00:01:39, Serial3/0.111

the summary created on interface fas0/0.147 is not sent out the serial interface, we see the ospf route originated by its redistribution into OSPF

It wasn't a 0.0.0.0/0 so if this is not a special case it shouldn't go on the WAN side

Hope to help

Giuseppe

Jon...

Thanks for your reply... really good one.. I agree there are 4 options.. I'm somehow reluctant on options 1 & 4..

But with options 2 & 3, I see a major work constructing the "distribute lists" , with regards to the network here.. To make things complicated, there is a LAN extension from the COre switches to another office, which has close to 50 /24's... now if we consider point 2:

Add sdfs onto the core switches and redistribute into EIGRP but only allow to distro switches

There is a challenge doing the distribute list here.. Firstly I have a distribute list which disallows default route onto some 10 peers (p2p links) terminating on the core routers. There are 4 more p2p ethernet links connecting to distro switches.. Now, I need to define distro lists for these interfaces which allows 0.0.0.0 and all other networks !

distribute list 2 out GE0/1 (connecting to core switch 1)

distribute list 2 out GE0/2 (connecting to core switch 2)

distribute list 1 out static

access-list 1 permit x.x.x.x (all 50 static networks)

access-list 2 permit any (which will permit all network, along with 0.0.0.0)

The same needs to be done in Core router 2, with all these dist lists ?? Is that right ? Looks complicated building these dist lists :(

Raj

Raj

Could you just clarify. You say

"There is a challenge doing the distribute list here.. Firstly I have a distribute list which disallows default route onto some 10 peers (p2p links) terminating on the core routers. There are 4 more p2p ethernet links connecting to distro switches.. Now, I need to define distro lists for these interfaces which allows 0.0.0.0 and all other networks ! "

If these P2P links terminate on the core routers not the core switches then you can simply add a very straightforward distribute-list to the core switches for the interfaces connecting to the core routers just denying 0.0.0.0 and permit all else.

Where i am a little confused is why you need to use distribute-lists at all on the distro switches. All we are trying to do is stop the default-route from getting up to the core routers. Unless i have misunderstood and you need to filter where the default-route goes from the core switches back into the LAN.

If you view the network you are designing in a very simple way, ie. core routers are WAN and core/distro/access-layer switches + anything hanging off them are LAN are we not just talking about propogating a default-route into the LAN without it affecting the WAN ?

If you need to filter within your LAN then yes building the distribute-lists is going to get complicated.

Could you clarify. Also, Giuseppe seems to be suggesting that the default-route with AD 5 will not get propogated to EIGRP neighbors (apologies if i misunderstood Giuseppe). Is there a reason you are not keen on 4 ?

Jon

Jon...

If you see my diagram, there are WAN P2P T1 links terminating on the core router which run EIGRP.. There are also Ethernet P2P links between the core and distribution (dual linked).. I was talking not to send the default route onto the WAN, and only to the Core switches through Ethernet links.. Hence on the core router I need to add the distribute list as given in my previous post.. Are the configs fine ?

What I want is:

1) On the core routers I need EIGRP WAN routes, and the routes originating from the LAN, through Distro & Core switches..

2) Want to avoid sending back 0.0.0.0 to WAN (through the 10 P2P T1 links as told before)

3) I want to send 0.0.0.0 to the core routers, and from there, to distro switches..

4) I also want to send all the WAN routes, POP static routes, etc inside the LAN (from the core switch)... Are the distribute lists given in the previous post ok ?

U are right.. i dont need distribute lists on the distro switches nor the core switch, if we choose point 2 of the solution given before..

Raj

Raj

The default-route that is on the core router(s). Is this currently not redistributed into EIGRP ie. it is purely local to the core routers ?

Jon

Right Jon.. Right now, there is only one distribute list which blocks 0.0.0.0 advertisement in "out" direction ! No specific dist lists on interfaces !!

Raj

If the sdf's are not being redistributed into EIGRP then why do you need a distribute list at all ?

Sorry to keep harping on about this but it has a big impact on what solution is the best.

Jon

Jon..

the basic need here is to get these default routes from the core routers to Inside network.. now since there is a distribute list OUT on the core routers, to stop advertising the def route to WAN, it also stops advertising to the internal LAN switches .. that is why I wanted to change the distribute list OUT on the core router and allow 0.0.0.0 only to the LAN segment & not to the WAN !! we are also doing a "redistribute static" on eigrp process and apply distribute list over it , as shown in the diagram..

Raj

Raj

"we are also doing a "redistribute static" on eigrp process and apply distribute list over it , as shown in the diagram."

My sincere apologies. I was so focussed on the LAN side i missed that your diagram had this on. My fault entirely, it'e been a long day !

The short answer is yes your distribute lists look fine to me. Yes they will need to be applied to both core routers but only to the core routers. The core switches and distribution switches are fine as they are as long as there are no "backdoors" floating around ie. what i mean by that is a site connecting to your distro switches mustn't have a secondaryconnection or another way onto the WAN.

One point though -

One last point

distribute list 1 out static

access-list 1 permit x.x.x.x (all 50 static networks)

If i understand you want to stop the default-route from being sent out. Why not just

distribute list 1 out static

access-list 1 deny 0.0.0.0

The added benefit of doing it this way is all the config i self-contained on the core routers and it is one standard way of doing things ie. filtering with distribute-lists for the WAN and LAN.

Once again apologies for being a bit slow :-)

Jon

Slow ???? Come on Jon.. You are lightning fast in ur replies... and crystal clear .. thanks a ton for all ur replies.. all my queries answered.. u deserve another 5 pointer ;) 14 from my end... :D

access-list 1 deny 0.0.0.0 makes more sense.. i have already told the client , but they are fine with the OLD model of working :( will anyway take that into consideration

Closing this case.. thanks again

Raj

Raj

Many thanks for the compliment and ratings.

"i have already told the client , but they are fine with the OLD model of working :("

Typical :-)

Jon

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: