BGp Default Route injection

post you router bgp section of the config.

There is no BGP next hop reachability, how many BGP speaking routers do you have? Can you see the default route on the edge router?

harbor235 ;}

I have a single 6500 edge router that is peering with 2 isp's. O am getting full bgp routes from both providers. The ISP  must be doing default information originate since I can see the default route in the BGP RIB.

However, I dont see anything in my local ip routing table for the default route. I am not running an IGP as I am stuck with default routing on my end. However, since I Want to get rid of that I should be able to remove the static default routes in the ip RIB and then see the BGP default routes from the ISP injected.. (at least I would think so)  So I am wondering why the bgp default routes dont appear in the ip routing table after removing the static default routes.

The default routes that the ISP gives me are the same as the default routes that I have already been using statically so they are valid

what is the next hop for the default route , do you have a route to it?

sh ip bgp 0.0.0.0/0 , can you post the output of this command?

harbor235 ;]

BGP routing table entry for 0.0.0.0/0, version 14381307
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Multipath: eBGP
  Not advertised to any peer
  3549, (received & used)
    204.88.184.181 from 204.88.184.181 (61.106.7.212)
      Origin IGP, metric 0, localpref 100, valid, external, multipath, best
  3356, (received & used)
    4.25.28.81 from 4.25.28.81 (4.25.180.161)
      Origin IGP, localpref 100, valid, external, multipath
      Community: 219938819 219939391 219940858

Do you have a default route injected by your IGP as well? Any filtering going on between
you and this peer?


harbor235 ;}

well the I was using static default routes back to the ISP.. However, if I remove the static routes , these should be injected to the ip rib. No filtering at this point..... I don't believe there is anything required to allow a default route advertised by your ISP into the local ip routing table correct?

Do you peer with your provider over  204.88.184.181? Do you have a route to
 204.88.184.181?  

post the output off "show ip route  204.88.184.181"

harbor235 ;}

yes I do and its a directly connected route . Meaning its the other end of the /30 that we have for peering with both ISP's

is the issue that since this is directly connected it will always see that route as best and since the default route is learned via ebgp, it will not install this? That would seem logical......

raising the admin distance of the static will do no good. The problem is that the default router injected by the ISP is actually a directly attached interface that I am peering with.

A directly attached router will always be preferred over any other method of learning a default route regardless of it being static or injected via EBGP.

It is not the bgp default route that is directly attached, it is the next hop.

The route will still be selected based on admin distance.

Let me make sure I am not missing something here... If I have a default route coming from the ISP and I can see it in sh ip bgp 0.0.0.0...... Should I not also be able to see the same route in the IP RIB by doing
sh ip route 0.0.0.0?

In general yes, if the next hop is available, and there is no other default route taking precedence.

Are you sure it is not there - a bit above the other routes?
Are the other routes you are receiving via BGP visible in the IP routing table?

yes I can see all the other routes in the IP RIB that are from BGP. However, even when I remove the static default route, I dont see the bgp default getting injected to the ip RIB.

sh ip route 0.0.0.0 has no return. This is why I assumed that since the default route next hop already exists in the IP RIB as connected, it will never be injected as a default route from EBGP and will always prefer the connected route due to admin distance of 0.

I am going to have to put this same scenario up in a LAB and see if I can prove this out.

I reproduced this in the lab and it worked correctly as you stated . The problem was that in production as I was testing someone else was playing with static default routes and kept screwing up the results.


Thanks