• Category : Tech Tips

 
 

Mixed ASM and SSM Multicast Client Behaviour

Multicast deployments can be difficult to operate and understand as an environment grows or clients with varying capabilities exist. One example of this is when both Any Source Multicast (ASM) and Specific Source Multicast (SSM) clients are connected to the same device in the same broadcast domain. In such a scenario, it is common that whilst the ASM client will receive all sources, the SSM client will want to receive a specific source. To illustrate this, consider the topology below:     Two sources exist, 101.0.0.1 and 101.0.0.2. Client1 is using IGMPv2 and is therefore only able to request the...
Continue reading →

Arista EOS is not vulnerable to CVE-2020-9015

Recently a third party submission was made to MITRE’s CVE database about a possible vulnerability in Arista EOS products. This vulnerability was given the identifier CVE-2020-9015 and can be viewed here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9015. This post is to discuss how this CVE was submitted in error and clarify that Arista EOS is not vulnerable to the issue discussed in the CVE. Before discussing the issue itself, it is worth noting that the CVE database is a public database, which accepts submissions from anyone. If a report is disputed, as is the case with this one, MITRE will not attempt to take sides...
Continue reading →

A Simple Quality of Service Design Example

While there is plenty of documentation available discussing the individual mechanics of Quality of Service, such as Class of Service (CoS) or Differentiated Services Code Point (DSCP) markings and what they mean, there is not as much documentation available bridging the gap from those basic building blocks to a working network QoS deployment. There are some understandable reasons for that lack of documentation, because the design and implementation of a QoS policy on a network is so closely coupled to the specific network’s business objectives and policies that it’s hard to develop much of a QoS policy and have it...
Continue reading →

How to modify the session timeout for the CVP UI

Description By default the UI session timeout is 24 hours, in some environments security policies dictate a much lower value. This article will show you how to modify the default session timeout using the CLI (in future releases this will be available as a knob on the UI). 2019.1.0+ 1. Modify /cvpi/conf/kubernetes/aaa.yaml and add -sessiontimeout=X flag to the pod arguments, where X is the duration and the unit of time, e.g. -sessiontimeout=1h will time you out after 1 hour -sessiontimeout=60s will time you out after 60 seconds -sessiontimeout=10m will time you out after 10 minutes e.g. args: - > /usr/bin/aaa -apiserver=127.0.0.1:9900 -sessionaddr=127.0.0.1:10000 -serveraddr=:9000 -modules=/aaa/conf/modules.json -permissions=/aaa/conf/permissions.json -authprovider=127.0.0.1:10032...
Continue reading →

Modifying the Timeout Value for Image Upgrades Done Using CVP (CloudVision Portal)

Description Traditionally, network image upgrades have been done manually on a device-by-device basis.  With Arista’s CloudVision Portal this arduous task has been greatly simplified.  Multiple groups of devices can be upgraded with a few simple clicks by modifying the applied image bundle in the Network Provisioning page. The tedious task of manually uploading device images is handled entirely by CVP.  For a majority of use cases, the default settings of CVP will not need any sort of modification.  However, if device upgrades will be done over slower WAN links it is recommended that the image upload timeout value within CVP...
Continue reading →

Troubleshooting STP instability 

Spanning Tree Protocol  A Layer 2 network protocol that ensures a loop-free topology for any bridged Ethernet LAN. The Spanning tree protocol allows the network to include redundant links as automatic backup paths that are available when an active link fails without creating loops or requiring manual intervention. The original STP is standardized as IEEE 802.1D. There are several variations to the original STP to improve performance and add capacity. Arista switches support these STP versions: Rapid Spanning Tree  (RSTP 802.1w) Rapid Per-VLAN Spanning Tree (Rapid-PVST) Multiple Spanning Tree (MSTP 802.1s)  Objective  In L2 networks, there can be physical layer...
Continue reading →

PVST BPDUs as data plane for MST

Introduction Arista Switches support the leading spanning tree protocols: RSTP, MSTP, and Rapid-PVST. Multiple Spanning Tree Protocol (MSTP/802.1s) is used by default. However, Rapid Spanning Tree Protocol (RSTP/802.1w), as well as Rapid Per-VLAN Spanning Tree (Rapid-PVST) are configurable. Objective This article is to provide an understanding of how PVST BPDUs are processed on Arista switches running MSTP. PVST BPDUs in MST Region In the case of Rapid PVST To interact properly with the Common Spanning Tree (CST), IEEE BPDUs are sent untagged to the reserved multicast MAC address of 0180.c200.0000. These BPDUs are generated and processed in VLAN 1 irrespective...
Continue reading →

DCS-7280SR2K with FLEXROUTE – A real world use case

When Arista introduced R-series back in 2015 (publicly announced, available in 2016), it was a game changer. For the first time in networking history, a switch with merchant-silicon chips was capable to absorb full IPv4 and IPv6 internet tables. This valuable capability opened a full set of new addressable use cases to all vendors which leveraged off-the-shelf ASICs to implement the device forwarding plane. Since then, two more generations have been released, namely the R2 and R3 platforms and these platforms further enhanced both performances and, more relevant to our discussion, scaling. Arista Networks has several routers to address Internet...
Continue reading →

Configuring Traffic Flows using sFlow in CVP (Cloudvision Portal) 2019.1.x

Introduction Many users rely on 3rd party flow tools to enable greater visibility into the network and generate alerts when irregular flows have been detected.  However, with the growing number of tools being used to provide this visibility, each with their own strengths, the user may experience tool sprawl.   In order to ease the number of tools required within an environment and move towards the goal of a “Single Pane of Glass” to manage our networks, Cloudvision Portal 2019.1.x provides a built-in IPFIX/sFlow collector that will show the top flows within a network.  Once these flows are collected, they can...
Continue reading →

Configuration Change Email Notification

Using Event-Handler Feature, you can send an email notification whenever the Startup Configuration has been modified.  Below is the basic setup required to configure the email client and Event-Handler. Email Client The following email client configuration utilizes Gmail as the SMTP server with user itnetops@example.com as the authorized user to send emails.  It also uses TLS as the transport to Gmail.  Any valid SMTP server can be used for this function. email   from-user itnetops@example.com   server smtp.gmail.com   auth username itnetops@example.com   auth password <password>   tls You may also specify a different host port to the server (server host:port) if needed.   Event-Handler...
Continue reading →

Selective Packet Truncation in Tap Aggregation

Selective Packet Truncation in Tap Aggregation Packet Truncation in tap aggregation mode allows tapped traffic to be truncated to a smaller size before being transmitted. It can be used to reduce the amount of traffic received by analysis devices, if only the headers are to be analyzed while the payload of the packets is irrelevant or unwanted for practical or legal reasons. Truncation is applied either at the tap or tool port. This means that all traffic either arriving from a source or sent to a tool is subject to the truncation setting. In practice, it may be desirable to...
Continue reading →

Sending Telemetry Data from TerminAttr to Multiple CVP instances

Sending Telemetry Data from TerminAttr to Multiple CVP instances Overview This article will explore the ability of the CloudVision Telemetry agent to send data to more than one CloudVision Portal (CVP) instance or CloudVision and a third party application.     The configuration used in this lab was also used as part of the “Synchronising CloudVision Portal Configlets with Ansible” POC lab to enable both CloudVision instances to receive Telemetry data from all the switches. The article for “Synchronising CloudVision Portal Configlets with Ansible” can be found here : https://eos.arista.com/synchronising-cloudvision-portal-configlets-with-ansible/   Introduction The Proof of Concept Lab created to demonstrate...
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 →

Arista EOS – IPv6 RFC Compliance

Arista EOS Software is in compliance with the following IPv6 RFCs: RFC 8200 – Internet Protocol, Version 6 (IPv6) Specification RFC 4861 – Neighbor Discovery for IP version 6 (IPv6) RFC 4862 – IPv6 Stateless Address Autoconfiguration RFC 4443 – Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC 8504* – IPv6 Node Requirements * Arista adheres to the best practices guidelines for the functionality supported in EOS

Introduction to the Network Time Protocol

This document covers the use of the Network Time Protocol (NTP) to synchronize the system clocks on Arista switches. While each switch does have a local clock which can keep time without NTP, each device’s clock will slowly drift out of sync, causing issues including incorrect timestamps on event logs, which can make it difficult to correlate events between devices on the network, an inability to correctly verify the validity of cryptographic certificates for protocols such as TLS or DNSSEC, etc. EOS comes with support to act as both an NTP client and an NTP server; this document will only...
Continue reading →

Memory utilization of EOS devices

Overview: Every operating system needs memory to store the data and the system memory is the place where the CPU holds current programs and data that are in use. This article aims at helping you understand how to check the memory utilization on an Arista switch. Memory Statistics: In EOS, memory statistics can be viewed by multiple methods: CLI:  show version  bash /proc/meminfo  show proc top  bash free -h show version and bash /proc/meminfo will show the same values for memory and it is a more accurate estimation of how much memory is available for processes to use. SW#show version...
Continue reading →

Platform Specific Discards

Objective This document is a guide to understand “input/output” discards (or congestion related drops) on various platforms and how to troubleshoot them. Introduction The term “Discards” in the world of Arista Networks refers to packets being dropped due to congestion- either on CPU level or interface level. Any other kind of drops , like drops due to- “Vlan not being allowed”, “route lookup failure”, “Incorrect Hardware state”, etc are not considered as “Discards” and are mostly considered as “Packet Processor” drops. Platforms to be covered 7050, 7060, 7260 and 7304 series 7280R, 7020R, 7500R series 7150 What is an Output...
Continue reading →

A Simple OSPF Configuration

At this point in your networking career you’ve mastered the L2 domain. I can recall several years ago when I was an embedded software engineer (programming NPUs – Network Processing Units for a networking startup) meeting a colleague that was a master of the L2 domain. This individual knew everything you wanted to know about L2, including non-Ethernet protocols. Then came the day when I was drawing a network diagram with L3 interfaces and diagramming the packet formats at the points of ingress and egress through each L3 hop. My L2 Grandmaster looked at me with a blank stare. I...
Continue reading →

vEOS/cEOS GNS3 Labs

Introduction vEOS-lab/cEOS-lab on GNS3 – What is it? Fast, Multi-user, Efficient nested virtual lab using Qemu/Kvm/docker images of vEOS-lab/cEOS-lab Dynamic persistent config/storage of each cEOS container across stop/starts and GNS3 project closure/re-opens Deployed in minutes on ESXi host. Cloning and creating another bubble is easy, fast and can be moved around Integrated data plane traffic generation tool (Ostinato) in this lab Packet capture on any links between vEOS/cEOS devices Required SW/HW  GNS3 Server VM (Ubuntu 18.04 LTS VM + GNS3 Server) VMware Host system running ESXi version 6 or above with Mgmt Network access ESXi host to deploy this GNS3...
Continue reading →

QoS Basics

Introduction Quality of service is the ability to provide different priority to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow. QoS processes apply to traffic that flows through Ethernet ports and control planes. These processes can modify data fields (CoS or DSCP) or assign data streams to traffic classes for prioritized handling. QoS Features Consider the following topology for the following examples. I. Classification Quality of Service defines a method of differentiating data streams to provide varying levels of service to the different streams. Criteria determining a packet’s priority level...
Continue reading →

Follow

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

Join other followers: