[dev] Fwd: Re: EVPN (and L3VPN) configuration
lberger at labn.net
Thu Jun 15 09:10:01 EDT 2017
Resend -- looks like previous message didn't make it to the list.
-------- Forwarded Message --------
Subject: Re: [dev] EVPN (and L3VPN) configuration
Date: Tue, 13 Jun 2017 20:49:05 -0400
From: Lou Berger <lberger at labn.net>
To: dev at lists.frrouting.org
Thanks for this message - discussing on list is useful.
My view is that we had lots of discussions the last time around and cam
up with a compromise solution. (From my view, I'm okay with changing
this past agreement as long as there is community agreement on the new
syntax.) Here's what I see in the notes document from the last time around:
router bgp ....
#nexthop ip <> | ipv6 <>
Rt import <> | export <> | both <>
[no] tunnel advertisement-method <encap-attribute|evpn>
tunnel type <none| l2tpv3overip | gre | ipinip | vxlan | mpls |
route-map rmap permit 10
Set label <value>
set extcommunity rt 10:100
set extcommunity soo 10:102
set ip nexthop <> | ipv6 nexthop <>*
router bgp XXX vrf <vrf-name>*
! (address-family ipv4)
network 184.108.40.206/24 <http://220.127.116.11/24>route-map foo
neighbor ... ! CE session (or alternately, VRF-lite session)
!make vrf redistribution (import/export)the default
redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
no redistribute vrf
no export vrf
export vrf [route map] ...
add [vrf <vrf-name>] prefix <prefix> [rd <value>] [label <value>] [pref
clear [vrf <vrf-name>] <all|prefix <prefix> [rd <value>]|rd <value>>
<extracted from google docs notes>
On 6/13/2017 3:08 PM, Vivek Venkatraman wrote:
> 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
> The essential configuration involves only two steps as documented in
> the file doc/evpn.md <http://evpn.md>:
> 1. Enable (activate) the EVPN (AFI/SAFI 25/70) address-family between
> BGP speakers
> 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 "vrf-policy"?
> 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 (route-maps).
> 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.
> dev mailing list
> dev at lists.frrouting.org
More information about the dev