BGP default route
This article has been updated on August 10th 2008
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/0I'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.
ip address 10.0.1.1 255.255.255.252
!
interface Serial1/1
ip address 10.0.1.5 255.255.255.252
!
router bgp 65100
neighbor 10.0.1.2 remote-as 65001
neighbor 10.0.1.6 remote-as 65002
!
ip route 0.0.0.0 0.0.0.0 10.0.1.2
ip route 0.0.0.0 0.0.0.0 10.0.1.6 250
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.
router bgp 65002Now 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.
neighbor 10.0.1.5 remote-as 65100
neighbor 10.0.1.5 default-originate
neighbor 10.0.1.5 filter-list 1 out
!
ip as-path access-list 1 deny .*
This article is part of You've asked for it series.
Posts
15 comments:
Depending on just how much memory the router has, this is also a very good solution: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a83.shtml
The solution on CCO is great to ensure more optimal routing, but it looks like they forgot about the default routing of everything else.
"ip default-network" would perhaps be a simpler solution.
@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.
Instead of typing the destination ip in the route specify the interface as done below.
ip route 0.0.0.0 0.0.0.0 serial1/0
ip route 0.0.0.0 0.0.0.0 serial1/1 250
This will ensure that if the interface goes down it will be removed from the routing table, thus no black hole
@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).
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. ??
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?
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.
#1 is true but #2 what if that customer also offers transit for his customers :)
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.
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.
No idea, it was probably fixed quite a while ago.
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.
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:
http://www.nil.si/ipcorner/DesigningBGPNetworks/
This blog is using JS-Kit comments. You have to enable JavaScript if you want to post a comment.