cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1064
Views
0
Helpful
8
Replies

BGP not installing best route in IP table

CriscoSystems
Level 5
Level 5

I asked this in the Certifications forum but it quieted the room:

Sethtek-G and Sethtek-H are set up as BGP neighbors in AS 190. PPP serial link between the two, with G's serial IP 172.16.0.1; H's ends in .2.

Each has three loopback interfaces configured: G has 207.207.1.0; 207.207.2.0; 207.207.3.0. H has the same but with 208's in 207's places.

I declared the first two in each's BGP process (saving the third for later debugging experiments).

So each of the declared loopback networks shows up just fine in each other's BGP tables, but not in their IP routing tables. Did I read wrong when I read that the optimal BGP path gets installed in the IP routing table? Not talking about redistributing into other routing protocols, just appearing as BGP routes in the IP table. Why is that not happening?

From debug ip bgp udates on Sethtek-H; every 60 secs I get this:

02:43:42: BGP(0): no valid path for 207.207.1.0/24

G is doing the same, for the 208.208. network. If it thinks there's no valid path why is it allowing it in the BGP table?

I also wonder about the weight assigned to the received routes. This here Cisco website says that "Any path that a Cisco router originates will have a default weight of 32768; other paths have weight 0." Meaning that only local bgp routes have the 32768 weight, and received routes will be 0, even if those routes originated on a Cisco, if remote, router?

I can't quite shake my suspicion that Weight 0 is why these routes aren't being installed in the ip table.

Output from Sethtek-H's sh ip bgp command looks like this:

===============

Sethtek-H#sh ip bgp

BGP table version is 3, local router ID is 208.208.3.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* i207.207.1.0 172.16.0.1 0 100 0 i

* i207.207.2.0 172.16.0.1 0 100 0 i

*> 208.208.1.0 0.0.0.0 0 32768 i

*> 208.208.2.0 0.0.0.0 0 32768 i

Sethtek-H#

===============

Nothing's really different on G's output, just the values switched where you'd expect.

Any insights anyone could offer would be greatly appreciated.

8 Replies 8

satish_zanjurne
Level 4
Level 4

'Can you attach config of both the routers ???

The problem you are experiencing is caused by a BGP feature called Synchonization, which basically states that a route learn from IBGP will not be considered a best path unless it is local or also learned from another internal routing protocol (eg. OSPF, EIGRP, IS-IS, etc). This is to prevent black holes when not all internal routers are running IBGP (because IBGP neighbors do not have to be directly connected). If however all routers are running IBGP, you can turn it off with this BGP command:

(config-router)#no synchronization

*edit* Sorry, replied to the wrong person.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Seth,

you are running iBGP in AS 190

to have these installed you need to disable synchronization: iBGP is waiting of an IGP to converge on the prefixes

do

router bgp 190

no sync

Hope to help

Giuseppe

Sethtek-H#sh ip bgp

BGP table version is 3, local router ID is 208.208.3.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* i207.207.1.0 172.16.0.1 0 100 0 i

* i207.207.2.0 172.16.0.1 0 100 0 i

freelancer42
Level 1
Level 1

The problem you are experiencing is caused by a BGP feature called Synchonization, which basically states that a route learn from IBGP will not be considered a best path unless it is local or also learned from another internal routing protocol (eg. OSPF, EIGRP, IS-IS, etc). This is to prevent black holes when not all internal routers are running IBGP (because IBGP neighbors do not have to be directly connected). If however all routers are running IBGP, you can turn it off with this BGP command:

(config-router)#no synchronization

I suspected a synchronization problem earlier, but the question I asked myself then was, why would they wait for an IGP to have these routes when they are directly connected (loopback) networks?

Technically the BGP process isn't aware of the fact that they are directly connected, since IBGP neighbors can be several hops away (unlike any other routing protocol). So to have it work, you have to turn of synchronization (just make sure all routers are running IBGP).

Yeah, I get it now - the local routers were advertising the loopbacks because they already had a route (duh, they were loopbacks); it's the remote router that doesn't know how its neighbor knows about the route.

Here's what's confusing: I disabled synchronization on Sethtek-G and of course the BGP routes to H's loopbacks appeared in the IP table. I HAVE NOT YET disabled synchronization on H, which is why it surprised me that I was able to ping successfully to Sethtek-H. Sethtek-H still doesn't have IP routes to G, so why and how did those ping replies get properly routed?

An attempt to ping G's loopbacks from H was, as expected, unsuccessful.

Well, pings from Sethtek-G to the loopback interface on Sethtek-H will originate from 172.16.0.1, and since that's the directly connected network between the routers, Sethtek-H will surely have a route back ;)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card