Do you mean:

-- A route learned from an iBGP peer cannot be sent to an eBGP peer unless there is a corresponding route in the routing table learned through an IGP? This is, indeed, synchronization.

-- A route learned from an iBGP peer cannot be sent to an eBGP peer if there is a corresponding route in the routing table inserted by an IGP? Let me start by saying this isn't the default behaviour for Cisco routers. We will send an iBGP learned route to an eBGP peer, even if the iBGP route is not being installed in the local routing table because of some better IGP route to that same destination. Now as to why some vendors implement things the other way, etc--it's because in a distance vector or path vector protocol, you should never advertise a route you are not yourself using to forward traffic. In other words, if the route isn't installed in your routing table, you shouldn't advertise it. This rule is in plave to prevent routing loops built using multiple interacting protocols on the same network.

Cisco follows this rule in that _some_ route to the destination in question has to be installed in the local routing table before we will advertise a route to a BGP peer. We just relax it slightly so we don't care what the source of the route in the routing table is. Why? Becuase it won't cause a routing loop in BGP. :-)

EIGRP follows the more strict version of this rule, by the way--if the route in the routing table isn't from EIGRP, then EIGRP won't advertise the route to its peers.

:-)

Russ.W