• Blog

 
 

DHCP Smart Relay

ContentsIntroductionPlatform CompatibilityEOS SupportConfigurationVRF commandsShow commandsLimitation 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...
Continue reading →

DHCP Relay

ContentsIntroductionPlatform CompatibilityEOS SupportConfigurationInterface commandsGlobal commandsIPv6 commandsVRF commandsShow commandsTroubleshooting 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...
Continue reading →

EVPN VXLAN Design Guide

EVPN VXLAN Design Guide   A Detailed Overview of the EVPN & VxLAN Protocols, Route Types, Use-Cases and Architectures   Contents1. Introduction2. VXLAN Overview2.1 VXLAN Bridging2.2 VXLAN Routing3 EVPN Overview3.1 EVPN Operational Benefits3.2 EVPN Terminology3.3 EVPN Address Family and Routes3.4 EVPN Service Models4.  EVPN Core Operations4.1 MAC Address Learning.4.2 ARP Suppression4.3 MAC Mobility4.4 MAC address Damping4.5 Broadcast and Multicast Traffic 4.6 Integrated Routing and Bridging 4.7 EVPN Type 5 Routes – IP Prefix advertisement4.8 Summary Comparison of Route Type-2 and Type-5 Prefix Announcements4.9 Auto RT and Auto RD For VLAN-Based EVIs5. Deployment Models5.1 Underlay and Overlay Design Options5.2 Site Topology...
Continue reading →

Arista Layer 2 VTEP EVPN VxLAN Route Type-1 Support

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   Contents IntroductionTopology ConfigurationsVerificationTraffic Verification 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...
Continue reading →

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

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 →

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

Multi-Tenant EVPN VXLAN IRB Configuration & Verification Guide   Symmetric and Asymmetric IRB With VLAN Based and VLAN Aware Bundle Services Using an eBGP 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 →

L3 EVPN VXLAN Configuration Guide

L3 EVPN VXLAN Configuration Guide   EVPN VXLAN Type-5 Layer 3 VPN  (With Dual-Homed Layer 2 and Layer 3 Sites) ContentsOverviewUse Case OverviewConfiguration ExampleeBGP Underlay ConfigurationVRF config on leafsVRF verificationVxlan Configuration on LeafsVxlan VerificationEVPN ConfigurationEVPN VerificationAdvertise VRF Routes in EVPN Verify EVPN Routes Overview 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 using type-2 routes, but additionally,  EVPN supports the exchange of layer 3 IPv4 and...
Continue reading →

How to Minimize Impact when Port is Flapping

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 →

Arista Any Cloud Platform – VM Migration

ContentsIntroductionObjectivePrerequisitesTopologyConfigurationReferences Introduction In many scenarios, resources are provisioned in the public cloud as a service, without a need to connect to a private on-prem environment. Situations will arise where connectivity is required between a public and private environment that conflict in IP space. This article will showcase how to leverage vEOS Router in AWS to establish connectivity between a VPC and a private on-prem datacenter that conflict in IP space. In this particular example, there are a hand-full of VMs that need to be migrated from AWS to a private environment. Objective Establish connectivity between the AWS VPC and the private environment. Once connectivity is...
Continue reading →

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

ContentsIntroductionProblem statementStep 1: Create a builder, import librariesStep 2: add the procedure to send REST API requestsStep 3: create the procedure to load peer list via eAPIStep 4: add main codeStep 5: save the builderLet’s test the builder 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...
Continue reading →

Cloud Tracer + Telemetry

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 →

User passwords with blank spaces

  ContentsOverviewIntroductionManually hashing the passwordCreating the user accountTesting the account Overview                 Arista EOS allows users to define local user accounts using the command “username <name> secret <password> “, where <password> is a plain text password. However, the Arista CLI does not accept blank spaces in the <password> portion of the command. This restriction is due to a limitation in the parsing algorithm EOS uses to find the password in the command. The parsing algorithm does not recognize blank spaces when parsing the password. To work around this issue a password with blank spaces can be manually converted to a...
Continue reading →

40G TapAgg BiDi Design

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

ContentsIntroductionRobot FrameworkWhy Robot Framework?KeywordsAristaLibrary for Robot FrameworkArista Network Validation FrameworkAristaLibrary ExampleReferences 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...
Continue reading →

Understanding Logging Levels

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 →

ChalkTalk Series Launched!

Be sure to check out the new Arista Chalk Talk Series –  https://eos.arista.com/arista-chalktalk-series/ You will need a login to access this content – so get one now!    

ZTPv6 using DHCPv6 Relay Agent

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 →

Arista Any Cloud Platform – Destination NAT (IP Anycast) in vEOS Router

ContentsOverviewObjectivesConfiguration and ValidationReachability TestFailover Test Overview Purpose of this post is to test and validate Destination NAT (IP Anycast) support on vEOS Router.  We built the following topology in AWS to validate this setup:    Here is the link to the EOS Central article that can be referenced to help build this topology – https://eos.arista.com/arista-any-cloud-platform-hybrid-cloud-veos-router-in-aws-deployment-guide/ Objectives We hope to accomplish  the following in this article: Create a Loopback interface on vRouter-1a and vRouter-1b with an IP address of 1.1.1.1/32 Advertise 1.1.1.1/32 as an equal cost route to vRouter-Transit.  At any given moment vRouter-Transit could take the path to vRouter-1a or vRouter-1b.  In this setup...
Continue reading →

Network CI/CD Part 2 – Automated Testing with Robot Framework library for Arista devices

ContentsPreviously on Network CI/CD Part 1…The problem of network testingWhy Ansible isn’t enough?Why scripting is too much?Robot Framework Arista Network ValidationTest bed setupTesting Custom keywordsFurther readingComing up Previously on Network CI/CD Part 1… We’ve established that lack of simulated test environments and automated test tools are among the inhibitors in a transition from a traditional network operation model to a DevOps workflow, where all changes are verified and tested prior to being deployed in production. We’ve seen how to solve the first problem with Arista’s cEOS-Lab docker container and a simple container orchestration tool. We’ve shown how the new containerised EOS allows us to dramatically increase the number of nodes...
Continue reading →

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

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 →

Follow

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

Join other followers: