The whole problem of the last scenario is the fact that R1 does not have the destination of 3.3.3.0/24 in its routing table. However, you can see that it is in the BGP table. In the BGP table it says that the next hop is 192.168.23.3, but R1 doesn’t know this IP, and it doesn’t have any routes to be able to reach it. So to solve the issue, we need to let R1 know how to get to the next hop IP address indicated in the BGP table.
This can be done either by changing the next hop address to one that R1 knows, like that of R2, or to use a static route. Rene choose the first option. Now we see the route showing up in R1, but we still can’t ping.
This is because the ping is able to reach R3, but R3 must be able to send back a reply. If we look in R3’s routing table, we’ll see that it has no route to 192.168.12.0/24, and so it has no way of knowing where to return the packet, so it drops it.
For this reason, R2 must advertise the 192.168.12.0/24 network to R3 so that it knows where to send all packets destined for that network. Once that’s done, R3 can now return R1’s pings since it now has a route to R1’s IP address.
Hi Folks,
If we create static route to get this entries to Routing table then BGP can advertise it to its neighbor. I will has problem, When packet return to R1, R1 will discard the packet, right?
In R1, we see the aggregate-address 172.16.0.0 255.255.0.0 command in the BGP configuration, and we want to send this aggregate address to BGP peers. This means that we must already have more specific routes in the routing table that we simply want to aggregate, such as 172.16.1.0/24 and 172.16.55.0/24 for example. These are not shown in the lesson, but would be there in a production environment.
Remember, a routing table lookup will look up the most specific routes. So even with the null static route, it would never be matched since something more specific would be matched, and successfully routed. If there are no routes that are more specific, then the packet would be dropped anyway so the null interface configuration wouldn’t make a difference.
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.
As the example, Discard route(/21) will be installed to routing table. If the prefix /24 comes, It will be only matched with discard route, for sure the packet is dropped.
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 1.1.1.0/24 n/w.
second if suppose we do not write exact subnet mask only advertise 1.1.1.0 and auto-summary also enabled in this case I think R2 should not face any issue b/c 1.1.1.0/8 will get stored in R2 Routing table and 1.1.1.0/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 1.1.1.1/24 then the network command must be exactly 1.1.1.0/24.
Now if we were to put in the command network 1.0.0.0 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:
Hi Rene and Laz,
I have the configuration from you, and everything is the same as in your config.
but I can not ping the 3.3.3.3
Router#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
How can I add the routerconfigs here?
Many thanks
Mihaly
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.
Hello there,
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.
