BGP synchronization is not commonly used today, however still part of the Cisco CCIE certification and must be understood by all candidates trying to obtain the certification. Further there may be some rare cases where this feature is still needed. Reading through literature, I found different definitions of how BGP synchronization works, especially when it comes to the details. All sources commonly describe the purpose of BGP synchronization. Avoid blackholing traffic by adding an additional constraint before advertising a route to an eBGP peer, which is: “Only advertise a route learned from an IBGP peer to an eBGP peer when there is an exact match of that route learned from an IGP in the routing table“. Look at the following graphic why this would be an issue:
Let’s look at the 1.1.1.0/24 prefix which is originated by R1 in AS50. R2 and R4 are the border routers of AS100 and form a iBGP relationship to each other. Let’s look at the configuration in AS100, without sync enabled. The IP address numbering scheme is easy: 10.10.<link>.<router>, where the link between R2 and R4 is 24. Hence, R4s address between R3 and R4 is 10.10.34.4. The configuration looks as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
! R2 router eigrp 100 network 10.0.0.0 router bgp 100 bgp log-neighbor-changes neighbor 10.10.12.1 remote-as 50 neighbor 10.10.24.4 remote-as 100 neighbor 10.10.24.4 next-hop-self ! R3 router eigrp 100 network 10.0.0.0 ! R4 router eigrp 100 network 10.0.0.0 router bgp 100 bgp log-neighbor-changes neighbor 10.10.23.2 remote-as 100 neighbor 10.10.45.5 remote-as 200 ! R5 # sh ip bgp 1.1.1.0/24 BGP routing table entry for 1.1.1.0/24, version 2 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 100 50 10.10.45.4 from 10.10.45.4 (10.10.34.4) Origin IGP, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 # sh ip route 1.1.1.1 Routing entry for 1.1.1.0/24 Known via "bgp 200", distance 20, metric 0 Tag 100, type external Last update from 10.10.45.4 00:30:23 ago Routing Descriptor Blocks: * 10.10.45.4, from 10.10.45.4, 00:30:23 ago Route metric is 0, traffic share count is 1 AS Hops 2 Route tag 100 MPLS label: none |
Pretty basic, huh? R5 learns about the 1.1.1.0/24 prefix from R4, but is not able to ping to the destination. R1 advertises the prefix to R2. R2 forwards it to R4, and has next-hop-self configured. This means the Next Hop field in the BGP update is set to 10.10.23.2, which is R2s outgoing interface towards R4. R4 then forwards the prefix to R5, so everything should work?
The problem is at R3, however. As R3 does not participate in the BGP process and hence does not learn about the BGP routes. In fact, it only learns about the internal networks from EIGPR:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# sh ip route | be Gat Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks D 10.10.12.0/24 [90/3072] via 10.10.23.2, 00:35:02, GigabitEthernet0/1.23 C 10.10.23.0/24 is directly connected, GigabitEthernet0/1.23 L 10.10.23.3/32 is directly connected, GigabitEthernet0/1.23 C 10.10.34.0/24 is directly connected, GigabitEthernet0/1.34 L 10.10.34.3/32 is directly connected, GigabitEthernet0/1.34 D 10.10.45.0/24 [90/3072] via 10.10.34.4, 00:33:51, GigabitEthernet0/1.34 # sh ip route 1.1.1.1 % Network not in table #sh ip cef 1.1.1.1 0.0.0.0/0 no route |
Hence AS100 advertises a path to other eBGP peers, but is not able to forward it, as R3 will throw the traffic away. There are two possible solutions to this problem:
- Configure R3 to be part of the BGP process, hence it learns the BGP routes and knows how to forward them. Depending of the network size, this can be a considerable amount of iBGP peerings or requires scaling techniques such as Route Reflectors or Confederations.
- Redistribute BGP routes into EIGRP and enable synchronization
Redistributing is required to provide R3 with reachability information. Synchronization is used to avoid traffic black holing. Let’s enable synchronization on R4:
1 2 3 4 5 6 |
R4#sh run | s bgp router bgp 100 synchronization bgp log-neighbor-changes neighbor 10.10.23.2 remote-as 100 neighbor 10.10.45.5 remote-as 200 |
Now, the network is not advertised to R5 anymore, as R4 does not have a matching route from an IGP in its routing table.
1 2 |
R5#sh ip bgp 1.1.1.0 % Network not in table |
1 2 3 4 5 6 7 8 9 |
R4#sh ip bgp 1.1.1.0 BGP routing table entry for 1.1.1.0/24, version 0 Paths: (1 available, no best path) Not advertised to any peer Refresh Epoch 1 50 10.10.12.1 (metric 3328) from 10.10.23.2 (10.10.12.2) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized rx pathid: 0, tx pathid: 0 |
We can see that the only available path is not synchronized and hence cannot be selected as best path. Since there is no best path, no path can be advertised to any peer. As soon as we redistribute the BGP paths coming from AS50 into EIGRP on R2, this should change:
1 2 3 4 5 |
ip as-path access-list 1 permit ^50_ route-map BGP_TO_EIGRP permit 10 match as-path 1 router eigrp 100 redistribute bgp 100 metric 100000 100 255 1 1500 route-map BGP_TO_EIGRP |
Now, R4 has a route to 1.1.1.0/24 and hence advertises it again to R5. Now, R5 is also able to ping the destination, as R3 now has reachability information
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
R4#sh ip route 1.1.1.0 Routing entry for 1.1.1.0/24 Known via "eigrp 100", distance 170, metric 51712 Tag 50, type external Redistributing via eigrp 100 Last update from 10.10.34.3 on GigabitEthernet0/1.34, 00:00:43 ago Routing Descriptor Blocks: * 10.10.34.3, from 10.10.34.3, 00:00:43 ago, via GigabitEthernet0/1.34 Route metric is 51712, traffic share count is 1 Total delay is 1020 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2 Route tag 50 R4#sh ip bgp 1.1.1.0/24 BGP routing table entry for 1.1.1.0/24, version 6 Paths: (1 available, best #1, table default, RIB-failure(17)) Advertised to update-groups: 2 Refresh Epoch 2 50 10.10.12.1 (metric 3328) from 10.10.23.2 (10.10.12.2) Origin IGP, metric 0, localpref 100, valid, internal, synchronized, best rx pathid: 0, tx pathid: 0x0 R5#sh ip bgp 1.1.1.0/24 BGP routing table entry for 1.1.1.0/24, version 4 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 2 100 50 10.10.45.4 from 10.10.45.4 (10.10.34.4) Origin IGP, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 |
In particular, note the line which is showing RIB-failure(17) at R4 for the route 1.1.1.0/24. As R4 is learning that route from EIGRP (AD 170) and iBGP (AD 200) the EIGRP route is preferred and BGP cannot put the selected best path into the routing table. This however is not a necessary condition to advertise it further.
BGP Synchronization an Route Reflector
Most sources however source that this is only relevant to external peers. And this is where some confusion comes in. One required condition for BGP to advertise a path to a neighbor (whether it is iBGP or eBGP) is to have a valid best path for that prefix, otherwise it cannot be selected. One general rule is that a route which is being learned from an iBGP peer is not forwarded to another iBGP rule, hence the synchronization rule does not apply in this case. But what about route reflectors? Consider the following topology:
Similar topology, but R2 and R4 no longer have a peering directly to each other, but use R3 as a route reflector. Intuitively thinking, synchronization would not make any sense in that case, as R3 is part of the BGP routing domain, and hence knows the path to 1.1.1.0/24. But what happens if it is enabled nonetheless? We can be sure that R4 would not advertise the prefix to R5, as shown in the previous example. But would it get to R4 in the first place?
According to what we’ve seen above, synchronization would prevent R3 to select the route learned from R2 as best path, and hence should not advertise it further. Here are the relevant running configurations for this example, synchronization already enabled on all routers, but redistribution disabled again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
R2#sh run | s bgp|eigrp router eigrp 100 network 10.0.0.0 router bgp 100 synchronization bgp log-neighbor-changes neighbor 10.10.12.1 remote-as 50 neighbor 10.10.23.3 remote-as 100 R3#sh run | s bgp|eigrp router eigrp 100 network 10.0.0.0 router bgp 100 synchronization bgp log-neighbor-changes neighbor 10.10.23.2 remote-as 100 neighbor 10.10.23.2 route-reflector-client neighbor 10.10.34.4 remote-as 100 neighbor 10.10.34.4 route-reflector-client R4#sh run | s bgp|eigrp router eigrp 100 network 10.0.0.0 router bgp 100 synchronization bgp log-neighbor-changes neighbor 10.10.34.3 remote-as 100 neighbor 10.10.45.5 remote-as 200 |
Recall that the synchronization rule is only valid if the route is learned from an external peer. We can verify that on R2, which advertises the rule to R3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
R2#sh ip bgp 1.1.1.0 BGP routing table entry for 1.1.1.0/24, version 2 Paths: (1 available, best #1, table default) Advertised to update-groups: 6 Refresh Epoch 1 50 10.10.12.1 from 10.10.12.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 R2#sh ip bgp neigh 10.10.23.3 ad BGP table version is 2, local router ID is 10.10.12.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 1.1.1.0/24 10.10.12.1 0 0 50 i Total number of prefixes 1 |
The route is tagged “external“, and note that there is no entry whether the path is synchronized or not. As R2 is learning it from an eBGP peer, that is fine. No let’s take a look at R3:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
R3#sh ip bgp 1.1.1.0 BGP routing table entry for 1.1.1.0/24, version 0 Paths: (1 available, no best path) Flag: 0x820 Not advertised to any peer Refresh Epoch 1 50, (Received from a RR-client) 10.10.12.1 (metric 3072) from 10.10.23.2 (10.10.12.2) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized rx pathid: 0, tx pathid: 0 R3#sh ip bgp neig 10.10.34.4 advertised-routes Total number of prefixes 0 |
R3 learns the route from R2 and installed it in his BGP table. As route-reflector, it should advertise the route to its route-reflector clients, being R4 in this case. But note that the path is not synchronized and hence can never be selected as best path. It is hence not advertised to any neighbor, including it’s iBGP neighbors.
1 2 |
R4#sh ip bgp 1.1.1.0/24 % Network not in table |
Prove with another Prefix
Now, let us add another prefix originated by R1 (AS50), being 5.5.5.0/24. Further, redistribute this network, but not 2.2.2.0/24 into EIGRP at R2.
1 2 3 4 5 6 7 8 9 10 11 12 |
! R1 int lo 5 ip address 5.5.5.5 255.255.255.0 router bgp 50 network 5.5.5.0 mask 255.255.255.0 ! R5 ip prefix-list ONLY_5 seq 10 permit 5.5.5.0/24 route-map BGP_TO_EIGRP_ONLY_5 permit 10 match ip address prefix-list ONLY_5 router eigrp 100 redistribute bgp 100 metric 100000 100 255 1 1500 route-map BGP_TO_EIGRP_ONLY_5 |
Now let us look at R3 again:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
R3#sh ip bgp 1.1.1.0/24 BGP routing table entry for 1.1.1.0/24, version 0 Paths: (1 available, no best path) Flag: 0x820 Not advertised to any peer Refresh Epoch 1 50, (Received from a RR-client) 10.10.12.1 (metric 3072) from 10.10.23.2 (10.10.12.2) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized rx pathid: 0, tx pathid: 0 R3#sh ip bgp 5.5.5.0/24 BGP routing table entry for 5.5.5.0/24, version 3 Paths: (1 available, best #1, table default, RIB-failure(17)) Advertised to update-groups: 4 Refresh Epoch 1 50, (Received from a RR-client) 10.10.12.1 (metric 3072) from 10.10.23.2 (10.10.12.2) Origin IGP, metric 0, localpref 100, valid, internal, synchronized, best rx pathid: 0, tx pathid: 0x0 R3#sh ip bgp neig 10.10.34.4 advertised-routes BGP table version is 3, local router ID is 10.10.34.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path r>i 5.5.5.0/24 10.10.12.1 0 100 0 50 i Total number of prefixes 1 |
Now we can see that 1.1.1.0/24 is not synchronized and hence not advertised any further, but 5.5.5.0/24 is synchronized and hence reflected to the other iBGP route-reflector clients. On R5 we can see that only 5.5.5.0/24 is advertised from AS100, but not 1.1.1.0/24
1 2 3 |
R5#sh ip bgp | b Network Network Next Hop Metric LocPrf Weight Path *> 5.5.5.0/24 10.10.45.4 0 100 50 i |
Summary
TL;DR and Summary: Many books and sources state that synchronization is used to prevent advertising routes to eBGP neighbors to prevent traffic black holing, but does not affect internal advertisements. While this was the original intention, this statement is not precise and even wrong. More precisely, the BGP synchronization rule should be stated:
During the BGP decision process, a route learned from an iBGP peer can only be considered as best path, when there is an exact match of the prefix in the routing table, learned by any IGP.
When there is no best path, the prefix is simply not advertised any further, regardless if the neighbors are iBGP or eBGP peers.