• Author : Michael (Mike) Fink

 
 

Sflow Subinterfaces

Description Packets sampled for sFlow are packaged in a flow sample structure containing, amongst other things, input and output port information. For single interfaces, port information is represented by the ifIndex of the interface. This feature allows for subinterface input and output port ifIndex values to be included in a sample, in place of parent interface ifIndexes. Samples in sFlow may be encoded in two formats: compact or expanded. The format  used depends on how ifIndex values are used on the device in question. If an sFlow agent will never use ifIndex values >= 2^24, then it must use compact...
Continue reading →

Sflow Output Subinterfaces

Sflow Output Subinterfaces Packets sampled for sFlow are packaged in a flow sample structure containing, amongst other things, input and output port information. For single interfaces, port information is represented by the ifIndex of the interface. This feature allows for subinterface output port ifIndex values to be included in a sample, in place of parent interface ifIndexes. Samples in sFlow may be encoded in two formats: compact or expanded. The format  used depends on how ifIndex values are used on the device in question. If an sFlow agent will never use ifIndex values >= 2^24, then it must use compact...
Continue reading →

Sflow IPv4 Tunnel Extension

When packets are encapsulated in tunnels via protocols such as GRE, sFlow samples with version 5 default extensions do not contain some important information about the packet including the IP address of the tunnel destination. Several additional, optional, tunnel extensions are defined in sFlow Tunnel Structure. The sFlow IPv4 tunnel extension feature provides the ability to add the extended_ipv4_tunnel_egress structure to packets forwarded via GRE next-hop groups. Platform Compatibility DCS-7280R DCS-7280R2 Configuration The tunnel extension is added to compatible samples by configuring sFlow on a device and then adding the desired tunnel extension sample configuration. For example: Arista(config)#sflow run Arista(config)#sflow...
Continue reading →

TAP Aggregation – Traffic Steering using User-Defined Fields

This article describes the TAP Aggregation User-Defined Fields feature. The purpose of the User-Defined Fields feature is to provide custom offset pattern matching to be used in TAP Aggregation Traffic Steering. This allows for deeper packet inspection of up to 128 bytes. User-Defined Fields, or UDFs, are defined as part of an access-list filter and are comprised of an offset, length and pattern match. This describes a single portion of any incoming packet to match the provided value upon. Access-list filters containing a UDF are then applied as usual as part of a TAP Aggregation Traffic Steering policy. UDFs may...
Continue reading →

Advanced Mirroring Features

Current Behavior Overview Filtered Mirroring allows certain packets to be selected for mirroring, rather than all packets ingressing or egressing a particular port. Platform Compatibility DCS-7010T, DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, DCS-7280E, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2, and DCS-7020 are supported. Configuration Note: To use this feature on the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-7500R2 series, a platform configuration may be required to enable the mirroring ACL profile. See the platform-specific section for instructions. Filtered mirroring is configured by creating an IPv4, IPv6 or MAC access-list and then attaching it to a monitor session. For example: Arista(config)#ip access-list acl1...
Continue reading →

Follow

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

Join other followers: