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. :)!!!