Advertising a Default Route Into EIGRP

Let’s get an IPv4 default route into EIGRP.  There are a few methods to do it.  I hate most of them, though.  I think it will be obvious which one I like.

Here’s the lab I have set up to test everything.  I want R4 to generate the default in each case.


Default Network – Candidate default.  I don’t think I’ve ever used that all my years in networking, but here’s how to use it in EIGRP for a default route.  You basically say “If you don’t know where to send a packet, send it to where network X lives.”  We’re going to set the as the default network, so, in our case X = R4 will tag that route as a default candidate when it advertises it to the rest of the network.  The config is easy but requires a classful (yes, classful) network to be configured as the default.

So, where’s the route?  See that asterisk?  That’s all you get.  But it works.

The trace is not very clean thanks to having multiple routes to in the routing table.  There’s one through R2 and another through R3.

Yes, I’m a terribly negative person, so let’s blast this method.  Where do you actually see the default route?  Where do you even see the gateway of last resort?  Dave’s not here, man.  Let’s hope your tier 1 support guys know what that asterisk means.

Summary – The default route is the biggest summary route you’ll ever see, so why not have a route generate a summary address of  That will work.  Summaries are configured on the interface, so the default will only be advertised out of that particular interface.

That works, but I don’t think this is the best method.  The configuration, as-is, isn’t highly-available.  If you lose the F0/0 interface on R4, then you don’t have a default route any more.  The same if R2 catches on fire.  The fix for that, obviously, is to configure the same on F0/1 towards R3.  I absolutely abhor having to configure the same thing in two places.  I would never remember to change both if I had to make a config change.  I’ll pass on this method.

Network – Yeah.  This one hurts.  You set a default route on R4 and then add network to EIGRP.  That part is fine.

Notice that the default route is an interface?  Yeah, that part sucks.  You have to use an interface instead of an IP address.  Welcome to a world without multiaccess networks.

Redistributing Static – This isn’t very fancy, but it works.  You just redistribute your static routes, and a default route shows up on the network.  This is assuming, of course, that we have a static default on R4, right?

This works fine in my book.  It advertises the default out of interfaces like any other route, so it shows up on multiple paths.  It also is very obvious which is the default network.  I would, however, probably put a route map on the redistribution.  That way you can treat your default route differently than the rest of your statics.  That’s up to you, though.

How about redistributing a default route from BGP instead of a static?  Sure.  From OSPF?  Sure.  Why not?

One thing to note is how the default routes appear in each method.  Using the default network method doesn’t actually show a route.  The network and summary methods show up as native EIGRP routes, and the redistribute method, as expected, shows up as external.  This may be important when meeting certain design goals….or taking an exam.

Send any questions marks questions my way.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:

7 comments for “Advertising a Default Route Into EIGRP

  1. @ecologu
    July 6, 2014 at 10:25 am

    ip default-network doesn’t work on newer IOS, like 15.0. The command is still there but it does not produce any effect on R1 routing table. My opinion is that Cisco is silently dropping the support for this command, which is a “left-over” from IGRP.

  2. July 9, 2014 at 6:53 pm

    Good to know, @ecologu. That command should be deprecated for sure. It’s older than the hills and actually needs a classful network. Ick.

  3. Guile
    November 3, 2014 at 9:21 pm

    Nice post, really helped me to understand default routing generation on EIGRP. So, using the redistribute static method seems fine, but can cause redistribution of undesirable statics. To avoid this, is there any other method than route map on the redistribution ?

    Other routing protocols seems to solve that with default-information originate x redistribute static. Making a static default not just a static like all others.

  4. Tom Brunette
    December 26, 2014 at 10:50 pm

    I’m a bit confused by the following statement from your article:

    “Using the default network method doesn’t actually show a route.”

    Any clarification would be greatly appreciated.

  5. Angelos Vassiliou
    February 25, 2015 at 3:27 pm

    When you say ” stateful (yes, stateful) network to beconfigured”, do you mean ” classful (yes, classful) network to be configured” ?
    Same for your reply, “needs a stateful network”, do you mean “needs a classful network” ?

    Great Post. This is actually the first post/document that actually explains the IOS 15.4 behaviour.
    It is beyond me why they would not document this change in behavior more.
    It is clearly stated in that “If the router has a directly connected interface to the specified network, the dynamic routing protocols running on that router will generate (or source) a default route.”
    Which from all _my_ tests on 15.4 IOU is NOT true at all. I cannot get EIGRP to flag a route as a candidate default for the life of me.

  6. April 22, 2015 at 8:18 pm

    Months late: You are, of course, correct about my terrible choice of words, Angelos. Those have been corrected.

    Just a thought on the candidate default problem : Did you make sure the default-network and route match?

  7. dave
    June 27, 2016 at 12:17 pm

    while configuring using default routing do u have to use static route for other non stub routers or can u use any other routing protocol like eigrp and d rest

Leave a Reply

Your email address will not be published. Required fields are marked *