Deep packet inspection – SCTP support

Stream Control Transmission Protocol ( 132 ) is a transport layer protocol, much like TCP. After the IP header, a SCTP packet has the following fields: source port, destination port, tag and checksum. Starting EOS 4.15.0F, deep packet inspection on Arista DCS 7150 allows for filtering of SCTP traffic via ACLs, by matching on source port, destination port and payload. Configuration The feature can be configures using following set of CLI commands: Arista(config)#tap aggregation Arista(config-tap-agg)#mode exclusive Arista(config)#ip access-list <acl name> Arista(config-acl)#permit/deny sctp <srcIp> <sport> <dstIp> <dport> payload [ { offset <value> pattern <value> mask<value> }+] switch(config-acl)#permit/deny sctp <srcIp> <dstIp> [ userl4 pattern < value>...
Continue reading →

OSPF distribute lists

OSPF distribute-list is a policy construct to filter out routes received from OSPF LSAs so that they will not be installed on the router even though the routes are resolved and are installable. The filtering is performed after SPF calculation and only on routes from received LSAs, not on self-originated LSAs. This feature does not affect the OSPF protocol behavior of the router. LSAs are exchanged, e.g. flooded, even if the routes are not installed locally on the router. The purpose of this feature is to have added control over what received routes to install. For example, one can prevent...
Continue reading →

Static NAT and twice NAT counters

Packet counters for Static and Twice NAT connections are now supported on the DCS-7150 series. This is a debug feature. Enable this feature to start counting packets translated by Static NAT rules in hardware. This can be used to troubleshoot Static NAT translation failures. Configuration The CLI command “ip nat translation counters” can be used to enable this feature globally. “no ip nat translation counters” will disable the feature. Once enabled, all rules currently programmed in hardware and new rules configured after this command will get policers for counting packets. Status Show Commands The CLI commands “show ip nat translation hardware detail”...
Continue reading →

Tap aggregation – traffic steering show/clear commands

This TOI briefs the commands related to the traffic steering policies used in Tap Aggregation. These commands display the configured traffic-steering policy-maps, class-maps, the interfaces they are applied to, and the counters for each rule of the policy (presented in acl-counter format). The policy rule counters can be cleared using the corresponding clear commands.   CLI commands Presented below are the command formats along with the sample output: show class-map type tapagg [class-name] This command displays all/named tap aggregation class-maps. The output lists a mapping between a class-map and access-list(s). Each class-map could be mapping to multiple access-lists, but all of the access-lists...
Continue reading →

Static ARP inspection

Static ARP inspection is a security feature that verifies the source IP and the source MAC addresses of each received ARP packet payload based on user configured IP-MAC bindings. Static ARP inspection is enabled on a per-VLAN basis. When it is enabled on a VLAN, the switch intercepts ARP packets, both requests and responses, on all interfaces belonging to this VLAN, and verifies that each intercepted packet has a valid IP-MAC address binding in its ARP payload. On user-configured trusted interfaces, all received ARP packets are considered valid. After being inspected, ARP packets that have valid IP-MAC bindings are forwarded...
Continue reading →

Dynamic and symmetric LAG hashing

Starting with EOS4.15.0F, dynamic and symmetric LAG hashing policies are supported on the 7500E platform. Dynamic LAG hashing enables high link utilization and highly even distribution among LAG members by employing a randomized hashing algorithm. Symmetric LAG hashing allows the two flows of a bidirectional communication link, even when the two flows enter the switch on different ingress ports, to be hashed to the same member of a LAG on egress. Dynamic and symmetric LAG hashing policies are enabled via named Port-channel load-balancing profiles. LAG load-balancing policies can be provisioned on per linecard basis using these profiles. Configuration To configure...
Continue reading →

Egress ACL deny logging

Egress ACL deny logging on Arista DCS-7280E, DCS-7500 and DCS-7500E series switches allows the logging of the frames matching deny rules in egress ACLs. This behavior can be enabled by using the log keyword when configuring an ACL deny rule. Frames matching those ACL rules are sent to the control plane, where a syslog entry of the frame header is being generated. This feature can be used to troubleshoot egress ACL related issues. Configuration When configuring an ip access-list, a log keyword can be associated with a deny rule: lf123(config)##ip access-list test1 lf123(config-acl-test1)#permit ip 10.30.10.0/24 host 10.20.10.1 lf123(config-acl-test1)#deny ip host 10.10.10.1 host 10.20.10.1 log lf123(config-acl-test1)#permit ip...
Continue reading →

IP in IP decapsulation

With this feature, Arista 7050 and 7050X series of switches can now decapsulate IP in IP tunneled packets. When IP in IP decapsulation is configured, incoming packets with an outer IP header having IpProto=4 (IP in IP) and IpDest matching the one configured will be decapsulated, meaning that the outer IP header will be removed from the packet and all subsequent forwarding decisions will be based on the inner IP header. For a detailed description of IP in IP tunneling, please refer to RFC2003. Configuration The IP in IP decapsulation feature is enabled by configuring a decap group with type IpIp...
Continue reading →

MPLS encapsulation

EOS 4.15.0F adds support for MPLS encapsulation of IP packets in EOS. The functionality is exposed through two mechanism(s): 1) We can have static IP routes which have a label associated with it, all IP packets hitting this route will get encapsulated with the MPLS label specified and sent out. This is supported for both V4 and V6 static IP routes 2) We can also program a NexthopGroup of type MPLS. For releases before 4.20, each NexthopGroup can have up to 4 MPLS label(s) associated with it.  Release 4.20 onwards, this maximum label stack size is different for different chip types....
Continue reading →

Hardware switch controller MLAG integration

The Hardware Switch Controller (HSC) provides an integration point between the SDN controllers (NSX or Nuage) and VXLAN Controller Service (VCS).  The SDN controller will interact with the HSC agent through OVSDB (Open vSwitch Database). The HSC agent, in turn, will translate information between OVSDB and VCS. The HSC agent publishes the inventory of physical switches and physical ports to the SDN controller. The SDN controller in turn would read this inventory and update the physical ports’ VLAN bindings in order to bind a VLAN to a logical switch. In a MLAG deployment where two physical switches publish MLAG ports....
Continue reading →

IPv6 vrf support

This feature adds the support for IPv6 unicast in a VRF context in EOS. This entails static routing and dynamic routing capabilities with OSPFv3 and BGP within a vrf . This allows IPv6 unicast routing to function in a non default VRF context. Following are some of the salient points regarding this feature No ipv6 route leaking support across VRFs static and dynamic ipv6 neighbor support  per VRF static ipv6 route support per VRF IPv6 ECMP support in a VRF context IPv6 dynamic routing supported with OSPFv3 and BGP in a VRF context Routed ports, SVIs, Loopback interfaces and Management interfaces...
Continue reading →

IPv4 VRRP VRF support

As of EOS 4.15.0F, VRRP is supported in a VRF context. Virtual IP addresses can be reused in different VRF contexts, but still follow the same rules within the each VRF. Configuration To enable VRRP in a VRF, the user must do the following steps: Configure VRF: Switch(config)#vrf definition foobar Switch(config-vrf-foobar)#rd 100:10 Enable global and VRF routing: Switch(config)#ip routing Switch(config)#ip routing vrf foobar Add a Vlan into the VRF and add a physical IP address: Switch(config)#interface Vlan10 Switch(config-if-Vl10)#vrf forwarding foobar Switch(config-if-Vl10)#ip address 10.0.0.1/24 Finally, configure VRRP normally: Switch(config-if-Vl10)#vrrp 1 ip 10.0.0.2 Switch(config-if-Vl10)#vrrp 1 ?                  ...
Continue reading →

SSL certificate and key management

This is an infrastructure that provides management of SSL certificates, keys and profiles. Only RSA keys are supported. SSL/TLS is an application-layer protocol that provides secure transport between client and server through a combination of authentication, encryption and data integrity. SSL/TLS uses certificates and private-public key pairs to provide this security. A user can manage certificates, keys and also multiple SSL profiles. A SSL profile is a configuration which includes certificate, key and trusted CA certificates used in SSL/TLS communication. A SSL profile configuration can be attached to another EOS configuration which supports SSL/TLS communication. Individual EOS features that use this infrastructure will document the details of...
Continue reading →

LANZ

Introduction LANZ on DCS-7280SE and DCS-7500E adds support for monitoring congestion on front panel ports at a more granular level with Start, Update, and Stop congestion events. These events are available while using Notifying mode. The previous behavior of polling the most congested queue per ASIC is still available in the default Polling mode. LANZ Streaming is now available on DCS-7280SE and DCS-7500E. Platform compatibility DCS-7280SE DCS-7500E Configuration Enabling Notifying mode Arista(config)# queue-monitor length notifying This enables Notifying mode. The default is Polling mode. In a mixed system with both DCS-7500 and DCS-7500E linecards configuring Notifying mode results in Notifying...
Continue reading →

MPLS label swap and pop

Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short path labels for directing data packets to network nodes. The labels identify virtual links (paths) between distant nodes rather than endpoints. MPLS is scalable and protocol-independent. Data packets are assigned labels, which are used to determine packet forwarding destinations without examining the packet. Arista switches utilize MPLS to improve efficiency and control from servers through data centers and to the WAN. The MPLS implementation supports static MPLS tunneling that is manually configured on each switch or established over a network by an SDN controller. The...
Continue reading →

Egress IPv4/IPv6 ACLs for IPoMPLS packets after MPLS pop

IPv4/IPv6 over MPLS packets are now eligible for ACLs at egress stage by default. The feature is applicable only to IPv4/IPv6 over MPLS packets that are MPLS label popped ( i.e if the label is Bottom of Stack ). The user can override this behavior if required and disable egress ACLs for certain MPLS labels by explicit configuration. Configuration No special configuration is needed to enable egress ACLs on IPv4/IPv6 over MPLS packets. There is however configuration to skip egress ACLs on a per label basis. The command to disable egress ACLs for a label is as follows switch(config)#[no] mpls...
Continue reading →

RACL divergence

RACL divergence enables the optimization of the utilization of hardware resources by installing ACLs only on the hardware components corresponding to the member interfaces belonging to the SVIs on which the ACL is applied. This can save a lot of hardware resources and enables RACLs to scale to larger configurations. Deployments where multiple large RACLs are applied on SVIs with member interfaces corresponding to mutually exclusive forwarding ASICs, will benefit from this feature. Terminology RACL : any access-Lists (ACL) applied to an Switched Virtual Interface (SVI). Ingress traffic : any traffic entering a VLAN is said to ingress the SVI corresponding to the VLAN Egress...
Continue reading →

IPv6 egress RACL sharing

IPv6 egress ACLs applied to routed interfaces across the same chip on the DCS-7500E and the DCS-7280E series can be shared starting EOS-4.15.0F. In addition to that, IPv6 egress ACLs can match on the DSCP value, starting with the same release. This result in a more efficient utilization of the system resources and it is particularly useful for environments with a few, potentially large, IPv6 Egress ACLs applied across multiple routed interfaces. Configuration By default, the sharing of ACLs is disabled. The CLI command used to enable it is: 7500(config)#hardware access-list resource sharing vlan ipv6 out The CLI command to disable it is: 7500(config)#no hardware access-list resource sharing vlan...
Continue reading →

Static multicast MACs

A number of L4-7 appliances use the same MAC address to load balance services across two or more appliances that form the cluster. A typical example are firewalls. As a result, a switch must be able to learn the same MAC address on several ports. With this feature, the user can now configure the static multicast MAC destination address with multiple destination ports. Configuration The command to configure static multicast MAC  address with multiple destination ports is as follows: Arista(config)#mac address-table static <MAC-address> vlan <VLAN-id> interface <destination-ports> Example : Arista(config)#mac address-table static 0100.1234.1234 vlan 3 interface et3/1,et3/4 Status 7500# show...
Continue reading →

Ingress replication to LAGs

On DCS-7048, DCS-7280E, DCS-7500 and DCS-7500E, prior to EOS 4.14.5, multicast traffic using ingress replication would load balance the traffic over lags on a per-multicast group basis. The software would pin a multicast flow to a port in the lag based on the vlan and the multicast MAC address of the flow. This meant that software would resolve the lag for a multicast-group, and program the resolved port into the hardware for multicast traffic destined to that group. This would result in two problems: The load balancing of traffic over ports may not be even. If there is more traffic...
Continue reading →