L3VPN Extranet

Lab file

Startup configs

IP addressing, IGP, Segment Routing, and BGP on the CEs is already configured.

The objective is to configure three L3VPN services, and allow the PARNTER1 L3VPN to have access to the loopbacks of each customer router. Additionally, each customer L3VPN service should have access to the 192.0.2.0/24 network. The idea is that the partner needs to manage these separate customers. So the partner needs reachability into the customer L3VPNs.

NAT is already configured on the customer CEs. The R2 customer routers will be NATed to 10.255.255.X and should be able to ping 192.0.2.2.

You will need to configure BGP on the provider network, but throughout this entire exercise you should not need to make any changes to customer routers.

The routing table of each CE should appear as follows:

CUSTOMER1_R1#show ip route bgp | be Gateway
Gateway of last resort is not set

B     192.0.2.0/24 [20/0] via 100.64.0.1, 00:16:40

CUSTOMER2_R1#show ip route bgp | be Gateway
Gateway of last resort is not set

B     192.0.2.0/24 [20/0] via 100.64.0.1, 00:16:05

PARTNER1_R1#show ip route bgp | be Gateway
Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 3 subnets
B        10.255.255.1 [20/0] via 100.64.0.1, 00:16:23
B        10.255.255.2 [20/0] via 100.64.0.1, 00:16:23

R2 of each customer should be able to ping 192.0.2.2:

CUSTOMER1_R2#ping 192.0.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/22/65 ms

CUSTOMER2_R2#ping 192.0.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Answers

First you must run iBGP inside the service provider network. You can simply run iBGP between PE1 and PE3, creating a BGP-free core. You will need to peer with each CE. They are all 100.64.0.2 with remote-as 65000. On PE3_XR you will need a route-policy that passes all routes received and advertised because these are eBGP neighbors (i.e. route-policy PASS in/out).

Next you will need to import PARTNER1 routes into the customer VRFs and import the customer 10.255.255.X/32 loopbacks into the PARTNER1 VRF. To do this you import 10:10 into each customer VRF, and import 1:1 and 2:2 into the PARTNER1 VRF.

The problem is that we must filter the routes that are imported so we don’t get the LAN routes. On PE1 you can use an import map such as this:

vrf definition CUSTOMER1
 rd 1:1
 route-target export 1:1
 route-target import 1:1
 route-target import 10:10
 !
 address-family ipv4
  import map PARTNER1_IMPORT_MAP
 exit-address-family
!
route-map CUSTOMER1_RM permit 10 
 match ip address prefix-list PARTNER_SUBNET
 match extcommunity 1
route-map CUSTOMER1_RM permit 20 
 match extcommunity 2
route-map CUSTOMER1_RM deny 30
!
ip prefix-list PARTNER1_PREFIX seq 5 permit 192.0.2.0/24
!
ip extcommunity-list 1 permit rt 10:10
ip extcommunity-list 2 permit rt 1:1
  • The logic of the route-map is that only the partner subnet is imported with RT 10:10, then any route with RT 1:1 is imported, and anything else is denied.

On PE3_XR you will need a route-policy such as this:

vrf CUSTOMER2
 address-family ipv4 unicast
  import route-policy PARTNER1_EXTRANET
  import route-target
   2:2
   10:10
  !
  export route-target
   2:2
!
route-policy PARTNER1_EXTRANET
  if extcommunity rt matches-any (10:10) then
    if destination in (192.0.2.0/24) then
      pass
    else
      drop
    endif
  endif
  pass
end-policy

I will leave it to you to figure out the route-policy for routes imported into the PARTNER1 VRF.

Finally, you will notice that none of these imported routes are accepted by the CEs. This is because they all use AS 65000 so they reject the route due to loop avoidance. You can use as-override on each CE neighbor to change the AS path from 100 65000 i to 100 100 i

Last updated