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.
Can the aggregate address also be used to summarise routes being learned from an eBGP peer?
Because I setup a lab with routes being learnt from an eBGP peer (R1) that were in the range 155.1.1-5.0/24, and I had routes being learned from an iBGP peer (R3) that were in the range 155.1.6-7.0/24 (see below).
I found that summarisation was occurring on the eBGP learned routes from R1 and being advertised to iBGP neighbour R3.
If aggregation can occur for to/from eBGP peers, why would it do it that way round? i.e. from eBGP to iBGP and not vice-versa. The obvious answer seemed to be because there were more eBGP routes to summarise, but when I modified the lab, it didnât make a difference. i.e. if there are any routes with in the summarisation range being learnt from eBGP, it would always summarise that then advertise to iBGP.
This is an interesting experiment that you have devised, and it shows very clearly some of the intricacies of how eBGP and iBGP interact with summarization.
When summarization takes place using the aggregate-address command, BGP takes a look at the following issues:
First, as stated in the lesson, in order for the aggregate address to be advertised, you must have at least one subnet in the routing table within the aggregate range.
Second, when aggregating routes, BGP needs to consider the next-hop attribute of the routes being aggregated. In Cisco IOS, when routes learned from iBGP are aggregated, if these routes have different next-hop attributes (which is common because iBGP routes maintain the original next-hop of the eBGP-learned routes), aggregation may not take place for these routes. This is because BGP by default prefers not to aggregate routes with differing next-hop attributes.
BGP also considers the AS-Path when aggregating. eBGP-learned routes typically have different AS-Path attributes than iBGP-learned routes (even if the iBGP routes are advertising the same networks). This difference can lead to separate entries in the BGP table, and Cisco IOS might only aggregate the routes with identical AS-Path attributes and leave the others out. Since iBGP does not modify the AS-Path, this can also contribute to why only eBGP routes are being aggregated.
In some configurations, Cisco devices may prefer eBGP-learned routes over iBGP-learned routes when they are available for aggregation, especially if the next-hop or AS-Path differs.
So although I donât have a definitive answer for you as to why this specific behavior is taking place, it is likely that one or more of the above considerations are being invoked, resulting in only the aggregation of only eBGP routes rather than the iBGP routes as well.
I played around some more and got to the bottom of what was happening and itâs to do with loop-prevention.
Because aggregation included eBGP learned routes and the as-set switch was used, the aggregate was being advertised back to the eBGP peer with its own AS included, and as a result it was rejecting it. Within iBGP peers, the AS path was not being checked.
To make it work, I removed as-set form the aggregation command. I guess an alternative would have been to use the allowas-in switch on the eBGP peer receiving the aggregated prefix, but I only just thought of it now and havenât tested it.