[cmaster-next] Fwd: EVPN - notes on the Cumulus implementation
Vincent JARDIN
vincent.jardin at 6wind.com
Mon Dec 12 23:39:53 EST 2016
Donald,
I just found this email into my spam box. See below the spam's ranking,
Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify)
header.i=@cumulusnetworks.com;
spf=pass (google.com: domain of
cmaster-next-bounces at lists.nox.tf designates 2a07:2ec0:2185:: as
permitted sender) smtp.mailfrom=cmaster-next-bounces at lists.nox.tf;
dmarc=fail (p=QUARANTINE dis=NONE) header.from=cumulusnetworks.com
https://dmarc.org/wiki/FAQ#What_does_a_.22quarantine.22_policy_mean_in_a_DMARC_record.3F
Le 29/11/2016 à 17:46, Donald Sharp a écrit :
> Resend if missed
>
>
> ---------- Forwarded message ----------
> From: Vivek Venkatraman <vivek at cumulusnetworks.com>
> Date: Mon, Nov 28, 2016 at 10:50 PM
> Subject: [cmaster-next] EVPN - notes on the Cumulus implementation
> To: cmaster-next at lists.nox.tf
>
>
> Here is some information on the Cumulus implementation. We can discuss
> further in tomorrow's meeting and/or subsequent ones.
>
>
> Functional description:
>
> The Cumulus implementation of EVPN is focused on EVPN as the control
> plane for VxLAN, though it is certainly feasible to extend it to
> support other encapsulations - e.g., MPLS. It is also clearly a
> work-in-progress. The implementation is focused on Linux as the
> network OS; there will be work needed to extend it for FreeBSD or
> provide the FPM-type interface.
>
> The current state of the implementation (end November 2016) allows for
> MAC learning and exchange but not for MAC+IP. The latter requires some
> enhancements to the Linux kernel's "ARP proxy" (ARP suppression)
> capabilities for VxLAN, and this is currently in the works.
>
> A precursor to MAC exchange is the exchange of VxLAN topology. This
> will build the mapping of VNIs to remote VTEPs and is required for
> handling BUM traffic through ingress replication. The exchange of this
> topology happens in BGP through the EVPN type-3 route. Currently, this
> is not configurable (i.e., these routes will always get exchanged).
> Additional options need to be added to disable this exchange (and
> hence, possibly, drop BUM traffic), attach to a multicast group or
> have the ability to go to a service or replicator node. Remote VTEPs
> learnt by BGP and informed to zebra will result in the "flood list"
> being setup - by installing the appropriate neighbor entry in the MAC
> FDB.
>
> MACs are exchanged using EVPN type-2 route. Local MACs get associated
> to the appropriate VNI. Remote MACs learnt by BGP and informed to
> zebra will be installed in the kernel MAC FDB.
>
> Some of the other aspects still in the works are the BGP encapsulation
> attribute (RFC 5512 - basic code already there in branch from Lou),
> the PMSI attribute (RFC 6514) and MAC mobility extended community (RFC
> 7432).
>
> All BGP protocol exchanges are as per RFC 7432 and draft-ietf-bess-evpn-overlay.
>
> Handling of access device dual homing (i.e., vPC, MLAG etc. in vendor
> speak) does not currently intend to use the EVPN type-4 route or EVPN
> type-1 route and related procedures. Instead, it will rely on the
> corresponding VTEPs using an "anycast IP" as their tunnel end point.
> This is in accordance with current industry practice (i.e., Cisco and
> Arista's approach).
>
> Work on L3 multi-tenancy (i.e., Inter-VxLAN routing) is at an early
> stage. This is where EVPN type-5 routes will be needed along with
> associating tenants to corresponding L3 VRFs, support for the Router
> MAC extended community etc.
>
>
> Provisioning/Management:
>
> As with other vendor implementations, there is no explicit
> configuration of a "MAC VRF" - the VNI defines the L2 domain and is
> the MAC VRF.
>
> VNIs (VxLAN interfaces), association of these to a bridge and mapping
> of access (VLAN) interfaces to the bridge are all supported (done)
> through existing Linux interfaces i.e., iproute2 or ifupdown2. There
> are no new Quagga commands to create or update these.
>
> The only essential pieces of Quagga configuration needed to activate
> EVPN (for the current and near-term functionality) are:
> a) enable EVPN - the current commands for this is "advertise-vni"
> b) activate EVPN address family for the remote VTEPs (or appropriate
> BGP peers, if peering is hop-by-hop)
>
> router bgp <as>
> address-family evpn
> advertise-vni
> neighbor <nbr> activate
>
> With the above configuration, VNIs known to the system will get
> associated with automatic RDs and RTs. The RDs are formed as
> "RouterID:VNI" and the RTs (import and export) are formed using
> "AS:VNI".
>
> Configuration options are provided to specify a different RD and/or RT
> value for a VNI. Whichever parameter that is not user-configured will
> be auto-derived. The VNI will of course be "active" only when it is
> known to the system (i.e., provisioned through existing Linux
> interface).
>
> router bgp <as>
> address-family evpn
> advertise-vni
> neighbor <nbr> activate
> vni <vni>
> rd <value>
> route-target import <value> ...
> route-target export <value>
>
> The main vtysh commands currently available to manage/monitor EVPN
> operation are:
>
> show evpn vni
> show evpn vni <vni> mac
> show bgp evpn summary
> show bgp evpn route
> show bgp evpn route rd <rd>
>
>
> Design description:
>
> zebra provides the kernel interface (through netlink) and maintains
> the VNI information and the MAC table per VNI. It should be considered
> later if these need to move into a "l2d"; this is best taken up for
> consideration, if at all, in conjunction with a "vrfd" and an "ifd" so
> that zebra effectively becomes "rtmd".
>
> The VNI hash table is populated with local VNIs which are learnt
> through existing netlink "link" notifications. The hash table also
> contains the remote VTEPs which are updated by BGP. Linux currently
> only supports an IPv4 address as the VTEP IP, so while the code has
> support for IPv6 address as a VTEP, it is incomplete.
>
> To be able to associate local MACs to the correct VNI (if they are
> associated with a VNI), zebra needs to understand bridges and bridge
> members and the VLAN to VNI mapping. These are built by listening
> mostly to existing netlink "link" notifications, however, some
> notifications related to the AF_BRIDGE family also need to be
> processed. The "L2" information for an interface is maintained in a
> structure linked off 'struct zebra_if'.
>
> The VNI hash table contains the MAC table corresponding to the VNI.
> This includes local MACs learnt from netlink "neighbor" notifications
> (AF_BRIDGE) as well as remote MACs updated by BGP. The remote MACs
> result in MAC FDB entries being installed in the kernel. When this is
> extended for MAC+IP, the IP information will result in creation of ARP
> "suppression" entries in the kernel.
>
> BGP also has a VNI hash table that it builds through interaction with
> zebra. Currently, there is no per-VNI routing table. Instead, EVPN
> routes (both local and remote) are only maintained in the main routing
> table where they are organized using a hierarchical radix tree in the
> same fashion as L3VPN routes and ENCAP routes. This is likely to need
> change in order to handle various scenarios. The change envisioned is
> that local EVPN routes will be only present in the per-VNI routing
> table from where they will be advertised to EVPN peers; remote (i.e.,
> learnt) EVPN routes will be present in the global EVPN routing table
> from where they will be "imported" into one or more VNI routing
> tables; the import can/will be done as a separate thread.
>
> Thanks,
> Vivek
>
>
>
> _______________________________________________
> cmaster-next mailing list
> cmaster-next at lists.nox.tf
> https://lists.nox.tf/listinfo/cmaster-next
>
> _______________________________________________
> cmaster-next mailing list
> cmaster-next at lists.nox.tf
> https://lists.nox.tf/listinfo/cmaster-next
>
Delivered-To: vincent.jardin at 6wind.com
Received: by 10.28.59.195 with SMTP id i186csp2392488wma;
Tue, 29 Nov 2016 08:46:29 -0800 (PST)
X-Received: by 10.194.19.101 with SMTP id d5mr23182580wje.18.1480437989623;
Tue, 29 Nov 2016 08:46:29 -0800 (PST)
Return-Path: <cmaster-next-bounces at lists.nox.tf>
Received: from eidolon.nox.tf (eidolon.nox.tf. [2a07:2ec0:2185::])
by mx.google.com with ESMTPS id
em6si60217654wjb.114.2016.11.29.08.46.29
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 29 Nov 2016 08:46:29 -0800 (PST)
Received-SPF: pass (google.com: domain of
cmaster-next-bounces at lists.nox.tf designates 2a07:2ec0:2185:: as
permitted sender) client-ip=2a07:2ec0:2185::;
Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify)
header.i=@cumulusnetworks.com;
spf=pass (google.com: domain of
cmaster-next-bounces at lists.nox.tf designates 2a07:2ec0:2185:: as
permitted sender) smtp.mailfrom=cmaster-next-bounces at lists.nox.tf;
dmarc=fail (p=QUARANTINE dis=NONE) header.from=cumulusnetworks.com
Received: from mailman.backend.nox.tf ([2a07:2ec0:2185::6d6d:616e]
helo=lists.nox.tf)
by eidolon.nox.tf with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.87)
(envelope-from <cmaster-next-bounces at lists.nox.tf>)
id 1cBlY0-002DNf-R9; Tue, 29 Nov 2016 17:46:28 +0100
Received: from localhost ([::1] helo=[127.0.0.1])
by lists.nox.tf with esmtp (Exim 4.84_2)
(envelope-from <cmaster-next-bounces at lists.nox.tf>)
id 1cBlY0-0006tg-Ny; Tue, 29 Nov 2016 16:46:24 +0000
Received: from eidolon.nox.tf ([2a07:2ec0:2185::])
by lists.nox.tf with esmtp (Exim 4.84_2)
(envelope-from <sharpd at cumulusnetworks.com>) id 1cBlXz-0006ta-3C
for cmaster-next at lists.nox.tf; Tue, 29 Nov 2016 16:46:23 +0000
Received: from mail-oi0-x230.google.com ([2607:f8b0:4003:c06::230])
by eidolon.nox.tf with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.87) (envelope-from <sharpd at cumulusnetworks.com>)
id 1cBlXx-002DNE-Ep
for cmaster-next at lists.nox.tf; Tue, 29 Nov 2016 17:46:23 +0100
Received: by mail-oi0-x230.google.com with SMTP id w63so197295154oiw.0
for <cmaster-next at lists.nox.tf>; Tue, 29 Nov 2016 08:46:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=cumulusnetworks.com; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=Yb17csKv6Y0dketgyFMpOW90QDWlmv7PQc4A7b8RnHA=;
b=YkiAO6K0C1QaZDiDpKTYfdmHEYfTZPGQb/dmnB1N+jsunVdjKnNixIqD4CBtlbjB2d
TwggRb7l4Od7S8OCq6v/UOtDUFG/jTgqWWEyGb+gXQYuIqIlZN22ALUxoovndUGBQ9c6
nbLnr4JrsKb3AOpc6WPfe2WI7k77yd8YI6/4s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=Yb17csKv6Y0dketgyFMpOW90QDWlmv7PQc4A7b8RnHA=;
b=hYUxq5YMkKWR/FOVyRnjd7ecA7ldQ95y+C2pejh+4+mdKEFTNEBBEw5ANPG4mdZVh7
cDpr2oo7wT84wuZDARoMl+nmmpcqqjo0rMei/SWaF7oRXdI/ji+L7wYbJErcf0wb85qR
CzY4NvGDDvxDyJ/LZPPZx++KM601zO5MUayiQqCYpMvkpf5hMjnb5vRjWo+qcqrQiODT
ukD9A1ThF/RzN6uH0zXdRH58+cMTrcRitLQqPBNPGyMC2Rnn3sObZnse+9uBlDPK6o99
Ydx91jgdTNHdA7xKXJzRxDDJrGpfCcX7vVkg0BU1P2gZDACfmkuMq8dtUZVeHMBVX+OQ
QWKA==
X-Gm-Message-State:
AKaTC03jGWi3Hqs/a8u3dL/CPrDwzJRUE5KXcGpXopxtad7nXCQhami0snmfhXZqke/cM1jeZw3ABvuAFMq+zksC
X-Received: by 10.202.183.6 with SMTP id h6mr15567494oif.76.1480437979431;
Tue, 29 Nov 2016 08:46:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.192.106 with HTTP; Tue, 29 Nov 2016 08:46:18 -0800 (PST)
In-Reply-To:
<CAMs_D18P1ASisDy4KYb0x_w8kNiiPnd+BCd7gJKHq8Z9HuxwKQ at mail.gmail.com>
References:
<CAMs_D18P1ASisDy4KYb0x_w8kNiiPnd+BCd7gJKHq8Z9HuxwKQ at mail.gmail.com>
From: Donald Sharp <sharpd at cumulusnetworks.com>
Date: Tue, 29 Nov 2016 11:46:18 -0500
Message-ID:
<CAK989ydPRXAX0pwia_amQrwD4764ddbGCmtSnFQJPYd8=GM+KA at mail.gmail.com>
To: cmaster-next at lists.nox.tf
Subject: [cmaster-next] Fwd: EVPN - notes on the Cumulus implementation
X-BeenThere: cmaster-next at lists.nox.tf
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <cmaster-next.lists.nox.tf>
List-Unsubscribe: <https://lists.nox.tf/options/cmaster-next>,
<mailto:cmaster-next-request at lists.nox.tf?subject=unsubscribe>
List-Archive: <http://lists.nox.tf/pipermail/cmaster-next/>
List-Post: <mailto:cmaster-next at lists.nox.tf>
List-Help: <mailto:cmaster-next-request at lists.nox.tf?subject=help>
List-Subscribe: <https://lists.nox.tf/listinfo/cmaster-next>,
<mailto:cmaster-next-request at lists.nox.tf?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: cmaster-next-bounces at lists.nox.tf
Sender: "cmaster-next" <cmaster-next-bounces at lists.nox.tf>
More information about the dev
mailing list