Hello Cliff,
you have made a progress as now the IP subnets in the two VRFs are different.
However, the two managers will likely want to access the Internet or other resources that are in the global routing table.
>> Concerning, "perform route leakage between each VRF and a default route coming from the global routing table." Could you please provide me some basic configs or a place where I can find out how to configure this?
You can follow the below document that provides you the full context on how to allow VRF users to access the internet.
https://community.cisco.com/t5/service-providers-documents/mpls-l3vpn-internet-access-option-1/ta-p/3823551
The simplest approach is to use static routing with additional parameters to perform the route leakage between each defined VRF and the global routing table.
ip route vrf BOSS1 0.0.0.0 0.0.0.0 192.168.12.2 global
ip route vrf BOSS2 0.0.0.0 0.0.0.0 192.168.12.2 global
You need also to ensure the return path to your subnets in VRF from the global routing table.
see also the following document
https://community.cisco.com/t5/service-providers-documents/providing-internet-access-for-mpls-l3-vpns/ta-p/3109924
In both documents they use NAT so the return path to VRFs is solved without a routing configuration.
on the remote PE node that is hosting the Enclave server you need the following
vrf definition Enclave-Server
rd 3:3
route-target import 1:1
route-target import 2:2
route-target export 3:3
address-family ipv4
exit-address-family
+
MP BGP configuration for AF vrf Enclave-Server
Note:
you need an end to end MPLS path between the local PE and the datacenter PE (mpls ip on all links between them)
You need a VPNv4 MP iBGP session between local PE and remote data center PE directly or via route reflector.
You need to activate the neighbor and to send community extended (route targets are extended communities).
Local PE node vrf BOSS1 and vrf BOSS2 must add a route-target import 3:3 to accept the routes coming from the datacenter PE via VPNv4 advertisements.
I know we are missing the return path for internet access from global routing table to the VRFs.
I will try to add it later
Edit:
a possible approach is to use PBR policy based routing on the global routing table interface that receives traffic destined to a VRF subnet
see the following thread
https://community.cisco.com/t5/switching/route-leaking-from-global-to-vrf-using-static-routes-only/td-p/2924086?dtid=osscdc000283
The key command in the route-map is the set vrf <vrf-name> that allows to move the traffic to the desired VRF.
In your case the route-map should use two blocks one for vrf BOSS1 and one for VRF BOSS2.
!access-list to select traffic
ip access-list extended to-BOSS1
permit ip any 10.100.1.0 0.0.0.255
p access-list extended to-BOSS2
permit ip any 10.100.2.0 0.0.0.255
!Route map to set the vrf
route-map TO-VRFs permit 10
match ip address to-BOSS1
set vrf BOSS1
route-map TO-VRFs permit 20
match ip address to-BOSS2
set vrf BOSS2
The route-map has to be applied on the local PE node on an interface on the return path from the internet.
PBR works only inbound.
Hope to help
Giuseppe
