EVPN IP-VRF-to-IP-VRF Models
This chapter provides information about EVPN IP-VRF-to-IP-VRF models.
Topics in this chapter include:
Applicability
This chapter was initially written based on SR OS Release 16.0.R3, but the MD-CLI in the current edition corresponds to SR OS Release 23.7.R2. SR OS supports the three EVPN IP-VRF-to-IP-VRF models described in draft-ietf-bess-evpn-prefix-advertisement.
Overview
EVPN is considered the standard for Data Centers (DCs) and DC Interconnect (DCI) for layer 2 and layer 3 services. Draft-ietf-bess-evpn-prefix-advertisement describes the following three IP-VRF-to-IP-VRF models:
Interface-less model (mandatory)
Interface-ful model with Supplementary Broadcast Domain (SBD) Interworking Routing and Bridging (IRB) (mandatory)
Interface-ful model with unnumbered SBD IRB (optional)
In standard terminology, SBD is the Broadcast Domain (BD) that joins two IP-VRFs. In SR OS, the SBD is a "backhaul" R-VPLS service that connects two PEs attached to VPRNs of the same VPN. For IP prefix advertisement in the SBD, IP route advertisement needs to be enabled in the BGP-EVPN context, whereas MAC advertisement is enabled by default. BGP-EVPN IP prefix route type 5 (RT-5) updates are used in all models; MAC/IP routes (RT-2) are used in the interface-ful models only. In the interface-less model, MAC advertisement must be disabled.
Interface-ful SBD IRB and Interface-ful unnumbered SBD IRB show the two interface-ful IP-VRF-to-IP-VRF models: SBD IRB and unnumbered SBD IRB. Both interface-ful SBD IRB models require BGP-EVPN IP prefix routes (RT-5) with recursive lookup to MAC/IP routes (RT-2). Host 1 is located in broadcast domain 1 (BD1 corresponds to an R-VPLS) linked to the VRF in PE-1 and host 2 is located in BD2 linked to the VRF in PE-2. The VRFs correspond to VPRNs that are linked to an SBD, which is a backhaul R-VPLS.
The following examples are based on EVPN-VXLAN, but IP-VRF-to-IP-VRF also works for EVPN-MPLS. Instead of the VNI, the MPLS label is then included in the RT-5 and RT-2 updates.
The interface-ful SBD IRB model requires an IP address on the VPRN interface for the SBD (IP2 on PE-2); no EVPN tunnel can be used. Both PEs will send BGP-EVPN RT-5 (IP prefix) and BGP-EVPN RT-2 (MAC/IP) updates. PE-2 sends an RT-5 update for IP prefix 10.0.2.0/24 with GW IP address IP2 and an RT-2 update for GW IP address IP2 with MAC2 and next-hop PE-2. On PE-1, the prefix 10.0.2.0/24 appears in the VRF route table as an EVPN route with next-hop GW IP2. The ARP table for the VRF contains the corresponding MAC address MAC2 for the GW IP address IP2. The FDB of the SBD includes an EVPN entry for GW MAC address MAC2 with next-hop PE-2.
When the VPRN is configured toward the SBD with an EVPN tunnel rather than a numbered IP interface, the RT-5 update will contain the GW MAC address MAC2 instead of the GW IP address IP2. Interface-ful unnumbered SBD IRB shows that PE-2 sends an RT-5 update for IP prefix 10.0.2.0/24 with GW MAC address MAC2 and an RT-2 update for GW MAC address MAC2 with next-hop PE-2. Again, a recursive lookup is done.
Finally, in the interface-less IP-VRF-to-IP-VRF model, MAC advertisement is disabled in the BGP-EVPN context of the backhaul R-VPLS. BGP-EVPN RT-5 updates will contain the GW MAC address, and no RT-2 updates will be sent; therefore, the number of BGP-EVPN updates is reduced and no recursive lookup is done on PE-1. PE-1 adds an entry in its FDB based on an RT-5 route instead of an RT-2 route from PE-2. Interface-less IP-VRF-to-IP-VRF model shows the interface-less IP-VRF-to-IP-VRF model where PE-2 sends an RT-5 update with GW MAC address MAC2.
Other vendors do not use a service context as the R-VPLS EVPN tunnel shown in Interface-less IP-VRF-to-IP-VRF model, and they configure the route targets used for the RT-5 updates in the VPRN (or VRF) instances. When interoperating with those vendors, ensure that the R-VPLS route targets match the route targets in the VRF of the third-party router.
EVPN interface-less (EVPN IFL) for Ethernet Network Virtualization Overlay (NVO) tunnels
Ethernet NVO indicates that the EVPN packets contain an inner Ethernet header. The ingress PE uses the received router's MAC extended community address in the IP prefix route as the inner destination MAC address for the EVPN packets sent to the prefix. This corresponds to the scenario described in Interface-less IP-VRF-to-IP-VRF model.EVPN IFL for IP NVO tunnels
IP NVO indicates that the EVPN packets contain an inner IP packet, but no Ethernet header. This is similar to the IP-VPN packets exchanged between PEs. In this scenario, the IP prefix route does not contain any GW (IP or MAC) address. The IP packets are directly encapsulated with an EVPN service label and the transport labels. This model is described further in Interface-less model in EVPN-MPLS with IP encapsulation.
EVPN MAC selection criteria
In the EVPN IFL for Ethernet NVO scenario, the MAC address entry in the R-VPLS FDB that is required to forward packets to the remote PE is obtained from an internal MAC/IP route. This internal route is obtained from the router MAC extended community in the BGP-EVPN RT-5 update. In case the same MAC address is received in multiple ways, the following MAC selection criteria apply. Beginning with criterion (1), the MAC is selected if the criterion is met, or the next criterion is applied. As indicated in (8), a MAC received from an RT-2 has higher priority than a MAC populated by the router MAC extended community in an RT-5 update.
Conditional static MAC addresses (locally protected MAC addresses)
Auto-learned protected MAC addresses (locally learned MAC addresses on SAPs or SDP-bindings due to the configuration of auto-learn-mac-protect)
EVPN ES PBR MAC addresses
EVPN static MAC addresses (remotely protected MAC addresses)
Data plane learned MAC addresses (regular learning on SAPs or SDP-bindings)
EVPN MAC routes with a higher sequence number
EVPN E-Tree root MAC addresses
EVPN non-RT-5 MAC addresses (this tie-breaking rule is only applied if the selection algorithm is comparing received MAC routes (RT-2) and internal MAC routes derived from the MAC addresses in IP-prefix routes, such as RT-5 MACs)
Lowest IP address for the next-hop of the EVPN NLRI
Lowest Ethernet tag (that will be zero for MPLS and might be different from zero for VXLAN)
Lowest route distinguisher
Lowest BGP instance (this tie-breaking rule is only applied if the preceding rules fail to select a unique MAC address and the service has two BGP instances of the same encapsulation)
EVPN IP-VRF-to-IP-VRF model comparison
Each model has its advantages. EVPN IP-VRF-to-IP-VRF model comparison compares the three IP-VRF-to-IP-VRF models.
Advantage |
Model 1 Interface-less |
Model 2 Interface-ful SBD IRB |
Model 3 Interface-ful unnumbered SBD IRB |
|---|---|---|---|
Reduced number of EVPN routes |
Yes |
No |
No |
Ease of provisioning (no IP address on core IRB) |
Yes |
No |
Yes |
Mass withdrawal due to recursive resolution |
No |
Yes |
Yes |
Configuration
The following use cases are documented in this chapter:
IP-VRF-to-IP-VRF model in EVPN-VXLAN
Example topology with services - EVPN-VXLAN shows the example topology with two PEs. Hosts 1 and 2—emulated through VPRNs—are attached to R-VPLS 1 and 2 respectively.
The initial configuration on the PEs includes the following:
Cards, MDAs, ports
Router interfaces
IS-IS (alternatively, OSPF can be used)
BGP for address family EVPN
On PE-1, the BGP configuration is as follows. The BGP configuration on PE-2 is similar.
# on PE-1:
configure {
router "Base" {
autonomous-system 64500
bgp {
vpn-apply-export true
vpn-apply-import true
rapid-withdrawal true
rapid-update {
evpn true
}
group "dc" {
type internal
family {
evpn true
}
}
neighbor "192.0.2.2" {
group "dc"
ebgp-default-reject-policy {
import false
export false
}
}
}Interface-ful model with SBD IRB in EVPN-VXLAN
The service configuration on PE-1 includes the SBD R-VPLS "sbd-15", VPRN "ip-vrf-151", and R-VPLS "bd-1". The service configuration on PE-2 is similar, but R-VPLS "bd-2" is configured instead of R-VPLS "bd-1".
On PE-1, SBD R-VPLS "sbd-15" is configured with VNI 15, as follows. MAC advertisement is enabled by default, but IP route advertisement must be enabled explicitly. Only one BGP instance and one VXLAN instance are configured.
# on PE-1:
configure {
service {
vpls "sbd-15" {
admin-state enable
description "backhaul R-VPLS 15"
service-id 15
customer "1"
vxlan {
instance 1 {
vni 15
}
}
routed-vpls {
}
bgp 1 {
}
bgp-evpn {
evi 15
routes {
ip-prefix {
advertise true
}
}
vxlan 1 {
admin-state enable
vxlan-instance 1
}
}
}
VPRN "ip-vrf-151" has two interfaces: one toward the SBD R-VPLS "sbd-15" and one toward BD R-VPLS "bd-1". The interface toward the SBD has GW IP address 172.16.151.1/24 and MAC address 00:00:00:01:51:01. The interface toward R-VPLS 1 has IP address 10.0.1.1/24 and MAC address 00:00:00:1e:01:01. VRRP is configured in passive mode, so PE-1 uses the backup IP address as an anycast gateway. The backup IP address is 10.0.1.254 and the auto-derived virtual MAC address is 00:00:5e:00:00:01 for VRID 1. On PE-1, VPRN "ip-vrf-151" is configured as follows:
# on PE-1:
configure {
service {
vprn "ip-vrf-151" {
admin-state enable
service-id 151
customer "1"
ecmp 2
interface "int-bd-1" {
mac 00:00:00:1e:01:01
ipv4 {
primary {
address 10.0.1.1
prefix-length 24
}
vrrp 1 {
backup [10.0.1.254]
passive true
ping-reply true
traceroute-reply true
}
}
vpls "bd-1" {
}
}
interface "int-sbd-15" {
mac 00:00:00:01:51:01
ipv4 {
primary {
address 172.16.151.1
prefix-length 24
}
}
vpls "sbd-15" {
}
}
}
On PE-1, R-VPLS "bd-1" is configured as follows. Host 1 is attached to the SAP.
# on PE-1:
configure {
service {
vpls "bd-1" {
admin-state enable
description "R-VPLS 1 - BD 1"
service-id 1
customer "1"
routed-vpls {
}
sap pxc-10.a:1 {
}
}
In this example, host 1 is simulated by VPRN "host1", as follows. The default route has next-hop 10.0.1.254, which is the VRRP backup address in VPRN "ip-vrf-151".
# on PE-1:
configure {
service {
vprn "host1" {
admin-state enable
description "Host-1 attached to R-VPLS 1"
service-id 11
customer "1"
interface "local" {
mac 00:00:00:10:11:01
ipv4 {
primary {
address 10.0.1.111
prefix-length 24
}
}
sap pxc-10.b:1 {
}
}
static-routes {
route 0.0.0.0/0 route-type unicast {
next-hop "10.0.1.254" {
admin-state enable
}
}
}
}
The service configuration on PE-2 is similar, with R-VPLS "bd-2" instead of R-VPLS "bd-1" and VPRN "host2" instead of VPRN "host1". The GW IP address on PE-2 is 172.16.151.2/24, interface "int-bd-2" in VPRN "ip-vrf-151" has IP address 10.0.2.2/24, and host "host2" has IP address 10.0.2.222/24.
PE-1 receives a BGP-EVPN RT-5 update from PE-2 for IP prefix 10.0.2.0/24, as follows. The GW address is IP address 172.16.151.2 and the next-hop is PE-2.
[/]
A:admin@PE-1# show router bgp routes evpn ip-prefix
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN IP-Prefix Routes
===============================================================================
Flag Route Dist. Prefix
Tag Gw Address
NextHop
Label
ESI
-------------------------------------------------------------------------------
u*>i 192.0.2.2:15 10.0.2.0/24
0 172.16.151.2
192.0.2.2
VNI 15
ESI-0
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
PE-1 receives the following BGP-EVPN MAC update for MAC address 00:00:00:01:51:02, which corresponds to GW IP 172.16.151.2:
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:15 00:00:00:01:51:02 ESI-0
0 Static VNI 15
172.16.151.2
192.0.2.2
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
The following traceroute on PE-1 from host 1 to host 2 shows that the first hop is 10.0.1.1 (interface "int-bd-1" in VPRN "ip-vrf-151" on PE-1), the second hop is the IP GW address 172.16.151.2 (interface "int-sbd-15" in VPRN "ip-vrf-151" on PE-2), and the third hop is host 2 with IP address 10.0.2.222:
[/]
A:admin@PE-1# traceroute 10.0.2.222 router-instance "host1" source-address 10.0.1.111
traceroute to 10.0.2.222 from 10.0.1.111, 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 2.27 ms 1.29 ms 1.45 ms
2 172.16.151.2 (172.16.151.2) 2.75 ms 2.09 ms 2.45 ms
3 10.0.2.222 (10.0.2.222) 6.29 ms 2.97 ms 3.20 ms
On PE-1, the following route table for VPRN "ip-vrf-151" contains a EVPN interface-ful (EVPN IFF) route for IP prefix 10.0.2.0/24 with next-hop 172.16.151.2 and preference 169 (whereas BGP-VPN routes for IP-VPN have a preference of 170):
[/]
A:admin@PE-1# show router service-name "ip-vrf-151" route-table
===============================================================================
Route Table (Service: 151)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.0.1.0/24 Local Local 00h03m12s 0
int-bd-1 0
10.0.2.0/24 Remote EVPN-IFF 00h02m49s 169
172.16.151.2 0
172.16.151.0/24 Local Local 00h03m12s 0
int-sbd-15 0
-------------------------------------------------------------------------------
No. of Routes: 3
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
On PE-1, the following ARP table of VPRN "ip-vrf-151" contains an EVPN entry for GW IP address 172.16.151.2:
[/]
A:admin@PE-1# show service id "ip-vrf-151" arp
===============================================================================
ARP Table
===============================================================================
IP Address MAC Address Type Expiry Interface SAP
-------------------------------------------------------------------------------
10.0.1.1 00:00:00:1e:01:01 Other 00h00m00s int-bd-1 rvpls
10.0.1.111 00:00:00:10:11:01 Dynamic 03h59m17s int-bd-1 rvpls
10.0.1.254 00:00:5e:00:01:01 Other 00h00m00s int-bd-1 rvpls
172.16.151.1 00:00:00:01:51:01 Other 00h00m00s int-sbd-15 rvpls
172.16.151.2 00:00:00:01:51:02 EVPN 00h00m00s int-sbd-15 rvpls
===============================================================================
The following FDB on PE-1 shows a static and protected EVPN entry for MAC address 00:00:00:01:51:02:
[/]
A:admin@PE-1# show service id "sbd-15" fdb detail
===============================================================================
Forwarding Database, Service 15
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
15 00:00:00:01:51:01 cpm Intf 10/26/23 08:52:31
15 00:00:00:01:51:02 vxlan-1: EvpnS:P 10/26/23 08:52:54
192.0.2.2:15
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend:L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf T=Trusted
===============================================================================
Interface-ful model with unnumbered SBD IRB in EVPN-VXLAN
On both PEs, the GW IP addresses 172.16.151.x/24 are removed from interface "int-sbd-15" in VPRN "ip-vrf-151" and an EVPN tunnel is configured instead. The changes in the configuration of VPRN "ip-vrf-151" are the following:
# on PE-1, PE-2:
configure {
service {
vprn "ip-vrf-151" {
interface "int-sbd-15" {
delete ipv4
vpls "sbd-15" {
evpn-tunnel {
}
}
}
The configuration of VPRN "ip-vrf-151" on PE-1 is as follows:
[ex:/configure service vprn "ip-vrf-151"]
A:admin@PE-1# info
admin-state enable
service-id 151
customer "1"
ecmp 2
interface "int-bd-1" {
mac 00:00:00:1e:01:01
ipv4 {
primary {
address 10.0.1.1
prefix-length 24
}
vrrp 1 {
backup [10.0.1.254]
passive true
ping-reply true
traceroute-reply true
}
}
vpls "bd-1" {
}
}
interface "int-sbd-15" {
mac 00:00:00:01:51:01
vpls "sbd-15" {
evpn-tunnel {
}
}
}
The provisioning is easier with unnumbered SBD IRB because no IRB IP addresses need to be configured in the VPRN.
PE-1 receives the following RT-5 update for IP prefix 10.0.2.0/24 with GW MAC address 00:00:00:01:51:02, because there is no GW IP address. The GW MAC address is used in the VPRN route table, where the EVPN tunnel leads toward this GW MAC address.
[/]
A:admin@PE-1# show router bgp routes evpn ip-prefix
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN IP-Prefix Routes
===============================================================================
Flag Route Dist. Prefix
Tag Gw Address
NextHop
Label
ESI
-------------------------------------------------------------------------------
u*>i 192.0.2.2:15 10.0.2.0/24
0 00:00:00:01:51:02
192.0.2.2
VNI 15
ESI-0
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
MAC advertisement is by default enabled, so PE-1 also receives the following RT-2 update for the GW MAC address. The interface is unnumbered, so there is no corresponding IP address.
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:15 00:00:00:01:51:02 ESI-0
0 Static VNI 15
n/a
192.0.2.2
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
The following traceroute from host 1 to host 2 shows that the second hop now is 10.0.2.2, which corresponds to the "bd-2" interface in VPRN "ip-vrf-151" on PE-2. The other hops remain the same as in the preceding case.
[/]
A:admin@PE-1# traceroute 10.0.2.222 router-instance "host1" source-address 10.0.1.111
traceroute to 10.0.2.222 from 10.0.1.111, 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 1.24 ms 1.01 ms 1.38 ms
2 10.0.2.2 (10.0.2.2) 2.08 ms 1.78 ms 2.32 ms
3 10.0.2.222 (10.0.2.222) 2.89 ms 2.41 ms 2.35 ms
The following route table of VPRN "ip-vrf-151" on PE-1 shows a EVPN IFF route for IP prefix 10.0.2.0/24 with EVPN tunnel (ET) to GW MAC address 00:00:00:01:51:02 in VPRN "ip-vrf-151" on PE-2.
[/]
A:admin@PE-1# show router service-name "ip-vrf-151" route-table
===============================================================================
Route Table (Service: 151)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.0.1.0/24 Local Local 00h07m23s 0
int-bd-1 0
10.0.2.0/24 Remote EVPN-IFF 00h02m38s 169
int-sbd-15 (ET-00:00:00:01:51:02) 0
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
The following ARP table for VPRN "ip-vrf-151" does not contain any entries for the unnumbered interface "int-sbd-15":
[/]
A:admin@PE-1# show service id "ip-vrf-151" arp
===============================================================================
ARP Table
===============================================================================
IP Address MAC Address Type Expiry Interface SAP
-------------------------------------------------------------------------------
10.0.1.1 00:00:00:1e:01:01 Other 00h00m00s int-bd-1 rvpls
10.0.1.111 00:00:00:10:11:01 Dynamic 03h55m06s int-bd-1 rvpls
10.0.1.254 00:00:5e:00:01:01 Other 00h00m00s int-bd-1 rvpls
===============================================================================
However, internally, ARP entries are created. The following command shows that the same number of ARP entries are consumed as in the preceding use case with the numbered interface "int-sbd-15". The BGP-EVPN ARP entry corresponds to the GW interface "int-sbd-15" on the BGP peer.
[/]
A:admin@PE-1# show router service-name "ip-vrf-151" arp summary
============================================================
ARP Table Summary (Service: 151)
============================================================
Local ARP Entries : 3
Static ARP Entries : 0
Dynamic ARP Entries : 1
Managed ARP Entries : 0
Internal ARP Entries : 0
BGP-EVPN ARP Entries : 1
------------------------------------------------------------
No. of ARP Entries : 5
============================================================
The FDB for R-VPLS "ip-vrf-151" on PE-1 is as follows:
[/]
A:admin@PE-1# show service id "sbd-15" fdb detail
===============================================================================
Forwarding Database, Service 15
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
15 00:00:00:01:51:01 cpm Intf 10/26/23 08:52:31
15 00:00:00:01:51:02 vxlan-1: EvpnS:P 10/26/23 08:57:14
192.0.2.2:15
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend:L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf T=Trusted
===============================================================================
Interoperable interface-less model in EVPN-VXLAN
This model is interface-less because no SBD is required to connect the VPRNs and no recursive resolution is required upon receiving an IP prefix route. The next-hop of the IP prefix route is directly resolved to an EVPN tunnel, without the need for any other route.
The only difference from the preceding configuration is that MAC route advertisement is disabled in the backhaul R-VPLS on both PEs, as follows:
# on PE-1, PE-2:
configure {
service {
vpls "sbd-15" {
bgp-evpn {
routes {
mac-ip {
advertise false
}
}
The configuration of the backhaul R-VPLS is as follows:
[ex:/configure service vpls "sbd-15"]
A:admin@PE-1# info
admin-state enable
description "backhaul R-VPLS 15"
service-id 15
customer "1"
vxlan {
instance 1 {
vni 15
}
}
routed-vpls {
}
bgp 1 {
}
bgp-evpn {
evi 15
routes {
mac-ip {
advertise false
}
ip-prefix {
advertise true
}
}
vxlan 1 {
admin-state enable
vxlan-instance 1
}
}
Again, the provisioning is easier with unnumbered SBD IRB because no IRB IP addresses need to be configured in the VPRN.
PE-1 receives the following BGP-EVPN RT-5 update for IP prefix 10.0.2.0/24 with GW MAC address 00:00:00:01:51:02, which is the same as in the preceding use case:
[/]
A:admin@PE-1# show router bgp routes evpn ip-prefix
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN IP-Prefix Routes
===============================================================================
Flag Route Dist. Prefix
Tag Gw Address
NextHop
Label
ESI
-------------------------------------------------------------------------------
u*>i 192.0.2.2:15 10.0.2.0/24
0 00:00:00:01:51:02
192.0.2.2
VNI 15
ESI-0
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
PE-1 does not receive any BGP-EVPN RT-2 updates because PE-2 does not advertise any MAC addresses in the backhaul R-VPLS, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
No Matching Entries Found.
===============================================================================
The following traceroute from host 1 to host 2 shows that the second hop is the IP address of the "int-bd-2" interface in VPRN "ip-vrf-151" on PE-2, as in the preceding use case:
[/]
A:admin@PE-1# traceroute 10.0.2.222 router-instance "host1" source-address 10.0.1.111
traceroute to 10.0.2.222 from 10.0.1.111, 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 1.43 ms 1.57 ms 1.33 ms
2 10.0.2.2 (10.0.2.2) 2.29 ms 2.29 ms 2.35 ms
3 10.0.2.222 (10.0.2.222) 3.15 ms 2.84 ms 2.59 ms
The following route table for VPRN "ip-vrf-151" on PE-1 shows an EVPN IFF route for IP prefix 10.0.2.0/24 with EVPN tunnel:
[/]
A:admin@PE-1# show router service-name "ip-vrf-151" route-table
===============================================================================
Route Table (Service: 151)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.0.1.0/24 Local Local 00h10m36s 0
int-bd-1 0
10.0.2.0/24 Remote EVPN-IFF 00h05m51s 169
int-sbd-15 (ET-00:00:00:01:51:02) 0
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
The following FDB in the backhaul R-VPLS on PE-1 shows an EVPN entry for GW MAC address 00:00:00:01:51:02, which is created out of the RT-5 GW MAC (router MAC extended community):
[/]
A:admin@PE-1# show service id "sbd-15" fdb detail
===============================================================================
Forwarding Database, Service 15
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
15 00:00:00:01:51:01 cpm Intf 10/26/23 08:52:31
15 00:00:00:01:51:02 vxlan-1: Evpn 10/26/23 09:01:13
192.0.2.2:15
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend:L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf T=Trusted
===============================================================================
IP-VRF-to-IP-VRF models in EVPN-MPLS
The three IP-VRF-to-IP-VRF models are also supported in EVPN-MPLS. Example topology with services - EVPN-MPLS shows the example topology with the services R-VPLS "sbd-16", VPRN "ip-vrf-161", R-VPLS "bd-3" (or "bd-4"), and VPRN "host3" for host 3 (or VPRN "host4" for host 4).
For MPLS, LDP is configured on the interface between PE-1 and PE-2.
Interface-ful model with SBD IRB in EVPN-MPLS
The following services are configured on PE-1 and PE-2:
Backhaul R-VPLS "sbd-16"
VPRN "ip-vrf-161"
R-VPLS "bd-3" on PE-1; R-VPLS "bd-4" on PE-2
VPRN "host3" on PE-1; VPRN "host4" on PE-2
The service configuration on PE-1 is as follows. MAC route advertisement is enabled by default. The configuration on PE-2 is similar.
# on PE-1:
configure {
service {
vpls "sbd-16" {
admin-state enable
description "backhaul EVPN-MPLS R-VPLS 16"
service-id 16
customer "1"
routed-vpls {
}
bgp 1 {
}
bgp-evpn {
evi 16
routes { # MAC advertisement is by default enabled
ip-prefix {
advertise true
}
}
mpls 1 {
admin-state enable
auto-bind-tunnel {
resolution any
}
}
}
}
vprn "ip-vrf-161" {
admin-state enable
service-id 161
customer "1"
ecmp 2
interface "int-bd-3" {
mac 00:00:00:3e:03:01
ipv4 {
primary {
address 10.0.3.1
prefix-length 24
}
vrrp 1 {
backup [10.0.3.254]
passive true
ping-reply true
traceroute-reply true
}
}
vpls "bd-3" {
}
}
interface "int-sbd-16" {
mac 00:00:00:01:61:01
ipv4 {
primary {
address 172.16.161.1
prefix-length 24
}
}
vpls "sbd-16" {
}
}
}
vpls "bd-3" {
admin-state enable
description "R-VPLS 3 - BD 3"
service-id 3
customer "1"
routed-vpls {
}
sap pxc-10.a:3 {
}
}
vprn "host3" {
admin-state enable
description "Host-3 attached to R-VPLS 3"
service-id 31
customer "1"
interface "local" {
mac 00:00:00:30:11:01
ipv4 {
primary {
address 10.0.3.111
prefix-length 24
}
}
sap pxc-10.b:3 {
}
}
static-routes {
route 0.0.0.0/0 route-type unicast {
next-hop "10.0.3.254" {
admin-state enable
}
}
}
}
PE-1 receives the following BGP-EVPN IP prefix route for prefix 10.0.4.0/24:
[/]
A:admin@PE-1# show router bgp routes evpn ip-prefix
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN IP-Prefix Routes
===============================================================================
Flag Route Dist. Prefix
Tag Gw Address
NextHop
Label
ESI
-------------------------------------------------------------------------------
u*>i 192.0.2.2:16 10.0.4.0/24
0 172.16.161.2
192.0.2.2
LABEL 524286
ESI-0
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
The GW address is the IP address 172.16.161.2. The following BGP-EVPN MAC route advertises the corresponding MAC address 00:00:00:01:61:02:
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:16 00:00:00:01:61:02 ESI-0
0 Static LABEL 524286
172.16.161.2
192.0.2.2
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
The following traceroute from host 3 to host 4 shows that the GW IP address is the second hop:
[/]
A:admin@PE-1# traceroute 10.0.4.222 router-instance "host3" source-address 10.0.3.111
traceroute to 10.0.4.222 from 10.0.3.111, 30 hops max, 40 byte packets
1 10.0.3.1 (10.0.3.1) 2.45 ms 1.03 ms 1.41 ms
2 172.16.161.2 (172.16.161.2) 2.27 ms 2.39 ms 2.32 ms
3 10.0.4.222 (10.0.4.222) 5.39 ms 2.62 ms 2.77 ms
The route table and ARP table in VPRN 161 and the FDB in R-VPLS 16 are similar to the ones in theInterface-ful model with SBD IRB in EVPN-VXLAN section.
Interface-ful model with unnumbered SBD IRB in EVPN-MPLS
The GW IP addresses are removed from the "int-sbd-16" interface in VPRN "ip-vrf-161" and an EVPN tunnel is configured instead. On PE-1, VPRN "ip-vrf-161" is configured as follows:
[ex:/configure service vprn "ip-vrf-161"]
A:admin@PE-1# info
admin-state enable
service-id 161
customer "1"
ecmp 2
interface "int-bd-3" {
mac 00:00:00:3e:03:01
ipv4 {
primary {
address 10.0.3.1
prefix-length 24
}
vrrp 1 {
backup [10.0.3.254]
passive true
ping-reply true
traceroute-reply true
}
}
vpls "bd-3" {
}
}
interface "int-sbd-16" {
mac 00:00:00:01:61:01
vpls "sbd-16" {
evpn-tunnel {
}
}
}
The route table in VPRN "ip-vrf-161" and the FDB in R-VPLS "sbd-16" are similar to the ones in the Interface-ful model with unnumbered SBD IRB in EVPN-VXLAN section.
Interoperable interface-less model in EVPN-MPLS with Ethernet encapsulation
In the EVPN interface-less (EVPN IFL) model, the next hop of the IP prefix route is directly resolved to an EVPN tunnel, without the need for any other route.
MAC route advertisement is disabled in backhaul R-VPLS "sbd-16", as follows:
[ex:/configure service vpls "sbd-16"]
A:admin@PE-1# info
admin-state enable
description "backhaul EVPN-MPLS R-VPLS 16"
service-id 16
customer "1"
routed-vpls {
}
bgp 1 {
}
bgp-evpn {
evi 16
routes {
mac-ip {
advertise false
}
ip-prefix {
advertise true
}
}
mpls 1 {
admin-state enable
auto-bind-tunnel {
resolution any
}
}
}
The following route table for VPRN "ip-vrf-161" contains a EVPN IFF entry for prefix 10.0.4.0/24 with an EVPN tunnel to GW MAC address 00:00:00:01:61:02:
[/]
A:admin@PE-1# show router service-name "ip-vrf-161" route-table
===============================================================================
Route Table (Service: 161)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.0.3.0/24 Local Local 00h58m13s 0
int-bd-3 0
10.0.4.0/24 Remote EVPN-IFF 00h55m46s 169
int-sbd-16 (ET-00:00:00:01:61:02) 0
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
The following FDB for VPLS "sbd-16" contains an EVPN entry for GW MAC address 00:00:00:01:61:02. This information is retrieved from a BGP-EVPN IP prefix route.
[/]
A:admin@PE-1# show service id "sbd-16" fdb detail
===============================================================================
Forwarding Database, Service 16
===============================================================================
ServId MAC Source-Identifier Type Last Change
Transport:Tnl-Id Age
-------------------------------------------------------------------------------
16 00:00:00:01:61:01 cpm Intf 10/26/23 09:07:40
16 00:00:00:01:61:02 mpls-1: Evpn 10/26/23 10:04:49
192.0.2.2:524286
ldp:65537
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend:L=Learned O=Oam P=Protected-MAC C=Conditional S=Static Lf=Leaf T=Trusted
===============================================================================
The IP prefix route for prefix 10.0.4.0/24 has GW MAC address 00:00:00:01:61:02, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn ip-prefix
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN IP-Prefix Routes
===============================================================================
Flag Route Dist. Prefix
Tag Gw Address
NextHop
Label
ESI
-------------------------------------------------------------------------------
u*>i 192.0.2.2:16 10.0.4.0/24
0 00:00:00:01:61:02
192.0.2.2
LABEL 524286
ESI-0
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
However, no EVPN MAC routes were received for R-VPLS 16, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
No Matching Entries Found.
===============================================================================
The interoperable interface-less model in EVPN-MPLS with Ethernet encapsulation is interface-ful although compatible with EVPN interface-less.
Interface-less model in EVPN-MPLS with IP encapsulation
In this IP NVO model, the ingress PE no longer pushes an inner Ethernet header, but the IP packet is directly encapsulated with an EVPN service label and the transport labels.
The PEs advertise IP prefixes without router MAC extended community. The route lookup in the VPRN does not point at an SBD R-VPLS, but rather to an MPLS tunnel terminated in the other PE. The packets are sent with an EVPN service label that was received in the IP prefix route.
The configuration of VPRN "ip-vrf-161" is modified: the interface "int-sbd-16" is removed and a BGP-EVPN context is added with route distinguisher, VRF target, and auto-bind tunnel. VPLS "sbd-16" is not used at all. The following shows the configuration of VPRN "ip-vrf-161" on PE-1:
[ex:/configure service vprn "ip-vrf-161"]
A:admin@PE-1# info
admin-state enable
service-id 161
customer "1"
ecmp 2
bgp-evpn {
mpls 1 {
admin-state enable
route-distinguisher "192.0.2.1:161"
vrf-target {
community "target:64500:161"
}
auto-bind-tunnel {
resolution any
}
}
}
interface "int-bd-3" {
mac 00:00:00:3e:03:01
ipv4 {
primary {
address 10.0.3.1
prefix-length 24
}
vrrp 1 {
backup [10.0.3.254]
passive true
ping-reply true
traceroute-reply true
}
}
vpls "bd-3" {
}
}
The configuration on PE-2 is similar.
The following route table shows that the EVPN route is interface-less, the next hop is the IP address of PE-2, and the tunnel is an MPLS (LDP) tunnel instead of an EVPN tunnel:
[/]
A:admin@PE-1# show router service-name "ip-vrf-161" route-table
===============================================================================
Route Table (Service: 161)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.0.3.0/24 Local Local 01h00m42s 0
int-bd-3 0
10.0.4.0/24 Remote EVPN-IFL 00h01m23s 170
192.0.2.2 (tunneled) 10
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
The following EVPN IP prefix does not have any GW address:
[/]
A:admin@PE-1# show router bgp routes evpn ip-prefix
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN IP-Prefix Routes
===============================================================================
Flag Route Dist. Prefix
Tag Gw Address
NextHop
Label
ESI
-------------------------------------------------------------------------------
u*>i 192.0.2.2:161 10.0.4.0/24
0 00:00:00:00:00:00
192.0.2.2
LABEL 524284
ESI-0
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
Conclusion
The three EVPN IP-VRF-to-IP-VRF models each have advantages. Different vendors have chosen different models in the first phases of their EVPN implementations. SR OS supports all three EVPN IP-VRF-to-IP-VRF models, so they can be deployed in all environments where third-party vendors are deployed already.