Chapter 9 - YSU Computer Science & Information Systems
Download
Report
Transcript Chapter 9 - YSU Computer Science & Information Systems
Cabrillo College
Building Scalable Cisco Networks
Ch. 9 Scaling BGP
Rick Graziani, Instructor with Mark McGregor
December 12, 2000
Scaling BGP
BGP’s main strength is its ability to impose
routing policy, primarily through route maps
that manipulate BGP path attributes.
These attributes allow for very precise and
complex policy implementation.
However, as ISPs scale their BGP routing to
include dozens—and even hundreds—of
routers, BGP’s precision can become an
administrative nightmare.
Scaling BGP
The Cisco IOS offers several methods
to make scaling BGP easier on
administrators and on the BGP routers
themselves:
– Route Reflectors –> CCNP Routing Exam
– Route Filtering
– COMMUNITIES Attribute
– Peer Groups
Scaling BGP
Autonomous systems consisting of hundreds
of BGP routers can pose a serious
management problem.
If that many Internal BGP (IBGP) speakers
are configured as a logical full mesh, BGP
operation becomes extremely complex.
– Imagine a network where over 100 neighbor
statements are required just to define the remoteas of each peer!
Route Reflector (RR)
recent addition to BGP (IOS 11.1)
offers an alternative to the logical full-mesh
requirement of IBGP.
acts as a focal point for IBGP sessions.
– Multiple BGP routers can peer with a central point
(the RR), rather than peer with every other router
in a full mesh.
– similar to OSPF’s DR/BDR feature
provides large ISPs with added BGP
scalability.
Route Reflector (RR)
The use of route reflectors is
recommended only for autonomous
systems that support a large internal
BGP mesh, on the order of more than
100 sessions per router.
– introduces processing overhead on the
routers that act as route reflectors
– if configured incorrectly, can cause routing
loops and instability.
Route Reflector (RR)
IBGP routers
are typically
fully meshed.
Route Reflector (RR)
Route Reflector Server
Route Reflector Client
A route reflector
can be configured
so that IBGP routers
don’t have to be in a
full mesh to
completely
exchange routing
information.
Route Reflector (RR)
Route Reflector Server
Route Reflector Client
RTA receives an
update from an
external peer and
passes it on to RTB,
which is configured
as a route reflector
server with two
clients, RTA and
RTC.
RTB will reflect the
update from client
RTA to client RTC.
Route Reflector (RR)
The IBGP peers of a route reflector fall under
two categories:
– clients
– nonclients
A route reflector and its clients form a cluster.
All IBGP peers of the route reflector that are
not part of the cluster are nonclients and must
be fully meshed to all other nonclients and
RR servers.
– Never configure route reflector clients to peer with
IBGP speakers outside their cluster.
Route Reflector (RR)
Clients and nonclients don’t even know that
route reflection is occurring.
To identify clients and clusters, use the
neighbor command, which has the following
syntax, on the route reflector server:
Router(config-router)#neighbor IP-address
route-reflector-client
Route Reflector (RR)
Configuring a RR server:
RTB(config)#router bgp 100
RTB(config-router)#neighbor 1.1.1.1 remote-as 100
RTB(config-router)#neighbor 1.1.1.1 route-reflector-client
RTB(config-router)#neighbor 2.2.2.2 remote-as 100
RTB(config-router)#neighbor 2.2.2.2 route-reflector-client
RTB(config-router)#neighbor 4.4.4.4 remote-as 100
RTB(config-router)#neighbor 7.7.7.7 remote-as 100
RTB(config-router)#neighbor 8.8.8.8 remote-as 200
Route Reflector (RR)
Configuring a RR client:
Doesn’t even know!
RTA(config)#router bgp 100
RTA(config-router)#neighbor 3.3.3.3 remote-as 100
Router C
router bgp
neighbor
neighbor
neighbor
neighbor
100
1.1.1.1
1.1.1.1
2.2.2.2
2.2.2.2
Without a route reflector, the
network shown would require a full
IBGP mesh.
(That is, Router A would have to be
a peer of Router B.)
If Router C is configured as a route
reflector, IBGP peering between
Routers A and B is not required
because Router C will reflect
updates from Router A to Router B
and from Router B to Router A.
remote-as 100
route-reflector-client
remote-as 100
route-reflector-client
Router C
router bgp
neighbor
neighbor
neighbor
neighbor
100
1.1.1.1
1.1.1.1
2.2.2.2
2.2.2.2
The router whose configuration
includes neighbor route-reflectorclient router configuration
commands is the route reflector.
The routers identified by the
neighbor route-reflector-client
commands are clients of the route
reflector.
When considered as a whole, the
route reflector and its clients are
called a cluster.
Other IBGP peers of the route
reflector that are not clients are
called nonclients.
remote-as 100
route-reflector-client
remote-as 100
route-reflector-client
An AS can have more than one
route reflector.
When an AS has more than
one route reflector, each route
reflector treats other route
reflectors as normal IBGP
speakers.
There can be more than one
route reflector in a cluster, and
there can be more than one
cluster in an AS.
The AS is divided into multiple
clusters, with each cluster
having one route reflector.
Each route reflector is
configured as a nonclient peer
of each other route reflector in
a fully meshed topology.
Note: Route reflector clients
should not establish peer
relationships with IBGP
speakers outside of their
cluster.
Routers A, B, and C form a
cluster, and Router C is the
route reflector.
Routers D, E, and F form a
second cluster, of which
Router D is the route reflector.
Router G forms a third cluster.
Note that Routers C, D, and G
are fully meshed and that the
routers within a cluster are not
fully meshed.
Route Reflector (RR)
When the route reflector receives an advertised route, depending
on the neighbor, it does the following (IBGP is not RIP):
– A route from an external BGP (from Router A) speaker is
advertised to all clients and nonclient peers.
– A route from a nonclient peer (from Router G, F, or E) is
advertised to all clients.
– A route from a client (from Router B, C, or D) is advertised to
all clients and nonclient peers.
Hence, the clients need not be fully meshed.
BGP Route Filtering
Route filtering empowers a BGP speaker to
choose what routes to exchange with any of
its BGP peers.
Route filtering is the cornerstone of policy
routing.
– an AS can identify inbound traffic it is willing to
accept by filtering its outbound advertisements
– an AS can control what routes its outbound traffic
uses by specifying the routes to accept from
EBGP neighbors
BGP Route Filtering
Even more precise policies can be defined
via route filters.
For example, BGP routes passing through a
filter can have their attributes manipulated to
affect the best-path decision process.
You can apply route filters to or from a
particular neighbor by using the distributelist command.
BGP Route Filtering
The distribute-list command can be used to filter updates so that
AS3 does not receive transit traffic to network 192.69.10.0 /24.
RTA(config)#router bgp 3
RTA(config-router)#neighbor 172.16.1.2 remote-as 3
RTA(config-router)#neighbor 172.16.20.1 remote-as 1
RTA(config-router)#neighbor 172.16.20.1 distribute-list 1 out
RTA(config-router)#exit
RTA(config)#access-list 1 deny 192.69.10.0 0.0.0.255
RTA(config)#access-list 1 permit any
The distribute-list keyword,
used as part of a BGP neighbor
statement, prevents RTA from
advertising prefix
192.69.10.0/24 to RTC.
The access list is used to
identify the prefixes to be
filtered, and the distribute-list
and out keywords apply the
filter to outgoing updates.
Whereas configuring BGP
neighbor statements to include
the distribute-list keyword is
effective for filtering specific
routes, controlling supernets can
be a bit trickier.
RTA(config)#router bgp 3
RTA(config-router)#neighbor 172.16.1.2 remote-as 3
RTA(config-router)#neighbor 172.16.20.1 remote-as 1
RTA(config-router)#neighbor 172.16.20.1 distribute-list 1 out
RTA(config-router)#exit
RTA(config)#access-list 1 deny 192.69.10.0 0.0.0.255
RTA(config)#access-list 1 permit any
BGP Route Filtering
Configuring a distribute list relies on creating an
access list.
If we use a standard access list, we are afforded
only limited functionality.
What if you want to advertise an aggregate address
of 172.16.0.0 /16, but not the individual subnets
themselves?
A standard access list would not work because it
permits more than is desired, since it filters based on
the network address only.
For example, this access list would permit not only
the 172.16.0.0/16 summary, but also all the
components of that summary as well:
access-list 1 permit 172.16.0.0 0.0.255.255
To restrict the update to the 172.16.0.0/16 summary,
you can use an extended access list.
In the case of a BGP route filter, an extended list
matches, first, the network address, and second, the
subnet mask of the prefix.
Both network and mask are paired with their own
wildcard bitmask, using the following syntax:
Router(config)#access-list number permit|deny
network network-wildcard mask mask-wildcard
Using this configuration, RTA would not send a subnet
route (such as 172.16.0.0 /17 or 172.16.10.0 /24) in an
update to AS1.
RTA(config)#router bgp 3
RTA(config-router)#neighbor
RTA(config-router)#neighbor
RTA(config-router)#neighbor
RTA(config-router)#exit
RTA(config)#access-list 101
255.255.0.0 0.0.0.0
172.16.1.2 remote-as 3
172.16.20.1 remote-as 1
172.16.20.1 distribute-list 101 out
permit ip 172.16.0.0 0.0.255.255
BGP Route Filtering
– Prefix lists
If using an extended access list to accomplish
this type of filtering seems confusing to you,
you are not alone.
Improved user-friendliness was one of the
factors that motivated Cisco to include the ip
prefix-list command in IOS 12.0.
You can use prefix lists as an alternative to
access lists with many BGP route-filtering
commands.
You must define a prefix list before you can
apply it as a route filter.
The Cisco IOS allows a very flexible
configuration procedure, where each
statement can be assigned its own sequence
numbers.
There is an implicit deny at the end of each
prefix list.
To define a prefix list, use the ip prefix-list
command, which has the following syntax:
Router(config)#ip prefix-list list-name [seq seq-value]
deny|permit network/len [ge ge-value] [le le-value]
BGP Route Filtering
Parameter
Description
list-name
Specifies the name of a prefix list.
seq
deny
(Optional) Applies the sequence number to the
prefix list entry being created or deleted.
(Optional) Specifies the sequence number for the
prefix list entry.
Denies access to matching conditions.
permit
Permits access for matching conditions.
network/len
(Mandatory) The network number and length (in
bits) of the network mask.
(Optional) Applies ge-value to the range specified.
seq-value
ge
ge-value
(Optional) Specifies the lesser value of a range
(the "from" portion of the range description).
le
(Optional) Applies le-value to the range specified.
le-value
(Optional) Specifies the greater value of a range
(the "to" portion of the range description).
Example:
RTA(config)#ip prefix-list ELMO permit 172.16.0.0/16
RTA(config)#router bgp 100
RTA(config-router)#neighbor 192.168.1.1 remote-as 200
RTA(config-router)#neighbor 192.168.1.1 prefix-list ELMO out
The real power of the ip prefix-list command is in its
optional parameters.
The keywords ge and le can be used to specify the
range of the prefix length to be matched for prefixes
that are more specific than the network/len value.
The prefix-length range is assumed to be from ge-value
to 32 if only the ge attribute is specified, and from len to
le-value if only the le attribute is specified.
For example, to accept a mask length of up to 24 bits in
routes with the prefix 192.0.0.0/8, (ie.192.1.0.0/16,
192.2.10.0/24) and deny more specific routes
(192.168.10.128/25), use the commands as shown in.
RTA(config)#ip prefix-list GROVER permit 192.0.0.0/8 le 24
RTA(config)#ip prefix-list GROVER deny 192.0.0.0/8 ge 25
The le and ge keywords can be used
together, in the same statement:
RTA(config)#ip prefix-list OSCAR permit
10.0.0.0/8 ge 16 le 24
This list permits all prefixes in the 10.0.0.0/8
address space that have a mask of between
16 and 24 bits.
Examples - The following examples show how a prefix
list can be used.
To deny the default route 0.0.0.0/0:
ip prefix-list abc deny 0.0.0.0/0
To permit the prefix 35.0.0.0/8:
ip prefix-list abc permit 35.0.0.0/8
The following examples show how to specify a group of
prefixes.
To accept a mask length of up to 24 bits in routes
with the prefix 192/8:
ip prefix-list abc permit 192.0.0.0/8 le 24
To deny mask lengths greater than 25 bits in routes
with a prefix of 192/8:
ip prefix-list abc deny 192.0.0.0/8 ge 25
To permit mask lengths from 8 to 24 bits in all
address space:
ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24
To deny mask lengths greater than 25 bits in all
address space:
ip prefix-list abc deny 0.0.0.0/0 ge 25
Each prefix list entry is assigned a sequence number, either by
default or manually by an administrator.
By numbering the prefix list statements, new entries can be
inserted at any point in the list, which is important because
routers test for prefix list matches from lowest sequence number
to highest.
By default, the entries of a prefix-list will have sequence values
of 5,10, 15, etc.
To disable this: RTR(config)# no ip prefix-list sequence-number
Sequence numbers can be created using the command:
Router(config)#ip prefix-list list-name [seq seq-value]
deny|permit network/len [ge ge-value] [le le-value]
RTA#show ip prefix-list
ip prefix-list ELMO: 3 entries
seq 5 deny 0.0.0.0/0
seq 10 permit 172.16.0.0/16
seq 15 permit 192.168.0.0/16 le 24
Communities and Peer Groups
Introduction only.
Not part of CCNP Routing Exam
Objectives.
The COMMUNITIES attribute
A BGP community is a group of destinations that
share some common property.
A community is not restricted to one network or one
AS.
Communities are used to simplify routing policies by
identifying routes based on a logical property rather
than an IP prefix or an AS number.
A BGP speaker can use this attribute in conjunction
with other attributes to control which routes to accept,
prefer, and pass on to other BGP neighbors.
A route map is configured to manipulate community
values.
The COMMUNITIES attribute
NO_EXPORT
– A route carrying this community value should not be
advertised to peers outside a confederation (or the AS if it is
the only AS in the confederation).
NO_ADVERTISE
– A route carrying this community value, when received,
should not be advertised to any BGP peer
Internet
– A route carrying this community value, when received,
should be advertised to all other routers.
Local-as
– A route carrying this community value, when received,
should be advertised to peers within the AS, but not
advertised to peers in an external system.
The COMMUNITIES attribute
The COMMUNITIES attribute
To prevent AS2 from learning the 172.16.65.0/24 route
from AS1, we can configure RTA (AS3) as follows:
To prevent AS2 from learning
the 172.16.65.0/24 route from
AS1, we can configure RTA
(AS3) as follows:
RTA(config)#router bgp 3
RTA(config-router)#no auto-summary
RTA(config-router)#network 172.16.1.0 mask 255.255.255.0
RTA(config-router)#network 172.16.10.0 mask 255.255.255.0
RTA(config-router)#network 172.16.65.0 mask 255.255.255.192
RTA(config-router)#network 172.16.220.0 mask 255.255.255.0
RTA(config-router)#neighbor 172.16.1.2 remote-as 3
RTA(config-router)#neighbor 172.16.1.2 update-source lo0
RTA(config-router)#neighbor 172.16.20.1 remote-as 1
RTA(config-router)#neighbor 172.16.20.1 send-community
RTA(config-router)#neighbor 172.16.20.1 route-map SETCOMMUNITY out
RTA(config-router)#exit
RTA(config)#route-map SETCOMMUNITY permit 10
RTA(config-route-map)#match ip address 1
RTA(config-route-map)#set community no-export
RTA(config)#route-map SETCOMMUNITY permit 20
RTA(config-route-map)#exit
RTA(config)#access-list 1 permit 172.16.65.0 0.0.0.255
RTA has defined a route map
SETCOMMUNITY, and will send that value
toward neighbor 172.16.20.1 (RTC).
Clause 10 of the route map will match on
prefix 172.16.65.0/24 and will set its
COMMUNITIES attribute to NO_EXPORT.
Clause 20 of the route map will enable all
other networks to be passed with no change.
Notice that RTA is configured with the sendcommunity option in the neighbor
statement.
This option is necessary to instruct RTA to
send the assigned community value out to
that neighbor.
Peer Groups
A BGP peer group is a group of BGP
neighbors that share the same update
policies.
Instead of defining the same policies for
each individual neighbor, you can define
a peer group and then assign policies to
the peer group itself.
Peer Groups
Not only do peer groups save you from
having to repetitively configure each BGP
peer, they also save the BGP router itself
from the effort of parsing the policies
sequentially for each neighbor.
With peer groups, the router formulates the
UPDATE once, based on the policies of the
peer group, and then floods the same
UPDATE to all the neighbors that fall within
the group.
Router C
router bgp
neighbor
neighbor
neighbor
out
neighbor
neighbor
neighbor
neighbor
neighbor
300
INTERNALMAP peer-group
INTERNALMAP remote-as 300
INTERNALMAP route-map INTERNAL
INTERNALMAP filter-list 1 out
INTERNALMAP filter-list 2 in
5.5.5.2 peer-group INTERNALMAP
6.6.6.2 peer-group INTERNALMAP
3.3.3.2 peer-group INTERNALMAP
A BGP peer group is a group of
BGP neighbors that share the
same update policies.
Update policies are usually set
by route maps, distribution lists,
and filter lists.
Instead of defining the same
policies for each individual
neighbor, you define a peer
group name and assign policies
to the peer group.
Members of a peer group
inherit all of the configuration
options of the peer group.
Peer group members can also
be configured to override
configuration options if the
options do not affect outgoing
updates.
That is, you can only override
options that are set for incoming
updates.
The preceding configuration
defines the following policies
for the INTERNALMAP peer
group:
A route map named INTERNAL
A filter list for outgoing
updates (filter list 1)
A filter list for incoming
updates (filter list 2)
Router C
router bgp
neighbor
neighbor
neighbor
out
neighbor
neighbor
neighbor
neighbor
neighbor
300
INTERNALMAP peer-group
INTERNALMAP remote-as 300
INTERNALMAP route-map INTERNAL
INTERNALMAP filter-list 1 out
INTERNALMAP filter-list 2 in
5.5.5.2 peer-group INTERNALMAP
6.6.6.2 peer-group INTERNALMAP
3.3.3.2 peer-group INTERNALMAP
The configuration applies the
peer group to all internal
neighbors: Routers E, F, & G.