Transcript BGP-Part 3
CCNP – Advanced Routing Ch. 9 Scaling BGP 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 – 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. 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. 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 routereflector-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 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 (must be fully meshed with other nonclients). – 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 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 distribute-list command. BGP Route Filtering RTA filters update to RTC so it does not include the 192.69.10.0/24 network. 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 filters update to RTC so it does not include the 192.69.10.0/24 network. 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 RTA filters update to RTC so it does not include the 192.69.10.0/24 network. 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 seqvalue] 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 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 X 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: X 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(config)#router bgp 3 RTA(config-router)#neighbor 172.16.20.1 sendcommunity RTA(config-router)#neighbor 172.16.20.1 routemap 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 X 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 send-community 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. 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 The configuration applies the peer group to all internal neighbors: Routers E, F, & G. 300 INTERNALMAP peer-group INTERNALMAP remote-as 300 The end result on this router is that the neighbors 5.5.5.2, 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 6.6.6.2, and 3.3.3.2 all get configurations which are applied to INTERNALMAP, including the remote-as, routemap and the filter-list statements.