MPLS L3VPN – OSPF PE-CE Routing

Routing Scenario 1

MPLS Forwarding Configuration

  1. Enable CEF: CEF is an essential component for label switching and is responsible for imposition and disposition of labels in an MPLS network. ip cef [distributed]
  2. Configure IGP Routing Protocol
  3. Define the Label Distribution Protocol: TDP is deprecated, and by default, LDP is the label distribution protocol. The command mpls label protocol {ldp | tdp} is configured only if LDP is not the default label distribution protocol or if you are reverting from LDP to TDP protocol or vice versa.
  4. Assign LDP RID: LDP uses the highest IP address on a loopback interface as the LDP router ID. If there is no loopback address defined, the highest IP address on the router becomes the LDP router ID. mpls ldp router-id interface-type
  5. Enable MPLS forwarding on the interface.
    • interface serial 0/0
      • mpls ip

Verification Commands

  • Verify MPLS forwarding is enabled on the interfaces. show mpls interfaces
  • Verify the status of the Label Distribution Protocol (LDP) discovery process. show mpls ldp discovery
  • Verify status of the LDP neighbor sessions. show mpls ldp neighbor
				
					! 'PE1-AS1'
router ospf 1
 mpls ldp autoconfig
 network 10.0.0.0 0.255.255.255 area 0
				
			
				
					! 'P1-AS1'
router ospf 1
 mpls ldp autoconfig
 network 0.0.0.0 255.255.255.255 area 0
				
			
				
					! 'PE2-AS1'
router ospf 1
 mpls ldp autoconfig
 network 10.0.0.0 0.255.255.255 area 0
				
			

Defining VPN VRF and its attributes

  1. Configure VRF on PE router: This results in the creation of a VRF routing table and a Cisco Express Forwarding (CEF) table for Customers.
  2. Configure the RD: The RD creates routing and forwarding tables. The RD is added to the beginning of the customer’s IPv4 prefixes to convert them into globally unique VPNv4 prefixes.
    • RD for an existing VRF can be changed only after deletion of that VRF.
    • RD has to be unique for that particular VRF. No two VRFs on the same router can have similar RD.
  3. Configure the import and export policy: Configure the import and export policy for the MP-BGP extended communities. The policy is used for filtering routes for that particular RT.
  4. Associate VRF with the interface: Associating the VRF to an interface results in removal of the IP address from that interface. This is only if VRF was associated to an interface that had the IP address already configured. This means that the IP address will have to be reconfigured after the VRF is associated with that interface.
				
					!!!!!!!!!!!!!
!!! '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
!
interface GigabitEthernet0/0
 vrf forwarding Cust_A
 ip address 172.16.1.1 255.255.255.252
!
interface GigabitEthernet0/1
 vrf forwarding Cust_B
 ip address 192.168.1.1 255.255.255.252
				
			
				
					!!!!!!!!!!!!!
!!! '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
!
interface GigabitEthernet0/2
 vrf forwarding Cust_A
 ip address 172.16.2.1 255.255.255.252
!
interface GigabitEthernet0/3
 vrf forwarding Cust_B
 ip address 192.168.2.1 255.255.255.252
				
			

BGP PE-PE Routing Configuration

Configuring BGP PE-PE routing between the PE routers is the next step in an MPLS VPN deployment. The purpose of this step is to ensure that VPNv4 routes can be transported across the service provider backbone using MP-iBGP. The P router is transparent to this entire process and, therefore, does not carry any customer routes.

PE routers will have to exchange VPNv4 routes through IBGP. When configuring IBGP, PE routers will only exchange IPv4 unicast routes by default. Since we need the PE routers to exchange VPNv4 routes, we will have to activate an additional address family.

  1. Configure BGP routing on PE routers: Enable BGP routing.
  2. Configure MP-iBGP neighbors: Configure the remote MP-iBGP neighbor and use the loopback interface as the source of BGP messages and updates. Note that you have to use the update-source command only when the neighbor is peering to your loopback address.
  3. Configure the VPNv4 address family: Configure the address family for VPNv4 under the BGP configuration process. This step allows you to enter the VPNv4 address family to activate the VPNv4 neighbors. Activate the iBGP neighbor, which is essential for transporting VPNv4 prefixes across the service provider backbone. In addition, configure the propagation of the extended communities with BGP routes so as to enable RT propagation, which identifies the VPNs that the routes have to be imported into.
    • Note that on some versions of IOS, adding the neighbor for VPNv4 route exchange using the neighbor ip-address activate command also automatically adds the neighbor ip-address send-community extended command.
    • If the neighbor needs to be configured for both standard and extended community exchange, you will explicitly have to configure the neighbor ip-address send-community both command under the VPNv4 address family.
  4. Configure the IPv4 address family: Configure the peer VRF IPv4 address family under the BGP configuration process. This step allows you to enter the IPv4 networks that will be converted to VPNv4 routes in MP-BGP updates.

Routers will be able to exchange IPv4 unicast prefixes and VPNv4 routes. However, the PE routers will only be used to exchange VPNv4 routes so we can disable the address-family for IPv4 unicast. With this BGP configuration, we will use IPv4 to establish the neighbor adjacency but we won’t exchange IPv4 prefixes. The only thing we will exchange are VPNv4 routes. show ip bgp summary won’t work since it is used to check IPv4 unicast prefixes, use show bgp vpnv4 unicast all summary instead.

				
					! 'PE1-AS1'
router bgp 1
 no bgp default ipv4-unicast
 neighbor 10.10.10.102 remote-as 1
 neighbor 10.10.10.102 update-source Loopback0
!
 address-family ipv4
  no neighbor 10.10.10.102 activate
 exit-address-family
!
 address-family vpnv4
  neighbor 10.10.10.102 activate
  neighbor 10.10.10.102 send-community extended
 exit-address-family
				
			
				
					! 'PE2-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
!
 address-family ipv4
  no neighbor 10.10.10.101 activate
 exit-address-family
!
 address-family vpnv4
  neighbor 10.10.10.101 activate
  neighbor 10.10.10.101 send-community extended
 exit-address-family
				
			

Configuring OSPF PE-CE Routing

  1. Enable per VRF OSPF Routing.
    • router ospf 101 vrf Cust_A
      router-id 172.16.101.1
      network 172.16.0.0 0.0.255.255 area 0
  2. Redistribute OSPF Routes into BGP: The OSPF routes received from the local CE routers are redistributed in MP-iBGP.
    • It is necessary to include the match command option; otherwise, only OSPF internal routes will be redistributed in BGP.
    • router bgp 1
      address-family ipv4 vrf Cust_A
      redistribute ospf 101 vrf Cust_A match internal external 1 external 2
  3. Redistribute MP-IBGP Routes into OSPF: In this step, you redistribute the BGP VPNv4 routes into OSPF on PE routers.
    • Ensure that the subnets keyword is included when configuring redistribution; otherwise, Cisco IOS redistributes only the major networks and supernets.
    • router ospf 100 vrf Cust_A
      redistribute bgp 1 subnets
				
					'[PE1-AS1]'
router ospf 101 vrf Cust_A
 network 172.16.0.0 0.0.255.255 area 0
 redistribute bgp 1 subnets
!
router ospf 201 vrf Cust_B
 network 192.168.0.0 0.0.255.255 area 0
 redistribute bgp 1 subnets

router bgp 1
 /*omitted*/
 !
 address-family ipv4 vrf Cust_A
  redistribute ospf 101 match internal external 1 external 2
 exit-address-family
 !
 address-family ipv4 vrf Cust_B
  redistribute ospf 201 match internal external 1 external 2
 exit-address-family
				
			
				
					'[PE2-AS1]'
router ospf 101 vrf Cust_A
 network 172.16.0.0 0.0.255.255 area 0
 redistribute bgp 1 subnets
!
router ospf 202 vrf Cust_B
 network 192.168.0.0 0.0.255.255 area 2
 redistribute bgp 1 subnets

router bgp 1
 /*omitted*/
 !
 address-family ipv4 vrf Cust_A
  redistribute ospf 101 match internal external 1 external 2
 exit-address-family
 !
 address-family ipv4 vrf Cust_B
  redistribute ospf 202 match internal external 1 external 2
 exit-address-family
				
			

OSPF Route-Propagation

BGP Extended Communities for OSPF PE-CE Routing

How do the PE routers know to which area a prefix belongs and which LSA type to use when we redistribute a VPNv4 route back into OSPF for the customer?

Our PE routers need something to tell other PE routers which Area and LSA Type to use. We use two additional BGP extended communities for this:

  • OSPF Domain ID
  • Route Type.

Don’t confuse the RT (route target) with the OSPF RT (route type).

In the MPLS VPN superbackbone, the following BGP extended attributes are carried:

  • OSPF Route Type: Propagates OSPF route type information across the MP-iBGP backbone.
  • OSPF Router ID: Identifies the router ID of the PE in the relevant VRF instance of OSPF. This address is not part of the provider’s address space and is unique in the OSPF network.
  • OSPF Domain ID: Identifies the domain of a specific OSPF prefix in the MPLS VPN backbone. By default, this value is equal to the value of the OSPF process ID and can be overwritten by the command domain ID ip-address under the OSPF process.
    • If the domain ID of the route does not match the domain ID on the receiving PE, the route is translated to the external OSPF route (LSA Type 5) with metric-type E2, assuming the route was received in the VRF table. All routing between OSPF domains is via Type 5 LSAs.
Router ID and Domain ID
OSPF Route Type Community Attribute

Domain ID Is Same on All PE Routers

CEA-S1 originates:

  • 172.16.10.0/24 (Area 1) as O IA (Inter-area route)
  • 172.16.1.0/30 (Area 0) as O (Intra-area route)

CEA-S2 originates:

  • 172.16.20.0/24 (Area 1) as O IA
  • 172.16.2.0/24 (Area 0) as O
  • 209.165.201.0/27 (RIPv2) as an External Type 1 O E1
  • 209.165.202.128/27 (EIGRP) as an External Type 2 O E2
  1. CEA-S1 propagates the OSPF routes.
  2. VRF Cust_A routing table on PE1-AS1 shows the received routes. OSPF cost for the received routes are copied into extended BGP attributes as BGP MEDs when OSPF routes are redistributed into MP-BGP. The routes are then propagated to PE2-AS1 via MP-iBGP session.
  3. PE2-AS1 receives the BGP VPNv4 routes 172.16.10.0/24 and 172.16.1.0/30 from PE1-AS1 and inserts them in the BGP table.
    • The OSPF metric for the routes are not altered and remain the same when propagated though the MP-BGP backbone.
  4. The receiving the PE router PE2-AS1, redistributes the MP-BGP routes back into OSPF, verifies the domain ID, and if the domain ID of the route matches the domain ID on the receiving PE, PE2-AS1, it uses the original LSA type and the MED attribute to generate an inter-area summary (LSA Type 3) LSA.
    • The Domain ID matches so PE2-AS1 reconstructs the original update and updates the metric based on the outgoing interfaces and propagates the 172.16.10.0/24 and 172.16.1.0/30 as an Inter-Area routes.
LSA Type Same Process ID? Propagated as..
1, 2 or 3
Yes
Type 3 LSA (O IA)
5 or 7 Remain the same
				
					'[PE1-AS1]'
PE1-AS1#show bgp vpnv4 unicast all 172.16.10.0
BGP routing table entry for 1:100:172.16.10.0/24, version 15
Paths: (1 available, best #1, table Cust_A)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local
    172.16.1.2 (via vrf Cust_A) from 0.0.0.0 (10.10.10.101)
      Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:100 'OSPF DOMAIN ID:0x0005:0x000000650200' 
        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:172.16.1.1:0
      mpls labels in/out 23/nolabel
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#

'[PE2-AS1]'
PE2-AS1#show bgp vpnv4 unicast all 172.16.20.0
BGP routing table entry for 1:100:172.16.20.0/24, version 26
Paths: (1 available, best #1, table Cust_A)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local
    172.16.2.2 (via vrf Cust_A) from 0.0.0.0 (10.10.10.102)
      Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:100 'OSPF DOMAIN ID:0x0005:0x000000650200' 
        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:0.0.16.1:0
      mpls labels in/out 23/nolabel
      rx pathid: 0, tx pathid: 0x0
PE2-AS1#
				
			
				
					'[CEA-S1]'
CEA-S1#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks
O IA     172.16.2.0/30 [110/2] via 172.16.1.1, 03:28:52, GigabitEthernet0/0
O IA     172.16.20.0/24 [110/3] via 172.16.1.1, 02:52:31, GigabitEthernet0/0
      209.165.201.0/27 is subnetted, 1 subnets
O E1     209.165.201.0 [110/22] via 172.16.1.1, 02:35:26, GigabitEthernet0/0
      209.165.202.0/27 is subnetted, 1 subnets
O E2     209.165.202.128 [110/20] via 172.16.1.1, 02:35:31, GigabitEthernet0/0
CEA-S1#

'[CEA-S2]'
CEA-S2#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks
O IA     172.16.1.0/30 [110/2] via 172.16.2.1, 02:45:40, GigabitEthernet0/2
O IA     172.16.10.0/24 [110/3] via 172.16.2.1, 02:45:40, GigabitEthernet0/2
CEA-S2#
				
			

Domain ID Is Different on All PE Routers

CEB-S1 originates:

  • 192.168.10.0/24 (Area 1) O IA
  • 192.168.1.0/30 (Area 0) O

CEB-S2 originates:

  • 192.168.20.0/24 (Area 2) O
  • 192.168.2.0/30 (Area 2) O
  • 192.168.99.0/24 (RIPv2) O E1
  • 192.168.199.0/24 (EIGRP) O E2
  1. CEB-S1 propagates the OSPF routes.
  2. VRF Cust_B routing table on PE1-AS1 shows the received routes.
  3. The PE router, PE1-AS1, redistributes the OSPF routes into MP-BGP, copies the OSPF cost for those routes into the multi-exit discriminator (MED) attribute, and sets the BGP extended community route type (RT) to indicate the LSA type from which the route was derived, as well as the extended community attribute OSPF domain ID to indicate the process number of the source OSPF process.
    • OSPF RTs carry information on the original area. The LSA type and the type for external routes are metric types.
  4. PE2-AS1 receives the BGP VPNv4 routes with the same metric information from PE1-AS1. The information received is inserted in the BGP table.
    • The OSPF metric for the routes are not altered and remain the same when propagated though the MP-BGP backbone.
  5. PE2-AS1 checks the attributes received in the route, and, because the domain ID of the route does not match the domain ID on the receiving PE, the route is translated to the external Type 2 route (LSA Type 5) OSPF route.
LSA Type Same Process ID? Propagated as..
1, 2 or 3
No

External Type 2 (O E2)
5
				
					'[PE1-AS1]'
PE1-AS1#show bgp vpnv4 unicast all 192.168.10.0
BGP routing table entry for 1:200:192.168.10.0/24, version 43
Paths: (1 available, best #1, table Cust_B)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local
    192.168.1.2 (via vrf Cust_B) from 0.0.0.0 (10.10.10.101)
      Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:200 'OSPF DOMAIN ID:0x0005:0x000000C90200' 
        OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:192.168.1.1:0
      mpls labels in/out 19/nolabel
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#

'[PE2-AS1]'
PE2-AS1#show bgp vpnv4 unicast all 192.168.20.0
BGP routing table entry for 1:200:192.168.20.0/24, version 45
Paths: (1 available, best #1, table Cust_B)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local
    192.168.2.2 (via vrf Cust_B) from 0.0.0.0 (10.10.10.102)
      Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:200 'OSPF DOMAIN ID:0x0005:0x000000CA0200' 
        OSPF RT:0.0.0.2:2:0 OSPF ROUTER ID:192.168.2.1:0
      mpls labels in/out 25/nolabel
      rx pathid: 0, tx pathid: 0x0
PE2-AS1#
				
			
				
					'[CEB-S1]'
CEB-S1#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      192.168.2.0/30 is subnetted, 1 subnets
O E2     192.168.2.0 [110/1] via 192.168.1.1, 00:38:04, GigabitEthernet0/1
O E2  192.168.20.0/24 [110/2] via 192.168.1.1, 00:38:04, GigabitEthernet0/1
O E2  192.168.99.0/24 [110/21] via 192.168.1.1, 00:38:04, GigabitEthernet0/1
O E2  192.168.199.0/24 [110/20] via 192.168.1.1, 00:38:04, GigabitEthernet0/1
CEB_S1#

'[CEB-S2]'
CEB_S2#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      192.168.1.0/30 is subnetted, 1 subnets
O E2     192.168.1.0 [110/1] via 192.168.2.1, 00:39:15, GigabitEthernet0/3
O E2  192.168.10.0/24 [110/2] via 192.168.2.1, 00:39:15, GigabitEthernet0/3
CEB_S2#
				
			

Routing Scenario 2

Sham-Links

The following sequence takes place when 172.16.40.0/24 is propagated by CE4-A to CE3-A:

  1. CE4-A sends a Type 1 LSA for 172.16.40.0/24 to the provider edge router, PE2-AS1 and CE3-A.
  2. The PE2-AS1 router receives 172.16.40.0/24 as an intra-area route. It redistributes into MP-BGP.
  3. PE1-AS1 redistributes 172.16.40.0/24 into OSPF and propagates 172.16.40.0/24 as an Inter-Area route to CE3-A.
  4. CE3-A receives the 172.16.40.0/24 as an inter-area route from PE1-AS1 and as an intra-area route from CE4-A. In OSPF, intra-area routes are preferred over inter-area routes; therefore, CE3-A prefers the intra-area route from CE4-A and inserts it in the OSPF database.

This sequence of events also occurs with 172.16.20.0/24, which is propagated by CE2-A. Therefore, data packets originating from the 172.16.30.0 network (Site 3) to 172.16.40.0 (Site 4) will take the backdoor link.

This also applies to traffic originating from 172.16.10.0 (Site 1) to 172.16.20.0 (Site 2) because any alternative routes from the MPLS VPN backbone would be inter-area routes, and intra-area routes are preferred. The traffic forwarding is, therefore, considered suboptimal because the backdoor link has low bandwidth and is intended for backup.

				
					/*- CE3-A router receiving routes from PE1-AS1 as Inter-Area routes
and from CE4-A as Intra-Area routes, choosing Intra over Inter. */

CE3-A#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 14 subnets, 3 masks
O        172.16.1.0/30 [110/2] via 172.16.3.1, 00:16:57, GigabitEthernet0/2
O        172.16.2.0/30 [110/3] via 172.16.5.2, 00:03:36, GigabitEthernet0/1
O        172.16.4.0/30 [110/2] via 172.16.5.2, 00:03:46, GigabitEthernet0/1
O IA     172.16.10.0/24 [110/3] via 172.16.3.1, 00:16:57, GigabitEthernet0/2
O IA     172.16.20.0/24 [110/4] via 172.16.5.2, 00:03:36, GigabitEthernet0/1
O        172.16.40.0/24 [110/2] via 172.16.5.2, 00:04:45, GigabitEthernet0/1
O        172.16.100.0/24 [110/3] via 172.16.3.1, 00:10:52, GigabitEthernet0/2
O        172.16.200.0/24 [110/4] via 172.16.5.2, 00:03:36, GigabitEthernet0/1
      209.165.201.0/27 is subnetted, 1 subnets
O E1     209.165.201.0 [110/23] via 172.16.5.2, 00:03:36, GigabitEthernet0/1
      209.165.202.0/27 is subnetted, 1 subnets
O E2     209.165.202.128 [110/20] via 172.16.5.2, 00:03:36, GigabitEthernet0/1
CE3-A#

/*- After disabling CE3-A <-> CE4-A link,
CE3-A router started installing the routes from PE1-AS1 */

CE3-A#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 13 subnets, 3 masks
O        172.16.1.0/30 [110/2] via 172.16.3.1, 00:23:07, GigabitEthernet0/2
O IA     172.16.2.0/30 [110/2] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
O IA     172.16.4.0/30 [110/2] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
O IA     172.16.5.0/30 [110/3] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
O IA     172.16.10.0/24 [110/3] via 172.16.3.1, 00:23:07, GigabitEthernet0/2
O IA     172.16.20.0/24 [110/3] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
O IA     172.16.40.0/24 [110/3] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
O        172.16.100.0/24 [110/3] via 172.16.3.1, 00:17:02, GigabitEthernet0/2
O IA     172.16.200.0/24 [110/3] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
      209.165.201.0/27 is subnetted, 1 subnets
O E1     209.165.201.0 [110/22] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
      209.165.202.0/27 is subnetted, 1 subnets
O E2     209.165.202.128 [110/20] via 172.16.3.1, 00:00:09, GigabitEthernet0/2
CE3-A#
				
			

This situation can be avoided by using a sham-link. A sham-link is a logical link that belongs to the area (intra-area) but is carried by the BGP-based superbackbone.

  • The two PE routers will be the endpoints of the sham-link.
  • They will form an OSPF adjacency across it and flood intra-area LSAs via this link.
  • The two sites that belong to Area 0 can have a sham-link between them and then receive intra-area OSPF routes via the backdoor link or the sham-link.
  • When the sham-link is up, it is regarded as an unnumbered point-to-point OSPF link in the area belonging to the VPN sites.
  • The sham-link is treated as a demand circuit (DC) by the OSPF in order to reduce the traffic flow over the sham-link. This implies that the regular LSA will flood over the sham-link but the periodic refresh traffic is avoided.
  1. CE4-A sends 172.16.40.0/24 as LSA Type 1 to CE3-A, which then propagates the LSA to the PE1-AS1 router.
  2. The PE1-AS1 router has now received the OSPF-LSA Type 1 route from two directions from CE4-A via CE3-A and from PE2-AS1 via the OSPF sham-link.
    • OSPF sham-link serves as an intra-area link between PE1-AS1 and PE2-AS1.
    • The OSPF cost of the sham-link can be configured so that it will be lower than the cost of the backup link between CE3-A and CE4-A.
  3. The PE2-AS1 router therefore redistributes the OSPF route 172.16.40.0/24 into MP-BGP because the OSPF route was not received via a sham-link from PE1-AS1.
    • The PE1-AS1 router also does not redistribute the route in MP-iBGP because the route was received from PE2-AS1 via the OSPF sham-link between PE1-AS1 and PE2-AS1.
    • PE1-AS1 therefore installs the OSPF route received over the sham-link in its VRF routing table. The LSA for route 172.16.40.0/24 is then propagated into Site 3 to allow CE3-A to select the best path.
    • Packets received from the Site 4 will, therefore, be routed across the MPLS VPN backbone and will use the high bandwidth link. Also, the CE3-A router at Site 3 selects the sham-link as the best path to reach 172.16.40.0/24. Therefore, the traffic between Site 3 and site 4 is optimally routed via the low cost sham-link between PE1-AS1 and PE2-AS1.

Sham-Link Configuration

  1. Create endpoints of the sham-link: The first step is to create the endpoints of the sham-link by creating a loopback interface on each PE router and associating it to the VRF Cust_A of the VPN. This associates the sham-link in the VRF Cust_A for the VPN site. The address of the loopback interface should be an address in the VPN’s address space, not the MPLS VPN service provider’s address space because the sham-link is considered a link of the VPN customer and not the MPLS VPN service provider’s.
    • interface Loopback101
      description sham-link Endpoint on PE1-AS1
      ip vrf forwarding Cust_A
      ip address 172.16.101.1 255.255.255.255
  2. Redistribute the endpoints in MP-BGP: Redistribute the sham-link endpoints created in Step 1 in BGP. This ensures that the PE routers have reachability to the endpoints. When the sham-link endpoint is created, it is necessary to ensure that each PE router has reachability to the endpoint. Such reachability information must be learned via BGP in each PE router, which can be done by redistributing the endpoint addresses to MP-BGP.
    • router bgp 1
      address-family ipv4 vrf Cust_A
      redistribute connected
  3. Enable sham-link under OSPF VRF process: Configure the sham-link under the OSPF process. Because the sham-link is considered an OSPF link within the area of the VPN sites, the area ID needs to be specified to match the VPN sites’ area ID, and a cost value needs to be assigned to it. When there is a backdoor connection, the cost assigned can determine whether the traffic flows between the backdoor link and the sham-link.
    • router ospf 101 vrf Cust_A
      area 0 sham-link 172.16.101.1 172.16.102.1 cost 1

Note: The endpoint address information should not be advertised via OSPF itself. The loopback interface should not be included in the OSPF 101 VRF process. It would cause a problem when a backdoor path exists between the two VPN sites. In such a scenario, the PE router that includes the endpoint address in the OSPF VRF process would exchange the endpoint address information via OSPF to the CE routers in LSA Type 1 or 2. The LSA would then propagate to the other side of PE router over the backdoor path. Although the other side of the PE would also receive the endpoint address information via MP-BGP, it will prefer the OSPF route rather than the BGP-learned route because of the administrative distance value. The sham-link will fail to be up because the endpoint address information is not learned via BGP.

				
					'[PE1-AS1]'
interface Loopback101
 vrf forwarding Cust_A
 ip address 172.16.101.1 255.255.255.255
!
router bgp 1
 /*omitted for brevity*/
 !
 address-family ipv4 vrf Cust_A
  redistribute connected
  redistribute ospf 101 match internal external 1 external 2
 exit-address-family
!
router ospf 101 vrf Cust_A
 area 0 sham-link 172.16.101.1 172.16.102.1
 redistribute bgp 1 subnets
				
			
				
					'[PE2-AS1]'
interface Loopback101
 vrf forwarding Cust_A
 ip address 172.16.102.1 255.255.255.255
!
router bgp 1
 /*omitted for brevity*/
 !
 address-family ipv4 vrf Cust_A
  redistribute connected
  redistribute ospf 101 match internal external 1 external 2
 exit-address-family
!
router ospf 101 vrf Cust_A
 area 0 sham-link 172.16.102.1 172.16.101.1
 redistribute bgp 1 subnets
				
			
				
					/* Sham-link UP */
PE1-AS1#show ip ospf neighbor 
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.200      0   FULL/  -        00:00:38    10.10.10.2      GigabitEthernet0/3
192.168.10.10     0   FULL/  -        00:00:33    192.168.1.2     GigabitEthernet0/1
0.0.16.1          0   FULL/  -           -        172.16.102.1    OSPF_SL0
172.16.30.30      0   FULL/  -        00:00:31    172.16.3.2      GigabitEthernet0/2
172.16.10.10      0   FULL/  -        00:00:31    172.16.1.2      GigabitEthernet0/0
PE1-AS1#

PE1-AS1#show ip ospf sham-links 
Sham Link OSPF_SL0 to address 172.16.102.1 is up
Area 0 source address 172.16.101.1
  Run as demand circuit
  DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40,
    Hello due in 00:00:00
    Adjacency State FULL (Hello suppressed)
    Index 1/3/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
PE1-AS1#
				
			
				
					CE3-A#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 16 subnets, 3 masks
O        172.16.1.0/30 [110/2] via 172.16.3.1, 02:24:02, GigabitEthernet0/2
O        172.16.2.0/30 [110/3] via 172.16.3.1, 00:14:53, GigabitEthernet0/2
O        172.16.4.0/30 [110/3] via 172.16.3.1, 00:11:02, GigabitEthernet0/2
O IA     172.16.10.0/24 [110/3] via 172.16.3.1, 02:24:02, GigabitEthernet0/2
O IA     172.16.20.0/24 [110/4] via 172.16.3.1, 00:14:53, GigabitEthernet0/2
O        172.16.40.0/24 [110/4] via 172.16.3.1, 00:11:02, GigabitEthernet0/2
O        172.16.100.0/24 [110/3] via 172.16.3.1, 02:17:57, GigabitEthernet0/2
O E2     172.16.101.1/32 [110/1] via 172.16.3.1, 00:14:53, GigabitEthernet0/2
O E2     172.16.102.1/32 [110/1] via 172.16.3.1, 00:17:13, GigabitEthernet0/2
O        172.16.200.0/24 [110/4] via 172.16.3.1, 00:14:53, GigabitEthernet0/2
      209.165.201.0/27 is subnetted, 1 subnets
O E1     209.165.201.0 [110/23] via 172.16.3.1, 00:14:53, GigabitEthernet0/2
      209.165.202.0/27 is subnetted, 1 subnets
O E2     209.165.202.128 [110/20] via 172.16.3.1, 00:14:53, GigabitEthernet0/2
CE3-A#

/* Traceroute from CE3-A router to CE4-A's loopback 172.16.40.40
which is a directly connected router via the backdoor link
Traffic crossing the MPLS network */

CE3-A#traceroute 172.16.40.40 source loo0 numeric 
/*Type escape sequence to abort.
Tracing the route to 172.16.40.40*/
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.3.1 3 msec 3 msec 5 msec
  2 10.10.10.2 [MPLS: Labels 16/30 Exp 0] 4 msec 4 msec 4 msec
  3 172.16.4.1 [MPLS: Label 30 Exp 0] 5 msec 3 msec 5 msec
  4 172.16.4.2 4 msec *  4 msec
CE3-A#
				
			
Tags:

Leave a Reply

Related Post