[ Pobierz całość w formacie PDF ]
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.
Cisco - BGP Case Studies
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
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.
Cisco - BGP Case Studies
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:
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.
Let's look at 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)
Cisco - BGP Case Studies
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)
Route Reflectors
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.
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 route-reflector-client
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.
Cisco - BGP Case Studies
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
[ Pobierz całość w formacie PDF ]