End of Sale

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.

v1.1 Updated January, 2021

This Policy Covers:

• MOS (Metamako Operating System)
• Supported 7130 Applications:
  • SwitchApp
  • MetaWatch
  • MetaMux
  • MultiAccess
  • MetaProtect
  • ExchangeApp
  • JTAG App

Policy:

Arista Networks' MOS and 7130 Apps Software Release Policy and Life Cycle guidelines help customers and partners facilitate MOS migration and plan multi-year infrastructure deployment. Arista will support designated LTS (Long term support) MOS and 7130 application software releases for up to 24 months from the date of the first posting of the initial minor release. (See below for definition of minor release)

To assist customers in selecting the right software releases for their environments, Arista follows a strict policy as to when new features are introduced into versions of MOS and applications. The versioning scheme identifies if a particular release is integrating new feature functionality, or a maintenance release on the previously released version.

The version numbers are defined by X.Y.Z[{alpha|beta}A]. X is the major release number, Y is the minor release number, Z is the patch release number. The alpha/beta tag identifies development releases which should not be deployed to production environments.

New minor releases -- i.e. where Z is 0 -- contain new functionality. New patch releases -- i.e. where Z is non-zero -- are maintenance releases.

Examples:

• mos-0.26.0 -- A new minor release. Contains new functionality compared with previous versions.
• mos-0.26.1 -- A new patch release. Only contains conservative bug fixes, compared with 0.26.0.
• mos-0.27.0beta1 -- A new development release. Do not use this in production environments.

Bug fixes are introduced using patch releases -- i.e. an upgrade to the latest patch release for the minor release number will be required to receive new bugfixes for that train.

Development releases (alpha/beta) carry no support commitment, though feedback is always welcomed.

Arista applications use the same versioning scheme as MOS. For example:

• metamux-3.5.6

Certain minor releases may be designated as "LTS" (Long Term Support). These will be supported with patch releases for 24 months following initial release of the .0 image. The LTS status of releases will be indicated in the release's description on the 7130 software downloads site. Releases other than LTS releases have no specific support timeline.

TAC support will be available on all versions of MOS and apps for 30 months following release.

If you need assistance with MOS or 7130 application software migration options, 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.

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: June 5, 2025

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 policy, please visit: https://www.arista.com/en/support/product-documentation/five-year-end-of-life-policy  

For Arista Switch HW product life cycle, please visit: https://www.arista.com/en/support/product-lifecycle

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  

DMF / CCF support on Accton / Edgecore Switch Hardware

DMF / CCF deployments running on Accton / Edgecore switches are no longer supported by Arista effective 01-Dec-2024. Customers using Accton / Edgecore switches with their DMF / CCF deployments are strongly encouraged to migrate their deployments from Accton / Edgecore to Arista hardware platforms as soon as possible. This migration is crucial to ensure continued support and access to the latest features and security updates. Please contact the Arista Sales team for guidance on Arista hardware platforms and migration options.

DMF / CCF Support on HPE Switch Hardware

DMF deployments running on HPE switches are no longer supported by Arista effective 01-Dec-2024.
CCF deployments running on HPE switches are no longer supported by Arista effective 01-Jun-2023.
Customers using HPE switches with their DMF / CCF deployments are strongly encouraged to migrate their deployments from HPE to Arista hardware platforms as soon as possible. This migration is crucial to ensure continued support and access to the latest features and security updates. Please contact the Arista Sales team for guidance on Arista hardware platforms and migration options.

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.

The Cloudvision On-Premises solution has two software components: CloudVision Portal Software (CVP) and CloudVision Appliance Software (CVA). The Software Release Policy and Life Cycle defines the various phases of development and support to guide customers in transitioning to newer versions of the product based on the milestones in the life cycle. Arista Networks will support each major software release train of CloudVision Portal and the CloudVision Appliance Software for up to 24 months from the general availability date for a particular train. The following diagram depicts the release phases and the Arista TAC support mapping across this timeline.

• Major release with new features and functionality
• Active maintenance releases for bug fixes as needed
• TAC support available

• Ongoing TAC support
• Software upgrade required for bug fixes

The following table depicts the CloudVision Portal release support matrix, including the timelines for each major software train (based on the 24 month life cycle policy) and includes the current state of support for each train.

The following table depicts the CloudVision Appliance Software (CVA) release support matrix, including the timelines for each major software train (based on the 24 month lifecycle policy) and includes the current state of support for each train.

^*The CloudVision Appliance was recently added to the Lifecycle policy. Because of this, Release 6.0 remains active for an extended period.

For assistance with software upgrades, please refer to the CloudVision Appliance Quick Start Guides: DCA-250-CV  DCA-300-CV  DCA-350E-CV or contact Arista Networks Support by emailing This email address is being protected from spambots. You need JavaScript enabled to view it..

EOS Support Lifecycle in CloudVision (On-Premises and Cloud Service)

Each CloudVision on-premises release has a minimum and maximum supported EOS release, as specified in the release notes. This also applies to CloudVision as-a-Service.

When an EOS train goes end of support, we do not explicitly remove support from CloudVision, however we stop testing newer CloudVision releases against that EOS train. While most CloudVision features will likely continue to work against the now unsupported EOS train, that support is best effort. Upgrading the EOS devices through CloudVision to reach a supported EOS release is supported, and is the recommended path.

To assist with customer migration of EOS on devices, CloudVision supports an EOS train for at least 12 months after the train’s end-of-support date, as reflected in this table.

The Expected End of Support in CloudVision dates provide guidance for CloudVision as-a-Service and on-premises releases.

For more information on EOS lifecycle information, please refer to: https://www.arista.com/en/support/product-documentation/eos-life-cycle-policy.

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. As of September 2018 Arista is extending some of the timelines for related milestones in the life cycle of our products 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 service contract will receive 24x7 support from Arista TAC for up to 5 years from the end-of-sale date of the product. This last day to get support will be referred to as the end-of-life date for the product.
• Software bug fixes will be available for up to 3 years from the end-of-sale date. After the first 3 years, Arista will make commercially reasonable efforts in assisting customers to mitigate Arista identified critical security vulnerabilities through the applicable end of life date. Customers may be required to upgrade to a newer software release to get the bug fixes, if available.
• Hardware repair or replacement will be available for up to 5 years from the end-of-sale date.
• 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

Figure 1: CloudEOS Router Software Licensing summary

Arista CloudEOS Router Licensing Model

Figure 2: CloudEOS Router product options

CloudEOS Router VM

CloudEOS Router VM is offered in each cloud provider marketplace under either a pre-purchased Bring-Your-Own-License (BYOL) subscription model or via Pay-As-You-Go (PAYG) hourly or annual consumption-based billing. It is also available for download for on-premise use via Arista’s Software Downloads page as BYOL only. For more details, please refer to CloudEOS Router VM datasheet.

Pay-As-You-Go (PAYG) Consumption Model

Under PAYG model, customers will be charged software subscription fees based on hourly or annual usage rates that have been set for the product. PAYG billing will be done via the cloud provider billing cycle. A benefit of the PAYG model is that the customers can start using CloudEOS Router immediately and pay only for the amount that they consume. Note that PAYG consumption does not require the customers to obtain a quote, generate a purchase order or to manage licenses, making it the preferred and de facto consumption model for most public cloud resources.

Bring-Your-Own-License (BYOL) Purchase Model

Under the BYOL model, customers will need to purchase monthly subscription SKUs from Arista in order to activate and use the CloudEOS Router. The BYOL customer will pay Arista directly for the subscription in advance and will be provided with license activation keys and proof of entitlement for the term of their subscription.

CloudEOS Router Container

CloudEOS Router Container is offered in on-premises Kubernetes deployment under Bring-Your-Own-License (BYOL) monthly subscription model. For more details, please refer to CloudEOS Router Container datasheet.