• Tag : EVPN

 
 

Extending EVPN and VXLAN to the Host

Overview VxLAN provides a highly scalable, standards based approach for constructing L2 overlays on top of routed networks. It is defined in RFC7348, and encapsulates the original host Ethernet frame in a UDP + IP + Ethernet frame. BGP EVPN (RFC 7432 and RFC 8365 for its application to VXLAN) is a standards based control protocol to efficiently discover other endpoints (VTEPs) and distribute reachability information (MAC addresses). This post assumes the reader is already familiar with configuration and operations of EVPN and VXLAN for Arista. Goals The use case here is the extension of a L2 overlay south of the TOR/Leaf...
Continue reading →

EVPN service on Subinterface

Does Arista support create evpn service on Subinterface? The goal is to make Arista switch to be a Router mode, so no vlan created on the switch, just SubInterface. I have tested on vEOS-Lab and on DCS-7280 but no clue. router bgp 65000 vlan 10 rd auto route-target both 10:10010 redistribute learned How to make above command attached to : interface Ethernet2.10 encapsulation dot1q vlan 10 and ofc without creating vlan 10 on the switch. Thanks in advance.

IGP cost for VTEP reachability

Introduction In EVPN deployment with VXLAN underlay when an EVPN type-5 prefix is imported into an IP VRF, the IGP cost of the underlay VTEP reachability is not considered as part of BGP bestpath selection post import. Therefore, if such a prefix is reachable via more than one VTEPs, the IGP metric step in the BGP best-path selection algorithm will not filter out any paths irrespective of the underlay’s IGP metric for the VTEP reachability. If ECMP is enabled in the overlay and multiple paths are found to be otherwise equivalent,  such paths would  form ECMP regardless of the IGP...
Continue reading →

Support BGP PIC edge for EVPN VXLAN routes for remote VTEP failures

Description Prior to 4.25.2F, support for BGP PIC was restricted to locally identifiable failures such as link failures. If a remote VTEP went down, this would require action by the IGP and BGP to recompute a new best path traffic destined to affected BGP prefixes originally reachable by the problematic VTEP. This feature introduces support for RFC8971 (BFD for VXLAN) for EVPN learned VTEPs to improve convergence times in these scenarios by tying the liveness detection provided by the BFD sessions into existing BGP PIC support for software fast-failover. Without this feature, until the underlay route providing reachability to the...
Continue reading →

cEOS, VRFs, and EVPN – Not Working Properly

Hey folks –   I’m playing around with the latest cEOS image 4.25.2F-20711308.4252F (engineering build) and its handling of VRFs within EVPN seems broken.  Specifically around the importing and exporting of RTs.  As an example, let’s say I have three VRFs: VRF A VRF B VRF C Within BGP I have: VRF A importing [A, B, C], and exporting A. VRF B importing [A, B], and exporting B. VRF C importing [A, C], and exporting C. Basically, A is importing all VRFs so he can talk to them via the VXLAN data plane.  Each of the other VRFs is importing...
Continue reading →

Multicast EVPN All-Active Multihoming

Description [L2-EVPN] and  [Multicast EVPN IRB] solutions allow for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a VLAN and L3VPNs respectively using multicast in the underlay network. This document describes the solution to support all-active multihoming for customer multicast traffic as described in [IGMP PROXY] . More information about VXLAN EVPN all-active multihoming may be found in [VXLAN EVPN All-Active Multihoming]. Multicast All-Active Multihoming IGMP PROXY support As described in [IGMP PROXY], in an all-active redundancy mode, IGMP reports from the CE may arrive at any one of the multihomed peers. The multihomed peer which...
Continue reading →

Multicast EVPN IRB

Description This solution allows delivery of multicast traffic in an IP-VRF using multicast in the underlay network. It builds on top of [L2-EVPN], adding support for L3 VPNs and Integrated Routing and Bridging (IRB).  The protocol used to build multicast trees in the underlay network is PIM Sparse Mode. In the figure above: VLAN 10 and VLAN 20 have SVIs provisioned on all VTEPs and are associated with the L3 VRF red. There are interested receivers in VLANs 10 and 20 on VTEP2, and in VLAN 20 on VTEP 3. Traffic arriving in VLAN 10 on VTEP 1 is: Delivered...
Continue reading →

Layer 2 Multicast EVPN

Description This solution allows the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a VLAN using multicast in the underlay network. BUM traffic can be classified into two traffic types: Flooded Traffic: This is broadcast, unknown unicast, and link-local multicast traffic, which is flooded to all VTEPs Multicast Traffic: This traffic is sent to VTEPs with interested receivers. The solution uses the procedures described in [IGMP PROXY], which use a BGP EVPN control plane and a VXLAN forwarding plane. Using multicast in the underlay network (as opposed to unicast) has the advantage of being bandwidth efficient. The...
Continue reading →

Spanning tree network super root

Description Arista MLAG supports STP for Layer-2 loop detection. In fact, most customers enable STP in their MLAG(s) to ensure no downstream Layer-2 loops due to mis-cabling or mis-configuration. Pre 4.25.1F EVPN All-Active multihoming mechanism did not support STP downstream because of the following reasons: Unlike MLAG, EVPN multihoming peers run STP independently. Hence, all EVPN multihoming PEs send BPDUs independently on port-channel links. STP BPDUs will have Bridge ID derived from the local system MAC address, so the BPDUs generated by each multihoming PE are different.  Hence, the downstream multihomed switch/server receives different BPDUs from different PEs, so STP...
Continue reading →

Deploying EVPN with IPv6 Fabric using RFC5549

Introduction To use IPv6 addresses for VXLAN underlay, there are two different approaches.  The first approach is to make use of IPv6 VXLAN tunnel (i.e. IPV6 tunnel encapsulation) for all VTEPs to VTEPs communication.  This approach is suitable for a Greenfield deployment environment where all the VTEPs are capable of supporting IPV6 VXLAN tunnels. The second approach is to use IPV4 VXLAN Tunnels while using IPv6 addresses in the Data center fabric.  In this approach, all VTEPs advertise the IPV4 VXLAN Tunnels VTEP IP with a IPv6 nexthop using RFC5549.  Because VTEPs to VTEPs are using IPV4 VXLAN Tunnels and...
Continue reading →

EVPN L3 Gateway

Description This feature adds control plane support for inter-subnet forwarding between EVPN networks. This support is achieved by advertising received EVPN IP Prefix routes (Type-5) with next-hop self. VXLAN and MPLS encapsulation are supported, and the encapsulation type used for advertised routes is dependent on the encapsulation type configured for EVPN peering. The following diagram shows an example topology where an EVPN VXLAN network exchanges Type-5 routes with an EVPN MPLS network.   Within the EVPN VXLAN and EVPN MPLS network, EVPN routes are exchanged as normal. The L3 gateway functionality is achieved by GW1/2 and GW3/4 advertising received type-5...
Continue reading →

EVPN VXLAN single-gateway centralized routing

Description In a traditional EVPN VXLAN centralized anycast gateway deployment, multiple L3 VTEPs serve the role of the centralized anycast gateway.  In order for hosts to have a consistent ARP binding for any of the individual centralized gateway VTEPs, each VTEP operating as a centralized gateway is configured with a virtual router MAC (VARP MAC), and a virtual VTEP IP (VARP VTEP IP), that is shared between all of the L3 VTEPs operating as centralized gateways.  Each centralized gateway VTEP also advertises an EVPN type-3 route for both its primary VTEP IP and VARP VTEP IP, so both IPs end...
Continue reading →

EVPN VXLAN Support for Wireless APs

Description Typical WiFi networks utilize a single, central Wireless LAN Controller (WLC) to act as a gateway between the wireless APs and the wired network. Arista differentiates itself by allowing the wireless network to utilize a distributed set of aggregation switches to connect APs to the wired network. This feature allows a decentralized and distributed set of aggregation switches to bridge wireless traffic on behalf of the set of APs configured to VXLAN tunnel all traffic to those aggregation switches, or their “local” APs. This is an extension of the VXLAN VTEP to VTEP bridging feature (https://eos.arista.com/eos-4-22-1f/vxlan-vtep-to-vtep-bridging/) which supports only...
Continue reading →

EVPN Control Plane Support for MSS

Description This feature enables support for Macro Segmentation Service (MSS) to insert security devices into the traffic path for VXLAN networks using an EVPN control plane. With this feature enabled, CVX will continue to monitor the network via NetDB state and will initiate intercept and offload rules. With this feature enabled, MAC and IP reachability information will be learned and distributed in user configured L2 domains via EVPN.   There are two options for pairing MSS and EVPN: Option 1: MSS + EVPN asymmetric IRB Option 2: MSS + EVPN symmetric IRB with VXLAN bridging to firewall (see https://eos.arista.com/eos-4-20-1f/evpn-irb-with-vxlan-underlay/ for...
Continue reading →

EVPN MPLS Virtual Private Wire Service (VPWS)

Description EVPN MPLS VPWS (RFC 8214) provides the ability to forward customer traffic to / from a given attachment circuit (AC) without any MAC lookup / learning.  The basic advantage of VPWS over an L2 EVPN is the reduced control plane signalling due to not exchanging MAC address information.  In contrast to LDP pseudowires, EVPN MPLS VPWS uses BGP for signalling.  Port based and VLAN based services are supported. VLAN Based Service Port Based Service Platform compatibility DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 DCS-7800R3 DCS-7500R3 DCS-7280R3 Configuration VPWS configuration is made up of two main components on each participating router.  The first...
Continue reading →

Discard unimportable VPN paths

Description In a Service Provider network, a Provider Edge (PE) device learns VPN paths from remote PEs and uses the Route Target extended communities carried by those paths to determine which customer VRF(s) the paths should be imported into (from where they can be subsequently advertised to Customer Edge (CE) devices). In large Service Provider networks, each PE device may learn a significant number of VPN paths even though it might only handle a relatively small number of customer VRFs. As a result, such PE devices are really only interested in a subset of the VPN paths that they receive...
Continue reading →

EVPN route type 5 imported

Hi, We are configuring L3 VPN service using EVPN route type 5. I can see the route in the bgp table of the VRF but in the route table, the destination of the learned prefix is null0. Can someone explain why and how to fix it? I am running vEOS 4.24.0F in our lab. Here is the output of the bgp table in the VRF: AT1-R1#show ip bgp 10.37.4.0/23 vrf CORE BGP routing table information for VRF CORE Router identifier 10.32.25.2, local AS number 65032 BGP routing table entry for 10.37.4.0/23 Paths: 1 available 65037 65370 2.2.2.3 from 1.1.1.103 (2.2.2.3),...
Continue reading →

EVPN route type 5 imported

Hi, We are configuring L3 VPN service using EVPN route type 5. I can see the route in the bgp table of the VRF but in the route table, the destination of the learned prefix is null0. Can someone explain why and how to fix it? I am running vEOS 4.24.0F in our lab. Here is the output of the bgp table in the VRF: AT1-R1#show ip bgp 10.37.4.0/23 vrf CORE BGP routing table information for VRF CORE Router identifier 10.32.25.2, local AS number 65032 BGP routing table entry for 10.37.4.0/23 Paths: 1 available 65037 65370 2.2.2.3 from 1.1.1.103 (2.2.2.3),...
Continue reading →

EVPN route null0

Hi, I am trying to configure BGP EVPN using route-type 5. I am run into issue that route table show learned route via Null0. However my control plane show the correct prefix is imported to BGP table. #show ip route vrf CORE C 10.24.4.0/23 [0/0] via Vlan2404, directly connected B E 10.27.4.0/27 [20/0] Null0 B E 10.224.4.0/23 [20/0] Null0 #show ip bgp 10.27.4.0/27 vrf CORE BGP routing table information for VRF CORE Router identifier 10.24.5.251, local AS number 65024 BGP routing table entry for 10.27.4.0/27 Paths: 2 available 65002 65000 65001 2.2.2.1 from 1.1.1.101 (192.168.2.0), imported EVPN route, RD 1.1.1.101:50002...
Continue reading →

EVPN border leaf configured as PE in MPLS network

Hello, I am testing EVPN and MPLS VPN feature of vEOS(4.24.1.1F) in EVE-NG. I created two networks, one is EVPN, the other one is MPLS VPN network. I would like to know if the border leaf in EVPN network could be configured as PE router in MPLS network. Basically I would like to combine border leaf and PE router as one node. I did not see any documentation describe if this is supported?

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: