• Tag : TOI

 
 

VXLAN On Arista AP

Overview VXLAN is a Layer 2 technology that helps you to create a virtual Layer 2 network (overlay network) on top of a physical Layer 3 network (underlay network), enabling you to use Layer 3 features of the underlying network, which cannot be achieved using 802.1q VLANs. Each VXLAN tunnel is identified by the VXLAN segment ID or VXLAN Network Identifier (VNI) which is 24 bits, which enables you to create up to 16 million isolated networks. This overcomes the limitation of VLANs, which have a 12 bit VLAN ID, allowing a maximum of 4,094 isolated networks. Arista WiFi Access...
Continue reading →

RF Transmit Power configuration enhancements

Description The transmit power configured on UI is now treated as EIRP (Equivalent Isotropically Radiated Power) instead of radio output power. EIRP is the effective power emitted by the AP in the direction of maxima of radiation pattern and is equal to the sum of Radio Transmit power and antenna gain. UI configuration for External Antennas has been introduced. It applies only to the APs with external antennas. APs with internal antennas would take default values (refer to datasheet for details on antenna gain values). Wireless Manager UI Configuration Tx power and External antenna gain values can be configured from...
Continue reading →

Packaging of Access Point (AP) Firmware Images on WM Server

Description This document describes a few enhancements done in Wireless Manager (WM) release 8.8 in respect of  AP firmware updates and packaging of AP firmware images in on-prem WM server. These changes affect only the on-prem WM servers that do not have HTTPs connectivity to Arista Cloud repository of AP images. On-prem WM servers that have such connectivity are not impacted. Current Behavior: Firmware images of different AP models such as. C-75, O-90, C-120, C-130, etc. are part of the WM server upgrade bundle. During server upgrade, AP images of the new build get copied onto the  WM server. When...
Continue reading →

SNMP support for Cloud and On-Prem deployments

Description Cloud: SNMP support for Event/Alerts (New Feature) Starting 8.8 release, Cloud customers can receive all events/alerts as SNMP traps. While configuring an SNMP trap destination server, an AP can be configured to act as CIP (Cloud Integration Point) to receive traps without exposing the SNMP destination server over the Internet. An SNMP destination server can be added through either “CloudVision WiFi” (SYSTEM -> Third-Party Servers -> SNMP-Alerts) or “Wireless Manager” UI (Configuration -> ESM Integration -> Events SNMP). To configure SNMP trap destination server through “CloudVision WiFi”, go to  “SNMP-Alerts” configuration page from the SYSTEM -> “Third-Party Servers”. Click...
Continue reading →

Reports in CloudVision WiFi

Description Arista WM gathers a wealth of data about the wireless deployment. The data gathered includes Wireless Intrusion Prevention System (WIPS) related incidents, state of the devices, etc. Reports allow compact, printable and scheduled delivery of relevant pieces of information. The reports generated by Arista WM are useful for assessing the WIPS outlook of the wireless deployment, meeting regulatory compliance requirements and for inventory management. The ability to work with reports has been added to CloudVision WiFi in version 8.8. CloudVision WiFi currently supports the following types of reports. Wireless Intrusion Prevention System (WIPS) Compliance Inventory Reports about the WiFi...
Continue reading →

Hitless WiFi AP Upgrades

Description Keeping WiFi Access Point (AP) firmware up-to-date allows network administrators to take advantage of the latest features, bug fixes, and security enhancements. The firmware of Arista APs can be upgraded via the Wireless Manager UI or CloudVision WiFi, by using any of these three techniques: New Device AP Upgrade: Newly provisioned APs can be automatically upgraded as soon as they connect to the Wireless Manager. Scheduled AP Upgrade: All the APs at a particular location can be upgraded within a particular time window—configurable in terms of specific days of the week and hours of the day. The schedule can...
Continue reading →

CloudVision WiFi 8.8

Hitless WiFi AP Upgrades Reports in CloudVision WiFi SNMP support for Cloud and On-Prem deployments Packaging of Access Point (AP) Firmware Images on WM Server RF Transmit Power configuration enhancements VXLAN On Arista AP

TapAgg support on MACsec linecards

Introduction Media Access Control Security (MACsec) is an industry standard security technology that provides secure communication for all traffic on Ethernet links. As of EOS 4.20.5F for Arista 7500 lines of switches, users of the tap aggregation features can benefit from using MacSec on tap/tool ports on MacSec capable line cards. Users can use MACsec to secure the communications between their tap/tool ports and ports from other switches which may not necessary be a TapAgg equipment. Enabling MACsec on a port puts it into an “unauthorized” state. Then the interface will not be forwarding any traffic until the MACsec peers successfully complete the MACsec Key Agreement (MKA) procedures. Once...
Continue reading →

Uniform Tx/Rx DOM Thresholds

EOS-4.20.6F adds support for customizing SFP+ and QSFP+ transceiver transmit and receive DOM thresholds. There are three sources of DOM thresholds available:   DOM threshold values that are hard-coded in each transceiver. These values are hard-coded by the transceiver manufacturer, and may vary based on manufacturer part number or serial number. In other words, transceivers with the same Arista part number could have different DOM threshold values. By default, Arista EOS uses the hard-coded values as the default DOM threshold values for each transceiver. An Arista provided DOM threshold file, which can be used to enable uniform thresholds per Arista...
Continue reading →

EVPN Centralized Anycast Gateway

EVPN Centralized Anycast Gateway Description EVPN IRB interface supports both L2 switching and L3 Vxlan Routing on the same TOR switch.  In a typical EVPN IRB deployment, the IP Default Gateway(DGW) for a host (or VM) is the IP address configured on the IRB interface (check out the EVPN IRB TOI for more detail).  To have the closest TOR to always perform both Vxlan bridging as well as Vxlan Routing, always configure the IRB interfaces as the DGW on all the TORs. This model is commonly known as “distributed Vxlan Routing with EVPN”.  This model is supported in EVPN since...
Continue reading →

Support for PBR in any VRF

This feature enables the user to configure PBR policy on an interface in any VRF, to match and forward incoming packets to next-hop in any VRF. If “vrf” keyword is not specified in the “set nexthop” configuration, the packets will be PBR forwarded in the VRF associated with the incoming interface. Platform compatibility DCS-7010 DCS-7050 DCS-7050X DCS-7060 DCS-7260 DCS-7160 DCS-7250X DCS-7280E DCS-7280R DCS-7300 DCS-7500E DCS-7500R Configuration To redirect matching incoming packets within ingress VRF, the specification of VRF as part of “set nexthop” is not necessary switch#configure terminal switch(config)#policy-map type pbr policy1 switch(config-pmap-pbr-policy1)#class class1 switch(config-pmap-c-pbr-policy1-class1)#set nexthop 11.11.0.1 switch(config-pmap-c-pbr-policy1-class1)#exit switch(config-pmap-pbr-policy1)#exit switch(config)#int...
Continue reading →

Cloud High Availability

Cloud HA feature provides active-active redundancy between two vEOS router instances running in Cloud such as AWS and Azure. Typical deployments will instantiate a pair of vEOS instances in different fault domains/Availability zones of a logical network ( e.g AWS Virtual Private Network( VPC) or Azure Virtual Network ) within a Cloud Provider’s network. The vEOS instances will be used to route traffic to/from cloud hosted VM instances in partitioned subnets which are logically deployed behind each of the vEOS router. The Cloud HA feature allows the vEOS router to back-up each other in case of either peer failure or...
Continue reading →

TAP Aggregation – FCS error handling

In TAP Aggregation mode, when receiving a packet whose Frame Check Sequence (FCS) is corrupted, the default behavior on the 7280E/R/R2 and 7500E/R/R2 series is to replace the bad FCS with the correct value and forward it. Configuration options are available to control the FCS error behaviour, such as to discard errors. Platform compatibility DCS-7280E/R/R2 series DCS-7500E/R/R2 series Configuration A global TAP Aggregation command is used to configure the behavior regarding the FCS errors. To discard the packets with a corrupted FCS: Arista(config-tap-agg)#mac fcs-error discard To revert to the default behavior, i.e. to replace the corrupted FCS with the correct...
Continue reading →

Stateful Switchover on DCS-7300x

Stateful switchover is a redundancy mode available on systems with 2 supervisor cards. One supervisor card is active and performs all the normal operations. The other card is in standby and is inactive. In the event of a failure of the active supervisor, the standby supervisor takes over and becomes active, preserving the configuration and with minimal traffic loss (up to 1s). The previously active supervisor is rebooted in standby mode if still present/functional.   Platform compatibility DCS-7304 and DCS-7308 Configuration To activate stateful switchover, issue the following commands on the system: Arista(s1)(config)#redundancy Arista(s1)(config-redundancy)#protocol sso Note: both supervisors must have the same...
Continue reading →

IP Packet length matching in Ingress Security ACLs

Similar to L4 ports, ACL rules can be configured to filter ingress packets based on their IP length (present in the IPv4 header). The match criteria consist of lookups on the IP length field. The supported range operators are as follows: any – all lengths eq length1, length2 … lengthn – A list of lengths. Max list size of 10 numbers gt length – The set of lengths with numbers larger than the listed length lt length – The set of lengths with numbers smaller than the listed length range length1 length2 – The set of lengths whose numbers are...
Continue reading →

Remove ARP from L3 when MAC L2 port is down

This feature removes an ARP entry when the physical port, on which the ARP entry’s MAC address is learned, goes down. This feature applies only to dynamic ARP entries, not static ARP entries. In addition, if the physical port, which is down, is a member of a LAG, ARP entries are not removed if the LAG remains up (due to other members still being up). ARP entries will be removed if the LAG interface goes down. Platform compatibility This feature is platform independent. Configuration This feature is configurable on a per L3 interface basis. By default, it is disabled. The following example...
Continue reading →

Asset Tagging

EOS release 4.20.5F adds asset tagging support that aids hardware identification by the use of user-supplied strings. Platform compatibility Fixed systems since release 4.20.5F.Modular systems since release 4.22.0F. Configuration Asset tags are configured via the CLI or eAPI using the following command: [ no | default ] hardware asset-tag <hardware> <tag> On a fixed system, <hardware> can be either switch or powersupply <1-2>, depending on the power supplies present. On a modular system, it can be chassis, or powersupply, supervisor, fabric, or linecard, followed by a slot number. For example, Arista# hardware asset-tag switch Floor3RU4 The current configuration can be viewed...
Continue reading →

Block Untagged Frames on Dot1Q-Tunnel Port

Introduction “Block Untagged Frames on Dot1Q-Tunnel port” is a new feature that has been added in this release. When this feature is activated, it can block any incoming untagged frame on Dot1Q Tunnel port. Ethernet frames carrying :  No Dot1Q tag (Untagged) or Dot1Q tag with VLAN Id equal to zero or Dot1Q tag carrying Tpid different than the one configured on Dot1Q tunnel port will be treated as Untagged frames, which will prevent them to flow through the VLAN of the Dot1Q-Tunnel port. This feature is applicable on the ingress direction and is supported at Ethernet interface and LAG level; This means that behavior applied to a Dot1Q-Tunnel port...
Continue reading →

EVPN IRB with Vxlan Underlay

EVPN Integrated Routing and Bridging (IRB) with VXLAN In the traditional data center design, inter-subnet forwarding is provided by a centralised router, where traffic traverses across the network to a centralised routing node and back again to its final destination. In a large multi-tenant data center environment this operational model can lead to inefficient use of bandwidth and sub-optimal forwarding. To provide a more optimal forwarding model and avoid traffic tromboning, the EVPN inter-subnet draft (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes integrating the routing and bridging (IRB) functionality directly onto the VTEP, thereby allowing the routing operation to occur as close to the end...
Continue reading →

TAP Aggregation – TCAM Profile Selection

This article describes a new TAP Aggregation TCAM profile and a corresponding enhancement to the TAP Aggregation mode command. The new TCAM profile is “tap-aggregation-default” and is used to support the standard TAP Aggregation features. Previously, the base TCAM profile natively supported TAP Aggregation, however to achieve better resource utilization, the TAP Aggregation TCAM features were moved into this new profile. To facilitate automatic usage of “tap-aggregation-default”, the TAP Aggregation mode command now supports applying an overlay TCAM profile. If no profile is selected, the default is chosen automatically (see Configuration).   Supported Platforms DCS-7280E, DCS-7280R DCS-7500E, DCS-7500R Configuration (config)#...
Continue reading →

Follow

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

Join other followers: