• Category : Tech Tips

 
 

Carrying Label Information in BGP-4

Posted on March 19, 2018 by

Theory of BGP-LU Overview  MPLS typically has been used in core service provider (SP) networks. These deployments, however, have expanded beyond the network core and edge to the access and metropolitan networks. This rapid growth of edge-to-edge, label-switched paths (LSPs) across many networks  has presented scaling challenges.  In particular, emerging business demands related to Carrier Supporting Carrier (CSC), global growth of IPv6 traffic, and delivery of services over native IPv4 networks require pertinent and flexible solutions. Many organizations prefer to continue with the existing MPLS-based solutions to more recent overlay technologies such as VXLAN.   A solution that solves these potential...
Continue reading →

DHCP Snooping

Posted on August 16, 2018 by

Introduction EOS supports DHCP Relay feature, which relays DHCP Requests/Responses between DHCP clients and DHCP servers in different subnets. However, DHCP server does not have visibility of where the request originated from and can only make IP address allocation decisions based on the client MAC address alone (client MAC address is included in the DHCP packet as part of the payload). To remedy that, DHCP Option-82 was formalized to allow relay agent to include Remote ID and Circuit ID so that DHCP server can apply more intelligent allocation policy. Switch intercepts DHCP requests from client and insert Option-82 information in...
Continue reading →

DHCP Smart Relay

Posted on August 14, 2018 by

Introduction EOS DHCP relay agent forwards all the DHCP requests from the clients using the primary IP address of the interface as the ‘giaddr’ in the relayed/forwarded requests even when there are secondary IP addresses configured on the interface and there are multiple IP address pools from secondary IP subnets with available addresses on the server. DHCP smart relay feature supports forwarding requests with secondary IP addresses in the gateway address ‘giaddr’ field. This allows the DHCP server offer addresses to client requests with gateway addresses from secondary IP subnets configured on the interface. The smart relay agent keeps track...
Continue reading →

DHCP Relay

Posted on August 14, 2018 by

Introduction DHCP Relay feature forwards DHCP packets between client and server when DHCP server is not in the same broadcast domain as client. DHCP Relay should be configured on the gateway interface (SVI/ L3 interface ) for the clients. DHCP Relay agent creates a new unicast DHCP packet and sets the giaddr field to the ‘primary’ IP address of the interface on which DHCP request packet is received.The modified request packet is then relayed to one or more configured DHCP servers. DHCP server assigns ip address to client from the pool corresponding to giaddr field. Platform Compatibility Supported on all...
Continue reading →

EVPN VXLAN Design Guide

Posted on August 6, 2018 by

EVPN VXLAN Design Guide   A Detailed Overview of the EVPN & VxLAN Protocols, Route Types, Use-Cases and Architectures   1. Introduction This document describes the operation and configuration of BGP EVPN Services over a VXLAN (Virtual eXtensible LAN) overlay on Arista platforms. The focus in this design guide is VxLAN as the protocol for the data-plane encapsulation for the overlay tunnels, and the functionality of the Multiprotocol BGP (MP-BGP) EVPN address-family for control plane signaling in the overlay.  MP-BGP EVPN is not only used for advertising MAC addresses, MAC and IP bindings and IP prefixes across the overlay; it...
Continue reading →

Arista Layer 2 VTEP EVPN VxLAN Route Type-1 Support

Posted on August 6, 2018 by

Arista Layer 2 VTEP EVPN Route Type-1 Support   Arista Layer 2 EVPN VTEP Inter-Operation With A/A Multi-homed Third-Party Layer 3 EVPN VXLAN VTEPs   Introduction   This document will explain the configurations required to support inter-working with EVPN VXLAN A/A multi-homed VTEPs, also known as L2 ECMP in VxLAN EVPN.   Currently, EOS uses MLAG is used to achieve Multi-homing in EVPN VxLAN Topologies, with an any-cast VxLAN VTEP configured on the MLAG pair, and as such does not need to support EVPN Multihoming Tx (Type-1 route generation). EOS can however install received Type-1 routes and can...
Continue reading →

Multi-Tenant EVPN VXLAN IRB Configuration & Verification Guide (iBGP Overlay eBGP Underlay)

Posted on August 6, 2018 by

Multi-Tenant EVPN VXLAN IRB Configuration & Verification Guide   Symmetric and Asymmetric IRB With VLAN Based and VLAN Aware Bundle Services Using an iBGP Overlay and eBGP Underlay Topology Logical Diagrams Tenant-A: Symmetric IRB Tenant-B: Asymmetric IRB Platform Support: https://www.arista.com/en/support/product-documentation/supported-features Topology Overview   In the symmetric and asymmetric IRB setups illustrated in the figures above;  for tenant-a four subnets are stretched across the two MLAG domains; with two subnets (vlan 10 – 10.10.10.0/24 and vlan 11 – 10.10.11.0/24) configured as a VLAN based service, and two other subnets (vlan 12 – 10.10.12.0/24 and vlan 13 – 10.10.13.0/24) as a vlan-aware...
Continue reading →

How to Minimize Impact when Port is Flapping

Posted on July 20, 2018 by

Intro A flapping port can cause network instability and disruption as L2/L3 protocols are constantly forced to re-converge and rebuild the topology with every port status change. If flapping happens at short intervals, it can cause a spike in the CPU utilization as well.  To minimize the impact in such scenarios, Arista introduced the ‘link-debounce’ feature. The idea is to wait until the port status is stable for a period of time before L2/L3 protocols are notified about the status change (up/down).  Feature Description The link-debounce command configures the link debounce under network interfaces. Link debounce time is the time...
Continue reading →

CVP REST API Tricks. Part 1: Form Builder with Dynamic Fields

Posted on June 29, 2018 by

Introduction Arista CloudVision Portal (CVP) covers customer demand for automation, provisioning and monitoring (telemetry) in a very simple and efficient way. Nevertheless, sometimes customers can have certain requests that are not covered by the default CVP workflow. Fortunately CVP workflow can be easily customised with REST API. “CVP REST API Tricks” series will cover some examples that are not part of the default feature set, but can be easily implemented via REST API.  WARNING: Examples covered by “CVP REST API Tricks” deviate from the default CVP provisioning model. If you are going to use that in production, be sure that...
Continue reading →

Cloud Tracer + Telemetry

Posted on June 26, 2018 by

Arista’s Cloud Tracer, coupled with CloudVision telemetry integrate together to create a compelling visibility and troubleshooting solution. Cloud Tracer Cloud Tracer is a feature within EOS software that monitors the performance of resources in the network.   Traditionally, network-based performance probes were based on proprietary packet formats and limited to router-router measurements.  Cloud Tracer is able to track and measure performance against an HTTP or HTTPS URL and provide measurements for response time, packet loss, round-trip latency, and jitter.  The URL could be another network device or a critical application resource. CloudVision Telemetry Arista’s CloudVision telemetry is a robust, state streaming...
Continue reading →

40G TapAgg BiDi Design

Posted on June 18, 2018 by

Arista QSFP BiDi optics allow both transmit and receive signals, to travel on the same fiber slice. The QSFP BiDi design provides 40Gbps (20Gbps egress & 20Gbps ingress on each fiber slice) bandwidth using the duplex MMF (OM3, & OM4) cable. This way one can leverage the existing cabling infrastructure to upgrade BW from 10Gbps to 40Gbps ( see diagram 1). The BiDi optics provides a number of benefits and some are listed below: ▪   Fiber replacement not required when moving from 10Gbps to 40Gbps ▪   Lower CAPEX as 75% less fiber comparing parallel cable (40G SR4) ▪   Interoperable with Industry standard...
Continue reading →

Robot Framework for Auto Test

Posted on June 14, 2018 by

Introduction In-house EOS code certification is generally a time consuming process as it involves a lengthy life cycle. At a high-level, the various stages involved are: Setting up the test environment Designing test cases Executing test cases Documenting test results Validating gathered test results As you can imagine, stages 3, 4 and 5 can be the most time consuming as they warrant an error-free execution. Additionally, since image and configuration management would be simplified, most customers would like to have a single EOS version deployed across all their platforms and networks. So certifying code at a brisk pace, on all platforms,...
Continue reading →

Understanding Logging Levels

Posted on June 6, 2018 by

Overview   EOS generates a number of logs to notify various events such as interface going down,spanning-tree state change, agent restart, bgp neighborship flap etc. One event can be more impacting than other and thus it is necessary that respective logs reflect that severity. This is why all the logs are categorized into different severity/logging levels. There are 8 logging levels available, from 0-7, 0 being most critical and 7 being least critical.  alerts         Immediate action needed           (severity=1)  critical       Critical conditions              (severity=2)  debugging      Debugging messages                (severity=7)  emergencies    System is unusable                (severity=0)  errors         Error conditions                  (severity=3)  informational  Informational messages            (severity=6)  notifications...
Continue reading →

ZTPv6 using DHCPv6 Relay Agent

Posted on June 2, 2018 by

1. IntroductionZTP (v4/v6) is a simple hands-off approach to both initial set up and upgrading an existing network.  ZTP does not require entering into the switch CLI, speeds up and simplifies deployment, reduces the risk of human error, and can adapt to many deployment scenarios. It offers scripting extensibility for complex networks and flexible provisioning using standard tools.  Additionally, the switch can be ZTP booted using a variety of identifiers, such as its MAC address, serial number, or LLDP neighbors. Arista switch’s ZTP process starts with communicating to a DHCP(v4/v6) Server, where apart from getting the IP Address, Default Gateway,...
Continue reading →

Tap Aggregration Tip: Popping MPLS tags for Untagged or VLAN based Tools

Posted on May 12, 2018 by

In Tap Aggregation scenarios common in WAN and Service Provider environments, MPLS tags are present.  Many of the analysis tools do not understand these tags and so the Arista DANZ feature set allows for these to be removed.  This functionality has been around since 4.15.0F however initially had the limitation that the traffic would always be sent out the Tool port with a VLAN tag.  However, some tools not only do not understand MPLS, but also VLAN tags, so this tip describes how to deal with both 802.1q and untagged scenarios. Step 1:  Configure MPLS pop/strip on the Tap port:...
Continue reading →

Integrating Salt and Arista ZTP Server for Zero Touch Automation of EOS

Posted on May 7, 2018 by

Zero Touch Provisioning The term ZTP or Zero Touch Provisioning is a feature often heard, which EOS has offered since the early days. During the initial boot, if a startup-configuration file is not found in the /mnt/flash/startup-configuration directory, the EOS device will automatically boot into ZTP mode. The switch will obtain an IP address from a DHCP server including DHCP options 66 and 67. Next the switch will ask the ZTP server or a server designated within option 66/67  for a bootstrap file. In this post we will use the Arista ZTP server which can be found here.  This process is depicted in the following picture: The...
Continue reading →

Summary of Arista VxLAN Control Plane Options

Posted on April 16, 2018 by

IP Multicast Head End Replication (HER) with static flood-set CloudVision eXchange (CVX) Ethernet VPN (EVPN) – VTEPs within a VNI join a configured control plane multicast group.– BUM traffic is sent to all VTEPs within the VNI over the configured multicast-group.– Arista supports only multicast decapsulation to interop with third-party VTEP(s). HER will be used for BUM traffic encapsulation.  – Underlay needs to be multicast capable which can possibly make the deployment limited.– Recommended for deployments where Arista VTEPs need to interop with legacy third-party VTEPs that support only multicast underlay for BUM traffic handling. – BUM traffic within a...
Continue reading →

CVX Deployment Recommendations for VxLAN Control Service

Posted on March 31, 2018 by

CVX (CloudVision eXchange) is an infrastructure for aggregating and sharing state across a network of physical switches running EOS. Services that run on top of this infrastructure provide network-wide visibility and coordination. CVX is a single pane of glass for network wide visibility and orchestration of physical switches running EOS. CVX provides VxLAN Control Service (VCS) which is a mechanism by which hardware VTEPs share states between each other in order to establish VxLAN tunnels without the need for a multicast control plane or manual configuration of static flood-set for Head End Replication. CVX is built on the same underlying...
Continue reading →

EOS allows you to choose your own hardware and run your own apps

Posted on March 20, 2018 by

You’ve decided to go open source with your datacenter network. Whether you want to go open software or open hardware, Arista EOS provides the best software stack to complete your solution. In fact, I’ve been told that most of my daily web usage travels through a switch running EOS along the way. Arista’s EOS software architecture is designed to manage the best network silicon available for datacenters.  EOS is offered as a single binary across all Arista products, including 4 silicon architectures, over a dozen chipsets, as well as in hypervisor, container, and cloud-platform packaging. We have always supported the...
Continue reading →

Deploying L2 and L3 services with Multiple Tenants on a Single Interface

Posted on March 5, 2018 by

The intention of this post is to provide a configuration example on how multiple tenants could be deployed on a single physical interface with a mix of multiple L2 and L3 EVPN services. Ponder the network in below diagram, where two EVPN end point switches have multiple tenants (Tenant A, B, C and D) connected on the same physical interface. The interface in this case is Ethernet3, at the respective sites. Tenant A and B want L2 EVPN services. Tenant C and D want L3 EVPN services. Please note that the IP core in the diagram could be a spine...
Continue reading →

« Older posts