R1, R2 & R3 are fully meshed with R1 & R3 learning EBGP routes from another two AS ? R2 has no EBGP peers.
When I configure R1, R2 & R3 with no synchronization they each show all the IBGP routes advertised by their IBGP peers and these routes are entered into the routing tables as expected.
However, when I enable synchronization on R1 and reset it?s BGP connections, I notice that the R1-R3 BGP connection does not come back up. Consequently R1 does not learn R3?s routes and R3 does not learn R1?s routes. R2?s maintains all the routes as before as it does manage to re-establish the BGP connections with both it?s peers.
Why should R1 (synch) drop the BGP connection with R2 (no synch), yet maintain a peer connection with R2 (no synch) ?? I understand that when synch is enabled IBGP routes are not entered into the routing table ie R1. But this doesn?t explain R3.
Another thing ? when R2 is the only router configured with synchronization, it will re-establish BGP connections with both peers and it does learn all the BGP routes but it only shows directly connected routes in it?s routing table. R1 & R3 both show all BGP routes and have all routes in the routing table.
Does anyone have information on synch mismatches related to IBGP without IGP????
If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. BGP synchronization is enabled by default in Cisco IOS? Software. If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization with use of the no synchronization BGP subcommand.
Note: Synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.
synchronization will only install iBGP routes into the IP routing table, if they are already present in the IP routing table. The intention is to avoid black holes. This explains the R2 behaviour described at the end of your posts.
It is not a bug - it is a feature! ;-)
BGP will ALWAYS depend on the IP routing table, because it will need to find the neighbor IP for TCP session startup. This can be "connected", "static" or a dynamic protocol.
Now on to your other problem. A shot into the dark (could you post the relevant BGP configs as well as interfaces and IPs?):
Could it be that R1 learns the R3 neighbor IP through iBGP from R2? If so, it would explain, why enabling sync does not allow the reestablishment of the BGP session R1-R3:
1) no sync: R3 neighbor IP is installed as iBGP route by R1 after getting iBGP update from R2 and session can be started.
2) sync: iBGP route to R3 is not installed in the IP routing table of R1 and thus no session BGP TCP session is established.
Normally one would enable an IGP to announce the R1,R2,R3 loopbacks used for iBGP sessions. In case you do not want an IGP you need either static routes ("IGP replacement") or use directly connected neighbors and connected IPs. Then iBGP should come up in any case.
Sidenote: I would nowadays always disable sync in any case and setup iBGP properly avoiding "black holes". The need for "synchronization" is usually because of bad BGP design. My 2 cents.
Actually after trying out Jeff Doyles Example (Ex 3-30 on P170 Routing TCP/IP VII) I was curious to expand a little and try out what happened if I tried out the same exercise on R1 (Vail).
The two attachments show the topology / configs & what I managed to find with further troubleshooting.
I'm thinking this TCP connection is dropped due to the synch/no synch mismatch & that the reason the connection is maintained to R2 (Aspen) is because it's directly connected and so should always be established as a neighbor?? This explanation would also be supported working back from R3 to R1 - the trouble is, I'm really not sure if I'm wide of the mark here or not :-)
Anyway, for some this might seem like a useless exercise but I beleive it helps me to really understand BGP so hopefully someone can try this one out too and put me straight.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...