Tag :: TOI

The Analytics Node includes CIDR (Classless Inter-Domain Routing) filtering for records and documents. The feature applies to dashboards including Netflow, sFlow®, ICMP, Dapper, and others. The filtering utilizes Lucene and KQL syntaxes. The update introduces two new fields: sIp.ip and dIp.ip.

For a pair of QSFP100 ports grouped together on a gearbox, it is possible to enable a 10G or 25G link on one port, the primary port, while maintaining usage of the other port, the secondary port.

CloudVision Cognitive Unified Edge (CV-CUE) introduces the following new features and enhanced functionalities

On enabling the Share Radar Hits setting, the Access Point (AP) shares radar select data with RF neighbor APs. The data is shared only with the RF neighbor AP and not with all APs.
By default, the setting is enabled. If you are experiencing false radar hits, you can disable this setting, and the impact will be limited to the affected AP. On disabling this setting, radar hit data will not be shared with RF neighbor APs.

In EOS 4.18.1, support for 25G/50G is added on 7500R, 7280R, 7500R2 and 7280R2 series. This feature provides forced

The BGP extended communities support within EOS has been enhanced to include support for 4 octet AS Extended BGP

The 400GBASE ZRP (also known as ZR+) is a transceiver that follows the OpenZR+ MSA (Multi Source Agreement)

7020 R4 Series Supports Speeds 25g, 10g, 1g on all SFP ports, 10g, 1g on all RJ45 ports, 100g, 50g, 25g on all QSFP ports

Starting EOS release 4.15.2F, the ability to re number front panel ports of 7050QX 32S is supported.

This document provides information on how to configure static NAT with selective VXLAN encapsulation using policy-based routing (PBR) and debug related issues on Arista 7170 switches.

Newly supported Features, Ingress IPv4/IPv6 and MAC ACL on FPP ( routed/switched ), Port-Channel, L3 subInterfaces ,Ingress IPv4/IPv6 and MAC ACL counters , Ingress IPv4/IPv6 and MAC ACL deny logging

This TOI supplements the Ingress Traffic Policy applied on ingress port interfaces. Please refer to that document for a description of Traffic Policies and field-sets. This TOI explains the Traffic Policies as applied in the ingress direction on VLAN interfaces. For Traffic Policies on the egress direction of VLAN interfaces, see the Egress Traffic Policy TOI.

The 7500E 6CFPX LC linecard with ACO CFP2 optics provides connectivity over DWDM systems and links. 7500E 6CFPX LC

EOS-4.23.1F added basic MLAG support for 7800R3, 7500R3 and 7280R3 platforms. The MLAG features that are currently supported are: Bridging, Routing, STP, VARP, L2 Multicast.

EOS-4.36.1F added basic MLAG support for 7800R4, 7280R4 and 7020R4 platforms.

The 802.11be standards build on 802.11ax by providing ultra-high throughput, improved resource utilization, and interference mitigation. The 320 MHz support increases the throughput and performance in the 6GHz band. The improved resource utilization is attributed to the introduction of Multiple Resource Units (MRU) in Orthogonal Frequency Division Multiple Access (OFDMA) transmission and Multi-Link Operation (MLO).

This article describes a feature for Tap Aggregation mode, which strips IEEE 802.1BR E-Tag and Cisco VN-Tag headers from all tagged packets received on tap interface before delivering them out of tool interfaces.

802.1X dynamic interface configuration allows for dynamic interface configuration on the 802.1X authenticator based on device profiling performed by a Network Access Controller (NAC). Traditionally, 802.1X authenticators require static interface configuration. This enhancement extends dynamic capabilities beyond existing features like dynamic VLAN assignment and ACL programming, enabling any type of interface configuration to be applied dynamically via the CLI.

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network. We support dot1x protocol standard 802.1X-2004 (version=2)

This feature allows a user to adjust the MTU of radius requests for 802.1x supplicants. Currently this feature only adjusts the MTU size of radius requests for supplicants undergoing EAP TLS authentication.  This can be useful in scenarios where hops between the switch and RADIUS doesn’t support IP MTU discovery and the switch ends up sending Access Requests based on the interface MTU size which get dropped at such hops. With this feature, a user has the flexibility to experiment and choose a MTU setting that works for such a topology forcing the Dot1x agent to send the Access Requests with the configured MTU.

802.1X port security controls who can send traffic through and receive traffic from the individual switch ports. A

802.1X supplicant feature supports different Extensible Authentication Protocol( EAP ) methods for 802.1X authentication. This document specifically talks about support for supplicants doing EAP Password ( EAP-PWD ) based authentication. Defined in RFC5931, EAP-PWD is an EAP method that uses a shared password for authentication. Furthermore, this feature allows EOS devices to interoperate with systems that rely on EAP-PWD for deriving MACsec CAK/CKN from the EAP Master Session Key (MSK) and EAP Session ID as per 802.1X-2020.

This feature adds support in AAA using the LDAP protocol. LDAP can be used for authentication and

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

When configuring the MAC address of a switch, CLI commands and REST endpoints will accept a MAC address formatted as three groups of four hexadecimal digits separated by periods (e.g. 1122.3344.5566) in addition to the already accepted form of six hexadecimal digit pairs separated by colons (e.g. 11:22:33:44:55:66). 

You can now enable CloudVision to combine the authentication and authorization requests that it sends to a RADIUS server into a single request. When RADIUS is configured as the AAA provider, CloudVision will send separate authentication and authorization requests by default. This can cause issues with One-Time Password (OTP) users, as issued passwords are only valid for one request. Note: Non-OTP RADIUS systems will be unaffected by the change. To combine authentication and authorization requests, navigate to Settings > Access Control and enable the Combine Login Auth Requests checkbox.

This studio enables you to quickly configure access interfaces towards endpoint devices in your campus network. This configuration relates to the devices in Access Pods deployed using the Campus Fabric (L2/L3/EVPN) Studio.

This studio enables you to quickly configure access interfaces towards endpoint devices in your campus network. This configuration relates to the devices in Access Pods deployed using the Campus Fabric (L2/L3/EVPN) Studio. The studio consists of port profiles and campus networks. You can create port profiles, which contain configuration for attributes like speed and MTU, which you can then assign to device interfaces in a campus fabric. Editing the profile will then affect all interfaces that the profile has been assigned to. You can also configure individual interfaces.

With the 12.0 release, CloudVision Cognitive Unified Edge (CV-CUE) introduces Access Points (AP) Explorer. AP Explorer helps you view the distribution of APs by various attributes such as Model, Software Version, Status, and so on.

Security policies occasionally prevent the download of PCAP files from packet queries. The integrated Wireshark web interface enables PCAP analysis within the DMF environment and requires authentication for access. This integration provides full Wireshark functionality while keeping the PCAP file on the Controller to maintain adherence to security requirements.

This feature enables user to modify QoS parameters for SVI traffic (L3 VLAN) based on ACL classification. The QoS

A common way of configuring a switch is with config session or with config replace. In a config session, if the

The feature allows filtering on source and destination IP addresses within the VXLAN inner payload, on ingress port ACL. The feature can be configured using the inner keyword within the VXLAN ACL configuration. Because of some limitations, the feature should be utilized for debugging purposes.

Ingress policing provides the ability to monitor the data rates for a particular class of traffic and perform action

Beginning with EOS version 4.36.0F, the CCS-710XP series offers the ability to increase ingress Access Control List (ACL) scale if counters are declared unnecessary. This will be the default behavior on CCS-710XP platforms running releases from 4.36.0F onwards. This document details steps to enable or disable counters as required, along with resources for related issues.

A new role permission, Action Execution, has been introduced to control the execution of custom actions when they are run in isolation, such as via Studio Autofill actions and standalone executions in the Action editor. A custom action is a user-created action that has either been installed via a package or has been created using python script and arguments.

This feature adds the support for a standby server to the existing syslog logging mechanism for UDP syslog servers. The user can specify a logging group and specify remote syslog servers. The first host configured will be the “active” server, which means syslogs will be forwarded to that host whenever it is reachable via ICMP. The second host will be the “standby” server, which will receive syslogs if the active server goes down. This provides more robustness for setups with multiple potential syslog servers.

The active active neutron controller support in CVX enables the deployment of highly available neutron service with

This feature gives AVT/DPS tunnels the ability to transport IPv6 overlay traffic. Formerly, such tunnels could only transport IPv4 overlay traffic.

Starting EOS 4.15.0F, users can configure NAT at IP address level with dynamically assigned one to one mapping

Adjacency sharing is a feature which deduplicates FEC to avoid installing identical FECs in hardware. Often this applies to Equal Cost Multi Path (ECMP) FECs, which are generally a much more scarce resource. Hierarchical FECs are not supported with adjacency sharing.

The following table describes the advanced mirroring features that are currently supported with links to their respective TOIs.

With the 21.2 release, CV-CUE introduces Advanced Alert Parameters to fine-tune alert sensitivity.

In diverse Wi-Fi environments, static global alert thresholds might generate false positives. For example, a high density of clients re-associating during a radio frequency change might be flagged as a DoS attack.