Configuring EVPN

The configuration of EVPN revolves around the selection of the border gateway nodes and the configuration of associated VNIs for the VRFs.

In addition, the fabric automation takes care of transparently performing various configurations, which can be verified with new show commands or with new parameters of existing commands, as shown in the examples below.

Configuring the Border Gateways

The first step involves configuring the vRouters on at least two nodes across two pods to make them border gateways. That is achieved with the vrouter-create command using the evpn-border/no-evpn-border parameter. In case of an existing vRouter, the vrouter-modify command can be used instead.

For example:

CLI (network-admin@switch) > vrouter-create name vRouter1 fabric-comm enable location border-switch router-type hardware evpn-border bgp-as 5200 router-id

Then the vrouter-show command can be used to verify the current EVPN parameter configuration:

CLI (network-admin@switch) > vrouter-show name vRouter1 format all layout vertical

id:                           c00029d:0

name:                         vRouter1

type:                         vrouter

scope:                        fabric


location:                     switch

zone-id:                      c00029d:1

router-type:                  hardware

evpn-border:                  enable

The second step is for the user to configure an MP BGP neighbor with the l2vpn-evpn parameter to point to an external EVPN border gateway:

CLI (network-admin@switch) > vrouter-bgp-add vrouter-name vRouter1 neighbor remote-as 65012 ebgp-multihop 3 update-source multi-protocol l2vpn-evpn

This configuration enables the use of the standard EVPN NLRI, which is carried using BGP Multiprotocol Extensions with an Address Family Identifier (AFI) of 25 (L2VPN) and a Subsequent Address Family Identifier (SAFI) of 70 (EVPN).

Configuring L3 VNIs

To uniquely identify VRF instances with EVPN it is necessary to specify a new l3-vni parameter during creation (or modification), like so:

CLI (network-admin@switch) > vlan-create id 1000 auto-vxlan 101000 scope fabric ports none

CLI (network-admin@switch) > vrf-create name VRF1 l3-vni 101000

As explained in more detail in the Configuring VXLAN chapter, subnets can be mapped to VRFs with the subnet-create command, for example:

CLI (network-admin@switch) > vlan-create id 12 auto-vxlan 500012 scope fabric

CLI (network-admin@switch) > subnet-create name subnet-vxlan-500012 scope fabric vxlan 500012 network anycast-gw-ip vrf VRF1

L3 VNIs also enable a new forwarding mode (see the two hop model described above), which is used for inter-pod VXLAN routing.

Once configured, you can check the VRFs with the vrf-show command:

CLI (network-admin@switch) > vrf-show format name,vnet,anycast-mac,l3-vni,active,hw-router-mac,hw-vrid,flags,enable

name vnet anycast-mac       l3-vni active hw-router-mac     hw-vrid flags  enable

---- ---- ----------------- ------ ------ ----------------- ------- ------ ------

VRF1 0:0  64:0e:94:40:00:02 101000 yes    66:0e:94:48:68:a7 1       subnet yes

Note that the user doesn't need to confgure vrf-gw and vrf-gw2 with EVPN except on border gateways connected to DC gateways for North South traffic. Traffic reaches the border gateways with the default route described in Figure 9-3 above.

Configuring Route Maps for EVPN Filtering

Since EVPN is based on a BGP configuration between the border gateways, it’s a natural extension (and general practice) to use route maps for filtering.

A user can create a route map using the match/set/permit/deny statements, and then apply it to the BGP EVPN configuration, inbound or outbound.

When a route map is applied inbound, it ensures that the match statement is applied to the routes that are learned from a BGP neighbor. When it is applied outbound, it ensures that the match statement is applied to the routes that are sent to a BGP neighbor.

Starting from release 7.0.0 NetVisor OS supports the configuration of route maps that support the following EVPN-related statements both in the inbound and the outbound direction:

  • match-evpn-default-route
  • match-evpn-route-type
  • match-evpn-vni
  • match-evpn-rd

These statements can match a default route (such as or 0::0/0), a route type (Type 2, 3, 5 routes), a VNI (L2 or L3), and a route distinguisher (Type 2, 3, and 5 routes carry an RD field in them). In addition, it is possible to apply IP prefix lists to the filters.

This enhancement extends the existing NetVisor OS vrouter-route-map-add/-modify commands, as described below:

CLI (network-admin@switch) > vrouter-route-map-add vrouter-name leaf1 name map

action permit | deny

with the additional parameters:





Note: This filtering capability must be configured on the EVPN border gateways. In redundant gateways, it must be enabled on both cluster nodes to ensure that the pair of EVPN border nodes filter routes symmetrically for the pod.

The following example filters Type 2 and Type 5 routes:

CLI (network-admin@switch) > vrouter-route-map-add vrouter-name vr1 name type52

action deny seq 1 match-evpn-route-type type-5

CLI (network-admin@switch) > vrouter-route-map-add vrouter-name vr1 name type52

action deny seq 2 match-evpn-route-type type-2

CLI (network-admin@switch) > vrouter-route-map-add vrouter-name vr1 name type52

action permit seq 3

Note that the third closing command is required (as permit all) for the entire route map to work.

Next, for example, the route map can be applied in the outbound direction like so:

CLI (network-admin@switch) > vrouter-bgp-modify vrouter-name vr1 neighbor route-map-out type52

to stop advertising EVPN routes to the neighbor specified in the route map.

Additionally, it is also possible to filter the incoming routes from the matching neighbor like so:

CLI (network-admin@switch) > vrouter-bgp-modify vrouter-name vr1 neighbor route-map-in type52

The next example shows how to configure an IP filter list (100) and then apply it to a route map (rmap1) to filter EVPN routes in the outbound direction:

CLI (network-admin@switch) > vrouter-prefix-list-add vrouter-name vr1 name 100

seq 1 prefix action permit

CLI (network-admin@switch) > vrouter-prefix-list-add vrouter-name vr1 name 100

seq 2 prefix action deny

CLI (network-admin@switch) > vrouter-route-map-add vrouter-name vr1 name rmap1

action permit match-prefix 100 match-evpn-route-type type-5 seq 1

CLI (network-admin@switch) > vrouter-bgp-modify vrouter-name vr1 neighbor route-map-out 100

CLI (network-admin@switch) > vrouter-route-map-show format vroutername,name,seq,action,match-prefix,match-evpn-route-type

vrouter-name name  seq action match-prefix match-evpn-route-type

------------ ----- --- ------ ------------ ---------------------

vr1          rmap1 10  deny   100          type-5

vr1          rmap1 20  permit none

On the neighboring node, route is present, because it’s not filtered by the prefix list 100, but gets filtered as shown below:

CLI (network-admin@switch) > vrouter-evpn-bgp-routes-show route-type show-interval 2 format


vrouter-name vni   ip           route-type next-hop   extended-community

------------ ----- ------------ ---------- ---------- --------------------------------------------

vr4          13434 5 RT:65011:1003434 ET:8 Rmac:00:00:5e:00:01:64

vr4          13434  5 RT:65011:1003434 ET:8 Rmac:00:00:5e:00:01:64

Configuring Virtual Service Groups with EVPN 

Starting from release 7.0.0 NetVisor OS supports the configuration of Virtual Service Groups (vSGs) not just in the local pod but also across EVPN pods. Refer to the Configuring Virtual Service Groups section in the Configuring VXLAN chapter for more details on the functionality. 

vSGs can be used to import/export (i.e., ‘leak’) subnet prefixes between Unicast Fabric VRFs. 

Starting from release 7.0.0, it is possible to decide which subnets/prefixes to import/export locally and which ones to import/export over an EVPN transport using Type-5 routes. The selection can be configured based on the new parameters discussed below and is needed on one EVPN pod only, from which the shared prefixes can be extended to the other pods. 

By default, exported (i.e., ‘leaked’) networks remain local and are not extended over EVPN, so this behavior is consistent with prior releases. However, it can be changed when adding a VRF to a vSG with the export-leaked-networks parameter: 

CLI (network-admin@switch) > vsg-vrf-add vsg-name <vsg_name> vrf <vrf> [export-leaked-networks evpn | none] 

in which none is the default. For example, you can enable the extension over EVPN of the leaked networks/subnets associated with vrf3 like so: 

CLI (network-admin@switch) > vsg-create name vsg-1 

CLI (network-admin@switch) > vsg-vrf-add vsg-name vsg-1 vrf vrf3 [type promiscuous] export-leaked-networks evpn 

CLI (network-admin@switch*) > vsg-vrf-show

CLI (network-admin@switch*) > vsg-vrf-show

vsg-name vnet  vrf   type        export-leaked-networks

-------- ----- ----- ----------- -------------------------

vsg-1    0:0   vrf3  promiscuous evpn 

The vsg-vrf-remove command would be used to remove a VRF from a vSG and consequently also stop any extension across pods, if enabled. 

In a VRF that is extended over EVPN you can also decide which subnets to share with the subnet-create or subnet-modify commands. For that you need to use the evpn-export-leaked-networks parameter, which defaults to permit

CLI (network-admin@switch) > subnet-create name <name> … [evpn-export-leaked-networks permit | deny] 

In other words, when the evpn-export-leaked-networks parameter is not specified leaked subnets are extended over EVPN by default (when export-leaked-networks is set to evpn). During creation or modification, you can elect not to extend a leaked subnet like so: 

CLI (network-admin@switch) > subnet-create name vlan-235 vlan 235 vxlan 10235 vrf vrf3 network anycast-gw-ip network6 2002:13:1:5::/64 anycast-gw-ip6 2002:13:1:5::254 evpn-export-leaked-networks deny 

CLI (network-admin@switch*) > subnet-show name vlan-235 format name,scope,vlan,vxlan,vrf,network,state,enable,evpn-export-leaked-subnets 

name     scope  vlan vxlan  vrf  network     state enable evpn-export-leaked-subnets 

-------- ------ ---- ------ ---- ----------- ----- ------ -------------------------- 

vlan-235 fabric 235  10235  vrf3 ok    yes    deny 

CLI (network-admin@switch) > vsg-network-add vsg-name vsg-1 vrf vrf3 subnet vlan-235 

Similarly, you can also decide to extend a specific network in the vsg-network-add/modify commands like so: 

CLI (network-admin@switch) > vsg-network-add vsg-name vsg1 vrf vrf3 network 

Configuring Bridge Domains with EVPN 

Starting from release 7.0.0 NetVisor OS supports the configuration of bridge domains (along with VLANs) across multiple EVPN pods. (For more information on bridge domains, refer to the Configuring Advanced Layer 2 Transport Services chapter.) 

The configuration of a VXLAN bridge domain (BD in short) does not change with the addition of the EVPN support: the main (and only) requirement for a bridge domain that is extended across EVPN pods is to use a common VXLAN ID. In other words, such ID has global significance and represents the bridge domain end-to-end. Note that this ID cannot be shared with VLAN-based VXLAN configurations. 

A bridge domain supports a variety of modes (dot1q, q-in-q and untagged) as well as of tagging schemes (auto, remove-tags and transparent). All of them are transparently supported with EVPN as well. 

Note: Starting from release 7.0.0, NetVisor OS supports bridge domains over EVPN on the following platforms: 

  • F9480-V (AS7326-56X), F9460-X (AS5835-54X), F9460-T (AS5835-54T) 
  • Dell S4100 and S5200 Series 
  • NRU03, and NRU-S0301

To create a BD in an EVPN pod, you can use the regular bridge-domain-create command (as also described in the respective chapter), for example like so: 

CLI (network-admin@switch) > bridge-domain-create name bd-evpn1 scope fabric vxlan 500500 rsvd-vlan 4030 

To add a port in the pod to a BD, you can use for example the command: 

CLI (network-admin@switch) > bridge-domain-port-add name bd-evpn1 port 81 vlans 55 

With EVPN you can also create another BD (name) in another pod, for example like so: 

CLI (network-admin@switch2) > bridge-domain-create name bd-evpn2 scope fabric vxlan 500500 rsvd-vlan 4050 

And add a port to it: 

CLI (network-admin@switch2) > bridge-domain-port-add name bd-evpn2 port 31 vlans 500

Note that the the BD names and VLAN numbers in the two pods can even be different but the VXLAN ID must be the same. The common VXLAN ID represents a unique forwarding domain end-to-end. Obviously in many cases, for consistency’s sake, it can be convenient to use the same BD name end-to-end. Also in certain scenarios, when possible, using consistent VLAN numbers end-to-end can be desirable to simplify the network design. 

You can check the BD configuration on a non-border gateway node: 

CLI (network-admin@switch*) > l2-table-show bd bd-evpn1 format mac,bd,vlan,vxlan,ip,ports,state,status,vtep-ip        

mac               bd       vlan vxlan  ip           ports state       status vtep-ip 

----------------- -------- ---- ------ ------------ ----- ----------- ------ ----------- 

00:12:c0:88:07:32 bd-evpn1      500500       tunnel,evpn 

00:12:c0:80:33:1e bd-evpn1 55   500500 81    active      host 

vtep-ip corresponds to the border gateway’s VTEP: 

CLI (network-admin@bgw*) > fabric-evpn-node-show 

fabric-pod evpn-node version        vtep-ip     evpn-role 

---------- --------- -------------- ----------- --------- 

evpn-fab1  bgw       6.2.6020018465 primary 

CLI (network-admin@bgw*) > vtep-show name vtep9 

scope  name  location vrouter-name ip         virtual-ip  mac-learning 

------ ----- -------- ------------ ---------- ----------- ------------ 

fabric vtep9 bgw      vr9 on 

The BD extends to the border gateway (and beyond): 

CLI (network-admin@bgw*) > l2-table-show bd bd-evpn1 format mac,bd,vlan,vxlan,ip,ports,state,status,vtep-ip 

mac               bd       vlan vxlan  ip           state       status vtep-ip 

----------------- -------- ---- ------ ------------ ----------- ------ ---------- 

00:12:c0:88:07:32 bd-evpn1      500500 tunnel,evpn 

00:12:c0:80:33:1e bd-evpn1 55   500500 tunnel      host         

The BD is extended to Pod 2 too, as shown below on a non-border gateway node: 

CLI (network-admin@switch2*) > l2-table-show bd bd-evpn2 format mac,bd,vlan,vxlan,ports,state,status,vtep-ip 

mac               bd       vlan vxlan  ports state                    status vtep-ip 

----------------- -------- ---- ------ ----- ------------------------ ------ ---------- 

00:12:c0:88:07:32 bd-evpn2 500  500500 31    active                   host 

00:12:c0:80:33:1e bd-evpn2      500500       tunnel,local-tunnel,evpn 

This extension happens transparently as there is no BD-specific information in BGP: 

CLI (network-admin@bgw*) > vrouter-evpn-bgp-routes-show format vrouter-name,vni,mac,ip,route-type,extended-community 

vrouter-name vni    mac               ip              route-type extended-community 

------------ ------ ----------------- --------------- ---------- -------------------- 

vr9          500500 00:12:c0:88:07:32                 2          RT:5002:500500 ET:8 

vr9          500500 00:12:c0:88:07:32 2          RT:5002:500500 ET:8 

Note that, as with VLANs when configured with EVPN, a BD is enabled once the BD's VXLAN ID is added to the respective border gateway’s VTEP and that same VXLAN ID is configured consistently on all the pods, as shown below on two nodes of different pods. 

First make sure EVPN is enabled: 

CLI (network-admin@bgw*) > vrouter-show name vr9 format evpn-border,




Then you can check that the BD’s VXLAN ID is correctly configured in Pod 1: 

CLI (network-admin@bgw*) > vtep-vxlan-show name vtep9 vxlan 500500 

name  vxlan  isolated 

----- ------ -------- 

vtep9 500500 no         

And also in Pod 2: 

CLI (network-admin@bgw2*) > vtep-vxlan-show name vtep2 vxlan 500500 

name  vxlan  isolated 

----- ------ -------- 

vtep2 500500 no 

Note: A hardware limitation is that you need to configure a BD port on the border gateway, regardless of whether there needs to be a host attached. So on the border gateway for BD configurations a port needs to be set aside anyway.