One of the main enhancements of BGP4 over BGP3 is CIDR (Classless Interdomain Routing). 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.
There 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.
ex: aggregate 129.0.0.0 255.0.0.0 as-set.
This 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 deny 160.20.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255
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 (metric, etc.) 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
Request: 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 i.e. 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.
Solution 1:
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
Solution 2:
In addition to the static route we add an entry for the network command, this will have 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
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})
The next two subjects, "confederation" and "route reflectors" are designed for ISPs who would like to further control the explosion of IBGP peering inside their autonomous systems.
BGP confederation is implemented in order to reduce the IBGP mesh inside an AS. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS by itself will have IBGP fully meshed and has connections to other AS's inside the confederation. Even though these ASs will have EBGP peers to ASs within the confederation, they exchange routing as if they were using IBGP; next hop, metric and local preference information are preserved. To the outside world, the confederation (the group of ASs) will look like a single AS.
To configure a BGP confederation use the following:
bgp confederation identifier autonomous-system
The confederation identifier will be the AS number of the confederation group. The group of ASs will look to the outside world as one AS with the AS number being the confederation identifier.
Peering within the confederation between multiple ASs is done via the following command:
bgp confederation peers autonomous-system [autonomous-system.]
The following is an example of confederation:
Example:
Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also, but we are only interested in the BGP speakers that have EBGP connections to other ASs). If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router, 8 IBGP peers and one EBGP peer to external ASs.
By using confederation we can divide AS500 into multiple ASs: AS50, AS60 and AS70. We give the AS a confederation identifier of 500. The outside world will see only one AS500. For each AS50, AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.
I will show a sample configuration of routers RTC, RTD and RTA. Note that RTA has no knowledge of ASs 50, 60 or 70. RTA has only knowledge of AS500.
RTC# router bgp 50 bgp confederation identifier 500 bgp confederation peers 60 70 neighbor 128.213.10.1 remote-as 50 (IBGP connection within AS50) neighbor 128.213.20.1 remote-as 50 (IBGP connection within AS50) neighbor 129.210.11.1 remote-as 60 (BGP connection with confederation peer 60) neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer 70) neighbor 5.5.5.5 remote-as 100 (EBGP connection to external AS100)
RTD#
router bgp 60
bgp confederation identifier 500
bgp confederation peers 50 70
neighbor 129.210.30.2 remote-as 60 (IBGP connection within AS60)
neighbor 128.213.30.1 remote-as 50(BGP connection with confederation peer
50)
neighbor 135.212.14.1 remote-as 70 (BGP connection with confederation peer
70)
neighbor 6.6.6.6 remote-as 600 (EBGP connection to external AS600)
RTA#
router bgp 100
neighbor 5.5.5.4 remote-as 500 (EBGP connection to confederation 500)
Another solution for the explosion of IBGP peering within an autonomous system is Route Reflectors (RR). As demonstrated in the "Internal BGP" section, a BGP speaker will not advertise a route learned via another IBGP speaker to a third IBGP speaker. By relaxing this restriction a bit and by providing additional control, we can allow a router to advertise (reflect) IBGP learned routes to other IBGP speakers. This will reduce the number of IBGP peers within an AS.
Example:
In normal cases, a full IBGP mesh should be maintained between RTA, RTB and RTC within AS100. By utilizing the route reflector concept, RTC could be elected as a RR and have a partial IBGP peering with RTA and RTB. Peering between RTA and RTB is not needed because RTC will be a route reflector for the updates coming from RTA and RTB.
neighbor
The router with the above command would be the RR and the neighbors pointed at would be the clients of that RR. In our example, RTC would be configured with the "neighbor route-reflector-client" command pointing at RTA and RTB's IP addresses. The combination of the RR and its clients is called a cluster. RTA, RTB and RTC above would form a cluster with a single RR within AS100.
Other IBGP peers of the RR that are not clients are called non-clients.
Example:
An autonomous system can have more than one route reflector; a RR would treat other RRs just like any other IBGP speaker. Other RRs could belong to the same cluster (client group) or to other clusters. In a simple configuration, the AS could be divided into multiple clusters, each RR will be configured with other RRs as non-client peers in a fully meshed topology. Clients should not peer with IBGP speakers outside their cluster.
Consider the above diagram. RTA, RTB and RTC form a single cluster with
RTC being the RR. According to RTC, RTA and RTB are clients and anything
else is a non-client. Remember that clients of an RR are pointed at using
the "neighbor
1- Route from a non-client peer: reflect to all the clients within the
cluster.
2- Route from a client peer: reflect to all the non-client peers and also
to the client peers.
3- Route from an EBGP peer: send the update to all client and non-client
peers.
The following is the relative BGP configuration of routers RTC, RTD and RTB:
RTC# router bgp 100 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-reflector-client neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 8.8.8.8 remote-as 200 RTB# router bgp 100 neighbor 3.3.3.3 remote-as 100 neighbor 12.12.12.12 remote-as 300 RTD# router bgp 100 neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100
As the IBGP learned routes are reflected, it is possible to have the routing information loop. The Route-Reflector scheme has a few methods to avoid this:
1- Originator-id: this is an optional, non transitive BGP attribute that is four bytes long and is created by a RR. This attribute will carry the router-id (RID) of the originator of the route in the local AS. Thus, due to poor configuration, if the routing information comes back to the originator, it will be ignored.
2- Cluster-list: this will be discussed in the next section.
Usually, a cluster of clients will have a single RR. In this case, the cluster will be identified by the router-id of the RR. In order to increase redundancy and avoid single points of failure, a cluster might have more than one RR. All RRs in the same cluster need to be configured with a 4 byte cluster-id so that a RR can recognize updates from RRs in the same cluster.
A cluster-list is a sequence of cluster-ids that the route has passed. When a RR reflects a route from its clients to non-clients outside of the cluster, it will append the local cluster-id to the cluster-list. If this update has an empty cluster-list the RR will create one. Using this attribute, a RR can identify if the routing information is looped back to the same cluster due to poor configuration. If the local cluster-id is found in the cluster-list, the advertisement will be ignored.
In the above diagram, RTD, RTE, RTF and RTH belong to one cluster with both RTD and RTH being RRs for the same cluster. Note the redundancy in that RTH has a fully meshed peering with all the RRs. In case RTD goes down, RTH will take its place. The following are the configuration of RTH, RTD, RTF and RTC:
RTH# router bgp 100 neighbor 4.4.4.4 remote-as 100 neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 9.9.9.9 remote-as 300 bgp route-reflector 10 (This is the cluster-id) RTD# router bgp 100 neighbor 10.10.10.10 remote-as 100 neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 7.7.7.7 remote-as 100 neighbor 3.3.3.3 remote-as 100 neighbor 11.11.11.11 remote-as 400 bgp route-reflector 10 (This is the cluster-id) RTF# router bgp 100 neighbor 10.10.10.10 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 13.13.13.13 remote-as 500 RTC# router bgp 100 neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 route-reflector-client neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 route-reflector-client neighbor 4.4.4.4 remote-as 100 neighbor 7.7.7.7 remote-as 100 neighbor 10.10.10.10 remote-as 100 neighbor 8.8.8.8 remote-as 200
Note that we did not need the cluster command for RTC because only one RR exists in that cluster.
An important thing to note, is that peer-groups were not used in the above configuration. If the clients inside a cluster do not have direct IBGP peers among one another and they exchange updates through the RR, peer-goups should not be used. If peer groups were to be configured, then a potential withdrawal to the source of a route on the RR would be sent to all clients inside the cluster and could cause problems.
The router sub-command bgp client-to-client reflection is enabled by default on the RR. If BGP client-to-client reflection were turned off on the RR and redundant BGP peering was made between the clients, then using peer groups would be alright.
It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. We will call these routers conventional BGP speakers. The route reflector scheme will allow such conventional BGP speakers to coexist. These routers could be either members of a client group or a non-client group. This would allow easy and gradual migration from the current IBGP model to the route reflector model. One could start creating clusters by configuring a single router as RR and making other RRs and their clients normal IBGP peers. Then more clusters could be created gradually.
Example:
In the above diagram, RTD, RTE and RTF have the concept of route reflection. RTC, RTA and RTB are what we call conventional routers and cannot be configured as RRs. Normal IBGP mesh could be done between these routers and RTD. Later on, when we are ready to upgrade, RTC could be made a RR with clients RTA and RTB. Clients do not have to understand the route reflection scheme; it is only the RRs that would have to be upgraded.
The following is the configuration of RTD and RTC:
RTD# router bgp 100 neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 route-reflector-client neighbor 5.5.5.5 remote-as 100 neighbor 5.5.5.5 route-reflector-client neighbor 3.3.3.3 remote-as 100 neighbor 2.2.2.2 remote-as 100 neighbor 1.1.1.1 remote-as 100 neighbor 13.13.13.13 remote-as 300 RTC# router bgp 100 neighbor 4.4.4.4 remote-as 100 neighbor 2.2.2.2 remote-as 100 neighbor 1.1.1.1 remote-as 100 neighbor 14.14.14.14 remote-as 400
When we are ready to upgrade RTC and make it a RR, we would remove the IBGP full mesh and have RTA and RTB become clients of RTC.
We have mentioned so far two attributes that are used to prevent potential information looping: the originator-id and the cluster-list.
Another means of controlling loops is to put more restrictions on the set clause of out-bound route-maps.
The set clause for out-bound route-maps does not affect routes reflected to IBGP peers.
More restrictions are also put on the nexthop-self which is a per neighbor configuration option. When used on RRs the nexthop-self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed.
Route dampening (introduced in Cisco IOS version 11.0) is a mechanism to minimize the instability caused by route flapping and oscillation over the network. To accomplish this, criteria are defined to identify poorly behaved routes. A route which is flapping gets a penalty for each flap (1000). As soon as the cumulative penalty reaches a predefined "suppress-limit", the advertisement of the route will be suppressed. The penalty will be exponentially decayed based on a preconfigured "half-time". Once the penalty decreases below a predefined "reuse-limit", the route advertisement will be un-suppressed.
Routes, external to an AS, learned via IBGP will not be dampened. This is to avoid the IBGP peers having higher penalty for routes external to the AS.
The penalty will be decayed at a granularity of 5 seconds and the routes will be un-suppressed at a granularity of 10 seconds. The dampening information is kept until the penalty becomes less than half of "reuse-limit" , at that point the information is purged from the router.
Initially, dampening will be off by default. This might change if there is a need to have this feature enabled by default. The following are the commands used to control route dampening:
bgp dampening (will turn on dampening).
no bgp dampening (will turn off dampening).
bgp dampening <half-life-time> (will change the half-life-time).
A command that sets all parameters at the same time is:
bgp dampening <half-life-time> <reuse> <suppress> <maximum-suppress-time>
<half-life-time> (range is 1-45 min, current default is
15 min).
<reuse-value> (range is 1-20000, default is 750).
<suppress-value> (range is 1-20000, default is 2000).
<max-suppress-time> (maximum duration a route can be suppressed,
range is 1-255, default is 4 times half-life-time).
Example:
RTB# hostname RTB interface Serial0 ip address 203.250.15.2 255.255.255.252 interface Serial1 ip address 192.208.10.6 255.255.255.252 router bgp 100 bgp dampening network 203.250.15.0 neighbor 192.208.10.5 remote-as 300 RTD# hostname RTD interface Loopback0 ip address 192.208.10.174 255.255.255.192 interface Serial0/0 ip address 192.208.10.5 255.255.255.252 router bgp 300 network 192.208.10.0 neighbor 192.208.10.6 remote-as 100
RTB is configured for route dampening with default parameters. Assuming the EBGP link to RTD is stable, RTB's BGP table would look like this:
RTB#sh ip bgp BGP table version is 24, local router ID is 203.250.15.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.208.10.0 192.208.10.5 0 0 300 i *> 203.250.15.0 0.0.0.0 0 32768 i
In order to simulate a route flap, I will do a "clear ip bgp 192.208.10.6" on RTD. RTB's BGP table will look like this:
RTB#sh ip bgp BGP table version is 24, local router ID is 203.250.15.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path h 192.208.10.0 192.208.10.5 0 0 300 i *> 203.250.15.0 0.0.0.0 0 32768 i
The BGP entry for 192.208.10.0 has been put in a "history" state. Which means that we do not have a best path to the route but information about the route flapping still exists.
RTB#sh ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 25
Paths: (1 available, no best path)
300 (history entry)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, external
Dampinfo: penalty 910, flapped 1 times in 0:02:03
The route has been given a penalty for flapping but the penalty is still below the "suppress limit" (default is 2000). The route is not yet suppressed. If the route flaps few more times we will see the following:
RTB#sh ip bgp
BGP table version is 32, local router ID is 203.250.15.2 Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal Origin codes:
i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*d 192.208.10.0 192.208.10.5 0 0 300 i
*> 203.250.15.0 0.0.0.0 0 32768 i
RTB#sh ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 32
Paths: (1 available, no best path)
300, (suppressed due to dampening)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, valid, external
Dampinfo: penalty 2615, flapped 3 times in 0:05:18 , reuse in 0:27:00
The route has been dampened (suppressed). The route will be reused when the penalty reaches the "reuse value", in our case 750 (default).The dampening information will be purged when the penalty becomes less than half of the reuse-limit, in our case (750/2=375). The Following are the commands used to show and clear flap statistics information:
show ip bgp flap-statistics
(displays flap statistics for all the paths)
show ip bgp-flap-statistics regexp <regexp>
(displays flap statistics for all paths that match the regexp)
show ip bgp flap-statistics filter-list <list>
(displays flap statistics for all paths that pass the filter)
show ip bgp flap-statistics A.B.C.D m.m.m.m
(displays flap statistics for a single entry)
show ip bgp flap-statistics A.B.C.D m.m.m.m longer-prefixes
(displays flap statistics for more specific entries)
show ip bgp neighbor [dampened-routes] | [flap-statistics]
(displays flap statistics for all paths from a neighbor)
clear ip bgp flap-statistics
(clears flap statistics for all routes)
clear ip bgp flap-statistics regexp <regexp>
(clears flap statistics for all the paths that match the regexp)
clear ip bgp flap-statistics filter-list <list> (clears flap statistics for all the paths that pass the filter)
clear ip bgp flap-statistics A.B.C.D m.m.m.m
(clears flap statistics for a single entry)
clear ip bgp A.B.C.D flap-statistics (clears flap statistics for all paths from a neighbor)
Now that we are familiar with the BGP attributes and terminology, the following list indicates how BGP selects the best path for a particular destination. Remember that we only select one path as the best path. We put that path in our routing table and we propagate it to our BGP neighbors.
Path selection is based on the following:
1-If NextHop is inaccessible do not consider it.
2-Prefer the largest Weight.
3-If same weight prefer largest Local Preference.
4-If same Local Preference prefer the route that the specified router
has originated.
5-If no route was originated prefer the shorter AS path.
6-If all paths are external prefer the lowest origin code (IGP<EGP<INCOMPLETE).
7-If origin codes are the same prefer the path with the lowest MED.
8-If path is the same length prefer the External path over Internal.
9-If IGP synchronization is disabled and only internal path remain prefer
the path through the closest IGP neighbor.
10-Prefer the route with the lowest ip address value for BGP
router ID.
The following is a design example that is intended to show the configuration and routing tables as they actually appear on the Cisco routers.
(End of section 4)