Hi Rene,
I dont know if someone has mentioned the wrong information in your article regarding to BGP Summarization. You have mentioned that what R1 has in its routing table (can’t advertise what I don’t have!). The correct one is what R1 has in its BGP table (can’t advertise what I don’t have!). It means that R1 could have connected Interfaces in its Routing Table but not in its BGP Table so in this case R1 will not advertise the summary route because R1 doesn’t see these connected Interfaces in its BGP Table. When it comes to BGP Summarization, The Router will check if the subsets Networks are on its BGP Table not on its Routing Table.
You are correct that if a prefix is not in the BGP table it cannot be advertised to other BGP peers. However, a prerequisite of having a prefix in the BGP table is to have that route in the routing table.
Yes that is true, but it will only enter the BGP table if the route exists in the routing table. So the statement that Rene made is correct.
Rene compared BGP with IGPs and shows how they behave differently in the lesson called “How to advertise networks in BGP” In it he states the following:
When you use any of the IGPs (RIP, OSPF or EIGRP) then the network command is used to activate the IGP on all interfaces that fall within the range of the network command.
BGP doesn’t care about interfaces, it doesn’t even look at them. When we use the network command in BGP then BGP will only look at the routing table. When it finds the network that matches the network command, it will install it in the BGP table.
I was going through your GNS3Vault labs but could not find any lab specifically to try out troubleshooting BGP nighborship and route advertisement related issues.
Can you please design a troubleshooting lab for basic and advanced BGP features…or if there is already one that you have can you direct me there please … !!!
And Thanks alot for the amazing content as always !!!
RESPECT !!!
Beyond what’s available on the GNS3Vault, Rene doesn’t have any ready-made labs that can be used to troubleshoot BGP peering and route advertisements. However, in both of the following lessons, the topologies used are quite simple to recreate as they only involve two routers. I suggest you recreate these topologies and try out the various scenarios to get more accustomed to the possible errors that may occur.
Hi Rene
thaks for Explanation , My question is from IBGP Split Horizon issue you describe , since bgp itself is one of the IGP protocol than why we use static route to establish the reachability between R1 and R3 i am confused on this. could you please explain this.
What is the difference between Neighborship , Adjecencies and Reachablity ,
when we establishedd Neighborship in bgp the other 2 Adjecencies and Reachablity can not come automatically?
One of the prerequisites of iBGP to function is that all of the iBGP peers must already be able to reach each other. Practically speaking, every iBGP router in an AS must be able to ping every other iBGP router in the AS. That way, a full mesh iBGP peering can be established. How that reachablility is established doesn’t matter. It could be using an IGP, it could be using static routing. The prerequisite is fulfilled in this case in the lesson using static routing.
The terms “peering” “neighborship” and “adjacency” are all used interchangeably to refer to the BGP session that is established between BGP peers, whether those are eBGP peers or iBGP peers.
Reachability in this case simply means that there is already routing in place to allow for communication between the routers in question. In other words, if one router has reachability to the other one, it simply means that they can ping each other. Put another way, it means that they are able to establish an BGP peering because the underlying routing exists so that they can communicate. This underlying routing can be established using an IGP or static routing. Take a look at this NetwokLesson note for more info. Note that iBGP peerings take place between routers that are not necessarily directly connected while eBGP peerings take place between BGP peers that are directly connected. (This is the default behavior, although it can be changed).
These adjacencies/peerings/neighborships between BGP peerings (whether eBGP or iBGP) are not automatically created like they are with OSPF or EIGRP. They must be manually configured on each end.