• Tag : VXLAN

 
 

Spine-Leaf BGP EVPN Best Practice

Hello I’m seeking for a white paper\best practice document that can cover deploying a topology of spine-leaf data center. The points i’m seeking clarifications are 1. underlay L3 connectivity – is IGP required to be configured between spine and leafs. 2. is multicast a must between spine and leaf for control plan operation? (forwarding BUM packets?) 3. with vxlan, are there any problems using mlags? how can i advertise a certain MAC address is available from two different VTEPs and encapsulate into vxlan from both connections? 4. in terms of configuration, how can i deploy such a scenario? 5. unconventional as it...
Continue reading →

vEOS on ESXi – Jumbo MTU Problem

Hi, I run couples of latest vEOS switches on ESXi, trying to build a VXLAN lab to test. Between vEOS switches, I used standard virtual switch as a virtual cable for each individual connection.  In vSwitch settings, I’ve set the MTU to 9000. MTU1500 works OK. But ping test over 1500 bytes all failed. PING 172.16.11.0 (172.16.11.0) 1473(1501) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable Searching over Internet came up no result…. Any thought?  

How to recover flood-list and mac address learning when using OVSDB management

Hi, I am a beginner of Arista switch. I have two questions on that. <Information of the switch>model:Arista DCS-7150S-64-CLversion:EOS-4.15.7M 1) The flood-list and the mac address  learning disappears when the switch restarts. Why? I set the infomation that “HER flood-list and mac address learning” on the Arista switch that using the OVSDB management. Example of setting  is as follows.(The following command executed on CVX.)-bash-4.1# vtep-ctl add-mcast-remote <LS-name> unknown-dst vxlan_over_ipv4 <vtep-ip>-bash-4.1# vtep-ctl add-ucast-remote  <LS-name>  <MAC-address> vxlan_over_ipv4 <vtep-ip> One day, I stopped the Arista switch and started it.Then, the information(HER flood-list and mac address  learning) disappeared from Arista switch…Note: I confirmed it by...
Continue reading →

Multicast in VXLAN with BGP EVPN control-plane

 Hello, We are trying to run multicast in data center overlay network. In our data centers we are using L3 leaf-spine topology with VXLAN. For the control plane BGP EVPN is used.  Leaf switches are deployed in an MLAG configuration. We want to run multicast between hosts that are on same vlan across switches in different MLAG domains. Multiple multicast receivers, as well as multiple senders are connected to different MLAG domains and are all in the same VLAN. Multicast receiver can receive m-c stream from the sender if both of them are in the same MLAG domain. But if receiver is connected to...
Continue reading →

EVPN Configuration – Layer 2 EVPN design with Type-2 routes

Introduction This document describes the operation and configuration of BGP EVPN with a VXLAN forwarding plane, for the construction of multi-tenant Layer 2 networks, termed L2VPNs within this document, over a layer 3 leaf-spine network. The configuration and guidance within the document unless specifically noted are based on the platforms and EOS releases noted in the table below Platform Software Release 7050X Series EOS release 4.18.1 7050X2 series EOS release 4.18.1 7060X Series EOS release 4.18.1 7160 series EOS release 4.18.1 7280R/7500R EOS release 4.18.1   Leaf spine underlay architecture EVPN with a VXLAN forwarding plane provides the ability to...
Continue reading →

VXLAN on 7150 EOS version 4.16.7M

Hi, I’m trying to get VXLAN to work between 2 back to Arista 7150S. But it does not work.   SW1 and SW2 are directly connected via a l3 interco. Traffic is being generated from SW1- eth1 On both switch I have version 4.16.7M Here is my config : SW1 config : SW1(config)#sh run int e2,1interface Ethernet1   load-interval 5   switchport trunk allowed vlan 777   switchport mode trunk   no lldp transmit   spanning-tree bpdufilter disableinterface Ethernet2   load-interval 5   switchport mode dot1q-tunnel   no switchport   ip address 7.7.7.1/30   ip igmp version 2   ip pim sparse-mode   spanning-tree bpdufilter disableSW1(config)#sh run int vxlan 1interface Vxlan1   vxlan...
Continue reading →

VXLAN on 7150 EOS version 4.16.7M

Hi, I’m trying to get VXLAN to work between 2 back to Arista 7150S. But it does not work.   SW1 and SW2 are directly connected via a l3 interco. Traffic is being generated from SW1- eth1 On both switch I have version 4.16.7M Here is my config : SW1 config : SW1(config)#sh run int e2,1interface Ethernet1   load-interval 5   switchport trunk allowed vlan 777   switchport mode trunk   no lldp transmit   spanning-tree bpdufilter disableinterface Ethernet2   load-interval 5   switchport mode dot1q-tunnel   no switchport   ip address 7.7.7.1/30   ip igmp version 2   ip pim sparse-mode   spanning-tree bpdufilter disableSW1(config)#sh run int vxlan 1interface Vxlan1   vxlan...
Continue reading →

vEOS – Logical VTEP with MLAG – VXLAN interpreted on MLAG Peer

Hello all, Please see attached picture for network topolgy. I try to use VXLAN with HER for DCI, together with BGP&BFD as routing protocol (for underlay) between Site A and Site B.– Site A: VLAN100 mapped to DCI VNI 10100– Site B: VLAN1100 mapped to DCI VNI 10100– spine1&spine2 as mlag peers with logical VTEP– spine3 as single VTEP– ports for DCI configured as L3 routed (no switchport)– EBGP between spine1 and spine3 as well as spine2 and spine3– VLAN4093 between spine1 (10.0.1.1) and spine2 (10.0.1.2) for re-routing in case one DCI is down– IBGP between spine1 and spine2– target...
Continue reading →

Access to manuals

Hi there! Currently I’m doing some research in new data center networking technologies. I downloaded vEOS image and built basic topology using Unetlab. Now I want to configure EVPN, but I couldn’t find any manuals on it. For some reason this one – https://eos.arista.com/eos-4-18-1f/evpn-vxlan/ is protected. How can I get it?

VXLAN Indirect Routing on 7280E, 7280R and 7500R series

In EOS-4.18.0F, VXLAN direct routing was introduced on the 7500R and 7280E/R series platforms. VXLAN routing provides the capability to route between VXLAN Layer 2 domains. In EOS-4.18.1, support for VXLAN Indirect Routing model is added to the 7500R and 7280E/R series platforms. In the Indirect routing model, the destination host is not directly attached to the VTEP(s) where the default gateway functionality is present. This model is called “indirect” because, in this model,  the packet possibly needs to go through multiple hops in the overlay to reach the final destination. It typically involves running routing protocols in the overlay...
Continue reading →

Overlay IPv6 routing over VXLAN

Overlay IPv6 routing over VXLAN Tunnel is simply routing IPv6 packets in and out of VXLAN Tunnels, similar to VXLAN overlay IPv4 routing. Underlay ( Outer IP Header ) in VXLAN still uses IPv4, and common for both overlay IPv4 and IPv6 . Hence VXLAN configuration remains exactly same for both IPv4 and IPv6 overlay routing support. This feature enables IPv6 networks/hosts get connected through VXLAN Tunnels. Following figure illustrates IPv6 routing followed by VXLAN encapsulation to reach a remote host across the VXLAN tunnel.   Following figure illustrates VXLAN decapsulation and routing of an IPv6 packet. Platform compatibility DCS-7050X DCS-7060X DCS7260X DCS-7050X2 DCS-7250X DCS-7304 / DCS-7308 /...
Continue reading →

