I am unable to understand how non connected IBGP peer send update to each other without redistributing BGP into IGP
Lets take an Eg
R1------> R2------------->R3----------> R4
you must have seen this scenario in case of BGP synchronization
Now R1 and R2 are connected via EBGP , R2 and R4 are connected via IBGP and we have ospf running on R2 , R3 and R4 but BGP and OSPF are not redistributed. Here synchronization is On, Now R1 will send an update about 10.10.10.0/24 to R2 ,I have seen in many cisco docs that R2 will send this update to R4 . My Question is since we are not having any redistribution between IGP and BGP so how did the update reached R4
Let's say it is send via R3 so would R3 make changes into its own routing table for this new route for 10.10.10.0/24 if not Why?
Now Let say R2 sends that update via R3 but R3 didn't make changes into it's routing table . Now R4 have received a data with destination to 10.10.10.0/24 now R3 didn't have route to 10.10.10.0/24 into it's IGP so it would drop this packet . My question is can't this data be send via the same process through which R4 receive the update from R2 via R3
Thanks in advance
First of all, Lets clear that BGP is a routing protocol that doesnt have transport protocol of its own like OSPF & EIGRP, it uses TCP 179.
So when R2 receives and update from EBGP it will send to all its IBGP neighbour i.e. R4, question is how and why R3 was skipped for this update..?
Ok, IBGP as said earlier uses TCP as a transport so it required reachability to the neighbour which is couple of hops away. so R3 doesnt see any routing updates passing through it .. it only sees TCP traffic passing by destined for R4. (R3 is running IGP so its concerned about any updates received on interfaces where IGP is enabled and uses the IGP transport like protocol 88, 89 )
R4 as synchronization is enabled it will check whether this route was learned via IGP, No, Do not install in routing table , leave it in BGP table.
now if you check the routing table or BGP table, every BGP learned routes doesnt show Outgoing interfaces for that route, like an IGP does it by default. Because it was received via TCP so only thing it bothers is checks next hop value and recurses the NH value in routing table to figure the exact path.
R3 will never know about any IBGP information untill and unless it redistributed in IGP.
Hope this answers your question
Pls rate useful posts
try to see the iBGP session as a user traffic flow that uses TCP:
R3 just needs to know how to route the TCP packets of the iBGP session.
The IGP in use will provide this IP connectivity between the loopback addresses of R2 and R4
Clearly R3 may not be able to route IP packets for a network that is present only in the BGP table.
It may be able if following the default route happens to send the packet to right edge router (R2 in this case).
Notice also that if we add MPLS to this picture we can safely disable split horizon even if R3 doesn't take part in iBGP mesh:
R4 will send a packet with a destination learned in a BGP route using the MPLS label switched path with destination = BGP next-hop = R2's loopback.
The IP packet is sent within an MPLS frame and R3 will switch the MPLS frame between two interfaces without examining the inner IP packet (label switching instead of IP routing)
Hope to help
When r2 sends a BGP update to r4 it is a unicast IP packet with r2 as the source address and with r4 as the destination address. r2 would use r3 as the next hop in the routing table to get to r4. The IP packet gets to r3 which analyzes the packet and determines that it can forward to the destination out its other interface and forwards the packet. A router does not look into a packet that it is forwarding, so r3 has no knowledge that it is forwarding a BGP update.
This is one of several things that make BGP different from other routing protocols. We are used to protocols like RIP or EIGRP or OSPF that send routing updates only to directly connected neighbors using broadcast or multicast IP packets. But BGP sends unicast IP packets to its neighbors, and the neighbors do not need to be directly connected.
So the question of how the update is sent is easy. But saying that r4 will receive te update does not necessarily mean that r4 will use the update. As Hitesh points out that with synchronization enabled when IBGP receives an update then BGP will check to see whether that prefix has been learned by an IGP.  note that this addresses the point of your question in your last paragraph. Your question assumes that r4 will use the route and therefore the traffic will be dropped at r3. This is exactly the problem that synchronization was designed to solve.
I would like to ask some question to you. My question is if syncronization is enabled then the R4 will learn path from R3 to reach the R2 to get update. Like in our network here we have disabled syn, so here in our network bgp is taking own route and IGP is taking own route to reach the destination. Please help me out from this confussion....
There are two issues involved here:
1) how does routing work to get BGP updates between R2 and R4. For the BGP session to be established between R2 and R4 it is necessary that both routers have routes to each other. In the example being discussed here that is accomplished since r2, R3, and R4 all participate in OSPF. Since R2 and R4 have learned routes to each other from OSPF then the BGP updates can be sent to each other.
2) how does routing work for data packets. For data packets each router along the data path must have a route in its routing table that tells the router how to forward the packet toward its destination. In this example R2 and R4 have received updates about a certain remote network and could forward data packets toward that remote network. But R3 does not have a route for that specific network. Unless R3 has some route in its routing table that tells how to forward to that remote network then R3 will drop the data packet.
I hope that this helps to resolve this confusion.
But when R3 can send the update considering that it have the received as packet as an TCP packet why can't data be also send like that, as data is also sent via TCP, what kind of differences are there in an update packet and data packet.
I believe that when sending the update R3 checkes that source is R2 and destination is R4 which can be reached via it's connected interfaces but when the data packed arrives from R4 ,R3 checks that source is R4 which he knows but destination 10.10.10.0/24 is unknown hence it drops the packed
Since this is only an assumption please confirm
>> what kind of differences are there in an update packet and data packet.
a different IP destination
update packet IP DA = R4's loopback ip address or R2's loopback IP address (depending on direction)
data packet IP DA = a specific IP address that is part of a BGP route
R3 is able to route the update packet because it participates in IGP routing but it may not able to to correctly route the data packet as its only option is to send it following the default route
This may be correct or not and as Rick has noted this is the point of synchronization attempting to avoid internal black holes for user traffic.
Hope to help
Your question has several parts, so first let me deal with this part:"what kind of differences are there in an update packet and data packet." The answer is that with the update packet both the source address and the destination address of the packets are addresses that are known to R3. With a data packet the destination address is an address that is not known to R3. So the issue becomes what does R3 do when it gets a data packet to forward and it does not know how to reach the destination.
The other part of your question is this:"it have the received as packet as an TCP packet why can't data be also send like that". To answer this we must distinguish between the normal forwarding operation and what it is possible to configure. In normal forwarding of data traffic R4 would forward a data packet (whose destination is in the network advertised by BGP) to R3, but when R3 received the data packet but did not have that destination network in its routing table it would drop the packet. That is the normal operating process. But there is an option which accomplishes what you are asking about. A potential solution here is to configure a GRE tunnel between R2 and R4, and to arrange the routing logic so that data packets for "remote" destinations are forwarded through the GRE tunnel. If you configure this option then R2 and R4 encapsulate the remote traffic and then what R3 sees is a packet whose source and destination addresses are R2 and R4 and so R3 can forward the traffic.
Thanks a Lot guys for this synchronization enabled situation
Lets take the same scenario but with synchronization disabled now R4 will receive the update from R2 about 10.10.10.0/24 via R3 but the difference is that now R4 will also install this route into it's routing table. Now when R4 received a packet destined for 10.10.10.0/24 it will check it's routing table and forward this packet to R3
here comes the issue that R3 still do not know about 10.10.10.0/24 since BGP is now redistributed into IGP (correct me if I am wrong here)
so what makes a diffrence with synchronisation enabled and disabled
how this synchronization helps
Thanks in advance.
First we need to check something in your recent post. You said:"since BGP is now redistributed into IGP". Is it really "now" (are you significantly changing the scenario) or is it supposed to be "not"?
The difference between synchronization enabled or synchronization disabled is that synchronization enabled prevents forming a black hole for traffic (R4 will not install the route so it will not forward data traffic for remote destination to R3) and synchronization disabled will allow the black hole to be created.
A few questions first.
1) Is R3 running IBGP?
2) Is R2 directly connected to R4? or is it connected through R3? (Im referring to physical connectivity)
3) Is R2 directly connected to R3?