Arista Portal

  • Tag : security

 
 

GTSM for BGP

Posted on June 10, 2019 by   |   26 Views

Description This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect BGP peering sessions (both iBgp and eBgp) from an attacker on the network segment causing denial of service using forged IP packets by spoofing the BGP peer’s IP address. The solution is described by the RFC 3682 (Generalized TTL Security Mechanism). The user can configure a minimum TTL for incoming IP packets received from the BGP peer. BGP session will only get established if the TTL value in the received IP packet header is greater than or equal to the...
Continue reading →

BGP Peering – Configuration Best Practices – Security and Manageability

Posted on November 27, 2018 by   |   1342 Views

      BGP Peering – Configuration Best Practices – – – – – – – – – – – – – – – – Security and Manageability       1) Introduction This article provides suggestions of BGP peering configuration, with general best practices and some particular considerations for manageability and security.     2) Arista EOS Security – General   It is recommended to approach security not only specifically for BGP but to englobe other aspects of security for Arista EOS. More global security topics are covered in other articles, listed below. The present article focuses solely on...
Continue reading →

VXLAN: security recommendations

Posted on January 16, 2017 by   |   1702 Views

Abstract This document provides recommendations that are advised to implement in order to increase the security in multitenant network environments built on Arista Networks devices using VXLAN. Introduction One of the crucial qualities of modern cloud network infrastructure is scalability. Scalability can’t be achieved if security of the network operations inside the cloud is compromised. As for example, load scalability is not achievable in environments where the VMs are not able to operate when the network between them is not working properly due to hijacked MAC-addresses. One of the technologies used nowadays to address the challenges with scalability inside the cloud networks...
Continue reading →

GTSM for BGP

Posted on August 25, 2016 by   |   97 Views

Description This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect BGP peering sessions (both iBgp and eBgp) from an attacker on the network segment causing denial of service using forged IP packets by spoofing the BGP peer’s IP address. The solution is described by the RFC 3682 (Generalized TTL Security Mechanism). The user can configure a minimum TTL for incoming IP packets received from the BGP peer. BGP session will only get established if the TTL value in the received IP packet header is greater than or equal to the...
Continue reading →

How are people generally separating internal and DMZ networks?

Posted on March 30, 2016 by   |   0 Views

Hi forum, Considering the design elements of a L3LS, the separation of functions into dedicated leaves (such as Services, Compute, Storage, Border), and given Cisco’s VDC and it’s logical separation (or rather, the broadly accepted/ marketed view that secure and less secure networks can be collapsed onto the same physical device) are people doing the same with L3LS deployments with VLANs and VXLAN?  Or are they interconnecting two L3LS ‘instances’ with border leaves with a secure gateway? Cloud datacentres seem to make no distinction between what a customer defines as secure and not secure and generally they seem to suggest...
Continue reading →

Securing eAPI

Posted on March 30, 2015 by   |   9195 Views

Introduction In this article we will talk about a few tips to secure our eAPI access, for example, HTTPS, changing port, certificate, ACL, on-box, AAA, vrf etc. Turning on/off eAPI First of all, the most secure way is turning off eAPI, which is by default. myswitch#configure myswitch(config)#management api http-commands myswitch(config-mgmt-api-http-cmds)#shutdown To turn eAPI on by “no shutdown”, by default the HTTPS protocol is running and HTTP is turned off for secure purpose, because HTTP send user and password in clear text. HTTP can be used by “protocol http”, however, we recommend using HTTPS. Both HTTP and HTTPS can be used concurrently. myswitch#configure terminal myswitch(config)#management api http-commands...
Continue reading →

Securing EOS CLI

Posted on March 25, 2014 by   |   59357 Views

Objective This Tech Tip is intended to provide Arista EOS users with the configuration guidelines and best practices to enable secure management plane protocols according to IT industry security standards. It is not the objective of this document to set the foundations or rules of a company security policy or a password policy. Note: This document is not intended to set company security or password policy. Ultimate responsible to define and apply an end-to-end IT security policy is the responsibility of the end user and must take into account any regulations directly related with company activities. Arista EOS includes a wide...
Continue reading →

Restricting access to the switch

Posted on January 24, 2014 by   |   16224 Views

In this article we demonstrate how you can enable your Arista switch to restrict access to various network services. By default, Arista EOS implements a control-plane ACL to restrict the packets going to the CPU.  This is done for security purposes, but in its default configuration is very permissive.  As such, it is recommended that the sources which can access the switch be restricted using the methods described below. To view the default ACL issue the following command: Arista#sh ip access-lists default-control-plane-acl IP Access List default-control-plane-acl [readonly] statistics per-entry 10 permit icmp any any [match 4, 11 days, 20:46:23 ago]...
Continue reading →

Automatic MD5 Verification of EOS image

Posted on January 23, 2014 by   |   7963 Views

Introduction This article describes how EOS can be extended in order to check the integrity of software images. The extension described below adds the ability to automatically download the MD5 sum of an EOS image and check its integrity.  This is done by adding an optional verify parameter to the existing copy command. When verify is specified, the switch will first attempt to copy the requested EOS image (e.g. EOS-4.12.5.swi), and then it will try to retrieve an MD5 sum for the same resource (e.g. EOS-4.12.5.swi.md5sum). Assuming both files are successfully downloaded, the MD5 sum of the software image will be...
Continue reading →

Follow

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

Join other followers: