Now you want to share these routes via BGP, using the aggregate-address command. You put in the following command in your BGP configuration:
aggregate-address 172.16.0.0 255.255.248.0
This results in BGP attempting to send this prefix to its neighbors. But because there is no exact match in the routing table, it does not. So you add the following static route:
ip route 172.16.0.0 255.255.248.0 null 0
And BGP will begin advertising this route.
Now, let’s say an IP packet with a destination address of 172.16.2.54 arrives at the router. What will happen? This destination address will be compared with the entries in the routing table. Which one will it match? The most specific match is: 172.16.2.0/24. This is because this match has a subnet mask (or prefix) of /24 while the static null route we installed has a subnet mask (or prefix) of /21.
It is not a matter of priority, but a matter of how specific a match it is based on the subnet mask or prefix of the particular routing table entry.
If you have a router with the routes I mentioned in the previous post, and you add the null route with the summary prefix, you will end up with a routing table that looks something like this (assume 10.10.10.1 and 10.20.20.2 are the next hop addresses for the individual routes):
172.16.0.0 is variably subnetted, 5 subnets, 2 masks
S 172.16.1.0 255.255.255.0 via 10.10.10.1
S 172.16.2.0 255.255.255.0 via 10.10.10.1
S 172.16.3.0 255.255.255.0 via 10.10.10.1
S 172.16.4.0 255.255.255.0 via 10.20.20.2
S 172.16.5.0 255.255.255.0 via 10.20.20.2
S 172.16.0.0 255.255.248.0 Null0
Now if a packet arrives with a destination IP of 172.16.3.55 for example, it will always match the most specific route in the routing table. In this case, it will match 172.16.3.0/24 and be sent to a next hop IP address of 10.10.10.1. Even though there is a null route to 172.16.0.0/21, this route is less specific and will never be matched by such a destination IP.
I think there should not be be any problem on R2 when auto summary is enabled on R1 and n/w is being advertised with exact subnet mask b/c then still R2 will receive 188.8.131.52/24 n/w.
second if suppose we do not write exact subnet mask only advertise 184.108.40.206 and auto-summary also enabled in this case I think R2 should not face any issue b/c 220.127.116.11/8 will get stored in R2 Routing table and 18.104.22.168/24 is also part of this then why would he do complain?
R2 still did not receive any advertisements for this network. The reason is because the network command and the address space assigned to a particular interface must be an exact match. If the loopback is assigned 22.214.171.124/24 then the network command must be exactly 126.96.36.199/24.
Now if we were to put in the command network 188.8.131.52 with auto-summary enabled, then yes, the classful network would be advertised, even without an exact match. I have tried this in my lab, and it did indeed work.
For more info on the auto-summary feature of BGP, take a look at this lesson:
There could be many reasons for you not being able to ping. The troubleshooting process described in the lesson should take you step by step in checking all of the configuration to ensure that everything is correct. Take a look again, and if you still encounter problems, give us some more information so that we can help you troubleshoot.
Just being a little curious, I was applying a CLI command on a BGP glass server, and I noticed that this neighbor is on Idle state and / Admin. My question is why is showing that Admin part?
Lets say you have iBGP neighborship between two routers using loopback interfaces then what will the next hop be changed to with next-hop-self while passing eBGP prefix received from another neighbor? Loopback address or the interface address used to reach the other iBGP neighbor?
The next-hop IP address used in BGP is always that of the source of the BGP information. This means that whenever the next-hop-self feature is used, the router replaces the next-hop IP address of the route with its own IP address, and specifically, the IP address which is used for the BGP peering. If that is the loopback address, then that is what will be used.
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.
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 !!!
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.