Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

reserve a seat
back to overview

BGP default route

Update 2011-12-07: You might also want to read the Responsible generation of BGP default route article describing the ISP side of the solution.
Update 2008-08-10: IOS behavior has changed; fixed the article.

Martin Kluge sent me an interesting BGP question: he has two upstream links and runs BGP on both. Since his router is low on RAM, he cannot accept full routing, so he's just announcing his IP prefix and using static default routing toward upstream ISPs.

The relevant configuration on the GW router is somewhat similar to the configuration I've used as a staring point in my lab:

interface Serial1/0
 ip address
interface Serial1/1
 ip address
router bgp 65100
 neighbor remote-as 65001
 neighbor remote-as 65002
ip route
ip route 250

I'm sure the long-time readers of my blog immediately figured out where the catch is: if the upstream router dies, but the interface stays up, the outbound traffic is blackholed. Reliable static routing might be a solution, but his router is running an old IOS version. Obviously it's time for yet another rarely known BGP feature: the BGP default route.

More information about the BGP default route information is available in the CT3 wiki.

If you've mastered default routes in other routing protocols, forget about what you know … BGP is different:

  • The default route is not announced to BGP neighbors, even if it's in the IP routing table and BGP table. This was true in old IOS releases, 12.4 and 12.2SRC announce BGP default route like any other network.
  • To announce a default route to a BGP neighbor, you can configure neighbor default-originate.
  • Once you've configured default route advertising with the neighbor default-originate, it's announced to the neighbor even if the router doesn't have the default route itself.
  • The default route advertised to a BGP neighbor with the neighbor default-originate does not pass through BGP output filters, so you cannot filter it.

To solve Martin's problem, you'd have to reconfigure BGP on E1 and E2 as follows (the ip as-path access list just ensures nothing else is sent to the customer router; obviously you could use a route-map instead):

router bgp 65002
 neighbor remote-as 65100
 neighbor default-originate
 neighbor filter-list 1 out
ip as-path access-list 1 deny .*

Now that the default route is advertised via BGP, there is no need for a static default, and the default route will be removed (and replaced with the backup one) if the BGP neighbor disappears.


  1. Depending on just how much memory the router has, this is also a very good solution:

  2. The solution on CCO is great to ensure more optimal routing, but it looks like they forgot about the default routing of everything else.

  3. "ip default-network" would perhaps be a simpler solution.

  4. @anonymous(2): You need another network in the IP routing table for the ip default-network to work. So you have to receive at least a few routes via BGP (to have them pointed toward the ISPs) and then you can use the default-network on a few of them.

  5. Instead of typing the destination ip in the route specify the interface as done below.

    ip route serial1/0
    ip route serial1/1 250

    This will ensure that if the interface goes down it will be removed from the routing table, thus no black hole

  6. @anonymous(3): If only life would be so simple ... if you lose the interface, you lose the next-hop as well, so both solutions work. The problem is if you lose the BGP peer, but not the physical interface (as I've written in the post).

  7. I know someone in similar situation. However they use a route server which gives them bgp routes with "next hops" that could change so the hard coding of upstream neighbors may change without notice. They are not given any default routes. Is there some way to do the same thing if there are potentially varying peers on the WAN ethernet side. ??

  8. I had a question similar to this, but it involved 2 routers that were multi-homed to both ISP's in a full-mesh. I know this is probably a bit overkill, but I was trying to setup the most fault-redundant configuration possible that would survive both a router problem, as well as a service problem. In this setup, ISP1 is successfully sending a default-route to R1, but I'm noticing that R1 is redistributing that static route back into BGP and sending it to ISP2, which now has a default static route pointing to R1. I know I could filter this out, but my question is would there be a better way of doing this?

  9. I hope your observation is from a test lab. There are two serious mistakes in your setup:

    #1 - As a multihomed customer DO NOT EVER propagate transit routes between upstream ISPs.
    #2 - As an ISP, DO NOT EVER accept routes not originating in the customer's AS from the customer.

  10. #1 is true but #2 what if that customer also offers transit for his customers :)

  11. Then he's not a regular customer, but an ISP buying transit (or a reseller of your services or whatever) and you should treat him differently. At least I hoped that would be somewhat obvious.

  12. Olivier Cahagne19 April, 2010 09:52

    Ivan, when you say "12.2SRC announce BGP default route like any other network", do you know which DDTS track this ? I've tested behaviour with 7600/SRA, SRD3, SXF17a and behaviour is the same: BGP default route is announced.

  13. Ivan Pepelnjak19 April, 2010 10:13

    No idea, it was probably fixed quite a while ago.

  14. Mark Paquette13 July, 2010 18:44

    Interesting point - in this scenario, it would pay to BGP peer to the internet-facing interface (so, ebgp-multihop 3 or somecrap) ... so if the internet-facing interface goes down, so does the eBGP peer.

  15. Ivan Pepelnjak13 July, 2010 18:47

    If you have direct EBGP connection and the interface goes down, the EBGP session is immediately reset due to fast failover (by default; adjustable). My IP Corner article on BGP convergence has more details:

  16. Good article! Thanks! But I have a question: customer receive two default routes from ISP1 ans ISP2, How can I (customer) create less priority for default route from ISP2?

  17. Ivan Pepelnjak21 August, 2011 06:56

    Using BGP weights or local preference. This video might help:

  18. Hi Ivan,

    Suppose ISP 1 lose connectivity to upstream provider,using default originate command SP1 will continue to advertise default route to customer, and if customer prefers ISP1, it will lose connectivity to internet even if customer has less preffered default route from ISP2. Am I right?

  19. The ISPs should use "responsible default route generation":

  20. Excellent article, thanks, cleared up a few doubts!

  21. Hello Ivan,

    I have the same issue like discussed above. My core router see the internet over 2 ISPs but when I removed the default route I lost the connection to a lot of websites. A part of the internet is reachable. From router I can ping everything but not from networks behind it. Do you have any idea?


    1. The usual root cause of "I can ping from the router, but not from the hosts" problem is that the subnet the hosts reside in is not visible from the rest of the network.

      In your case, that would mean you're not advertising your IPv4 prefix to the rest of the Internet. Does this make sense?

  22. I am advertising all my prefix and can see them from more a one looking glas. now everything running good but when I remove the default gateway I got the issue. When I add the default gateway back the issue remains until I reboot the router :(

  23. What about use SLA for those two default routes Ivan?


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.