BGP learned route via IGP learned route

Unanswered Question
Jul 25th, 2008
User Badges:

I'm working on a backup solution that uses a vpn tunnel as a backup connection for my site (Philadelphia) and other WAN sites should another location (New York) lose its connection to the WAN. The WAN uses BGP, I have a private AS that peers up with ATT's AS, and the same things happens for remote locations. They all peer up with an eBGP neighbor. My backup uses a floating static route that leads to a vpn tunnel that connects to the remote site. In BGP, I'm using as-path prepending to notifiy other WAN sites of an alternative route to networks located in New York. So, I need to have a route, and reachability to New York's networks before I can advertise them via BGP. I put a floating static route into my WAN router that points toward the tunnel for those networks. I simulate an outage on the WAN link for New York, and remote sites start seeing the longer AS alternative path via my WAN router and it works fine. The problem is in the failback to the primary when I bring back New York's WAN connection. My WAN router sees a better path via the tunnel now, I think it's the route origin step. This better path is not only reflected in the show ip bgp output, but also in the sh ip route output. Why does my router see a floating static route with an admin distance of 200 as being better than an eBGP learned route with an admin distance of 20? Any ideas on how I can automatically lose that floating static route when New York's primary WAN connection comes back online?

thank you,


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
AJAZ NAWAZ Fri, 07/25/2008 - 08:07
User Badges:
  • Silver, 250 points or more

Are you redistributing your static route into bgp?

I think you've answered your own question. I believe this is to do with origin. Your router has two tables. The routing table and the bgp table. Routing tables consider longest match, admin distance, and metric - in that order. However, bgp table does not consider admin distance at all. If my memory serves me correctly - it's step five in the bgp best patch selection process, that is what I urge you to pay special attention to.



sdoremus33 Fri, 07/25/2008 - 13:27
User Badges:
  • Bronze, 100 points or more

do a show ip bgp for this route what is the origin code and the metric for the route

also in the floating static route change to a value of 210 that way we get abetter idea as mentioned befor the prder in which a route is preocessed is specificity (longets match), then origin I believe.

If the route is still being preferred over the backup we now know it is a problem in the routing table not the BGP RIB.HTH

sdoremus33 Fri, 07/25/2008 - 16:10
User Badges:
  • Bronze, 100 points or more

Could you post the following

show ip route x.x.x.x

show ip bgp x.x.x.x

where x.x.x.x is the particulatr route in question. Thanks

WILLIAM STEGMAN Mon, 07/28/2008 - 04:56
User Badges:

here's what it looks like after bringin back the primary connection after a simulated outage where the backup kicked in.

HBGWAN-T3#sh ip bgp

BGP routing table entry for, version 104

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Advertised to update-groups:


13979 65001 from (

Origin IGP, localpref 100, valid, external

Local from (

Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

HBGWAN-T3#sh ip route

Routing entry for

Known via "static", distance 245, metric 0

Advertised by bgp 65000

Routing Descriptor Blocks:


Route metric is 0, traffic share count is 1

here's what it looks like when only the backup link is active

BGP routing table entry for, version 115

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Not advertised to any peer

Local from (

Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

lamav Fri, 07/25/2008 - 15:25
User Badges:
  • Blue, 1500 points or more


Can you post the relevant configurations and a small diagram?




This Discussion