In such a scenario, flapping routes will cause BGP to reconverge continually, which means that there will be excessive CPU usage on all routers involved as well as bandwidth usage with excessive BGP updates. As far as routing goes, this can cause a disruption in network traffic since routes within routers would be continually changing.
It can indeed be a double-edged sword. Ultimately you have to weigh the pros and cons of this feature based on the network topology. This topology doesnât need AS-SET since R4 is not connected via alternate routes to R2 and R3, so it shouldnât actually be implemented. But the lesson is for demonstration purposes.
If I donât use AS-Set and R2, R3 learned /16 prefix from R4 as u mentioned bcz they donât see their AS in AS Path, As I know will not be routing loop as described, Cuz R2 will learn /16 from R4 and already has /32 , more specific route will fix this issue from R2 and R3 side
If R3 need to go some prefix within /16 will ask R4 and R4 will ask R1 and R1 has summary to null 0 with /16 and also /32 for each R2 and R3
Where is the loop? @ReneMolenaar@lagapidis
And letâs assume that AS-SET is not configured and that R1 has an aggregate-address configured as in the lesson. R4 would advertise the 172.16.0.0/16 network to R2, and R2 would accept this. But this can potentially create a routing loop. Why? Because the 172.16.0.0/16 network includes the 172.16.2.2/32 address on R2. The loop prevention mechanism of BGP which does not accept a prefix with an AS path that contains its own AS number is negated, and this can be dangerous.
You are correct that in this particular scenario, a routing loop would not occur since the more specific route will be used. However, what happens if the L0 interface fails? R3 may try to reach 172.16.2.2, the packet will reach R2 and R2 will send it back to R4 using the summary route, since it no longer has a specific route to 172.16.2.2. Thus it will use the summary route to R4, and there you have your loop.
Thx for your reply
Ok if lo0 is down now, How R3 will try to reach it if itâs down and not advertised via bgp?
R1 receive /32 loopback prefix and summarize it to R4, not to R3
If R3 has in itâs routing table 172.16.2.2 thatâs mean itâs up and not down, if not then thatâs mean itâs down and will drop the packet and not ask R1 about it
Also if lo0 in R2 down, R1 will not forward the request toward R2 since itâs down and no longer available in BGP Table
The important issue here is not if this particular topology will create a loop, but if the use of a summary route without the AS-SET can potentially create a loop. I understand that the current topology will not cause a loop as I described it above, but we may easily create a situation where it would.
What if R1 sends the summary route to R3 as well? Or if R4 was directly connected with R3? Then we would have a loop if the L0 network went down.
The point is that by using a summary, there is potential for negating BGPs loop prevention mechanism of not accepting a prefix with an AS path that contains its own AS number. That is why AS-SET is necessary, regardless of whether or not your current topology would create a loop.
The atomic aggregate attribute is a well-known discretionary BGP attribute. This means that it must be recognized by all BGP speakers, but it does not have to be included in all BGP updates. The atomic aggregate attribute informs BGP peers that the router is using a less specific âaggregateâ route to a destination.
If a BGP speaker selects an aggregate route, when a more specific route is available, it must attach the Atomic Aggregate attribute when propagating the route. The purpose of the attribute is to alert BGP speakers along the path that some information may have been lost due to the route aggregation process and that the aggregate path might not be the best path to the destination.
When you use the Atomic Aggregate attribute, the BGP speaker has the option to send the Aggregator attribute. The Aggregator attribute includes the AS number and the IP address of the router that originated the aggregated route. In Cisco routers, the IP address is the router ID of the router that performs the route aggregation.
More info about the atomic aggregate attribute can be found here:
Iâve ran into this by an accident and I am wondering purely out of curiosity, why isnât it possible to create a summary using the aggregate-address command?
The aggregate-address command is used to create an aggregate entry within the BGP table. This essentially means that you can summarize multiple routes into a single route, thus reducing the size of the BGP table and minimizing the number of BGP updates when individual routes change.
If you issue the aggregate-address 0.0.0.0 0.0.0.0 command, youâre telling BGP to consolidate ALL ROUTES into a single aggregate route. This is essentially a default route FOR EVERYTHING, and in the context of aggregation that doesnât make sense. Taking aggregation to such extremes defeats the purpose of the feature.
If you want to create a default route, it is preferable to use a network statement in the BGP router configuration mode. This is much more efficient (aggregation requires more system resources to perform) and simpler as well.
Note that the use of the summary-only keyword makes no difference to the outcome of the command. You get the error message with or without it.
To be honest the error message is a little bit out of the ordinary, Iâve never come across an error message that says what youâre trying to do âmakes no senseâ!
For more info about this command, take a look at the following command reference:
We can see that the AS Path information has been lost.
But if I create a summary route which will only include R3âs 172.16.3.3/32 network
The AS Path information is retained??
How exactly does it work? Why did it retain the information in this case? One argument might be that the components which are being summarized all come from the same neighbor/same AS. However, why doesnât BGP also retain the AS Path if we summarize routes from multiple neighbors/ASes?
In my first example, why doesnât BGP just set the AS Path to â2, 1â since those have the networks that we are summarizing, why does it completley remove the AS Path information?
In this case it is retained, because you are using the as-set keyword. And since the route contained within the summary comes from a single eBGP peer, it has a single AS path and not multiple ones as shown in the lesson with the curly brackets or braces â{ }â.
Iâm not quite sure where your concern is. The only thing that I find strange in the output of your BGP table is the existence of AS number 8, which I donât see in the topology.
In the first example, the as-set keyword was not used, and that is why the AS path information was removed.
If I have misunderstood your query, please clarify and let me know.
