The following is a sample topology that is used as an example to explain the VRF Route Sharing in a hybrid cloud:
In the above-mentioned topology, the CSR 1000v instance is deployed on the VM of the public cloud. Site A is an ACI deployment
site, while Site B is the public cloud. Leaf 1 and Leaf 2 are the Virtual Port Channel (vPC) pair for ACI. These two vPCs
are configured with different Route Distinguishers (RD). Here, VRF 1 and VRF 2 are configured on the vPC pair for ACI. For
example,
VRF1 - RT:RT-EVPN-1, prefix:1.1.1.1
VRF2 - RT:RT-EVPN-2, prefix:2.2.2.2
VRF3 and VRF4 are configured on the CSR 1000v instance. These two VRFs pair with the Voice Gateway (VGW), and these two VRFs
have two different Route Targets (RT). For example,
VRF3 – RT for EVPN: RT-EVPN-3, RT for IP BGP: RT-3, prefix:3.3.3.3
VRF4 – RT for EVPN: RT-EVPN-4, RT for IP BGP: RT-4, prefix:4.4.4.4
In the topology, the BGP-EVPN fabric is present between the ACI and the CSR 1000v instance in the public cloud and the IP
BGP protocol is used between the CSR 1000v instance and the Cloud Service Provider such as Azure. The BGP-EVPN fabric redistributes
the stitching routes between the EVPN and the IP BGP.
To enable the traffic flow between the ACI Site and the Public Cloud, both ACI and the CSR 1000v instance need to support
VRF Route Sharing.
The CSR 1000v instance must be able to import the EVPN routes of VRF1 and VRF2 from ACI into VRF3 and VRF4. The IP BGP on
the CSR side then redistributes the routes to the VGW in the public cloud.
Note |
When the VTEP (VxLAN Tunnel Endpoint) IP and the RMAC (Route MAC addrress) are the same for two leafs, and the VNIC alone
differs, the CSR1000v instance can forward the traffic across the tunnel.
|
Use Cases
Using the same sample topology, here are the use cases for configuring VRF Route Sharing in a CSR 1000v instance:
-
When VRF1 and VRF2 can talk to VRF3, but VRF3 and VRF4 cannot talk to each other, perform the following configuration:
vrf definition VRF3
rd 300:1
address-family ipv4
route-target export RT-EVPN-3 stitching
route-target import RT-EVPN-1 stitching
route-target import RT-EVPN-2 stitching
vrf definition VRF4
rd 400:1
address-family ipv4
-
When VRF1 and VRF2 can talk to VRF3&4, but VRF3 and VRF4 cannot talk to each other, perform the following configuration:
vrf definition VRF3
rd 300:1
address-family ipv4
route-target export RT-EVPN-3 stitching
route-target import RT-EVPN-1 stitching
route-target import RT-EVPN-2 stitching
vrf definition VRF4
rd 400:1
address-family ipv4
route-target export RT-EVPN-4 stitching
route-target import RT-EVPN-1 stitching
route-target import RT-EVPN-2 stitching
-
When VRF1 and VRF2 can talk to VRF3, but VRF3 and VRF4 can talk to each other, perform the following configuration:
vrf definition VRF3
rd 300:1
address-family ipv4
route-target export RT-EVPN-3 stitching
route-target import RT-EVPN-1 stitching
route-target import RT-EVPN-2 stitching
route-target export RT-3
route-target import RT-4
vrf definition VRF4
rd 400:1
address-family ipv4
route-target import RT-3
route-target export RT-4
-
When VRF1 and VRF2 can talk to VRF3&4, but VRF3 and VRF4 can talk to each other, perform the following configuration:
vrf definition VRF3
rd 300:1
address-family ipv4
route-target export RT-EVPN-3 stitching
route-target import RT-EVPN-1 stitching
route-target import RT-EVPN-2 stitching
route-target export RT-3
route-target import RT-4
vrf definition VRF4
rd 400:1
address-family ipv4
route-target export RT-EVPN-4 stitching
route-target import RT-EVPN-1 stitching
route-target import RT-EVPN-2 stitching
route-target import RT-3
route-target export RT-4
Note |
For the above-mentioned use case, the CSR 1000v instance must configure EVPN on both VRF3 and VRF4.
Even IP BGP already imports all the routes from VRF3 and VRF4, BGP does not advertise the imported routes of the VRF to the
EVPN peer.
|
You need to use the Stitching keyword in the configuration only when the sharing happens across the EVPN.