Tag :: IPSec

The multicast boundary specifies subnets where the source traffic entering an interface is filtered to prevent the creation of mroute states on the interface. The multicast boundary can be specified through one standard ACL. However, when providing multicast services via a range of groups per service, an interface could potentially join arbitrary groups and, hence, need arbitrary combinations of ACL rules.

IPsec control packets are generally sent out of any of the egress interfaces based on the ECMP IP route that covers the remote IP address of the IPsec connection. This is not suited in some deployments. For example, when an IPsec end device is establishing connections with another device across more than one ISP (Internet Service Provider) and the control packets may get different NAT treatment based on which ISP they are going over.

This feature provides a way to distinguish groups of flows within encrypted GRE tunnels. That enables downstream forwarding devices to process multiple flows in parallel while maintaining packet order within individual flows. Parallel processing offers the opportunity for significant aggregate throughput improvement.

This is an extension to the IKE policy and SA policy configuration options available in EOS. The key lifetimes for IKE policies and SA policies are specifiable in hours. This feature allows specifying the key lifetimes in minutes as well.

Support for IPSec connections in a full-cone Network/Port Address Translation (NAT) environment has been added to the Dynamic Path Selection (DPS) setup. DPS optimizes application performance by selecting different paths for various types of traffic. In this configuration, STUN is used to discover the translated IP address of WAN interfaces and export it to BGP.

PKI (Public Key Infrastructure) is a certificate based authentication solution for IPsec protocol.

An IPsec service ACL provides a way to block IPsec connections to/from specific addresses. This feature works in a similar way to other protocols in EOS that provide this functionality.

IPSec tunnel mode support allows the customer to encrypt traffic transiting between two tunnel endpoints.

IPv4 traffic can be encrypted and carried over IPSec tunnels originating or terminating on EOS dut. 

By default, the only visibility a user has into packets that are dropped due to errors with the MACsec/IPsec protocols is a set of counters, such as with show mac security counters detail. This feature enables redirecting such packets to the CPU for manual inspection; it is intended to assist with debugging unexpected packet drops.

EOS secures the communication between EOS router instances using IPsec by employing control plane protocol Internet Key Exchange(IKEv1/IKEv2) and data plane protocol ESP(IPsec SA). IKE and IPsec Security Association(SA) use policies to ensure secure communication.

EOS provides support for the use of IPsec to establish and maintain IPsec tunnels. This feature adds support for redirecting traffic matching on traffic policy rules to an IPSec tunnel.

IPsec is a standard for enabling secure network communication between two devices using the Internet Protocol (IP) by way of an encrypted packet tunnel.Previous versions of Arista EOS have required that IPsec tunnels use the default VRF for underlay traffic.Starting with the release 4.31.0, this restriction is removed and EOS now supports IPsec tunnel interfaces using one or more non-default VRFs.

Support is added to use VRRP (Virtual Router Redundancy Protocol) virtual IP (Internet Protocol) address as an IPsec ( Internet Protocol Security) tunnel source or destination address. This allows for configurations that offer both security (provided by IPsec tunnels) and redundancy (provided by VRRP).