Configuring BGP VPN to Default VRF Reachability
In this example, the configuration enables route re-importation through an intermediate VRF, called VRF_A, which is between
the VPN and the default VRF.
vrf context VRF_A
address-family ipv4 unicast
route-target both auto evpn
import vrf default map MAP_1 advertise-vpn
export vrf default map MAP_1 allow-vpn
Route re-importation is enabled by using the advertise-vpn option to control importing routes from the VPN into VRF_A, and allow-vpn for the export map to control exporting VPN-imported routes from VRF_A out to the default VRF. Configuration occurs on the
intermediate VRF.
Configuring VPN to VRF-Lite Reachability
In this example, the VPN connects to a tenant VRF, called VRF_A. VRF_A connects a VRF-Lite, called VRF-B. The configuration
enables VPN imported routes to be leaked from VRF_A to VRF_B.
vrf context VRF_A
address-family ipv4 unicast
route-target both auto
route-target both auto evpn
route-target import 3:3
route-target export 2:2
import vrf advertise-vpn
export vrf allow-vpn
vrf context VRF_B
address-family ipv4 unicast
route-target both 1:1
route-target import 2:2
route-target export 3:3
Route leaking between the two is enabled by using the allow-vpn in an export map configured in VRF_A (tenant). The export map in VRF_A allows route imported from the VPN to be leaked into
the VRF_B. Routes processed by the export map have the route-map export and export-map attributes added to the route's set of route targets. The import map uses advertise-vpn which enables routes that are imported from the VRF-Lite for be exported out to the VPN.
After a route leaks between the VRFs, it is reoriginated and its route targets are replaced by the route target export and
export map attributes specified by the new VRF's configuration.
Leaf-to-Leaf Reachability
In this example, two VPNs exist and two VRFs exist. VPN_1 is connected to VRF_A and VPN_2 is connected to VRF_B. Both VRFs
are route distinguishers (RDs).
vrf context VRF_A
address-family ipv4 unicast
route-target both auto
route-target both auto evpn
route-target import 3:3
route-target export 2:2
import vrf advertise-vpn
export vrf allow-vpn
vrf context VRF_B
address-family ipv4 unicast
route-target both 1:1
route-target import 2:2
route-target export 3:3
import vrf advertise-vpn
export vrf allow-vpn
Route leaking between the two is enabled by using the allow-vpn in an export map configured in VRF_A and VRF_B. VPN imported routes have route-map export and export-map attributes added to the route's set of route targets. The import map uses advertise-vpn option which enables routes that are imported from each VRF to be exported out to the VPN.
After a route leaks between the VRFs, it is reoriginated and its route targets are replaced by the route target export and
export map attributes specified by the new VRF's configuration.
Leaf-to-Leaf with Loop Prevention
In the leaf-to-leaf configuration, you can inadvertently cause loops between the BLs that are leaking between the same VRFs
unless you are careful with your route maps:
-
You can use an inbound route map in each BL to deny updates from every other BL.
-
If a BL originates a route, a standard community can be applied, which enables other BLs to accept the routes. This community
is then stripped in the receiving BL.
In the following example, VTEPs 3.3.3.3, 4.4.4.4 and 5.5.5.5 are the BLs.
ip prefix-list BL_PREFIX_LIST seq 5 permit 3.3.3.3/32
ip prefix-list BL_PREFIX_LIST seq 10 permit 4.4.4.4/32
ip prefix-list BL_PREFIX_LIST seq 20 permit 5.5.5.5/32
ip community-list standard BL_COMMUNITY seq 10 permit 123:123
route-map INBOUND_MAP permit 5
match community BL_COMMUNITY
set community none
route-map INBOUND_MAP deny 10
match ip next-hop prefix-list BL_PREFIX_LIST
route-map INBOUND_MAP permit 20
route-map OUTBOUND_SET_COMM permit 10
match evpn route-type 2 mac-ip
set community 123:123
route-map SET_COMM permit 10
set community 123:123
route-map allow permit 10
vrf context vni100
vni 100
address-family ipv4 unicast
route-target import 2:2
route-target export 1:1
route-target both auto
route-target both auto evpn
import vrf advertise-vpn
export vrf allow-vpn
vrf context vni200
vni 200
address-family ipv4 unicast
route-target import 1:1
route-target export 2:2
route-target both auto
route-target both auto evpn
import vrf advertise-vpn
export vrf allow-vpn
router bgp 100
template peer rr
remote-as 100
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-map INBOUND_MAP in
route-map OUTBOUND_SET_COMM out
neighbor 101.101.101.101
inherit peer rr
neighbor 102.102.102.102
inherit peer rr
vrf vni100
address-family ipv4 unicast
network 3.3.3.100/32 route-map SET_COMM
vrf vni200
address-family ipv4 unicast
network 3.3.3.200/32 route-map SET_COMM
In this example, the tenant VRFs for the border leaf (BL) router can leak traffic by enabling extra import export flows, and
the route targets in the route maps determine where the routes are imported from or exported to.
Multipath in a VRF
In this example, a VPN has multiple incoming paths. This configuration enables route leaking through an intermediate VRF,
called VRF_A, which is between the VPN and another VRF, named VRF_B. Assume that multipathing is enabled in VRF_A.
vrf context VRF_A
address-family ipv4 unicast
route-target both auto evpn
route-target export 3:3
export vrf allow-vpn
vrf context VRF_B
address-family ipv4 unicast
route-target import 3:3
Route leaking is enabled by allow-vpn in the export map configured in VRF_A. When two paths for a given prefix are learnt from a VPN and imported into VRF_A, two
different paths exist in VRF_B with the same source RD (VRF_A’s local RD). Each route is distinguished by the original source
RD (remote RD).
Path Duplication
In this example, the configuration enables a single VPN path to be imported into both VRF_A and VRF_B. Because VRF_A is configured
with export vrf allow-vpn , VRF_A also leaks its routes into VRF_B. VRF_B then has two paths with same source RD (VRF_A's local RD), each one distinguished
by the original source RD (remote RD).
vrf context VRF_A
address-family ipv4 unicast
route-target import 1:1 evpn
route-target export 1:1 evpn
route-target export 2:2
export vrf allow-vpn
vrf context VRF_B
address-family ipv4 unicast
route-target import 1:1 evpn
route-target import 2:2
This configuration creates a situation in which multipathing does not exist.
Feedback