EVPN extension to BGP using VXLAN

Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: L2VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to exchange overlay MAC and IP address reachability information between BGP peers within a tunnel [1]. In EOS 4.18.1F VXLAN tunnel support was introduced [2]. The available features are: Single-homing L2 routes (EVPN type 2 and type 3), with MLAG used as the L2 multi-homing solution. Multi-homing L2 routes (EVPN type 1 and type 2) are received and installed, with up to two all-active remote paths per destination (additional paths...
Continue reading →

OVSDB Hardware-VTEP L3 Integration

EOS currently supports VXLAN L2 integration with external controllers using the Arista OVSDB HW VTEP schema ([HW-VTEP]) implementation. External controllers can read and write the tables specified in OVSDB to orchestrate a VXLAN L2 overlay network. EOS-4.18.0F  introduces  support for L3 functionality in VXLAN Overlay Networks. The functionality,  implemented in Arista’s Cloudvision Controller (CVX) and switches, will be used to orchestrate L3 VXLAN Overlay in a physical network of Arista switches. External controllers (e.g., VMWare NSX or Nuage VSP) can interact with the OVSDB server running on CVX/EOS. CVX/EOS reads all the information from OVSDB and communicates with the appropriate Arista...
Continue reading →

VXLAN: security recommendations

Abstract This document provides recommendations that are advised to implement in order to increase the security in multitenant network environments built on Arista Networks devices using VXLAN. Introduction One of the crucial qualities of modern cloud network infrastructure is scalability. Scalability can’t be achieved if security of the network operations inside the cloud is compromised. As for example, load scalability is not achievable in environments where the VMs are not able to operate when the network between them is not working properly due to hijacked MAC-addresses. One of the technologies used nowadays to address the challenges with scalability inside the cloud networks...
Continue reading →

VXLan, MLAG and duplicate ARP

We having an issue that we believe is related to receiving duplicate ARP requests. We’ve got nodes (part of openstack) connected to a pair of 7060 switches using MLAG, these 7060 switches then join a VXLan to connect to other pairs of 7060 switches where other nodes exist. The behaviour we’re seeing with ARP requests is that the broadcast is being flooded to the VTEP that is on both switches in the MLAG group, this is then being forwarded down both legs to the node, so the node sees the request twice. This seems to be confusing the OVS running...
Continue reading →

A comparison of virtual ip commands

The ‘ip virtual-router’ command Switch1:   Switch1(config)#interface vlan 10   Switch1(config-if-Vl10)#ip address 10.0.0.2/24   Switch1(config-if-Vl10)#ip virtual-router address 10.0.0.1   Switch1(config)#ip virtual-router mac-address 00:1c:73:00:00:99 Switch2:   Switch2(config)#interface vlan 10   Switch2(config-if-Vl10)#ip address 10.0.0.3/24   Switch2(config-if-Vl10)#ip virtual-router address 10.0.0.1   Switch2(config)#ip virtual-router mac-address 00:1c:73:00:00:99 The ‘ip virtual-router address’ command requires an IP address to be configured on the SVI where it is applied. How does the host resolve ARP for the default gateway/vIP? Gratuitous ARPs: Gratuitous ARPs are periodically sent from both switches which have VARP configured. In the gratuitous ARPs the configured vMAC is used as the Ethernet Source MAC. The ARP message  informs the host that Virtual IP...
Continue reading →

VxLAN VTEP counters

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP basis. Specifically, it enables the device to count bytes and packets  that are getting 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 VxLAN packets the device has to support VxLAN and have a VxLAN interface...
Continue reading →

EVPN Control-Plane support for VxLAN

Just wondering if there is EVPN Control-Plan extensions planned for support (and when) with VxLAN Leaf devices like ahem, other vendor’s are doing.  Stretched fabrics (over wan) are becoming popular as an escape from OTV and prior ilk are where this seems most relevant, and something I’m seeing interest in where flood control can/should be most relevant.

ARP replies in a VxLAN plus routing Data Center Inter-connect deployment

Overview VxLAN and routing with DCI inter-connect can cause ARP issues with VLAN segment extensions between datacenters. The goal of this article is to outline the issue relating to ARP replies with VxLAN routing and VARP. We will show the use of a workaround today (recommended) and how the new ARP-Reply feature will resolve the problem.  This feature will be introduced in later version of EOS. The date will be announced in the future. Issue: VxLAN with the directing routing model for DCI will requires a unique VARP MAC address per DC. This is needed when  when there are two...
Continue reading →

Follow

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

Join other followers: