[dev] EVPN (and L3VPN) configuration

Vivek Venkatraman vivek at cumulusnetworks.com
Tue Jun 13 15:08:20 EDT 2017

About 3 weeks ago, I submitted PR 619 (
https://github.com/FRRouting/frr/pull/619) which provides the standardized
EVPN control plane for VxLAN. This is the EVPN implementation that is
available/shipping with Cumulus Linux, just merged with the FRR 'master'
branch. The PR provides a summary of the functionality.

The essential configuration involves only two steps as documented in the
file doc/evpn.md:

1. Enable (activate) the EVPN (AFI/SAFI 25/70) address-family between BGP
2. Enable EVPN itself on the local system - to advertise local VNIs and
MACs and Neighbors (ARP/ND) associated with those VNIs using BGP/EVPN
procedures. The RD and RT parameters will be automatically derived as
specified in these procedures and/or prevalent best practice.

Step #2 is of course not needed on a Route Reflector.

In addition, there are commands to configure the RD and RTs if
auto-derivation is not desired - for e.g., peering with third-party BGP
system. The syntax for this is shown through an example configuration below
(which also shows steps #1 and #2).

router bgp 65001
 address-family l2vpn evpn
  neighbor SPINE activate
  vni 10100
   rd 1:10100
   route-target import 1:10100

One topic of discussion is regarding this optional VNI configuration.
Instead of the keyword being "vni", should it be "vni-policy" to match with

I don't think "vni-policy", or for that matter, "vrf-policy" is the best
choice due to the following two main reasons:

1. A "policy" is a fairly familiar construct in routing parlance. It
commonly refers to a set of rules or definitions that are generically
specified and can then be applied to different "attach points". In FRR, a
"route-map" would be a good example of such a policy. It may be misleading
to call the specific configuration for a VNI or VRF as "policy",
particularly when the VNI/VRF may later support import/export policies

2. The configuration syntax that emerged for VRFs after the last round of
discussions separates out the "CE side" configuration (e.g., CE neighbors,
redistribution etc.) from the "PE side" configuration (e.g., RD and RT
configuration). From the user/operator's perspective, I do not see any
value add in this separation, only a potential source of confusion since
the same entity (VRF) needs to be configured in multiple places. It can
also be debatable where a configuration lies. For e.g., should
"vrf-import-policy" reside on the "PE side" as it deals with received L3VPN
routes or on the "CE side" as it decides which routes to import into which
VRF table?

I see it as being very useful to have all the configuration relevant to a
VRF (or VNI) in one place.

The purpose of this email is to solicit wider feedback since only a few
people participated in the earlier discussion and their positions are very
likely unchanged. My suggestion would be to have the initial deliberations
on the list and if that does not converge or indicates the need for a
meeting, the maintainers will call one.

Based on the consensus that emerges, I shall update my PR and/or introduce
modifications in a subsequent PR - if needed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170613/975b0277/attachment.html>

More information about the dev mailing list