End of Sale

Hardware Guides

These hardware guides are for the Pluribus Networks Freedom Series set of switches. You can find Dell EMC hardware guides here and Edgecore hardware guides here.

Transceiver Compatibility Information

These compatibility reference guides indicate which transceivers have been tested and qualified with the respective hardware platforms that run Netvisor ONE OS: Freedom Series, Edgecore and Dell EMC Open Networking Switches.

Pluribus Networks Technical Documentation​​

This page contains online documentation for Pluribus Networks products now: Arista NetVisor OS, Arista NetVisor UNUM, and Insight Analytics™ releases. To access documentation for earlier software versions or products not listed, log in to the Customer Portal.

Arista NetVisor UNUM Management Platform and Insight Analytics Technical Documentation

Arista NetVisor UNUM is an agile, multi-functional web management portal that enhances the intrinsic automation of the Unified Cloud Fabric architecture. It combines an elastic big data database and intelligent analytics engine with an intuitive and consistent user interface that allows seamless navigation across fully integrated management and analysis modules.

Arista NetVisor UNUM 6.3.3 Software

Arista NetVisor OS Technical Documentation

Arista NetVisor OS 7.0.2 Software is downloaded to your open networking switch and then enabled with license keys. The documents below will help you install and operate the NetVisor OS.

Arista NetVisor OS 7.0.2 Software

Netvisor ONE 6.1.1 Software

Netvisor ONE 5.2.1 Software

Portions of Arista Networks software are covered by open-source licenses including the GNU General Public License . Please find below the list of source files:

• Wi-Fi WM 16.1.0
• .Wi-Fi AP 16.1.0 51 Source
• .Wi-Fi AP 16.1.0 51 Licenses
• .Wi-Fi WM 16.1.0 51 Source

• Wi-Fi WM 16.0.0
• .Wi-Fi AP 16.0.0 214 Source
• .Wi-Fi AP 16.0.0 214 Licenses
• .Wi-Fi WM 16.0.0 214 Source

• Wi-Fi WM 15.0.1
• .Wi-Fi AP 15.0.1 22 Source
• .Wi-Fi AP 15.0.1 22 Licenses
• .Wi-Fi WM 15.0.1 22 Source

• Wi-Fi WM 15.0.0
• .Wi-Fi AP 15.0.0 114 Source
• .Wi-Fi AP 15.0.0 114 Licenses
• .Wi-Fi WM 15.0.0 114 Source

• Wi-Fi WM 14.0.0
• .Wi-Fi WM 14.0.0 35 Source

• Wi-Fi WM 13.0.2
• .Wi-Fi AP 13.0.2 28 Source
• .Wi-Fi AP 13.0.2 28 Licenses

• Wi-Fi WM 13.0.1
• .Wi-Fi AP 13.0.1 83 Source
• .Wi-Fi AP 13.0.1 83 Licenses
• .Wi-Fi WM 13.0.1 83 Source

• Wi-Fi WM 13.0.0
• .Wi-Fi AP 13.0.0 67 Source
• .Wi-Fi AP 13.0.0 67 Licenses
• .Wi-Fi WM 13.0.0 67 Source

• Wi-Fi WM 12.0.1
• .Wi-Fi AP 12.0.1 48 Source
• .Wi-Fi AP 12.0.1 48 Licenses
• .Wi-Fi WM 12.0.1 48 Source

• Wi-Fi WM 12.0.0
• .Wi-Fi AP 12.0.0 162 Source
• .Wi-Fi AP 12.0.0 162 Licenses
• .Wi-Fi WM 12.0.0 162 Source

PURPOSE

The purpose of this Anti-Counterfeit Policy (this “Policy”) is to define actions to be taken by Arista Networks (“Arista”) for the avoidance of the introduction of counterfeit materials into the supply chain for its finished products. This Policy also addresses measures that are taken to avoid the sale of counterfeit Arista products into the marketplace.

SCOPE

This Policy covers items acquired by Arista either directly or through its contract manufacturers. It applies to the parts and components that comprise Arista’s end-products.

STATEMENT OF POLICY

Arista will not knowingly, and shall take all reasonable steps to ensure that it will not, procure, use, or supply any counterfeit item or material. Arista shall implement certain procedures as detailed below to manage the risk of counterfeit material in the supply chain. All Arista staff shall follow this Policy and associated anti-counterfeit management plans and promote awareness of the issues concerning counterfeit material in Arista’s supply chain.

ARRANGEMENTS FOR MANAGEMENT OF RISK

Arista shall mitigate the risk of acquiring counterfeit material by undertaking the following steps:

Approved Supplier List - Arista provides its contract manufacturers with a list of preferred suppliers that it has prescreened for quality and security purposes (the “Approved Supplier List”) and requires its contract manufactured to purchase all parts and components from vendors on this list.

Assessment – of likelihood and criticality of encountering counterfeit materiel in the supply chain for a particular product, part, or application; taking into account the criticality of the material in relation to performance and safety and the geo-political region from which it is sourced.

Avoidance – through application of Arista’s supplier selection process and Approved Supplier List, Arista will only acquire products and services from known, reputable and traceable sources. The business policy is to purchase directly from the original manufacturer whenever possible and to flow down the requirement to manage counterfeit material where risk is identified.

Certification – by requiring our contract manufacturers to certify on a regular basis that all purchases of parts, components and testing equipment is only from vendors on Arista’s Approved Supplier List.

Detection – by inspection of goods and materials, any new or potentially risk-bearing suppliers will have their supplied goods inspected. In addition, all goods inwards staff and technicians will be required to be vigilant for counterfeit material using their experience, training and awareness.

Elimination – any instances of counterfeit material will result in quarantine of the items and reporting of detected instances to the customer, industry, and the appropriate authorities. Counterfeit material will not be returned to the supplier. Instances of counterfeit material detection shall be communicated to the intellectual property right holder as known, the supplier, the customer if in receipt, relevant organizations, relevant authorities, including the Trading Standards Office if the occurrence is in the UK.

Testing - by requiring Arista’s contract manufacturers to test and verify suspected counterfeit material on a case-by-case basis commensurate with risk and criticality in relation to safety and performance and report all instances of counterfeit materials to Arista.

ROLES & RESPONSIBILITIES

This Policy will be maintained by Arista’s Vice President of Manufacturing or such other person as Arista’s Chief Executive Officer may designate from time to time (“VPM”). The VPM shall ensure that the Policy is available, communicated, understood, and implemented by relevant staff members. The VPM has the responsibility and authority to ensure that the necessary measures required to manage the risk of counterfeit material in the supply chain are implemented and maintained by the company.

Any Arista Employee that becomes suspicious or aware of counterfeit parts or materials in the supply chain should report any concerns to the VPM and to Arista’s vendor quality alias (This email address is being protected from spambots. You need JavaScript enabled to view it.). Reports are tracked through Arista’s Line Alert Process (DOC-00553-01).

Arista’s contract manufacturers must test and verify suspected counterfeit material on a case-by-case basis commensurate with risk and criticality in relation to safety and performance. All instances of counterfeit materials must be reported to Arista.

COMPETENCE, TRAINING, AWARENESS & COMMUNICATION

All staff that are involved in the procurement, design or manufacturing process shall receive Anti Counterfeit Training that include this Policy and its implications for Arista. The training shall be compulsory and records of training shall be maintained. This Policy shall be available to all staff through publication on the Arista Intranet. This Policy shall be made available to third parties on request and published on the Company website (https://www.arista.com/en/support/product-documentation/policies)

ARISTA BRAND PROTECTION

Arista takes measures to avoid the misrepresentation of its material by others. These measures include, among other things:

• Arista applies unique serial numbers on all manufactured products.
• Arista utilizes unique trusted platform module (TPM) chips to deter counterfeiting of select hardware products.
• Arista actively enforces its registered trademarks against manufacturers and suppliers of counterfeit materials.
• Arista controls production, packaging, and documentation to avoid misrepresentation of its products in the supply chain.
• Arista controls the production processes to prevent the misappropriation of material or unauthorized production overruns
• Arista’s channel agreements strictly prohibit the sale or distribution of counterfeit Arista products by our partners.

APPENDIX A: Standards Referenced In This Policy

• Defense Standard 05-135 Avoidance of Counterfeit Materiel

Introduction

Arista modular platforms such as the 750, 7300, 7500 and 7800 families support mixed generations of line cards, fabric cards, supervisors and power supplies (referred to in this document as “modules”). A-Care is applied to the entire chassis, rather than specific modules within the chassis. This can lead to inadequate support coverage and deployed devices that contain components that are End of Support.

This document explains how to update A-Care coverage through the lifecycle of a modular platform that includes mixed generations of modules.

A-Care Entitlement Policy for Modular Products

The level of support for a modular platform is defined by the generation of the switch fabric or switch card and therefore A-Care coverage must be updated to reflect the correct switch fabric or switch card as part of the next renewal. Line cards, supervisor modules and power supplies are not considered when choosing the correct level of A-Care for a modular system.

For example, a 7500 series product with E series switch fabrics requires A-Care coverage for E series systems while the same 7500 series product with R3 series switch fabrics requires A-Care coverage for R3 systems. 

If, in month 30 of a 36 month A-Care term, a 7500E is updated with R3 series switch fabric cards and therefore becomes an R3 series system, the existing A-Care coverage will remain valid until the A-Care renewal date but future A-Care coverage must be changed to the R3 coverage level instead of E series A-Care plans.

Documenting Component Upgrades to Ensure RMA Support

Although A-Care coverage may continue, when changes are made to the installed base, up to date records must be provided to Arista TAC to ensure continuity of RMA coverage in the correct geographical locations for the newly upgraded systems.

End of Sale Components Are Not Supported

In a modular platform, it is possible that a system could contain both supported and End of Support components (for example a mixture of line cards from different generations). The purchased A-Care contract will provide coverage for all components except those that are End of Support.

Overview

An organization's communications infrastructure and the tools that support that infrastructure are critical to the business' ability to function. That same importance also makes the infrastructure a high value target for malicious actors seeking to gain entry deeper into the organization or to exfiltrate sensitive intellectual property.

Arista Networks sees its role in security as a continuous process that begins at manufacturing and continues throughout the lifecycle of the product as vulnerabilities are detected, mitigated, and remediated.

The following document is intended to cover Arista's vulnerability management process. This process is broken down into four primary components: design choices for vulnerability avoidance, vulnerability detection, vulnerability communication, and security assessment testing.

Product security must also be complemented through best practice configuration during the installation and operation of the infrastructure. Arista provides regularly updated hardening guides and security recommendations through living documents available via EOS Central.

Design Choices

• Safe Choices in Design and Runtime

  • Arista's product family encompasses a variety of software products including EOS, DANZ Monitoring Fabric (DMF), CloudVision (CV) and CloudVision Wi-Fi (CV Wi-Fi), each of which is designed with safe execution in mind. As a result, many types of common programming issues are caught during development or not able to occur due to the frameworks and policies in use.

    The following list provides some examples of fundamental design choices that form part of Arista's software design process:

    • Safe language choices ensure mitigation against common flaws such as buffer overflows, protection against access of uninitialised data and other memory management issues.
    • Use of highly audited libraries where necessary (e.g. common security protocols).
    • Prevention of resource leakage using safe memory operations, bounds checking, reference counting and Valgrind analysis.
    • Pipelined execution models organised around single threaded functions to avoid race conditions and deadlocks.
    • Strong input sanitization for internal and external APIs to prevent malformed data injection.
    • Memory-safe virtual machines and Containerized execution to provide process separation and abstraction from the underlying OS.
    • Principle of least privilege to limit the permissions given to processes and users, avoiding malicious escalation.
     

  • Both the design of new Arista features and maintenance of existing features are done with security as a goal.

    • Engineers are provided training on secure coding practices and how to implement them in their code. By having a series of guidelines and examples engineers can create features that are designed to be secure from the start and can recognize previously written insecure designs.

    • The usage of security critical open source libraries is limited to a few well understood libraries. This serves to limit the surface of attack as well as make analyzing the usage of said libraries in the codebase easier.

    • Awareness and review of common attack vectors and the associated mitigations is an important part of security at Arista. The PSIRT team makes sure to stay aware of common patterns in insecure code and how to detect them. Information on rising trends is integrated into the training as well as company wide announcements. By making sure to keep a dialogue open within the company on security, engineers on all teams are able to keep secure coding principles in mind when writing code.

Vulnerability Detection

This section describes examples of the tools, processes and testing procedures Arista undertakes to ensure awareness of emerging vulnerabilities:

• Vulnerability Detection

  • CVE Scanner is an Arista automated process that searches for publicly disclosed vulnerabilities in the open source packages used in EOS(™), CloudVision(™) Portal, Danz Monitoring Fabric(™) and CloudVision(™) Wireless. It works by automatically downloading the database of known issues from the National Vulnerability Database and then cross-checking the version for each vulnerability against the versions of shipped code in all releases that have not yet reached end-of-life. Upon identifying a match for a vulnerability, a new bug is automatically filed and an engineer will investigate the potential problem. This automated process provides Arista with the ability to quickly uncover potential security vulnerabilities disclosed in the public domain.

  • Arista also keeps open lines of communication with its third-party vendors that provide software and hardware solutions to Arista products. In the event that a security issue is found with the 3rd party vendors product they are encouraged to reach out to Arista's PSIRT team and discuss the issue. Arista will treat these issues in the same manner as any other security issue discovered.

  • Arista PSIRT engineers conduct ongoing, detailed, security reviews of the Arista written code base to check for potential vulnerabilities and issues. Special attention is paid to areas of code believed to be at higher risk, such as those that parse user input or handle external packets.

  • Any potential security issue identified is reviewed for severity and potential impact. As part of this internal issues are scored using CVSSv3 scoring. If the usage of a publicly disclosed piece of vulnerable software differs significantly from the original reported usage, Arista may re-report the score with regards to how vulnerable Arista products are.

• Security Assessment Testing

  • Arista performs regular internal security assessment testing on our software products. These internal tests are done for every major software release (multiple releases per year). Examples of internal security test cases are included below.
  • The findings of these tests are reviewed to find ways in which to improve or harden our software.

  • Example test cases include, but are not limited to:

    • External host fingerprinting for display of compromising information.
    • Automated vulnerability scanning for checking installed software against known CVEs.
    • Validation of automated scanning results by an Arista engineer who specializes in security.
    • Attempt Proof-of-Concept exploitation against running host, for vulnerabilities with documented ability to do so.
    • Internal host configuration review including the boot loader, kernel (hardware drivers, modules, patches, etc), ipv4 and ipv6 stack and other services running on the host.
    • Use of open-source tools such as nmap and gcov to ensure thorough coverage and understanding of the code deployed.
    • Testing to standards defined by the DoD DISA STIG configuration and best practices. Arista uses the DoD DISA standards as our baseline for secure computing since they provide a high level for initial entry and cover threats one would expect to find in a datacenter.

Vulnerability Avoidance/Mitigation

While many vulnerabilities are mitigated by implementing best practices, Arista also provides rapid response via advice and hotfixes as detailed below:

• Publication of Best Practises

  • Review of product software architecture and design documentation, with a focus on external attack vectors, to identify design flaws from a security perspective.
  • Regular review of best practices for securing and hardening Arista products to ensure the security of the network. Best practices maintained in the Arista's Hardening Guides, which are living documents stored here: Hardening and Security

• Vulnerability Mitigation on Running Systems

  • In the event of a vulnerability that affects Arista products, Arista is oftentimes able to provide a hotfix to mitigate the issue. This is an extension that can be installed on a running system and will fix the problem with a minimum of downtime. While not all fixes are available as a hotfix, here is an example of how this hotfix scenario could look:

    • The SSH Server is found to be vulnerable to a publicly disclosed CVE.
    • Arista creates a hotfix to resolve the problem.
    • The hotfix is installed on a switch, the SSH server goes down for approximately 1 second while it is restarted. No other services on the switch are affected.
    • The fix is in place and can persist across reboots of the switch until a newer image with the fix integrated can be loaded.

Vulnerability Communication

New vulnerabilities are made available as soon as possible via well known mechanisms:

• If the issue impacts Arista products, an appropriate solution or set of solutions to the problem will be provided. The solutions can include a recommended configuration change, software patch, new software image, or other procedures that are appropriate to mitigate or fix the vulnerability.

• Details of the security vulnerability and associated solutions are then documented publicly via a security advisory on the Arista website which can be accessed pro-actively as an RSS feed

  Advisories Notices

• Customers deploying CloudVision benefit from automated alerting via the Compliance Dashboard. CloudVision is able to warn customers of both bugs and security vulnerabilities to help ensure the environment is kept secure.

• Arista Networks follows best practices when it comes to making CVEs findable as well. All security issues have CVEs assigned by MITRE so that issues can be efficiently tracked across security scanners, advisories, and all other forms of security issue management procedures.

Summary

Arista goes to great lengths to ensure the ongoing security of its products and rapid mitigation of emerging threats, following industry best practices and leveraging close relationships with suppliers.

The effectiveness of these robust processes is demonstrated by extremely limited exposure to common security issues as well as rapid and usually impact-free solutions for remediation.

Arista customers following our recommended hardening steps can be confident that they have deployed the industry's leading secure networking solutions.

Arista Networks' CloudVision Wi-Fi™ (CVW) Software Release Policy and Life Cycle guidelines help customers and partners facilitate CVW migration and plan multi-year infrastructure deployment.

CVW Release Numbering Policy

CVW releases are numbers as per the following format - “xx.yy.zz”
For feature releases, the last number is always zero - “xx.yy.0”
For maintenance releases, all three numbers are non-zero - “xx.yy.zz”

e.g. Releases 8.8.0 and 9.0.0 are feature releases; while releases 8.8.2 and 9.0.1 are maintenance releases.

CVW Release Delivery

CVW is available as a cloud service and for on-premises deployments; either as a hardware or a virtual appliance.

In case of cloud deployments, Arista upgrades the cloud for each feature and maintenance release, and customers can decide to upgrade the access points (APs) either automatically or manually.

For on-premises deployments, upgrade images are made available to customers via the support portal.

For both cloud and on-premises deployments, upgrade images for the APs are made available on the cloud repository simultaneously with server side upgrades. Both the server and AP images carry the same release numbers.

CVW On-Premises Release Lifecycle Guidelines

Note: The release lifecycle guidelines below apply only to on-premises deployments because cloud deployments will be upgraded as releases become generally available.

Arista continues to maintain and provide support for releases that are either two feature releases or 18 months older than the current release, whichever is the smaller time interval.

Examples of Release Lifecycle

If a customer requests support for a release that is more than two feature releases or 18 months older than the current release, the customer will be required to upgrade the deployment (appliance and APs in case of on-premises deployments and only APs in case of cloud deployment) to a release not older than two feature releases before the current release.

With each release, the CVW release notes will mention the release that is no longer supported and the minimum release number to which a customer will need to upgrade for continued support.

If you need assistance with CVW migration options, please contact Arista TAC or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.

Arista Networks Product Life Cycle Policy for:

DANZ Monitoring Fabric (DMF), Converged Cloud Fabric (CCF) and Multi Cloud Director (MCD)

[Life Cycle Policy updated on March 22, 2024]

This document covers both software and hardware appliance life cycle policy for DMF, CCF and MCD, as applicable.

DMF, CCF and MCD Software Life Cycle

Arista Networks DANZ Monitoring Fabric (DMF), Converged Cloud Fabric (CCF) and Multi Cloud Director (MCD) Software Release Policy and Life Cycle guidelines help customers and partners facilitate DMF, CCF and MCD migration and plan multi-year infrastructure deployment. Arista will support each major DMF, CCF and MCD software release for up to 36 months from the date of initial posting for a particular train.

To assist customers in selecting the right DMF / CCF / MCD software release for their environments, Arista follows a standard naming convention for DMF / CCF / MCD releases. The naming convention identifies if a particular release is integrating new feature functionality, or has reached software maintenance mode.

Version numbering scheme:
<major version>.<minor version>.<patch version>

The Product Lifecycle policy guidelines apply to all major and minor releases only. Patch releases will follow the end-of-life policy milestones of the corresponding minor release.

Maintenance Phase

• DMF, CCF and MCD software releases in this phase will only receive incremental fixes. No new functionality will be added.
• TAC support available

Support Only Phase

• DMF, CCF and MCD software releases in this phase will receive ongoing TAC support only.
• Software upgrade required for bug fixes

End of Software Support

• Upon completion of the Support Only Phase, the release is designated as ‘End of Software Support’ after which no further Arista software support including maintenance for that release would be provided.

DANZ Monitoring Fabric Software Lifecycle

The following table depicts the Arista DMF release support matrix, including the timelines for each major Arista DMF software train (based on the 36 month lifecycle policy) and the current state of TAC support for each train.

Note: Future dates are for general planning purposes and are subject to change

Converged Cloud Fabric Software Lifecycle

The following table depicts the Arista CCF release support matrix, including the timelines for each major Arista CCF software train (based on the 36 month lifecycle policy) and the current state of TAC support for each train.

Note: Future dates are for general planning purposes and are subject to change

Multi Cloud Director (MCD) Software Lifecycle

The following table depicts the Arista MCD release support matrix, including the timelines for each major Arista MCD software train (based on the 36 month lifecycle policy) and the current state of TAC support for each train.

Note: Future dates are for general planning purposes and are subject to change

DMF and CCF Hardware Appliance Life Cycle

As technology evolves, there comes a time when it is better for our customers to transition to newer platforms. Arista's End-of-Sale and End-of-Life policy is designed to help customers identify such life-cycle transitions and plan their infrastructure deployments with a multi-year outlook.

All End-of-Sale and End-of-Life announcements will be made on Arista's website. Milestones in the life cycle of our products is as follows:

• An End-of-Sale announcement will be posted on our website 6 months prior to the last day to order the product
• All customers who have a valid software license and a valid service contract will receive 24x7 support from Arista TAC for up to 5 years from the end-of-sale date or till the manufacturer’s end-of-life date of the hardware, whichever is sooner.
• Software bug fixes will be available for up to 3 years from the end-of-sale date. Fixes for critical security vulnerabilities will be available through the end of life. Customers may be required to upgrade to a newer software release to get the bug fixes.
• Hardware repair or replacement will be available for 5 years from the end-of-sale date or till the manufacturer's end-of-life date of the hardware, whichever is sooner.
• Customers can renew service contracts up to 1 year prior to the end-of-life date.

End-of-Sale & End-of-Life Milestones at a Glance

Note: * HW repair or replacement will be available for 5 years from the end-of-sale date or till the manufacturer’s end-of-life date for the hardware, whichever is sooner.

Hardware Appliance Life Cycle

(Controller Appliance, Service Node, Recorder Node, Analytics Node)

Arista Switch Hardware Lifecycle

For Arista Switch HW End-of-Life, please visit: https://www.arista.com/en/support/product-documentation/five-year-end-of-life-policy  

Dell EMC Switch Hardware Lifecycle

Note: Arista and Dell have jointly decided to terminate their partnership on DMF/CCF. Arista will only support Dell switch deployments with DMF/CCF for up to the End of Life of the respective switch hardware or 31-Dec-2028, whichever is sooner. Please refer to Arista Dell Partnership Termination Field Notice for details.
For assistance with new / expansion / migration opportunities, please contact your Arista sales representative or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.

For Dell EMC Switch HW End-of-Life, please visit: https://www.dell.com/en-us/work/shop/networkingwarranty/cp/networkingwarranty  

Edge-Core Switch Hardware Lifecycle

Note: Arista will only support Edge-Core switch deployments with DMF/CCF that were purchased on 31-Dec-2020 or earlier, for up to the End of Life of the respective switch hardware or 01-Dec-2024, whichever is sooner. For assistance with expansion / migration opportunities, please contact your Arista sales representative or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.

For Edge-Core Switch HW End-of-Life, please visit:  https://www.edge-core.com/productsEOL.php  

DMF / BMF Support on HPE Hardware

Support for DMF/BMF on non-EOL HPE Hardware (Controllers, Service Nodes, Switches) will end once DMF/BMF 7.3 release reaches End of Support. For support on HPE HW related issues, please reach out to your HPE sales representative.

If you need assistance with DMF/CCF solutions, please contact your Arista sales representative or contact us at: This email address is being protected from spambots. You need JavaScript enabled to view it.