MPLS L3VPN – BGP PE-CE Routing

BGP PE-CE Routing

BGP version 4 (BGP4) is the current de facto Internet standard for inter-domain (AS) exterior routing. In MPLS VPN networks, MP-BGP is used and plays a pivotal role in the transportation of VPNv4 prefixes across the service provider network. In traditional environments, customer networks prefer to use BGP in their networks and, therefore, use BGP as a PE-CE routing protocol when migrating from a non-MPLS based to an MPLS VPN based network. This helps the customer establish a consistent end-to-end routing policy. In an MPLS VPN network, BGP attributes for a VPN site are transparently transported across the service provider backbone to another site in the same VPN. Because there is a single routing protocol used across the VPN between service provider core and customer sites, the concept of redistribution does not apply.

BGP PE-CE peering in an MPLS VPN environment can be performed in two different ways:

  1. BGP PE-CE VPN sites implementing unique AS numbers
  2. BGP PE-CE VPN sites implementing same AS numbers

Implementing BGP PE-CE routing for the Customer A network is not an issue because the VPN sites use unique AS numbers. However, Customer B plans on using the same AS number on its sites. This causes an issue when migrating from a traditional non-MPLS based network topology, where the customer might use the same AS numbers at all his sites, to an MPLS VPN-based infrastructure due to the BGP loop prevention mechanism. The BGP loop prevention mechanism disallows customer sites having identical AS numbers to be linked by another AS number. In other words, if such a case occurs, routing updates from one site would be dropped when the other site receives them; therefore, connectivity cannot be established between the sites without additional configuration on the SP PE routers.

To circumvent the BGP loop prevention mechanism, the AS-PATH update procedure in BGP was modified. The current AS-PATH update procedure allows customer topologies to reuse AS numbers at the sites by using the AS Override functionality. The functionality is made active only when the first AS number in the AS-PATH is equal to the AS number of the receiving BGP router.

Figure shows the AS Override functionality when identical AS numbers are used at customer sites. The AS Override function causes all leading occurrences of the AS number of the receiving BGP router to be replaced with the AS number of the sending BGP router. When AS Override is used, AS 65001 in the AS-PATH is replaced with the AS number of the sending BGP router PE2-AS1, which is 1. Any other occurrences (further down the AS-PATH) of the receiving router’s AS number are not replaced because they indicate a real routing information loop. In addition, an extra copy of the sending router’s AS number is prepended to the AS-PATH (standard AS number prepending procedure that occurs on every eBGP update) to maintain proper AS hop count for proper BGP route selection.

Implementing Unique and Same AS Numbers

BGP AS Override & Allow-AS-In

BGP has a simple loop prevention mechanism for external BGP. When we see your own AS number in the AS path, we do not accept the prefix. This mechanism is fine for Internet routing but there are some other scenarios where this might be an issue.

*Apr 15 05:17:05.261: BGP(0): 192.168.2.1 rcv UPDATE about 192.168.10.0/24 — DENIED due to: AS-PATH contains our own AS;

There are two possible solutions for this issue:

  1. Allow-AS in: this can be configured on the CE routers which tells them to accept prefixes with their own AS number in the AS path.
  2. AS override: this can be configured on the PE routers, the AS number will be replaced with the AS number from the service provider.

Configuration

				
					'[PE1-AS1]'
vrf definition Cust_A
 rd 1:100
 route-target export 1:100
 route-target import 1:100
 !
 address-family ipv4
 exit-address-family
!
vrf definition Cust_B
 rd 1:200
 route-target export 1:200
 route-target import 1:200
 !
 address-family ipv4
 exit-address-family
!
router bgp 1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.102 remote-as 1
 neighbor 10.10.10.102 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.102 activate
  neighbor 10.10.10.102 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf Cust_A
  neighbor 172.16.1.2 remote-as 65001
  neighbor 172.16.1.2 activate
 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
 exit-address-family
				
			
				
					'[PE2-AS1]'
vrf definition Cust_A
 rd 1:100
 route-target export 1:100
 route-target import 1:100
 !
 address-family ipv4
 exit-address-family
!
vrf definition Cust_B
 rd 1:200
 route-target export 1:200
 route-target import 1:200
 !
 address-family ipv4
 exit-address-family
!
router bgp 1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.101 remote-as 1
 neighbor 10.10.10.101 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.101 activate
  neighbor 10.10.10.101 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf Cust_A
  neighbor 172.16.2.2 remote-as 65002
  neighbor 172.16.2.2 activate
 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
 exit-address-family
				
			
				
					PE1-AS1#show bgp vpnv4 unicast all summary 
/* BGP router identifier 10.10.10.101, local AS number 1
omitted */
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.102    4            1     194     196       19    0    0 02:47:59        4
172.16.1.2      4        65001     177     182       19    0    0 02:36:56        2
192.168.1.2     4        65001      40      40       19    0    0 00:31:56        2
PE1-AS1#

PE1-AS1#show bgp vpnv4 unicast all 
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100 (default for vrf Cust_A)
 r>   172.16.1.0/30    172.16.1.2               0             0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>   172.16.10.0/24   172.16.1.2               0             0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
Route Distinguisher: 1:200 (default for vrf Cust_B)
 r>   192.168.1.0/30   192.168.1.2              0             0 65001 i
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 65001 i
 *>   192.168.10.0     192.168.1.2              0             0 65001 i
 *>i  192.168.20.0     10.10.10.102             0    100      0 65001 i
PE1-AS1#

PE1-AS1#show bgp vpnv4 unicast all 172.16.20.0
BGP routing table entry for 1:100:172.16.20.0/24, version 12
Paths: (1 available, best #1, table Cust_A)
  Advertised to update-groups:
     4         
  Refresh Epoch 1
  65002
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1:100
      mpls labels in/out nolabel/21
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#

PE1-AS1#show bgp vpnv4 unicast all 192.168.20.0
BGP routing table entry for 1:200:192.168.20.0/24, version 14
Paths: (1 available, best #1, table Cust_B)
  Advertised to update-groups:
     5         
  Refresh Epoch 1
  65001
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1:200
      mpls labels in/out nolabel/20
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#
				
			
				
					CE1-A#traceroute 172.16.20.20 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 172.16.20.20
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.1.1 3 msec 6 msec 3 msec
  2 10.10.10.2 [MPLS: Labels 16/21 Exp 0] 4 msec 5 msec 5 msec
  3 172.16.2.1 [AS 65002] [MPLS: Label 21 Exp 0] 5 msec 4 msec 4 msec
  4 172.16.2.2 [AS 65002] 4 msec *  5 msec
CE1-A#

CE1-B#traceroute 192.168.20.20 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 192.168.20.20
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.1.1 3 msec 4 msec 2 msec
  2 10.10.10.2 [MPLS: Labels 16/20 Exp 0] 5 msec 5 msec 6 msec
  3 192.168.2.1 [AS 1] [MPLS: Label 20 Exp 0] 4 msec 4 msec 4 msec
  4 192.168.2.2 [AS 1] 5 msec *  5 msec
CE1-B#
				
			

Implementing Route-Reflectors in MPLS VPN Networks

BGP 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 to 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 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.

RR Deployment Methods

In MPLS-based VPN networks, RRs can be deployed in several ways.

Option 1 Using PE Router as VPNv4 RR

In 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.

PE Routers as RRs

Option 2 Using P Router as IPv4 and VPNv4 RR

In 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 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.

P Routers as IPv4 and VPNv4 RRs

Option 3 Using P Router as RR Only for VPNv4

In 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 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.

P Router Reflecting Only VPNv4 Routes

Option 4 Dedicated Router as RR for IPv4 and VPNv4

In this scenario, an additional router performs the function of reflecting IPv4 and VPNv4 routes. The router does not perform any data forwarding functions.

Figure 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.

Dedicated IPv4 and VPNv4 RR for Control Plane Functionality

Option 5 Dedicated Router as RR for Only VPNv4

In 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 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.

Dedicated VPNv4 RR for Control Plane Functionality

Option 6 Partitioned RRs

This 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, 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.

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).

PE Routers

				
					! 'PE1-AS1'
router bgp 1
 no bgp default ipv4-unicast
 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
				
			
				
					! 'PE2-AS1'
router bgp 1
 no bgp default ipv4-unicast
 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
				
			

P Router as RR for Only VPNv4 Prefixes

				
					! 'P1-AS1'
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
 !
 address-family ipv4
 exit-address-family
 !
 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

				
			

Verification

				
					P1-AS1#show bgp vpnv4 unicast all summary 
/*omitted*/
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.101    4            1      15      17       13    0    0 00:07:58        4
10.10.10.102    4            1      15      18       13    0    0 00:07:54        4
P1-AS1#

P1-AS1#show bgp vpnv4 unicast all 
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100
 *>i  172.16.1.0/30    10.10.10.101             0    100      0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>i  172.16.10.0/24   10.10.10.101             0    100      0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
Route Distinguisher: 1:200
 *>i  192.168.1.0/30   10.10.10.101             0    100      0 65001 i
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 65001 i
 *>i  192.168.10.0     10.10.10.101             0    100      0 65001 i
 *>i  192.168.20.0     10.10.10.102             0    100      0 65001 i
P1-AS1#
				
			
				
					CE1-A#traceroute 172.16.20.20 source lo0 numeric 
/*Type escape sequence to abort.
Tracing the route to 172.16.20.20
VRF info: (vrf in name/id, vrf out name/id)*/
  1 172.16.1.1 3 msec 3 msec 4 msec
  2 10.10.10.2 [MPLS: Labels 16/20 Exp 0] 6 msec 5 msec 5 msec
  3 172.16.2.1 [AS 65002] [MPLS: Label 20 Exp 0] 5 msec 4 msec 4 msec
  4 172.16.2.2 [AS 65002] 5 msec *  4 msec
CE1-A#

CE1-B#traceroute 192.168.20.20 source lo0 numeric 
/*Type escape sequence to abort.
Tracing the route to 192.168.20.20
VRF info: (vrf in name/id, vrf out name/id)*/
  1 192.168.1.1 2 msec 3 msec 3 msec
  2 10.10.10.2 [MPLS: Labels 16/22 Exp 0] 6 msec 6 msec 4 msec
  3 192.168.2.1 [AS 1] [MPLS: Label 22 Exp 0] 5 msec 4 msec 4 msec
  4 192.168.2.2 [AS 1] 4 msec *  7 msec
CE1-B#
				
			

Partitioned RRs

Existing 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 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.

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:

  • Outbound or inbound filters: Outbound filters on the PE routers or inbound filters on RRs. In both cases, the filtering can be performed with a route-map, matching routes on any BGP attribute that is usually on route target or standard BGP community. Outbound filters (ORF) on the PE routers reduce bandwidth utilization and CPU utilization of the RRs. The disadvantage with outbound filters is that the service providers may incur additional operational burden due to constant maintenance required for these filters on all PE routers. On the other hand, inbound filters on RRs are optimal from a maintenance perspective, but may increase the CPU utilization of the RRs.
  • BGP RR groups: Configure the inbound route-target filter on the BGP RR by using the bgp rr-group command. This command performs the same function as a route-map. However, it is configured under the BGP routing process and applies to all BGP neighbors. Also, another important operational detail is that the extended community access-list maintained on the RR is downloaded as an outbound filter to the PE routers through the ORF functionality. The route-map based input filter cannot be downloaded via ORF functionality.

RR Partitioning Using BGP Inbound Route-Target Filters

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).

  • Step 1 Create an extended-community access-list: The first step is to create an extended-community access-list on the RR that permits routes with the appropriate route-target value. P1-AS1-RR1 accepts only VPNv4 routes with the route target 1:100, and P2-AS1-RR2 accepts only VPNv4 prefixes with a route-target value of 1:200.
    • P1-AS1-RR1(config)#ip extcommunity-list standard VPNA
      P1-AS1-RR1(config-extcomm-list)#permit rt 1:100
  • Step 2 Define the route-target based inbound filter: In this step, you configure the bgp rr-group command under the BGP routing process on the RRs.
    • P1-AS1-RR1(config)#router bgp 1
      P1-AS1-RR1(config-router)#address-family vpnv4
      P1-AS1-RR1(config-router-af)#bgp rr-group VPNA
				
					'P1-AS1-RR1'
ip extcommunity-list standard VPNA
 10 permit rt 1:100
 !
router bgp 1
 !
 address-family vpnv4
  bgp rr-group VPNA
 exit-address-family
				
			
				
					'P2-AS1-RR1'
ip extcommunity-list standard VPNB
 10 permit rt 1:200
 !
router bgp 1
 !
 address-family vpnv4
  bgp rr-group VPNB
 exit-address-family
				
			
				
					/* Before the Route-Target filters are applied */
P1-AS1-RR1#show bgp vpnv4 un all
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100
 *>i  172.16.1.0/30    10.10.10.101             0    100      0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>i  172.16.10.0/24   10.10.10.101             0    100      0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
Route Distinguisher: 1:200
 *>i  192.168.1.0/30   10.10.10.101             0    100      0 65001 i
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 65001 i
 *>i  192.168.10.0     10.10.10.101             0    100      0 65001 i
 *>i  192.168.20.0     10.10.10.102             0    100      0 65001 i
P1-AS1-RR1#

/* After the Route-Target filters are applied */
P1-AS1-RR1#show bgp vpnv4 unicast all
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100
 *>i  172.16.1.0/30    10.10.10.101             0    100      0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>i  172.16.10.0/24   10.10.10.101             0    100      0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
P1-AS1-RR1#

P2-AS1-RR2#show bgp vpnv4 unicast all 
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:200
 *>i  192.168.1.0/30   10.10.10.101             0    100      0 65001 i
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 65001 i
 *>i  192.168.10.0     10.10.10.101             0    100      0 65001 i
 *>i  192.168.20.0     10.10.10.102             0    100      0 65001 i
P2-AS1-RR2#
				
			

RR Partitioning Using Standard BGP Communities

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).

Configuration Steps on the P Routers

  • Step 1 Create a community access-list and route-map policy: Create a community access-list that permits the route with the route-target value that is to be accepted by the RR. P1-RR is accepting only VPNv4 prefixes with the route target 1:100, and P2-RR is accepting only VPNv4 prefixes with the route-target value of 1:200. Prior to this, make sure that the routers are configured with ip bgp-community new-format.
    • P1-AS1-RR1(config)#ip community-list 1 permit 1:100
      P1-AS1-RR1(config)#route-map allow-VPNA permit 10
      P1-AS1-RR1(config-route-map)#match community 1
  • Step 2 Apply the route-map to the BGP PE neighbor: In this step, apply the route-map to the relevant BGP neighbors.
    • P1-AS1-RR1(config)#router bgp 1
      P1-AS1-RR1(config-router)#address-family vpnv4
      P1-AS1-RR1(config-router-af)#neighbor 10.10.10.101 route-map allow-VPNA in
      P1-AS1-RR1(config-router-af)#neighbor 10.10.10.102 route-map allow-VPNA in
      P1-AS1-RR1(config-router-af)#neighbor 10.10.10.103 route-map allow-VPNA in
				
					'PE1-AS1'
ip access-list standard VPNA
 permit 172.16.0.0 0.0.255.255
ip access-list standard VPNB
 permit 192.168.0.0 0.0.255.255
!
route-map allow1 permit 10
 match ip address VPNA
 set community 1:100
route-map allow2 permit 10
 match ip address VPNB
 set community 1:200
!
ip bgp-community new-format
!
router bgp 1
 !
 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
				
			
				
					'PE2-AS1'
ip access-list standard VPNA
 permit 172.16.0.0 0.0.255.255
ip access-list standard VPNB
 permit 192.168.0.0 0.0.255.255
!
route-map allow1 permit 10
 match ip address VPNA
 set community 1:100
route-map allow2 permit 10
 match ip address VPNB
 set community 1:200
!
ip bgp-community new-format
!
router bgp 1
 !
 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
				
			
				
					'P1-AS1-RR1'
ip community-list standard VPNA permit 1:100
!
route-map allowVPNA permit 10
 match community VPNA
!
router bgp 1
 !
 address-family vpnv4
  neighbor 10.10.10.101 route-map allowVPNA in
  neighbor 10.10.10.102 route-map allowVPNA in
  neighbor 10.10.10.103 route-map allowVPNA in
 exit-address-family
				
			
				
					'P2-AS1-RR1'
ip community-list standard VPNB permit 1:200
!
route-map allowVPNA permit 10
 match community VPNB
!
router bgp 1
 !
 address-family vpnv4
  neighbor 10.10.10.101 route-map allowVPNB in
  neighbor 10.10.10.102 route-map allowVPNB in
  neighbor 10.10.10.103 route-map allowVPNB in
 exit-address-family
				
			
				
					/* Before applying the community ACL */
P1-AS1-RR1#show bgp vpnv4 unicast  all
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100
 *>i  172.16.1.0/30    10.10.10.101             0    100      0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>i  172.16.10.0/24   10.10.10.101             0    100      0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
Route Distinguisher: 1:200
 *>i  192.168.1.0/30   10.10.10.101             0    100      0 65001 i
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 65001 i
 *>i  192.168.10.0     10.10.10.101             0    100      0 65001 i
 *>i  192.168.20.0     10.10.10.102             0    100      0 65001 i
P1-AS1-RR1#

/* After applying the community ACL */
P1-AS1-RR1#show bgp vpnv4 uni all
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100
 *>i  172.16.1.0/30    10.10.10.101             0    100      0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>i  172.16.10.0/24   10.10.10.101             0    100      0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
P1-AS1-RR1#

P1-AS1-RR1#show bgp vpnv4 uni all 172.16.10.0
BGP routing table entry for 1:100:172.16.10.0/24, version 31
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     1         
  Refresh Epoch 4
  65001, (Received from a RR-client)
    10.10.10.101 (metric 2) (via default) from 10.10.10.101 (10.10.10.101)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 1:100
      Extended Community: RT:1:100
      mpls labels in/out nolabel/23
      rx pathid: 0, tx pathid: 0x0
P1-AS1-RR1#
				
			

RRs and Peer Groups

A 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.

				
					'P1-AS1-RR1'
router bgp 1
 no bgp default ipv4-unicast
 neighbor G1 peer-group
 neighbor G1 remote-as 1
 neighbor G1 update-source Loopback0
 neighbor 10.10.10.101 peer-group G1
 neighbor 10.10.10.102 peer-group G1
 neighbor 10.10.10.103 peer-group G1
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor G1 send-community extended
  neighbor G1 route-reflector-client
  neighbor G1 route-map allowVPNA in
  neighbor 10.10.10.101 activate
  neighbor 10.10.10.102 activate
  neighbor 10.10.10.103 activate
 exit-address-family
				
			
				
					'P2-AS1-RR1'
router bgp 1
 no bgp default ipv4-unicast
 neighbor g2 peer-group
 neighbor g2 remote-as 1
 neighbor g2 update-source Loopback0
 neighbor 10.10.10.100 peer-group g2
 neighbor 10.10.10.101 peer-group g2
 neighbor 10.10.10.102 peer-group g2
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor g2 send-community extended
  neighbor g2 route-reflector-client
  neighbor g2 route-map allowVPNB in
  neighbor 10.10.10.100 activate
  neighbor 10.10.10.101 activate
  neighbor 10.10.10.102 activate
 exit-address-family
				
			
				
					P1-AS1-RR1#show bgp vpnv4 uni all
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100
 *>i  172.16.1.0/30    10.10.10.101             0    100      0 65001 i
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 65002 i
 *>i  172.16.10.0/24   10.10.10.101             0    100      0 65001 i
 *>i  172.16.20.0/24   10.10.10.102             0    100      0 65002 i
P1-AS1-RR1#

P1-AS1-RR1#show bgp vpnv4 unicast all peer-group G1
BGP peer-group is G1,  remote AS 1
  BGP version 4
  Neighbor sessions:
    0 active, is not multisession capable (disabled)
  Do log neighbor state changes (via global configuration)
  Default minimum time between advertisement runs is 0 seconds

 For address family: VPNv4 Unicast
  BGP neighbor is G1, peer-group internal, members:
  10.10.10.101 10.10.10.102 10.10.10.103 
  Index 0, Advertise bit 0
  Route-Reflector Client
  Extended-community attribute sent to this neighbor
  Inbound path policy configured
  Route map for incoming advertisements is allowVPNA
  Update messages formatted 0, replicated 0
  Number of NLRIs in the update sent: max 0, min 0
P1-AS1-RR1#

P2-AS1-RR2#show bgp vpnv4 uni all
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:200
 *>i  192.168.1.0/30   10.10.10.101             0    100      0 65001 i
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 65001 i
 *>i  192.168.10.0     10.10.10.101             0    100      0 65001 i
 *>i  192.168.20.0     10.10.10.102             0    100      0 65001 i
P2-AS1-RR2#

P2-AS1-RR2#show bgp vpnv4 unicast all peer-group g2
BGP peer-group is g2,  remote AS 1
  BGP version 4
  Neighbor sessions:
    0 active, is not multisession capable (disabled)
  Do log neighbor state changes (via global configuration)
  Default minimum time between advertisement runs is 0 seconds

 For address family: VPNv4 Unicast
  BGP neighbor is g2, peer-group internal, members:
  10.10.10.100 10.10.10.101 10.10.10.102 
  Index 0, Advertise bit 0
  Route-Reflector Client
  Extended-community attribute sent to this neighbor
  Inbound path policy configured
  Route map for incoming advertisements is allowVPNB
  Update messages formatted 0, replicated 0
  Number of NLRIs in the update sent: max 0, min 0
P2-AS1-RR2#
				
			
Tags:

Leave a Reply

Related Post