• Tag : EVPN

 
 

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?

BFD support in vEOS lab

When I tried to run the following BFD interval command under global scope in vEOS, I got error: bfd interval 1200 min_rx 1200 multiplier 3 % Incomplete command Can you give me hint what the correct syntax is?   Thanks  

What is the meaning of this command?

In EVPN configuration guide, I read the following command has been used: ip address virtual source-nat vrf A address 10.10.10.10 But I could not find any documentation to explain this command. What is used for? and How to use it? Please give some hint about this command. Thanks.

IPv6 Underlay Support for VXLAN With EVPN Control Plane

Description Several customers have expressed interest in using IPv6 addresses for VXLAN underlay in their Data Centers (DC). Prior to 4.24.1F, EOS only supported IPv4 addresses for VXLAN underlay, i.e., VTEPs were reachable via IPv4 addresses only. This feature enables a VTEP to send VXLAN Encapsulated packets using IPv6 underlay. The following list describes the capabilities of this feature. The feature is designed for a Greenfield deployment environment, i.e., an environment where all VTEPs communicate using IPv6 underlay only. In such deployments, the VTEPs must be configured with an IPv6 address on the VXLAN source interface. And all VTEP-VTEP VXLAN...
Continue reading →

4-way L2 ECMP support for EVPN VXLAN All-Active Multihoming 

Description As of EOS 4.22.0F, EVPN all-active multihoming is supported as a standardized redundancy solution.  Redundancy provides not only better fault tolerance but also a way to load balance unicast traffic for better efficiency.  The EVPN VXLAN 4-way L2 ECMP feature allows a Customer Edge (CE) to perform Equal Cost Multi-Path (ECMP) unicast VXLAN switching to a remote CE that is multihomed to at most four Provider Edges (PE).  This feature overcomes the existing 2-way ECMP limitation by providing up to 4-way ECMP. Platform compatibility Platform Independent. (Subject to any and all platform compatibility limitations listed in EVPN Extension to...
Continue reading →

VXLAN Unresolved ARPs to 172.16.1.1

We have stand for test VXLAN between different DCs (schema in attachment). All Leafs connected to CVX server on each DC. And each CVX connected between themeslaves via BGP EVPN. For test in each leaf was connect server with linux and configured port on access VLAN100. Next step I configure assotiation VLAN100 and VNI25100. MAC Lerning good work and on both leaf I see mac-addreses. Connection for vxlan configured in GRE tunnel and has good L3 connectevless. But traffic has no on VNI 25100. I tried to debug this problem and discovered: show vxlan config-sanity category result detail ———————————- ——–...
Continue reading →

EVPN Transit Route VRF Leaking

Description As described in the L3 EVPN VXLAN Configuration Guide, it is common practice to use Layer 3 EVPN to provide multi-tenancy within a datacenter. This is achieved by keeping each tenant’s prefixes in separate VRFs.   In order to allow hosts from different VRFs to communicate with each other, a new mechanism lets the Spine act as a VTEP to which cross-VRF traffic will be directed for leaking.   The Spine will: Import specific learned IP or IPv6 prefixes belonging to one VRF into another Advertise these leaked routes to relevant EVPN neighbors (Leafs) with itself as next-hop. Furthermore,...
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 Configuration VPWS configuration is made up of two main components on each participating router.  The first is the patch...
Continue reading →

EVPN E-Tree for MPLS

Description E-Tree is an L2 EVPN service (defined in RFC8317) in which each attachment circuit (AC) is assigned a role of Root or Leaf.  Once roles are assigned, forwarding rules are enforced such that: Root ACs can communicate with leaf ACs and other root ACs Leaf ACs can only communicate with root ACs.  Leaf AC to leaf AC traffic is blocked In this implementation, ACs are configured at the VLAN level, and the forwarding rules are enforced using a combination of local configuration of leaf VLANs (for local hosts), and  asymmetric route targets (for remote hosts). Platform compatibility DCS-7280R DCS-7280R2...
Continue reading →

EVPN Centralized Anycast Gateway

Description In the Centralized Anycast Gateway configuration, the Spines are configured with EVPN-IRB and are used as the IP Default Gateway(DWG), whereas the Top of rack switches perform L2 EVPN Routing. EVPN-IRB  supports both Virtual eXtensible Local Area Network (VXLAN) Bridging and IP Routing on the top of rack (TOR) switch.  In a typical EVPN IRB deployment, the IP Default Gateway(DGW) for a host (or VM) is the IP address configured on the IRB interface (check out the EVPN IRB TOI for more detail).   Platform compatibility DCS-7050X* DCS-7050X2 DCS-7050X3 DCS-7300/DCS-7320 DCS-7300X3 DCS-7260X* (DCS-7260X, DCS-7260X2, DCS-7260X3) DCS-7280R, DCS-7280R2, DCS-7280R3 DCS-7500R, DCS-7500R2,...
Continue reading →

Migrating from legacy DC design to EVPN VXLAN Fabric

Introduction This document is intended to provide a reference of steps and sequence followed for:  (1) migrating a legacy 3-tier L2 network to EVPN based VXLAN environment using Leaf & Spine design (2) migrating an L2 Leaf & Spine network with VXLAN using CVX as the control plane to EVPN based control plane (3) migrating an L2 Leaf & Spine network with VXLAN using static VXLAN as the control plane to EVPN based control plane. Scope The key objective of this report is to migrate a Layer 2 datacenter to EVPN based VXLAN using Leaf & Spine (L3LS) solution for...
Continue reading →

EVPN Internetworking with IPVPN

Description This feature adds control-plane support for inter-subnet forwarding between EVPN and IPVPN networks. It also introduces a new BGP path-attribute, D-PATH, that may be used for loop prevention when internetworking between EVPN and IPVPN domains. The supported transport type for IPVPN networks is MPLS, while EVPN networks may use MPLS or VXLAN. The following diagram shows an example topology where a DC EVPN-VXLAN cloud is connected to an MPLS-VPN cloud via border leaf nodes peering with both EVPN and IPVPN. The MPLS-VPN cloud is then connected to a DC EVPN-MPLS cloud, where the border leaf nodes peer with both...
Continue reading →

EVPN VxLAN control plane support for OpenStack

Description This feature enables support for an EVPN VxLAN control plane in conjunction with Arista’s OpenStack ML2 plugin for automated network provisioning. When utilizing this feature: VCS (Vxlan Controller Service) on CVX (CloudVision eXchange) will be responsible for dynamically provisioning VLAN to VNI mappings on switches based on OpenStack configuration The OpenStack service on CVX will be responsible for dynamically provisioning VLANs and allowing them on applicable trunk switchports on switches EVPN will be responsible for distributing and configuring flood lists based on  EVPN type 3 IMET routes and host reachability based on type 2 MAC-IP routes This feature is...
Continue reading →

Follow

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

Join other followers: