So what you are trying to do here is to make sure that R2 will redistribute the 1.1.1.0/24 prefix into OSPF, so that R4 will have it in its IGP (which is OSPF). This satisfies the synchronization rule and allows the BGP route to 1.1.1.0/24 to be installed in the routing table.
I’m not completely sure why it’s not working for you just from the information you have shared. You will need to troubleshoot the redistribution of the route into OSPF. One thing that comes to mind is the fact that you are redistributing 1.1.1.1/32. Is that what you have configured on your R1 loopback interface? In the lesson, it’s 1.1.1.1/24 and the network command is advertising 1.1.1.0 0.0.0.255. This may have something to do with it.
If not, troubleshoot redistribution and see why the network is not being shared to R4. You can take a look at these lessons to help you out:
as u mentioned it should be running fine, although when i change the loopbacks to 1.1.1.0/24 instead 1.1.1.1/32 it runs. Yes the network commands area the same as loopbacks on bgp configuration. I suggest there will be a problem with bgp router- , maybe sthing is wrong from the same protocol and i
bind the 1.1.1.1 to update loopback bgp neighborship
define bgp router- 1.1.1.1
make static routes to this prefix
i advertsise the 1.1.1.1/32 host as network.
Do u have any in ur mind ? Do u have mmet any other same case?
Remember that the network command in BGP must match the address and subnet mask exactly as it exists in the routing table. Check out what’s in the routing table for that loopback address. If it does not match, then it won’t work.
If I understand the rule correctly, as Rene said, this was the “solution” to scenarios where we didn’t run iBGP on all routers in our transit AS.
So if the prefix is validated via an IGP, the assumption here is that even R3 (who isn’t running BGP) is running that IGP and knows about the route, so no traffic will be blackholed, right?
Yes, that is correct. This is a feature that is meaningful when there are some routes within our AS that are not running BGP. However, this approach is declining in use, and the best practice is to ensure that there is a full mesh of iBGP peerings between routers in an AS.
Yes. R4 refuses to install the BGP route unless there is an IGP route installed in the routing table for that prefix. This ensures that this route is known within the IGP domain, and thus any routers not running iBGP will be able to route it.
What is the idea behind the synchronization rule? Or to frame my question better, why did they decide to do something like this?
On one hand, knowing the routes also via an IGP ensured that you wouldn’t have routing blackholes but what was the point of having the IGP also know the same routes as BGP? Wouldn’t that eliminate the use case for BGP? It would also be impossible to run this in the modern world since an IGP cannot handle so many routes that there are today.
The BGP Synchronization rule is a historical safety mechanism designed to prevent routing black holes in transit ASes where not all internal routers ran BGP. In the early days of the internet (late 1980s–early 1990s), routers had very limited RAM and CPU. It was common practice in transit ASes to run BGP only on edge/border routers, while internal “core” routers ran only an IGP (OSPF, EIGRP, IS-IS, etc.). This, however, produced the problem that we saw in the lesson.
The synchronization rule was the solution, which worked well for the size and the requirements of the Internet of the time. This rule forced operators to redistribute the BGP prefix into the IGP first, ensuring the entire forwarding path was valid.
It seems that way, but BGP and the IGP still served different roles even with this requirement. The IGP was used purely as a forwarding underlay to ensure internal routers could actually deliver packets to the destination. BGP remained the authoritative protocol for inter-domain routing, still carrying rich policy attributes that IGPs cannot carry. BGP was still required at the edges for inter-AS policy enforcement and loop prevention.
It’s also important to note that the redistribution was selective and filtered. Operators did not dump the entire Internet table into the IGP. Only specific transit prefixes were redistributed, which was manageable when the early internet had only thousands of routes (not millions).
Absolutely. This design cannot work at modern internet scale. Injecting the global BGP table into OSPF, EIGRP, or IS-IS would instantly cause IGP instability and network collapse.
This problem is solved today in two ways:
Full iBGP Mesh / Route Reflectors / Confederations: Every internal router has BGP routes directly, no IGP redistribution of external prefixes is needed.
MPLS BGP-Free Core: Service Providers use MPLS so that core routers only switch labels, not IP destinations. Core routers still only run an IGP (for label-switched path setup), but traffic is encapsulated at the edge, so the core never needs to look up BGP destination prefixes.
BGP synchronization should never be used today, and indeed, as a feature, it is disabled by default starting with Cisco IOS 12.2(8)T. The purpose of the lesson is to simply get to know this feature and its implications.