CIDR and Aggregate Addresses
One of the main enhancements of BGP4 over BGP3 is Classless Interdomain Routing (CIDR). CIDR or supernetting is a new way of looking at IP addresses. There is no notion of classes anymore (class A, B or C).
For example, network 192.213.0.0 which used to be an illegal class C network is now a legal supernet represented by 192.213.0.0/16 where the 16 is the number of bits in the subnet mask counting from the far left of the IP address. This is similar to 192.213.0.0 255.255.0.0.
Aggregates are used to minimize the size of routing tables. Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. In the example below, RTB is generating network 160.10.0.0. We will configure RTC to propagate a supernet of that route 160.0.0.0 to RTA.
RTB#
router bgp 200
neighbor 3.3.3.1 remote−as 300
network 160.10.0.0
#RTC
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
network 170.10.0.0
aggregate−address 160.0.0.0 255.0.0.0
RTC will propagate the aggregate address 160.0.0.0 to RTA.
Aggregate CommandsThere is a wide range of aggregate commands. It is important to understand how each one works in order to have the desired aggregation behavior.
The first command is the one used in the previous example:
aggregate−address address mask
This will advertise the prefix route, and all of the more specific routes. The command aggregate−address 160.0.0.0 will propagate an additional network 160.0.0.0 but will not prevent 160.10.0.0 from being also propagated to RTA. The outcome of this is that both networks 160.0.0.0 and 160.10.0.0 have been propagated to RTA. This is what we mean by advertising the prefix and the more specific route.
Please note that you can not aggregate an address if you do not have a more specific route of that address in the BGP routing table.
For example, RTB can not generate an aggregate for 160.0.0.0 if it does not have a more specific entry of 160.0.0.0 in its BGP table. The more specific route could have been injected into the BGP table via incoming updates from other ASs, from redistributing an IGP or static into BGP or via the network command (network 160.10.0.0).
In case we would like RTC to propagate network 160.0.0.0 only and NOT the more specific route then we would have to use the following:
aggregate−address address mask summary−only
This will a advertise the prefix only; all the more specific routes are suppressed.
The command aggregate 160.0.0.0 255.0.0.0 summary−only will propagate network 160.0.0.0 and will suppress the more specific route 160.10.0.0.
Please note that if we are aggregating a network that is injected into our BGP via the network statement (ex: network 160.10.0.0 on RTB) then the network entry is always injected into BGP updates even though we are using "the aggregate summary−only" command. The upcoming CIDR example discusses this situation.
aggregate−address address mask as−set
This advertises the prefix and the more specific routes but it includes as−set information in the path information of the routing updates.
aggregate 129.0.0.0 255.0.0.0 as−set
This command will be discussed in an example by itself in the following sections.
In case we would like to suppress more specific routes when doing the aggregation we can define a route map and apply it to the aggregates. This will allow us to be selective about which more specific routes to suppress.
aggregate−address address−mask suppress−map map−name
This advertises the prefix and the more specific routes but it suppresses advertisement according to a route−map. In the previous diagram, if we would like to aggregate 160.0.0.0 and suppress the more specific route 160.20.0.0 and allow 160.10.0.0 to be propagated, we can use the following route map:
route−map CHECK permit 10
match ip address 1
access−list 1 permit 160.20.0.0 0.0.255.255
access−list 1 deny 0.0.0.0 255.255.255.255
By definition of the suppress−map, any packets permitted by the access list would be suppressed from the updates.
Then we apply the route−map to the aggregate statement.
RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 remote−as 100
network 170.10.0.0
aggregate−address 160.0.0.0 255.0.0.0 suppress−map CHECK
Another variation is the:
aggregate−address address mask attribute−map map−name
This allows us to set the attributes (such as metric) when aggregates are sent out. The following route map when applied to the aggregate attribute−map command will set the origin of the aggregates to IGP.
route−map SETMETRIC
set origin igp
aggregate−address 160.0.0.0 255.0.0.0 attribute−map SETORIGIN
CIDR Example 1Request: Allow RTB to advertise the prefix 160.0.0.0 and suppress all the more specific routes.
The problem here is that network 160.10.0.0 is local to AS200, meaning AS200 is the originator of 160.10.0.0. You cannot have RTB generate a prefix for 160.0.0.0 without generating an entry for 160.10.0.0 even if you use the aggregate summary−only command because RTB is the originator of 160.10.0.0. There are two solutions to this problem.
The first solution is to use a static route and redistribute it into BGP. The outcome is that RTB will advertise the aggregate with an origin of incomplete (?).
RTB#
router bgp 200
neighbor 3.3.3.1 remote−as 300
redistribute static (This will generate an update for 160.0.0.0 with the origin path as *incomplete*)
ip route 160.0.0.0 255.0.0.0 null0
In the second solution, in addition to the static route we add an entry for the network command. This has the same effect except that the origin of the update will be set to IGP.
RTB#
router bgp 200
network 160.0.0.0 mask 255.0.0.0 (this will mark the update with origin IGP)
neighbor 3.3.3.1 remote−as 300
redistribute static
ip route 160.0.0.0 255.0.0.0 null0
CIDR Example 2 (as−set)AS−SETS are used in aggregation to reduce the size of the path information by listing the AS number only once, regardless of how many times it may have appeared in multiple paths that were aggregated. The as−set aggregate command is used in situations were aggregation of information causes loss of information regarding the path attribute. In the following example RTC is getting updates about 160.20.0.0 from RTA and updates about 160.10.0.0 from RTB. Suppose RTC wants to aggregate network 160.0.0.0/8 and send it to RTD. RTD would not know what the origin of that route is. By adding the aggregate as−set statement we force RTC to generate path information in the form of a set {}. All the path information is included in that set
irrespective of which path came first.
RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote−as 300
RTA#
router bgp 100
network 160.20.0.0
neighbor 2.2.2.1 remote−as 300
Case 1:RTC does not have an as−set statement. RTC will send an update 160.0.0.0/8 to RTD with path information (300) as if the route has originated from AS300.
RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 4.4.4.4 remote−as 400
aggregate 160.0.0.0 255.0.0.0 summary−only
!−− this causes RTC to send RTD updates about 160.0.0.0/8 with no indication
!−− that 160.0.0.0 is actually coming from two different autonomous
!−− systems, this may create loops if RT4 has an entry back into AS100.
Case 2:
RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 4.4.4.4 remote−as 400
aggregate 160.0.0.0 255.0.0.0 summary−only
aggregate 160.0.0.0 255.0.0.0 as−set
!−− causes RTC to send RTD updates about 160.0.0.0/8 with an
!−− indication that 160.0.0.0 belongs to a set {100 200}.
