• Tag : CVX

 
 

Must I use all the same version of EOS for switches and CVX?

Hi, there. I’m using 5 Arista switches with EOS(4.24.4M) and CVX (4.24.0F). I’m trying to upgrade one of switches to 4.26.2.1F. Is it OK to use one different version of EOS? (maybe any faults… between 4.24 CVX and 4.26 EOS??) Have any ideas? Thank you !

Problem with CVX EVPN and other vendor

Hi! I have full Arista VXLAN network with CVX as a controller with “service vxlan” and BGP EVPN between different CVX for DCI. Now I need to interconnect another vendor leaf switches to CVX via BGP EVPN. And got a problem. When I recive mac-ip route from other CVX via EVPN, then advertise this route to “service vxlan” is great work, but when I recive mac-ip route from other vendors then this route don’t advertise to “service vxlan”. Route wich I recive from other CVX and work: CVX-1(config)#show bgp neighbors 10.102.0.2 evpn received-routes route-type mac-ip fa16.3e6b.aa20 detail BGP routing table...
Continue reading →

Problem with Openstack routers and arista-ml2 driver with HPB

Hi! I have a problem with VLAN – VNI mapping for openstack routers on network nodes. My environment: Openstack Ussuri Neutron with legacy routers realisation (not DVR) Some compute nodes Two network nodes (with l3, dhcp and metadata agents) Arista-neutron-ml2-driver with VXLAN HPB Arista 7050SX integrated with CVX   Problem: I create a tenant network. Network is visible on CVX (show openstack network). Next I connect instance to this network and driver correctly mapped VNI to VLAN and dattach VLAN to compute interface on the switches. Next I enable DHCP on this network and driver correctly attach VLAN to network...
Continue reading →

Support for Static Topology

Description This feature addresses cases where the deployment infrastructure in an OpenStack setup which manages Virtual Machines and Bare Metal servers does not provide a support for enabling LLDP on interfaces connecting hosts to switches. As a result the topology information does not appear on CVX. An example of this case is some deployments of OpenStack that do not provide a good way to enable LLDP for DPDK interfaces. Even with manual configuration of LLDP on hypervisors, the configuration does not persist after OpenStack redeployment. With this feature, the topology can be configured statically using the CLI on CVX without...
Continue reading →

Macro-Segmentation Service deployment in a Brownfield Environment

Description This document presents how Arista Macro-Segmentation Service (MSS) can be deployed in a brownfield environment with a mix of non-Arista switches. This solution targets a VXLAN based network where both Arista and non-Arista Virtual Tunnel Endpoints (VTEPs) share the overlay reachability using the EVPN control plane.The following figure depicts such setup: In order to enable security enforcement with MSS, the user can put the resources that they would want to protect behind Arista VTEPs and express the security objectives using firewall policies. Moreover, this feature allows the user to enable MSS in a multiple datacenter (DC) environment where a...
Continue reading →

Still warning in vxlan config-sanity

Hi All I deploy vxlan that controlled by CVX. However there some warning in config-sanity. below are the output text from “show vxlan config-sanity” Local VTEP Configuration Check WARN VLAN-VNI Map WARN VLAN 915 does not exist VLAN-VNI Map WARN VLAN 916 does not exist VLAN-VNI Map WARN VLAN 920 does not exist Flood List WARN No remote VTEP in VLAN 920 Flood List WARN No remote VTEP in VLAN 915 Flood List WARN No remote VTEP in VLAN 916 Routing WARN Virtual VTEP IP is not configured CVX Configuration Check FAIL CVX Server FAIL No route to 10.9.99.101 MLAG...
Continue reading →

Consistent Policy Enforcement and Multi-VRF support for Macro-Segmentation Service

Description This document presents Arista Macro-Segmentation Service (MSS) deployment in a network with multiple Virtual Routing and Forwarding (VRF) instances. MSS can ensure more granular segmentation within a VRF, either by attracting a subset of east-west traffic to the firewall or enforcing the security objective at the top-of-rack (TOR) switches. This document also explains the policy enforcement guarantee that MSS provides in the presence of switches with varying hardware resources. Summary of Enhancements This section briefly describes the enhancements made to the current set of MSS features in this release: MSS now can be enabled in a non-default VRF in...
Continue reading →

Mss fortigate, cvx, cvp and Arista L3LS

Hi master. My customer has infrastructure Arista 2spine and 4leaf. They want to deploy new firewall Fortigate HA = 2 unit and Cloudvison appliance with MSS features. I’m reading and learn concept mss configuration on cvx and Fortigate, but there is something I’m not understanding about config mss on cvx. Arista Macro Segmentation Service integration with Fortinet Firewalls The link at the top, define command on cvx “type Fortinet fortimanager”My customer asks for me, how about not used /without the fortimanager? It is can used mss features, configuration or not?   Please advise and share your experience and link recommended.     Thanks   Robma bayu    

Openstack multi-region problem with CVX

Hi! I have a problem with intergration multi-region Openstack and CVX. Opestack has two region: Miami and Moscow. Configuration neutron plugin region Moscow controller nodes: [ml2_arista] eapi_username=admin eapi_password=Fhpfvfc16 eapi_host = 10.240.31.45 region_name = Moscow use_fqdn = true Configuration CVX in region Moscow: MSK-CVX(config-cvx-openstack-Moscow)#show running-config section cvx ! device: MSK-CVX (vEOS, EOS-4.24.1.1F) ! cvx no shutdown source-interface Management1 ! service openstack no shutdown authentication role admin name-resolution interval 10 ! region Moscow username arista_cvx_msk tenant service password 0 password keystone auth-url http://10.240.33.58:5000/v3/ provision sync mandatory   Openstack endpoint list: +——–+————–+————–+———+———–+————————————————–+ | Region | Service Name | Service Type | Enabled |...
Continue reading →

VXLAN Unresolved ARPs to 172.16.1.1

We have stand for test VXLAN between different DCs (schema in attachment). All Leafs connected to CVX server on each DC. And each CVX connected between themeslaves via BGP EVPN. For test in each leaf was connect server with linux and configured port on access VLAN100. Next step I configure assotiation VLAN100 and VNI25100. MAC Lerning good work and on both leaf I see mac-addreses. Connection for vxlan configured in GRE tunnel and has good L3 connectevless. But traffic has no on VNI 25100. I tried to debug this problem and discovered: show vxlan config-sanity category result detail ———————————- ——–...
Continue reading →

Policy Control Service

Description Policy Control Service (PCS) is the integration of Arista CVX and VMWare NSX-T to enable NSX-T managed networks to enforce security policies on Arista switches for traffic sourced from or destined to bare metal servers that are connected to the switches. PCS service runs on CVX and directly interfaces with NSX-T policy manager. It receives policies from NSX-T policy manager and converts them into ACLs that are applied on the switches to enforce the desired behavior for traffic ingressing and egressing through these switches. Figure 1: PCS Integration with VMWare NSX-T   To help understand the interaction between PCS...
Continue reading →

Migrating from legacy DC design to EVPN VXLAN Fabric

Introduction This document is intended to provide a reference of steps and sequence followed for:  (1) migrating a legacy 3-tier L2 network to EVPN based VXLAN environment using Leaf & Spine design (2) migrating an L2 Leaf & Spine network with VXLAN using CVX as the control plane to EVPN based control plane (3) migrating an L2 Leaf & Spine network with VXLAN using static VXLAN as the control plane to EVPN based control plane. Scope The key objective of this report is to migrate a Layer 2 datacenter to EVPN based VXLAN using Leaf & Spine (L3LS) solution for...
Continue reading →

CVX preserve client state

Description The CVX preserve client state feature allows client state to be preserved on CVX even when the management connection between the client and CVX is disrupted. With the feature is enabled, clients become inactive upon disconnection, and all client state is preserved on CVX. When clients reconnect to CVX, client state learned during the connection outage is immediately processed. For example, with the VXLAN controller service, MAC’s are learned from each client, and the aggregated state is published to the clients to populate their MAC address table. If a client disconnects, the MAC’s for that client are preserved on...
Continue reading →

Layer 2 Data Center Interconnect – Reference Designs

Introduction VxLAN is a popular choice for extending Layer 2 both intra and inter DC using overlays. Arista offers multiple control plane choices for VxLAN: Static HER, CVX and EVPN. In this article, two approaches to designing a L2 DCI over a L3 underlay are discussed. High-level technical details of each design approach is described first, followed by a comparison of the two options along with their typical use cases. Design 1: Multi-domain Overlay In this design, two overlay domains are identified: DC Fabric domain: This is the VxLAN domain within the DC Layer 3 Leaf-Spine Fabric with Leafs acting...
Continue reading →

How to recover flood-list and mac address learning when using OVSDB management

Hi, I am a beginner of Arista switch. I have two questions on that. <Information of the switch>model:Arista DCS-7150S-64-CLversion:EOS-4.15.7M 1) The flood-list and the mac address  learning disappears when the switch restarts. Why? I set the infomation that “HER flood-list and mac address learning” on the Arista switch that using the OVSDB management. Example of setting  is as follows.(The following command executed on CVX.)-bash-4.1# vtep-ctl add-mcast-remote <LS-name> unknown-dst vxlan_over_ipv4 <vtep-ip>-bash-4.1# vtep-ctl add-ucast-remote  <LS-name>  <MAC-address> vxlan_over_ipv4 <vtep-ip> One day, I stopped the Arista switch and started it.Then, the information(HER flood-list and mac address  learning) disappeared from Arista switch…Note: I confirmed it by...
Continue reading →

Issues Arista Integration with OpenStack (Mitaka)

Hello All, We are trying to integrate Arista Switches with OpenStack using Ml2 Plugins. Details of the setup as below  Setup Details: Base OS: CentOS Linux release 7.3.1611 (Core) OpenStack Version: Mitaka (13.1.2-1.el7) Control +Network Node : 172.16.48.30 Compute 1 : 172.16.48.31 Arista CVX VM : 172.16.48.100   Attached are the configuration, Physical Setup Details and logs from the network+Controller node. Once the recommended changes are made Neutron service fails.  Can anybody guide here.  Regards, Lalit   

Bug Alerts

Bug-Alerts is a service that runs on Arista CloudVisionTM eXchange (CVX) that provides customers with information on known, resolved bugs that are impacting Arista switches. The feature collects switch properties such as EOS version, hardware platform, configuration and operating conditions of all connected switches. It uses these switch properties and a local database of known bugs to determine the list of impacting bugs for each switch. This information is then displayed via show commands on CVX. The complete Bug-Alerts feature consists of the following components: CVX components AlertBase – This is the database of known and resolved bugs in Arista...
Continue reading →

VXLAN Without Controller for Network Virtualization with Arista physical VTEPs

  1) Introduction This article assumed an understanding of the VXLAN concepts. This article aims at guiding the design and implementation of network virtualization with VXLAN, employing physical VTEPs. This controller-less design provides Layer2 communication across a Layer3 network for any Layer2 Ethernet device. This solution guide resolves network virtualization for network teams that might not have yet a network virtualisation controller, or cloud management platform (CMP), but want to benefit now from all the advantages of VXLAN. Without network controller, the virtual switches will not participate natively in the VXLAN overlay setup, they would be configured the traditional way...
Continue reading →

SDN Starter Kit Quick Start Guide v2015.1

Introduction The Quick Start Guide is intended to provide an introduction to Arista Networks switches, Extensible Operating System (EOS) and recently released CloudVision management. It is intended to help the reader quickly deploy Arista switches and leverage the power of automation by using CloudVision. The setup, installation and configuration from start to finish should not take more than a couple hours.  Audience This guide is intended for the following audience:  • End user getting familiar with CloudVision • End user getting familiar with Arista’s EOS CLI CloudVision – Network Automation Key CloudVision features include point and click interface to simplify bulk tasks,...
Continue reading →

Configure CVX and VXLAN with Ansible

Purpose: This Ansible playbook allows an administrator to easily configure a Cloud Vision Exchange (CVX) environment as well as configure a Virtual Extensible LAN (VXLAN) between two switches in an environment built using Arista switches, whether they be physical or virtual (vEOS). It is ideally suited for test environments and administrators wanting to test CVX and VXLAN. The playbook can be modified for more complex deployments. Running the playbook: From the /etc/ansible directory in the Linux CLI run: ansible-playbook cvx_vxlan_playbook.yaml Prerequisites: An Ansible server (http://docs.ansible.com/ansible/intro_installation.html) arista.eos roles for Ansible v1.0.1 # sudo ansible-galaxy install arista.eos. Rename the following files under...
Continue reading →

Follow

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

Join other followers: