|
|
< Day Day Up > |
|
Implementing Route-Reflectors in MPLS VPN NetworksBGP route-reflectors (RRs) are considered a scalability tool that allows network designers to steer away from BGP full mesh requirements. Classical iBGP split horizon rules mandate that updates received on eBGP sessions should be forwarded on all iBGP and eBGP sessions, but updates received on an iBGP session should be forwarded only on all eBGP sessions. This requires the BGP edge or boundary router (ASBR) to send updates to all other BGP-enabled routers in its own AS directly through individual iBGP sessions to each BGP router. RRs modify the iBGP split horizon rule and allow a specific router, under certain conditions, to forward all incoming iBGP updates to an outgoing iBGP session. This router is called a route-reflector. Figure 6-5 shows a typical MPLS VPN-based network where, in the absence of RRs, whenever a new PE is introduced, each existing PE in the service provider network will require an additional BGP neighbor command associating it to the new PE. In BGP, updates received by a peer in an AS are not allowed to be forwarded to another peer within the same AS. Therefore, a BGP network must be fully meshed, with all peers adjacent to one another, as far as BGP routing updates are concerned. If the number of PEs becomes substantial enough to make this operation impractical (that is, adding neighbor commands in every PE), BGP RRs are recommended. RRs obviate the need to fully mesh the BGP peers and avoid the addition of neighbor commands to each PE. With RRs, the PEs would only require neighbors defined for each RR. Any updates, including VRF information, would be sent to the RR alone. The RRs are then responsible for propagating information received from PEs to all other PEs. Each time a new Edge LSR or PE is added, a neighbor statement pointing to the RR needs to be added on the new PE router, and on the RR, a neighbor statement pointing to the PE must be added. Figure 6-5. RRs
RRs are also useful in the event of a route change in the customer network. Without RRs, the PE that locally terminates that portion of the customer network would have to update every PE peer participating in that VPN. RRs, therefore, help remove the burden of BGP updates from the PE. RR Deployment MethodsIn MPLS-based VPN networks, RRs can be deployed in several ways. Option 1—Using PE Router as VPNv4 RRIn this option, the PE device is used as a RR. This type of setup is not recommended due to additional constraints of memory and CPU imposed on the PE router, which is handling both the functions of providing services to client edge routers as well as reflecting routes to several other PEs in the same MPLS domain. Figure 6-6 provides an illustration of PE routers, PE6-RR1 and PE7-RR2, which are being used as VPNv4 RRs. Figure 6-6. PE Routers as RRs
Option 2—Using P Router as IPv4 and VPNv4 RRIn this scenario, the provider (P) router is used both as an IPv4 and VPNv4 RR. The P router, in this case, handles not only the function of route reflection for IPv4 and VPNv4 routes, but also performs data forwarding operations for IPv4 traffic and VPNv4 traffic. Figure 6-7 shows a scenario in which the P routers, P1-RR1 and P2-RR2, are IPv4 RRs for the ISP's IPv4 network, which provides Internet services for Customer C and D. At the same time, those RRs serve as IPv4 and VPNv4 RR for the MPLS-enabled network, routing VPNv4 prefixes for VPNA and VPNB sites, as well as providing Internet services to those VPN sites. This scenario may not scale well in large MPLS VPN environments due to memory and CPU constraints imposed on the RR that not only provides IPv4 and VPNv4 routing services but also data forwarding functionality. Figure 6-7. P Routers as IPv4 and VPNv4 RRs
Option 3—Using P Router as RR Only for VPNv4In this scenario, the P router is used only as a VPNv4 RR. The P router will forward both control and data plane forwarding for VPN sites only. Figure 6-8 shows the scenario in which RRs P1-RR1 and P2-RR2 are used for reflecting only VPNv4 routes and forwarding all data traffic between VPN client sites. This implementation can be used in large-scale MPLS VPN environments in which the provider network wants to isolate IPv4 functionality on the VPNv4 RR; however, this can increase the provider's cost to maintain a dedicated RR for IPv4 routing and a dedicated RR for VPNv4 routes. Figure 6-8. P Router Reflecting Only VPNv4 Routes
Option 4—Dedicated Router as RR for IPv4 and VPNv4In this scenario, an additional router performs the function of reflecting IPv4 and VPNv4 routes. The router does not perform any data forwarding functions. Figure 6-9 highlights the scenario in which P1-RR1 and P2-RR2 perform the function of reflecting VPNv4 and IPv4 routes and not that of data forwarding. This also increases the provider's operational costs because the provider has to dedicate routers as RRs for IPv4 and VPNv4 prefixes as well as ensure their PE routers have physical connectivity with each other for data forwarding functionality or are connected to a dedicated P router, which will perform data forwarding functionality. Figure 6-9. Dedicated IPv4 and VPNv4 RR for Control Plane Functionality
Option 5—Dedicated Router as RR for Only VPNv4In this approach, the RR performs the task of reflecting only VPNv4 routes and not that of data forwarding. This approach also requires a dedicated router that can handle this functionality. Figure 6-10 shows an MPLS environment adopting this approach. RR1 and RR2 reflect only VPNv4 routes and perform no data forwarding function. Using this approach, considerable savings in CPU and performance improvements can be realized but at the cost of additional routers providing provider router functionality and increased cost in providing physical connectivity between PE to P routers. Figure 6-10. Dedicated VPNv4 RR for Control Plane Functionality
Option 6—Partitioned RRsThis scenario is used primarily in large-scale environments in which using the dedicated VPNv4 RR does not scale to the demands of a large provider carrying a large number of VPNv4 prefixes. In this approach, as shown in Figure 6-11, RR1 reflects VPNv4 routes only for VPNA, and RR2 reflects VPNv4 routes only for VPNB. There are no mandatory requirements that the RR in this approach should not perform the data forwarding function. However, the decision to forward data traffic or not should be made after evaluating future network growth. The drawback would be the additional cost of maintaining separate routers for performing P router functionality and the cost of connectivity between PE and P routers. The complexity of the network could increase with the use of partitioned RRs. Figure 6-11. Route Partitioning Using RRs
Configuring P Router as RR Only for VPNv4 Prefixes (Option 3)The objective of this configuration scenario is to demonstrate the RR configuration when the P router serves as an RR and performs both the control plane and data forwarding functionality for VPNv4 prefixes only (option 3). To implement this configuration, the network topology shown in Figure 6-1 is used except that P1-AS1-RR (for this configuration, the scenario hostname for P1-AS1 in Figure 6-1 is P1-AS1-RR) is configured as a RR peering with PE routers PE1-AS1 and PE2-AS1. PE routers will be configured to peer with the RRs only. Configuration Flowchart for P Router as RR for Only VPNv4 PrefixesThe configuration flowchart for implementing this scenario is shown in Figure 6-12. Figure 6-12. Configuration Flowchart to Implement RR
Configuration Step for PE Routers PE1-AS1 and PE2-AS1To configure BGP peering on the PE routers PE1-AS1 and PE2-AS1 with the RR P1-AS1-RR, BGP routing on the PE routers must be configured and BGP neighbors activated. Enable global BGP routing on PE1-AS1 and PE2-AS1 routers and activate the BGP RR neighbors on the PE routers for VPNv4 route exchange only. Example 6-10 shows the configuration for defining P1-AS1-RR as the BGP neighbor on the PE router PE1-AS1. Use the same steps to configure PE2-AS1. Example 6-10. Configure BGP Routing on PE Routers and Activate BGP NeighborsPE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#neighbor 10.10.10.100 remote-as 1 PE1-AS1(config-router)#neighbor 10.10.10.100 update-source Loopback0 PE1-AS1(config-router)#no bgp default ipv4-unicast PE1-AS1(config-router)# address-family ipv4 PE1-AS1(config-router-af)#no neighbor 10.10.10.100 activate PE1-AS1(config-router-af)#address-family vpnv4 PE1-AS1(config-router-af)#neighbor 10.10.10.100 activate PE1-AS1(config-router-af)#neighbor 10.10.10.100 send-community extended PE1-AS1(config-router-af)#exit-address-family Configuration Step for P Router as RR for Only VPNv4 PrefixesTo configure the RR P1-AS1-RR, configure the P router as VPNv4 RR. Enable global BGP routing on the P router, P1-AS1-RR. Example 6-11 shows the configuration procedure to enable global BGP routing, define the BGP relationship with PE routers PE1-AS1 and PE2-AS1, activate them for VPNv4 route-exchange, and configure the PE routers as clients for the route-reflection process. Example 6-11. Configure Provider Router as VPNv4 RRP1-AS1-RR(config)#router bgp 1 P1-AS1-RR(config-router)#neighbor 10.10.10.101 remote-as 1 P1-AS1-RR(config-router)#neighbor 10.10.10.101 update-source Loopback0 P1-AS1-RR(config-router)#neighbor 10.10.10.102 remote-as 1 P1-AS1-RR(config-router)#neighbor 10.10.10.102 update-source Loopback0 P1-AS1-RR(config-router)#no bgp default ipv4-unicast P1-AS1-RR(config-router)#address-family ipv4 P1-AS1-RR(config-router-af)#no neighbor 10.10.10.101 activate P1-AS1-RR(config-router-af)#no neighbor 10.10.10.102 activate P1-AS1-RR(config-router-af)#exit P1-AS1-RR(config-router)#address-family vpnv4 P1-AS1-RR(config-router-af)#neighbor 10.10.10.102 route-reflector-client P1-AS1-RR(config-router-af)#neighbor 10.10.10.102 route-reflector-client P1-AS1-RR(config-router-af)#neighbor 10.10.10.101 activate P1-AS1-RR(config-router-af)#neighbor 10.10.10.102 activate CE ConfigurationsRefer to Example 6-4 for CE configurations. P1-AS1-RR, PE1-AS1, and PE2-AS1 Final Configuration for MPLS VPN Using RRsExample 6-12 outlines the final relevant configurations for PE1-AS1, PE2-AS1, and P1-AS1-RR implementing MPLS VPN for sites using the P router as a VPNv4 RR. Refer to Example 6-5 for the remaining configurations pertaining to each router. Example 6-12. Relevant Configurationshostname PE1-AS1 ! !For the remainder configuration refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended exit-address-family __________________________________________________________________________ hostname PE2-AS1 ! !For the remainder configuration refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended exit-address-family __________________________________________________________________________ hostname P1-AS1-RR ! !For the remainder configuration refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 route-reflector-client exit-address-family Verifying MPLS VPNs Using RRsThe steps to verify MPLS VPNs using RRs are
Partitioned RRsExisting RRs carrying VPNv4 routes will not scale to meet the demands of continually expanding MPLS VPN networks. Large MPLS VPN providers might have to resort to partitioning or segregating VPNv4 prefixes based on route targets or any other BGP attributes, for example, standard BGP communities, to accommodate a large number of VPNv4 routes. Figure 6-13 shows a basic MPLS VPN network in which P1-RR accepts only VPN-A VPNv4 prefixes with a route-target value of 1:100, and P2-RR accepts only VPN-B VPNv4 prefixes with a route-target value of 1:200. Figure 6-13. Route Partitioning
In order to receive all the routing information required for proper operation, all PE routers may need to have BGP sessions with all RRs. Further resource optimization can be achieved if the PE routers peer only with the relevant RRs. This deployment, although optimal, may lead to the providers incurring additional management and configuration complexity. Partitioning of RRs can be achieved by configuring
As an alternate solution, the VPNv4 routing information can also be partitioned based on standard BGP communities. In the first design, outbound updates on the PE routers are filtered. Because the PE routers have to attach standard BGP community to the VPNv4 routes, the filtering of outbound VPNv4 routing updates based on the standard BGP community does not represent an additional maintenance burden. The second design is to attach standard BGP communities to the VPNv4 routes on the PE routers and perform the filtering on the RRs, either in the inbound or outbound direction. This design achieves a clear separation of the marking of customer routes from the partitioning of VPNv4 routing information. Inbound filtering is preferred, because it reduces the volume of VPNv4 routing information on RRs. RR Partitioning Using BGP Inbound Route-Target FiltersFigure 6-14 is similar to Figure 6-1 except that a second RR (P2-AS1-RR2) has been added to the topology. P1-AS1-RR1 and P2-AS1-RR2 perform both control and data plane functionality for VPNA and VPNB sites. As previously demonstrated, the configured route targets on PE1-AS1 and PE2-AS1 for VPNA and VPNB are 1:100 and 1:200, respectively. To demonstrate route partitioning, P1-AS1-RR1 will accept routes only for VPN-A (Cust_A) and P2-AS1-RR2 will accept routes only for VPN-B (Cust_B). Figure 6-14. MPLS Network Implementing Route Partitioning Using Inbound Route-Target Filters
Figure 6-15 shows the flowchart to configure route partitioning using inbound route-target filters on RRs. Figure 6-15. Configuration Steps for Partitioning Routes Using Inbound Route-Target Filters
Route-Partitioning Configuration Steps on the P Routers P1-RR and P2-RRThe configurations steps for the RRs are the same as those demonstrated in the section "Configuring P Router as RR Only for VPNv4 Prefixes (Option 3)." In addition to those steps, the following steps are required to configure route partitioning on the RRs:
PE1-AS1, PE2-AS1, P1-AS1-RR1, and P2-AS1-RR2 Final Configuration for Partitioned RRsExample 6-18 shows only the additional configurations on PE1-AS1, PE2-AS1, and P1-AS1-RR1. The complete configuration is shown for P2-AS1-RR2. For the remaining configurations, refer to Example 6-5. Example 6-18. PE1-AS1, PE2-AS1, P1-AS1-RR1, and P2-AS1-RR2 Final Configurations for Partitioned RRshostname PE1-AS1 ! !Refer to example 6-5 for the rest of the configuration router bgp 1 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family __________________________________________________________________________ hostname PE2-AS1 ! !Refer to example 6-5 for the rest of the configuration router bgp 1 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family __________________________________________________________________________ hostname P1-AS1-RR1 ! !Refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended neighbor 10.10.10.103 route-reflector-client bgp rr-group VPNA exit-address-family ! ip extcommunity-list standard VPNA permit rt 1:100 __________________________________________________________________________ hostname P2-AS1-RR2 ! mpls ldp router-id Loopback0 ! interface Loopback0 ip address 10.10.10.103 255.255.255.255 ! interface Serial0/0 ip address 10.10.10.10 255.255.255.252 mpls ip ! interface Serial1/0 ip address 10.10.10.14 255.255.255.252 mpls ip ! interface Serial2/0 ip address 10.10.10.18 255.255.255.252 mpls ip ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no bgp default ipv4-unicast neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended neighbor 10.10.10.100 route-reflector-client bgp rr-group VPNB exit-address-family ! ip extcommunity-list standard VPNB permit rt 1:200 Verifying Partitioned RRsThe steps to verify partitioned RRs are
RR Partitioning Using Standard BGP CommunitiesThis configuration scenario demonstrates RR partitioning using standard BGP communities. The same topology as what's shown in Figure 6-14 is used for this scenario. The objective is to ensure that P1-AS1-RR1 will accept routes only for VPNA (Cust_A) and P2-AS1-RR2 will accept routes only for VPNB (Cust_B). Figure 6-16 shows the steps to configure route partitioning using standard BGP communities. Figure 6-16. Configuration Flowchart for Partitioning Routes Using Standard BGP Communities
Configuration Steps on the PE Routers PE1-AS1 and PE2-AS1On the PE routers, set the community for the CE1-A and CE1-B prefixes on PE1-AS1 and for CE2-A and CE2-B on PE2-AS1. Example 6-21 shows the additional relevant configuration on PE1-AS1. Repeat the same steps on PE2-AS1. Example 6-21. PE1-AS1 ConfigurationPE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#address-family vpnv4 PE1-AS1(config-router-af)#neighbor 10.10.10.100 send-community both PE1-AS1(config-router-af)#neighbor 10.10.10.100 route-map allow1 out PE1-AS1(config-router-af)#neighbor 10.10.10.103 send-community both PE1-AS1(config-router-af)#neighbor 10.10.10.103 route-map allow2 out PE1-AS1(config-router-af)#exit-address-family PE1-AS1(config-router)#exit PE1-AS1(config)#ip bgp-community new-format PE1-AS1(config)#access-list 10 permit 172.16.10.0 0.0.0.255 PE1-AS1(config)#access-list 20 permit 192.168.10.0 0.0.0.255 PE1-AS1(config)#route-map allow2 permit 10 PE1-AS1(config-route-map)# match ip address 20 PE1-AS1(config-route-map)# set community 1:200 PE1-AS1(config-route-map)#exit PE1-AS1(config)#route-map allow1 permit 10 PE1-AS1(config-route-map)# match ip address 10 PE1-AS1(config-route-map)# set community 1:100 Configuration Steps on the P Routers P1-AS1-RR1 and P2-AS1-RR2The configuration steps for the RRs are the same as demonstrated in the section "Configuration Step for PE Routers PE1-AS1 and PE2-AS1." In addition to that step, the following steps are required to configure route partitioning on the RRs using standard BGP communities:
PE1-AS1 and PE2-AS1 Final Configuration for Partitioned RRsExample 6-24 shows the relevant configuration on the PE1-AS1, PE2-AS1, and P routers. Example 6-24. Relevant Configuration on the PE1-AS1, PE2-AS1, and P Routers!PE1-AS1 Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community both neighbor 10.10.10.100 route-map allow1 out neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community both neighbor 10.10.10.103 route-map allow2 out exit-address-family ! ip bgp-community new-format ! access-list 10 permit 172.16.10.0 0.0.0.255 access-list 20 permit 192.168.10.0 0.0.0.255 ! route-map allow1 permit 10 match ip address 10 set community 1:100 ! route-map allow2 permit 10 match ip address 20 set community 1:200 ________________________________________________________________ !PE2-AS1 Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community both neighbor 10.10.10.100 route-map allow1 out neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community both neighbor 10.10.10.103 route-map allow2 out exit-address-family ! ip bgp-community new-format ! access-list 10 permit 172.16.20.0 0.0.0.255 access-list 20 permit 192.168.20.0 0.0.0.255 ! route-map allow1 permit 10 match ip address 10 set community 1:100 ! route-map allow2 permit 10 match ip address 20 set community 1:200 ________________________________________________________________ !P1-RR Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.101 route-map allow-VPNA in neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.102 route-map allow-VPNA in neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community both neighbor 10.10.10.103 route-map allow-VPNA in exit-address-family ! ip bgp-community new-format ip community-list 1 permit 1:100 ! route-map allow-VPNA permit 10 match community 1 ________________________________________________________________ !P2-RR Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community both neighbor 10.10.10.100 route-map allow-VPNB in neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.101 route-map allow-VPNB in neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.102 route-map allow-VPNB in exit-address-family ! ip bgp-community new-format ip community-list 1 permit 1:200 ! route-map allow-VPNB permit 10 match community 1 Verifying Partitioned RRs Using Standard BGP CommunitiesThe steps to verify partitioned RRs using standard BGP communities are
RRs and Peer GroupsA BGP peer group is a collection of BGP neighbors that share the same outbound policies. Instead of configuring each neighbor with the same policy individually, peer groups allow the user to group the policies that can be applied to individual peers. Using BGP peer groups reduces the amount of system resources (CPU and memory) used by allowing the routing table to be checked only once and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. The reduction in system resources, however, depends on the number of peer group members, the number of prefixes in the table, and the number of prefixes that are being advertised or being imported. The other benefit of peer groups is also to help in simplifying the BGP configuration. Figure 6-17 shows an MPLS VPN network where P1-AS1-RR and P2-AS1-RR are RRs for PE1-AS1 and PE2-AS1 PE routers. PE1-AS1 and PE2-AS1 are both members of peer group group1 and group2 on P1-AS1-RR and P2-AS1-RR, respectively. Figure 6-17. PE1-AS1 and PE2-AS1 Members of Peer Group group1 and group2
Figure 6-18 shows the steps to configure peer groups in a RR-based MPLS VPN network. Figure 6-18. Configuration Steps for RRs with Peer Groups
Configuring Peer Groups on P Routers P1-AS1-RR1 and P2-AS1-RR2The steps to configure peer groups on P routers P1-AS1-RR1 and P2-AS1-RR2 are
P1-AS1-RR1 and P2-AS1-RR2 Final RR Configurations with Peer GroupsExample 6-33 shows the relevant configuration on P1-AS1-RR1 and P2-AS1-RR2. Example 6-33. P1-AS1-RR1 and P2-AS1-RR2 Configuration!P1-AS1-RR1 Router Configuration router bgp 1 no bgp default ipv4-unicast neighbor group1 peer-group neighbor group1 remote-as 1 neighbor group1 update-source Loopback0 neighbor 10.10.10.101 peer-group group1 neighbor 10.10.10.102 peer-group group1 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor group1 send-community extended neighbor group1 route-reflector-client neighbor 10.10.10.101 activate neighbor 10.10.10.102 activate neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family ________________________________________________________________ !P2-AS1-RR2 Router Configuration router bgp 1 no bgp default ipv4-unicast neighbor group2 peer-group neighbor group2 remote-as 1 neighbor group2 update-source Loopback0 neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.101 peer-group group2 neighbor 10.10.10.102 peer-group group2 ! address-family ipv4 no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor group2 send-community extended neighbor group2 route-reflector-client neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended neighbor 10.10.10.101 activate neighbor 10.10.10.102 activate exit-address-family Verifying Peer Groups and RRsThe steps to verify peer groups and RRs are
BGP ConfederationsBGP confederation is another BGP scalability tool that can reduce the iBGP mesh inside an AS. In BGP confederation, an AS is divided into multiple autonomous systems or sub autonomous systems, and these are assigned to a single confederation. Each sub AS will be fully iBGP meshed. Each sub AS will also have connections to other autonomous systems inside the confederation. Each sub AS will be eBGP peered with other sub autonomous systems. Although the sub autonomous systems will be eBGP peered to other autonomous systems within the confederation, they will exchange routing as if they were using iBGP; next hop, metric, and local preference information will be preserved. To the outside world, the confederation (the group of autonomous systems) will look like a single AS. Figure 6-19 shows a provider network, AS 1, which is divided into multiple sub autonomous systems, AS 100, AS 101, and AS 102. Each sub AS is iBGP fully meshed, and there is eBGP peering between the sub autonomous systems. To BGP CE neighbors, the confederation (the group of autonomous systems, AS 100, 101, and 102) will look like a single BGP AS 1. Figure 6-19. BGP Confederation
Figure 6-20 shows an MPLS VPN network in which BGP AS 1 is divided into three sub autonomous systems, AS 100, AS 101, and AS 102. P1-AS1, PE1-AS1, and PE2-AS1 are in AS 100, AS 101, and AS 102. Figure 6-20. MPLS VPN Network Using BGP Confederations
Configuration Flowchart to Implement BGP ConfederationsFigure 6-21 shows the configuration flowchart to implement BGP confederation in the provider core. Figure 6-21. Configuration Flowchart to Implement BGP Confederations
Configuring BGP Confederation for P Routers PE1-AS1, PE2-AS1, and P1-AS1The steps to configure BGP confederation for the topology shown in Figure 6-20 are as follows. The steps are shown for PE1-AS1 and PE2-AS1. Configure P1-AS1 similarly:
Final BGP Confederation Configuration on PE1-AS1, P1-AS1, and PE2-AS1Example 6-41 shows the relevant configuration on PE1-AS1, P1-AS1, and PE2-AS1. Example 6-41. PE1-AS1, P1-AS1, and PE2-AS1 Configurationhostname PE1-AS1 !Refer to examples on VRF, interface, and OSPF configuration ! router bgp 101 no bgp default ipv4-unicast bgp log-neighbor-changes bgp confederation identifier 1 bgp confederation peers 100 102 neighbor 10.10.10.102 remote-as 102 neighbor 10.10.10.102 ebgp-multihop 2 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.200 remote-as 100 neighbor 10.10.10.200 ebgp-multihop 2 neighbor 10.10.10.200 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 next-hop-self neighbor 10.10.10.200 activate neighbor 10.10.10.200 send-community extended neighbor 10.10.10.200 next-hop-self exit-address-family ! address-family ipv4 vrf Cust_B neighbor 192.168.1.2 remote-as 65001 neighbor 192.168.1.2 activate neighbor 192.168.1.2 as-override no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf Cust_A neighbor 172.16.1.2 remote-as 65001 neighbor 172.16.1.2 activate no auto-summary no synchronization exit-address-family __________________________________________________________________________ hostname P1-AS1 !Refer to examples on VRF, interface, and OSPF configuration> ! router bgp 100 no bgp default ipv4-unicast bgp log-neighbor-changes bgp confederation identifier 1 bgp confederation peers 101 102 neighbor 10.10.10.101 remote-as 101 neighbor 10.10.10.101 ebgp-multihop 2 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 102 neighbor 10.10.10.102 ebgp-multihop 2 neighbor 10.10.10.102 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 next-hop-self neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 next-hop-self exit-address-family __________________________________________________________________________ hostname PE2-AS1 !Refer to examples on VRF, interface, and OSPF configuration> ! router bgp 102 no bgp default ipv4-unicast bgp log-neighbor-changes bgp confederation identifier 1 bgp confederation peers 100 101 neighbor 10.10.10.101 remote-as 101 neighbor 10.10.10.101 ebgp-multihop 2 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.200 remote-as 100 neighbor 10.10.10.200 ebgp-multihop 2 neighbor 10.10.10.200 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 next-hop-self neighbor 10.10.10.200 activate neighbor 10.10.10.200 send-community extended neighbor 10.10.10.200 next-hop-self exit-address-family ! address-family ipv4 vrf Cust_B neighbor 192.168.2.2 remote-as 65001 neighbor 192.168.2.2 activate neighbor 192.168.2.2 as-override no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf Cust_A neighbor 172.16.2.2 remote-as 65002 neighbor 172.16.2.2 activate no auto-summary no synchronization exit-address-family Verifying BGP ConfederationsThe steps to verify BGP confederations are
|
|
|
< Day Day Up > |
|
