iBGP - Not Syncronised

kfarrington · ‎05-24-2005

Hello, all,

I have two routers that connect to AS200 and receive the same prefixes from both eBGP peers. Also have an iBGP peer between them.

When the prefix is received on the iBGP peer, it shows as "not syncronized" and Im sure

I have posted this before, but not sure if there was a reply.

Syncronisation is on.

The route is in the IGP as it shows "Advertised by eigrp 11" under the show ip route on router 1 and router2.

The Next-hop for the IBGP learned route is in the IGP.

BUT.....

The next hop for the IBGP leanred prefix IS NOT in the BGP table. .

Does a route learned from iBGP have to have the next hop accessible from the IGP -AND- have an entry in the BGP table?

Please if someone could clear this point up for me, it would be great.

Kindest regards,

Ken

-------------

router2#sh ip bgp 129.9.0.0

BGP routing table entry for 129.9.0.0/16, version 8690

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

Advertised to non peer-group peers:

155.195.32.65 155.195.61.1 155.195.68.1

200

199.100.42.254 (metric 30720) from 155.195.32.65 (155.195.32.65)

Origin incomplete, localpref 100, valid, internal, not synchronized

200, (received & used)

199.100.41.254 from 199.100.41.254 (30.130.255.3)

Origin incomplete, localpref 100, valid, external, best

router2#

-------------------

router1>sh ip bgp 129.9.0.0

BGP routing table entry for 129.9.0.0/16, version 9968

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

Advertised to non peer-group peers:

155.195.36.129 155.195.61.1 155.195.68.1

200, (received & used)

199.100.42.254 from 199.100.42.254 (31.11.143.2)

Origin incomplete, localpref 100, valid, external, best

200

199.100.41.254 (metric 30720) from 155.195.36.129 (155.195.36.129)

Origin incomplete, localpref 100, valid, internal, not synchronized

router1>

router1>sh ip route 199.100.41.254

Routing entry for 199.100.41.0/24

Known via "eigrp 69", distance 170, metric 30720, type external

Redistributing via eigrp 69

Last update from 155.195.45.77 on FastEthernet5/0, 1w6d ago

Routing Descriptor Blocks:

* 155.195.44.77, from 155.195.44.77, 1w6d ago, via FastEthernet0/0

Route metric is 30720, traffic share count is 1

155.195.45.77, from 155.195.45.77, 1w6d ago, via FastEthernet5/0

Route metric is 30720, traffic share count is 1

router1>

router1>sh ip bgp 199.100.41.0 255.255.255.0

% Network not in table

router1>

--------------------------------

actual route for prefix from bgp

router1>sh ip route 129.9.0.0

Routing entry for 129.9.0.0/16

Known via "bgp 500", distance 20, metric 0

Tag 200, type external

Redistributing via eigrp 11

Advertised by eigrp 11

Last update from 199.100.42.254 2w6d ago

Routing Descriptor Blocks:

* 199.100.42.254, from 199.100.42.254, 2w6d ago

Route metric is 0, traffic share count is 1

AS Hops 1

router1>

router1>sh ip eigrp top 129.9.0.0

IP-EIGRP topology entry for 129.9.0.0/16

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2585600

Routing Descriptor Blocks:

0.0.0.0, from Redistributed, Send flag is 0x0

Composite metric is (2585600/0), Route is External

155.195.45.77 (FastEthernet5/0), from 155.195.45.77, Send flag is 0x0

Composite metric is (2588160/2585600), Route is External

155.195.44.77 (FastEthernet0/0), from 155.195.44.77, Send flag is 0x0

Composite metric is (2588160/2585600), Route is External

router1>

Rui Carlos Antunes · ‎05-24-2005

The next-hop of the IBGP route must be the same as the next-hop for the IGP route! Synchronization requires that an IGP route, with the same network prefix and the same next-hop, be in the IP routing table.

As you can see, in your case the IGP and BGP next-hops do not match:

BGP routes point to 199.100.4x.254

IGP routes point to 155.195.4x.77

Note: If you have no intermediate router between the IBGP peers, then you do not need synchronization - disable it with "no synchronization".

Hope that helps...

kfarrington · ‎05-25-2005

Many thx for that. I am a little confused, so if you could possibly help me one more time?

Two things if you dont mind.

1. Where does it say that the next-hop of the iBGP route has to be the same as the next-hop of the IGP route? I just thought that for synchronisation to work, you just need a route in the IGP table?

2. In a situation where you have two peers externally peering to the same AS and they have an IBGP peer in between, as they will both learn the same prefix (say 10.0.0.0) as an external on the routers, and no other BGP attributes are modified so that they both select the external prefix, syncronisation would never work in this type of design, would that be a correct assumtion, as where we redistribute the received eBGP prefixes into the IGP, in the bgp table there are two possible entries for the 10.0.0.0, one via the external, one via the internal, and there would only ever be an external route in the local routers routing table, with a next hop of the external peer so the iBGP route would never syncronise?

With that, I assume the rule is only use BGP synchronisation if you are a transit AS?

Any help with this design question would be fantasic.

-To recap-

If you are not a transit AS, and you just have two peers peering to another AS, and synchronsation is on, the iBGP route would never synchronise as on both routers the eBGP prefix s selected and entered into the IP routing table with a next-hop of the external peer. Therefore, the routing table for prefix 10 will say 10.0.0.0 via 1.1.1.1 (ebgp peer) and the iBGP entry will say 10.0.0.0 via the iBGP peer which IS reachable through the IGP, but the routing tables next-hop is not the same BGP tables next hop for the iBGP entry.

I hope that makes sense.

It just a legacy setup we have and I WILL turn syncronisation off as it is not required.

Kindest regards,

Ken

EXAMPLE BELOW

router1>sh ip route 10.0.0.0 255.0.0.0

Routing entry for 10.0.0.0/8

Known via "bgp 500", distance 20, metric 470016

Tag 600, type external

Redistributing via eigrp 11

Advertised by eigrp 11

Last update from 155.195.1.2 3d02h ago

Routing Descriptor Blocks:

* 155.195.1.2, from 155.195.1.2, 3d02h ago

Route metric is 470016, traffic share count is 1

AS Hops 1

router1>sh ip bgp 10.0.0.0

BGP routing table entry for 10.0.0.0/8, version 9804

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

Advertised to non peer-group peers:

155.195.32.65 155.195.36.129 155.195.68.1

600

155.195.23.66 (metric 30720) from 155.195.68.1 (155.195.68.1)

Origin IGP, metric 469760, localpref 100, valid, internal, not synchronized

600, (received & used)

155.195.1.2 from 155.195.1.2 (79.52.128.65)

Origin IGP, metric 470016, localpref 100, valid, external, best

router1>

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

router2>sh ip route 10.0.0.0 255.0.0.0

Routing entry for 10.0.0.0/8

Known via "bgp 500", distance 20, metric 469760

Tag 600, type external

Redistributing via eigrp 11

Advertised by eigrp 11

Last update from 155.195.23.66 3d02h ago

Routing Descriptor Blocks:

* 155.195.23.66, from 155.195.23.66, 3d02h ago

Route metric is 469760, traffic share count is 1

AS Hops 1

router2>sh ip bgp 10.0.0.0

BGP routing table entry for 10.0.0.0/8, version 9093

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

Advertised to non peer-group peers:

155.195.32.65 155.195.36.129 155.195.61.1

600, (received & used)

155.195.23.66 from 155.195.23.66 (79.52.180.35)

Origin IGP, metric 469760, localpref 100, valid, external, best

600

155.195.1.2 (metric 30720) from 155.195.61.1 (155.195.61.1)

Origin IGP, metric 470016, localpref 100, valid, internal, not synchronized

router2>

Rui Carlos Antunes · ‎05-25-2005

A route is identified by a network prefix AND by a next-hop. If you receive two routes (for the same network prefix) with two differente next-hops, then they are two different routes.

IBGP synchronization requires that the exact same route be in the IP routing table (learnt from some IGP, like EIGRP) - "exact same route" means same network prefix and same next-hop.

IBGP synchronization can work if you configure "neighbor ... next-hop-self" on your IBGP peers. This way, the IBGP next-hop and the IGP next-hop will be the same and the route will be considered as synchronized.

Nevertheless, disabling synchronization is in fact the best way...

kfarrington · ‎05-25-2005

Many thx indeed. That is fantastic.

Beers are in the post :))

Thx

Ken