BGP Synchronization


A BGP router with synchronization enabled will not advertise its iBGP learned routes to its eBGP peers unless it has learned or verified this route on its routing table through an IGP. This feature can be useful if in an AS not all routers are running BGP. The purpose of this post is to illustrate the difference between synchronization being enabled versus it being disabled. We will also take a look for some work arounds for the problems it creates. Take a look at the diagram below for the lab.





R1 is on AS 1 while R2 and R3 is on AS 23. Now configure the router with the configuration below.


R1

!
interface Serial1/0
ip address 192.168.12.1 255.255.255.0
serial restart-delay 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 192.168.12.2 remote-as 23
no auto-summary

R2

!
interface Serial1/0
ip address 192.168.12.2 255.255.255.0
serial restart-delay 0
!
interface Serial1/1
ip address 192.168.23.2 255.255.255.0
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 23
no synchronization
bgp log-neighbor-changes
neighbor 192.168.12.1 remote-as 1
neighbor 192.168.23.3 remote-as 23
no auto-summary


R3

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Serial1/1
ip address 192.168.23.3 255.255.255.0
serial restart-delay 0
!
router ospf 1
log-adjacency-changes
network 192.168.23.0 0.0.0.255 area 0
!
router bgp 23
no synchronization
bgp log-neighbor-changes
network 3.3.3.3 mask 255.255.255.255
neighbor 192.168.23.2 remote-as 23
no auto-summary

     

Based on the configuration below, the defaults are "no synchronization". R3 is announcing its loopback interface and R1 sees the advertisement and even puts it in its routing table.


R1#sh ip bgp
BGP table version is 2, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.3/32 192.168.12.2 0 23 i
R1#sh ip route bgp
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.12.2, 00:10:59

R2#sh ip bgp
BGP table version is 2, local router ID is 192.168.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i3.3.3.3/32 192.168.23.3 0 100 0 i
R2#sh ip route bgp
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [200/0] via 192.168.23.3, 00:00:24
R2#

Take note that the "show ip bgp" command does not necessarily mean that the route is valid. It
means that this advertisement has been learned by BGP from its neighbors. It will only be put to the
routing table once the route is valid and marked as * and >. Above we can see both R1 and R2
seeing the advertisement from R3. R1 learned the route from R2. Seeing the route learned by BGP
in the routing table doesn't necessary mean that the network is pingable. It only means that the
router knows which AS it belongs to and the path to get there is the IGP within the AS 23
responsibility in our example.

Now the fun part. Lets configure the "synchronization command on R2 and let's see what happens
to R1. After configuring the one below, clear the BGP process by doing "clear ip bgp *" command.
Changes will not take effect unless the BGP peerings have been reset.


R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 23
R2(config-router)#sync

R2#clear ip bgp *
*Mar 1 06:07:27.103: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Down User reset
*Mar 1 06:07:27.107: %BGP-5-ADJCHANGE: neighbor 192.168.23.3 Down User reset
*Mar 1 06:07:27.995: %BGP-5-ADJCHANGE: neighbor 192.168.23.3 Up
*Mar 1 06:07:28.259: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up


Let's take a look at R1 and R2 again.


R1#sh ip bgp

R1#sh ip route bgp

R2#sh ip bgp
BGP table version is 2, local router ID is 192.168.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i3.3.3.3/32 192.168.23.3 0 100 0 i


Now we can see that R1 has nothing, and with synchronization R2 still has the 3.3.3.3 in the "show
ip bgp" command but the
> is gone. It is no longer considered the best path because if synchronization
is enabled, for BGP in R2 to send the information regarding 3.3.3.3 to R1, 3.3.3.3 should be in the
routing table in R2 learned by an IGP. That explains R1 has nothing because in the first place R2 has
no BGP learned route in its routing table. We can now see the effect of synchronization command!

Is there a solution? Of course there is! It will not be fun if there isn't! The synch rule says, for synchronization
to work, there should be a route to 3.3.3.3 learned from an IGP. So we will advertise 3.3.3.3 in R3 under the OSPF
process.



R3(config)#router ospf 1
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R3(config-router)#^Z


There you go. Lets see what happens to R1 and R2.


R1#sh ip bgp
BGP table version is 6, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.3/32 192.168.12.2 0 23 i
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.12.2, 00:01:11

R2#sh ip bgp
BGP table version is 4, local router ID is 192.168.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
r>i3.3.3.3/32 192.168.23.3 0 100 0 i
R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/65] via 192.168.23.3, 00:01:06, Serial1/1
C 192.168.23.0/24 is directly connected, Serial1/1


Woah! Whats going on! :) R1 has a route for 3.3.3.3 learned through BGP but R2 hasn't!
Check the output of R2 and you will see this
r>i3.3.3.3/32. This nasty letter "r" means RIB failure
meaning that the reason why its not in the routing table because another routing protocol which has
a lower administrative distance learned it. In our case, its OSPF because we announced this through
OSPF from R3. So why did R1 learn it? It fulfilled the requirement of synchronization thats why it has been
advertised to a eBGP peer.



R2#sh ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
3.3.3.3/32 192.168.23.3 Higher admin distance n/a



What can we do to make BGP more "believable" than OSPF? Thankfully OSPF has a feature to set
AD for a specific source ip. Lets see what happens if we apply this config in R2.



R2(config)#router ospf 1
R2(config-router)#distance 254 192.168.23.3 0.0.0.255


Let's check if there are changes in the BGP table and routing table.


R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [200/0] via 192.168.23.3, 00:00:00
C 192.168.23.0/24 is directly connected, Serial1/1


Lo and behold by changing the AD of all the routes advertised by R3, we made R2 believable and
solved the RIB failure problem.

Another work around is to configure static routes and redistribute it to the BGP process but I won't
discuss it in this post. :)!!!

Comments

14 Responses to "BGP Synchronization"

sltmycom said... September 13, 2009 at 9:50 PM

Thanks a million...Finally, I understand how BGP Synchronization works...Really Appreciate bro..
Encore Encore Encore !!! :)

Anonymous said... February 8, 2010 at 2:40 PM

Very good tutorial indeed! Keep up the good work Pete.Regards, marksant

Gurdeep Singh Rai said... January 4, 2011 at 5:25 PM

Hi Pete,
I have one question if you can answer that....it would be great. i am learning BGP and went through a diagram which was combination of IBGP and EBGP. please mail me so that i can send you the diagram and let me know how can i achieve the target. i was running HSRP as well..my id is rai.gurdeep@gmail.com

Anonymous said... February 24, 2012 at 12:45 AM

very good

Anonymous said... May 9, 2012 at 5:29 PM

Very Nice explanation......

Anonymous said... July 23, 2012 at 5:58 PM

Strange - in my GNS3 topology changing ospf distance to 254 doesn't change the situation - still it's O route in R2's sh ip route.
No idea why...

Anonymous said... July 23, 2012 at 6:11 PM

I tried to apply "distance ospf intra-area 254" command on R2 under router ospf 1 process and it led me to the route flapping! Every second the entry in IP routing table is changing - from O to B and vice-versa. What the hell? :)

Dima

Abulfaz said... October 27, 2012 at 10:13 PM

Thanks a lot! Excellent explanation!

George Servetas said... April 26, 2013 at 5:36 AM

Very nice lab, but I see a mistake. Please correct me if am wrong.

R2(config)#router ospf 1
R2(config-router)#distance 254 192.168.23.3 0.0.0.255

it should be:

R2(config)#router ospf 1
R2(config-router)#distance 254 3.3.3.3 0.0.0.0

where 3.3.3.3 is the RID of R3

Bidyout Acharyya said... May 1, 2013 at 3:36 PM

Its great explanation!

Bidyout

tejendra said... June 15, 2013 at 12:35 PM

thank's sir for this explanation ... i too had done this lab on Gns3 ..it's great .

Anonymous said... August 25, 2013 at 9:39 PM

Thanks for your explaination.

Anonymous said... September 7, 2013 at 6:10 PM

Thanks, Its really good explanation.

demongeb said... January 7, 2014 at 10:05 PM

hi there,
Changing ospf distance to 254 doesn't change the situation - still it's O route within R2's sh ip route...
I will follow next tip:
R2(config)#router ospf 1
R2(config-router)#distance 254 3.3.3.3 0.0.0.0

where 3.3.3.3 is the RID of R3

please answer!

Post a Comment

Certifications

Certifications

The Dreamer

A fun loving person who enjoys learning new things. Currently working as a Network Engineer supporting the global network of a Fortune 500 company. This blog serves as my notes for the labs I created for my CCIE journey. I can guarantee there are errors in my posts. If you spot them, please let me know.

Join my Facebook Page I WANT TO BE A CCIE

Donate to the Cause

My aim is to create materials for free and possibly a free lab. If you wish to help out, please send any amount. Thanks.

Join my Bandwagon

Blogs that I Read