4

I have set up BGP on two routers using qugga. When I down the interface that holds the IP block that I am advertising zerba removes the route from its table but bgpd keeps advertising it. I can see that it is still advertised via the neighboring BGP tables as well as the show ip bgp nei 172.16.14.1 ad command from the router that is doing the advertising. This interface holds the full route that is being advertised so there is no aggregation.

As anyone run into this before ... it seems to fundamentally break the main functionality of a routing protocol...

Update:
So in the router I have the following for a BGP table.

so-rt1# show ip bgp
BGP table version is 0, local router ID is 172.16.14.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          12.12.12.12                   200      0 5555 i
*  15.15.15.0/24    172.16.14.2              0    100      0 i
*>                  0.0.0.0                  0         32768 i

Total number of prefixes 2

For the 15.15.15.0/24 network, which I announce, the directly connect route (the last entry) is the route that is preferred. If I shutdown the interface that holds 15.15.15.0/24 not only is the directly connected route not removed from the BGP table, it is still the preferred route. So after shutting down that interface, the BGP table stays exactly the same.

Zebra is aware that the directly connected 15.15.15.0/24 route is no longer there. I see it with show ip route while the interface is up and the entry is gone when I shut it down. So the problem I think is that the BGP table is somehow not getting the updates I believe it should from zebra.

Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444

1 Answers1

2

If I understand the question correctly you have an IGP (or local) route to the network, and you annouce it over BGP. When the route vanishes in the IGP (or local) you want BGP to pull the route.

If that is the case you are doing stuff wrong(TM), and Quagga will not let you easily do this. From the manual for the network command:

BGP: network A.B.C.D/M

    This command adds the announcement network.             

    router bgp 1
     network 10.0.0.0/8

    This configuration example says that network 10.0.0.0/8 will be announced 
    to all neighbors. Some vendors' routers don't advertise routes if they 
    aren't present in their IGP routing tables; bgp doesn't care about IGP 
    routes when announcing its routes. 

This is due to the increased flapping you can easily get if you export IGP information in BGP. We have enough of a route churn on the internet allready, and it's considered bad practice to redistribute routing information from IGP into BGP. BGP is not an IGP, and don't abuse it as one ;)

Also I can't really see any good cases for pulling the route from the Internet (it will cause flapping and you risk getting dampened for hours or days), unless you are ending up in a split-AS situation if this specific route is gone and want to protect yourself from the weird routing issues this can cause. (In this case, you should consider if you want the router to stay online at all. Split-AS situations are nasty!)

The correct solution(TM) is to leave the route up and as stable as possible, regardless of what your IGP is doing. If you lose the connection to the network just drop the traffic locally. Make sure you don't loop it back to your transit provider if the IGP route to the network is down.

The basic rule is "never change your BGP announcements unless it's something the whole Internet has to know about". That your IGP is flapping is not something the rest of the Internet cares about.

Edit:

From what I understand your network looks like this:

Provider (AS 5555) --------------------- Provider (AS 5555)
 (12.12.12.12)                                   |
     | eBGP                                      |eBGP
     |                                           |
  Router1---------15.15.15.0/24---------------Router2
172.16.14.1                                 172.16.14.2
     |                  iBGP                     |
      --------------------------------------------

And your problem is that if you take down the interface on Router1 towards 15.15.15.0/24 you want it to stop announcing the network so you shift the data over to 172.16.14.2. This type of automatic changes to your peering policy is not something you usually do, and is as far as I know not something supported by Quagga. Instead you are expected to reroute the data over the IGP and keep your peerings static. If you were to do changes to your peerings you would change the MED (MULTI_EXIT_DISC) to steer the traffic to the right router.

Note that if taking down 15.15.15.0/24 splits your AS you have additional failure modes, none of them good.

pehrs
  • 8,749
  • 29
  • 46
  • This is not the redistribution of an IGP route (iBGP in this case). Rather is is the announcement of a directly connected route. So I have two routers with the route directly connect to each of them. When it looses the route in its actually routing table I do want it to pull the route so the other router can pull it. As far as the flapping I don't care that much because this is just a private peering with my ISP... – Kyle Brandt Jul 21 '10 at 16:35
  • Please, draw a map of your network and post it so I can see what it looks like. It sounds like you are trying to solve problem with a network split. – pehrs Jul 21 '10 at 16:49
  • It is very similar to http://www.kbrandt.com/wp-content/uploads/2010/02/BGP-HSRP-LAB-Smaller.jpg . The main changes being the 172.16.14.0/30 forms the iBGP peering in the client side and the 192.168.1.0/24 network is actually a public IP block that is a /24 block .. so no NAT. – Kyle Brandt Jul 21 '10 at 17:07
  • Also updated my question trying to explain the issue a little more clearly. – Kyle Brandt Jul 21 '10 at 17:16
  • Added some more comments. Note that static/directly connected routes are a form of IGP in this case. Many routers treat them as such when it comes to the relationship to BGP... – pehrs Jul 21 '10 at 20:56
  • The un-documented `bgp network import-check` seems to do what I am looking for in specific. I will play with it and also meditate on your additional comments -- thanks! – Kyle Brandt Jul 21 '10 at 21:22