Arista EOS Central - Tag

IPv6 Underlay Support for VXLAN With EVPN Control Plane

Posted on June 21, 2020 by Madhu Sudan | 32 Views

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

Posted on June 10, 2020 by Hyun Chul Chung | 77 Views

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

Posted on June 3, 2020 by Stanislav Tretiakov | 0 Views

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 →

Scalable VXLAN/EVPN-MS

Posted on May 27, 2020 by Danail Petrov | 0 Views

G’day, I am looking for some guidance as well as real life experience, gotchas, etc (if someone has done something similar it will be great to hear some thoughts). I am working on a design of 50+ DCs, meaning I’ll have 50+ fabrics across the globe. The requirement is to support multi-tenancy across all the sites and the only “relief” here is I only need to support layer3! That being said, I am considering multi-site, multi-pod architecture running route-servers within and between all sites. My current idea is to have three major sites (regions) – US, EMEA & APAC. In...
Continue reading →

RACL on inner IP fields for VXLAN decapsulated packets

Posted on May 4, 2020 by Kaladhar Musunuru | 56 Views

Description This feature introduces the support for ACL configuration on VxLAN decapsulated packets. The configured ACL rules will be applied to the inner packet header after Vxlan header decapsulation. The ingress RACLs for VxLAN decap packets can be configured on SVIs or under Vxlan tunnel interface. Platform Compatibility DCS-7280R/R2 DCS-7500R/R2 Configuration No special configuration needed to enable RACLs on SVIs to match inner header fields for VxLAN decapsulated packets. interface Vlan100 ip address 1.0.5.1/24 ip access-group vxlanAclIpv4CoreToEdge in ! interface Vxlan1 vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 100 vni 20000 vxlan flood vtep 172.16.1.1 172.16.1.2 172.16.1.3 ! ip...
Continue reading →

EVPN Transit Route VRF Leaking

Posted on April 27, 2020 by alton | 206 Views

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 →

Migrating from legacy DC design to EVPN VXLAN Fabric

Posted on March 6, 2020 by Gopinath Balakrishnan | 735 Views

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

Posted on March 5, 2020 by Jeffrey Nelson | 485 Views

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

Posted on February 5, 2020 by Mitchell Jameson | 336 Views

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 →

VCS to EVPN hitless migration

Posted on December 23, 2019 by Hyun Chul Chung | 225 Views

Description This feature enables support for migrating from only using VCS as the control plane to only using EVPN as a control plane in a hitless manner with respect to L2 reachability information. Platform compatibility Platform Independent (Subject to any and all platform compatibility limitations of both VCS and EVPN) Configuration Assume that initially only VCS is configured as the control plane. The step-by-step migration process is as follows: Check VCS L2 reachability information in L2Rib: Use the following show commands to verify that L2 reachability information is in L2Rib’s input and output: show l2Rib input vxlan-control-service show l2rib input...
Continue reading →

EVPN VxLAN IPV6 Overlay

Posted on December 20, 2019 by Aadil Ahamed Ahamed | 314 Views

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPV6 host to another IPV6 host on a stretched VXLAN VLAN. This TOI explains the EOS configuration and show commands. Platform Compatibility Platform supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F (Starting in 4.22.1F) DCS-7050SX3-48YC8 (Starting in 4.22.1F) DCS-7050/7050X/7050X2 (Starting in 4.22.1F) DCS-7260X/7260X3 (Starting in 4.22.1F) DCS-7060X/7060X2 (Starting in 4.21.1F) DCS-7250 (Starting in 4.22.1F) DCS-7300/DCS-7320 (Starting in 4.22.1F) Platform not supporting ND Proxy, No ND Suppression DCS-7020R DCS-7160 DCS-7500R/7500R2/7500E Configuration Enable IPv6 Routing Enable global IPv6 unicast routing and IPv6...
Continue reading →

Problem with EVPN type-5 packet forwarding on vEOS

Posted on November 18, 2019 by Stefano Sasso | 0 Views

Hello, I am testing a solution based on VXLAN EVPN, with Type-5 routes, with vEOS 4.23.0.1, but I am having some issues in packet forwarding. The routes are correctly propagated, but when I try to ping from a device connected to one node, on a device connected to another node, the ping does not work. I also tried a ping, with a forced source IP, from the vEOS machine itself, but it has problems too. LEAF-2 LEAF-2#sh ip route vrf gold VRF: gold Codes: C – connected, S – static, K – kernel, O – OSPF, IA – OSPF inter...
Continue reading →

EVPN VxLAN IPV6 Overlay TOI

Posted on November 14, 2019 by Kallol Mandal | 237 Views

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to another IPV6 host on a stretched Vxlan VLAN. This TOI explains the EOS configuration and show commands. Platform Compatibility Platform supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F ( Starting in 4.22.1F ) DCS-7050SX3-48YC8 ( Starting in 4.22.1F ) DCS-7050/7050X/7050X2 ( Starting in 4.22.1F ) DCS-7260X/7260X3 ( Starting in 4.22.1F ) DCS-7060X/7060X2 ( Starting in 4.21.1F ) DCS-7250 ( Starting in 4.22.1F ) DCS-7300/DCS-7320 ( Starting in 4.22.1F ) Platform not supporting ND Proxy, No ND Suppression DCS-7020R...
Continue reading →

VXLAN Auto Flood-List Construction

Posted on November 12, 2019 by Jeffrey Nelson | 213 Views

Description VXLAN flood-lists are typically configured via CLI or learned via control plane sources such as EVPN. The introduction of wireless access points (APs) into the VXLAN data-plane and the desire to minimize AP configuration led to the introduction of a new feature to learn VXLAN flood-lists via the data-plane. When a VXLAN packet is received from a remote VTEP on a new VNI, that remote VTEP is added to the flood-list for that VNI. When all of the MACs behind a remote VTEP have aged out or been removed, that remote VTEP is no longer considered active and it...
Continue reading →

EVPN Control Plane Support for MSS

Posted on November 12, 2019 by Mitchell Jameson | 235 Views

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. CVX will continue to use the Vxlan Controller Service to discover network state and distribute MAC reachability information in service L2 domains (MSS L2 only.) Platform Compatibility Platform Independent (Subject to...
Continue reading →

EVPN – MLAG single homed hosts

Posted on November 11, 2019 by Amit | 506 Views

Description As described in the Multi-VTEP MLAG TOI, singly connected hosts can lead to suboptimal peer-link utilisation. By adding a local VTEP to each MLAG peer, the control plane is able to advertise singly connected hosts as being directly behind a specific local VTEP / MLAG peer. The multi-VTEP MLAG feature has been extended to add EVPN control plane support. VXLAN bridging (EVPN Type-2 and Type-3 routes) and routing (EVPN Type-5 routes and IRB) are supported by this feature. When multi-VTEP MLAG mode is enabled, outgoing EVPN route advertisements will contain a nexthop and router MAC extended community as summarized...
Continue reading →

attached-host routes and MLAG

Posted on November 4, 2019 by Jon Nicholson | 0 Views

I have been experimenting in our test environment with attached-host routes on a vxlan network. We have are using asymmetric IRB across our vxlan infrastructure as it is (for the moment at least) simple enough for this not to cause us an issue. We want to use attached-host to ensure that the correct pair of leaf switches are used for routing “southbound” traffic. In the production environment there will be 5 pairs of leaf switches which will be routing traffic for the edge vlan. Behind this vlan are ~50 nodes that are connected with MLAG to the pairs of (7060CX)...
Continue reading →

SSU support for L2 EVPN with VXLAN

Posted on October 14, 2019 by Narendra C R | 189 Views

Description Smart System Upgrade (SSU) aims to minimize traffic loss during a software upgrade. The Smart System Upgrade (SSU) process includes the core functionality of Accelerated Software Upgrade, plus additional optimizations that permit a hitless restart of several features. SSU leverages protocols capable of graceful restart to minimize traffic loss during upgrade. For protocols not capable of graceful restart, SSU generates control plane messages and buffers them in hardware to be slowly released when the control plane is offline. Additionally, under SSU, the forwarding ASIC does not get reset and ports do not flap. Starting EOS 4.22.1F SSU is now...
Continue reading →

EVPN mutlihoming w/ ESI

Posted on September 19, 2019 by Joe Hlasnik | 0 Views

I stumbled upon this archived [post](https://www.reddit.com/r/Arista/comments/azubnz/mlag_or_esi/) while researching EVPN support specifically on the EVPN multihoming side using common ESIs to extend beyond 2 switches in a LAG. Also this is the only post I’ve found mentioning EVPN Multihoming – https://eos.arista.com/arista-layer-2-vtep-evpn-vxlan-route-type-1-support/ but is limited to using mlag only. Does anyone have any information on when there will be support for the EVPN ESI LAGs?

VxLAN VTEP and VNI Counters

Posted on August 28, 2019 by Rohit Maurya Maurya | 234 Views

Description The VxLAN VTEP and VNI counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP and per VNI basis. Specifically, it enables the device to count bytes and packets that are encapsulated and decapsulated as they are passing through. The counters are logically split up in the two VxLAN directions: “encap” counters count packets coming from the edge, encapsulated on the device and directed to the core, while “decap” counters count packets coming from the core, decapsulated on the device and heading towards the edge. To be able to count...
Continue reading →

Tag : VXLAN