• Refine tenancy model for VXlan VNI assignments

Implementing -cvsourceip in TerminAttr daemon allows to support two use cases:

• Registration of the device using provision.py script
• Device connected to CVP via a loopback or an SVI

Configuration example for TerminAttr < 1.7

daemon TerminAttr
   exec /usr/bin/TerminAttr -ingestgrpcurl=10.83.12.79:9910 -cvcompression=gzip -taillogs -ingestauth=key,xxx \
-smashexcludes=ale,flexCounter,hardware,kni,pulse,strata -ingestexclude=/Sysdb/cell/1/agent,/Sysdb/cell/2/agent \
-ingestvrf=default -cvsourceip=<Device_Source_IP>
   no shutdown

Configuration example for TerminAttr >= 1.7

daemon TerminAttr
   exec /usr/bin/TerminAttr -ingestgrpcurl=10.83.12.79:9910 -cvcompression=gzip -taillogs -cvauth=key,xxx \
-smashexcludes=ale,flexCounter,hardware,kni,pulse,strata -ingestexclude=/Sysdb/cell/1/agent,/Sysdb/cell/2/agent \
-ingestvrf=default -cvsourceip=<Device_Source_IP> -cvvrf=default 
   no shutdown

Role description is missing.

• Add support for SNMP configuration

Role eos-config-deploy-cvp is only supporting Fabric creation. In some use cases, it might be interesting to reset fabric from CVP and move EOS devices to ZTP mode.

Role should allow an option to choose whether we want to build or cleanup CVP.

- name: Configuration deployment with CVP
  hosts: CVP
  connection: local
  gather_facts: no
  tasks:
    - name: run CVP provisioning
      import_role:
         name: eos-config-deploy-cvp
      vars:
        state: {{present|absent}}  # present is default value

example of data model entry:

Tenants:
  Tenant_A:
    l2vlans:
      260:
        name: VMotion
        tags: [ vmotion ]
        enabled: true

add BGP router-id under each VRF so that it is deterministic.

Due to absence of recovery timer for EVPN blacklist MAC-addresses possible workaround would be following event-handler:

event-handler evpn-blacklist-recovery
action bash FastCli -p 15 -c “clear bgp evpn host-flap”
delay 300
!
trigger on-logging
regex EVPN-3-BLACKLISTED_DUPLICATE_MAC

Summary:

In case only you defined only L2 VNIs in your tenants, CLI config gen fails with follfowing elements:

FAILED! => changed=false 
  msg: 'AnsibleUndefinedVariable: ''dict object'' has no attribute ''vrfs'''

Context information:

• arista.avd version 1.0.0
• ansible 2.9
• Impacted file: vxlan-interface.j2

Solution:

{% if vxlan_tunnel_interface.Vxlan1.vxlan_vni_mappings.vrfs is defined and 
vxlan_tunnel_interface.Vxlan1.vxlan_vni_mappings.vrfs is not none %}
{%     for vrf in vxlan_tunnel_interface.Vxlan1.vxlan_vni_mappings.vrfs | arista.avd.natural_sort %}
   vxlan vrf {{ vrf }} vni {{ vxlan_tunnel_interface.Vxlan1.vxlan_vni_mappings.vrfs[vrf].vni }}
{%     endfor %}
{% endif %}

Instead of:

{%     for vrf in vxlan_tunnel_interface.Vxlan1.vxlan_vni_mappings.vrfs | arista.avd.natural_sort %}
   vxlan vrf {{ vrf }} vni {{ vxlan_tunnel_interface.Vxlan1.vxlan_vni_mappings.vrfs[vrf].vni }}
{%     endfor %}

Same change should been done in documentation part of the role.

Notes

Abstraction role (eos_l3ls_config) has not been tested as we are using a custom role to generate VXLAN HER topology.

example required for 7280R2:

hardware tcam profile vxlan-routing

iBGP required in overlay VRFs between MLAG pairs for certain connectivity and failure scenarios.

On chassis switches, I like to use "interface Ma0" which floats as a virtual IP address across both supervisors, which have the following physical management interfaces:

SUP #1:
interface management 1/1
interface management 1/2

SUP #2:
interface management 2/1
interface management 2/2

interface management0 floats between 1/1 and 1/2 when physically wired like this:

Resulting in a config that looks like this:
interface Management0
vrf forwarding MGMT
ip address x.y.z.a/s

There are other combinations to consider, I'm sure. ;-)

example:
vlan internal allocation policy ascending range

It may make sense to keep "generated_vars", "intended_configs", & "documentation" in their own directory called "derived_objects" and then that way the only directories at the scope below "physical_poc" are "derived_objects", "group_vars" and "config_backup". This may assist segmenting what's really an input and what's really an output.

In addition, move "inventory.yml" into "group_vars" as that is also an input.

Move "ip ospf" commands to "router ospf" scope instead of under, say, "Interface EthernetX" scope. I think this makes it easier to debug the derive configs by putting all relevant info into less areas of the running-config.

HTML has to be removed from Markdown docs. It's not critical, but increases complexity of maintaining and compatible with all dev tools.
Here is an example:

## Role Inputs and Outputs

Figure 1 below provides a visualization of the roles inputs, and outputs and tasks in order executed by the role.

<p align="center">
  <img src='media/figure-1-role-eos_l3ls_evpn.gif' alt='Figure 1: Ansible Role eos_l3ls_evpn'/>
</p>

**Inputs:**

This is not displayed correctly in PyCharm for instance.

A simple Markdown string instead would be much better:

![Figure 1: Ansible Role eos_l3ls_evpn](media/figure-1-role-eos_l3ls_evpn.gif)

One particular example, from the global configuration.

redundancy
protocol sso

• Add BFD to router OSPF configuration
• Remove additional underlay BGP configuration that is not required:
  • redistribute connected

• fallback (port-channel)
• storm-control
• portfast

Recall that there are no GARPs for interfaces with "ip address virtual", which could be somewhat problematic for L2 infrastructure that is southbound of the VTEPs.

Of course, removing "ip address virtual" results in chewing up more IP addresses in the entire eVPN fabric.

Hi All,

I know this is not the place to post this question but the eos thread does not have an option to ask for support. I'm still really new to using Ansible as I have only just got Ansible roles to work i.e. the old way, and after seeing the demo video about arista.avd collections I would really like to get arista-eos up and running without the cloudvision part but after trying to read the doc's about the eos collections I have no idea how this works. Before i could just do the following to push configuration.

• host file including groups, or children groups
• A playbook calling roles, host, and stating the connection type
• all file in the group_vars directory to push to all hosts
• host vars in the host_vars directory to push to individual hosts including the vault stored username and password.

Could someone please let me know how I should be setting up the Ansible layout in order for this new format of arista-eos collection to work. I'm really at my wits end after not being able to find a demo complete inventory, playbook, group_vars, host_vars example.

Thanks in advanced Shaun

add the following to default template:

switchport default mode routed
!
no aaa root
!
management console
   idle-timeout 15
!
management ssh
   no shutdown
   idle-timeout 15
   vrf default
      shutdown
   vrf MGMT
      no shutdown
!
management telnet
   shutdown
!
management defaults
   secret hash sha512
!
vlan 1
   state suspend
   trunk group DO_NOT_USE
!

Refactor to split out sub-section in BGP templates in the eos-l3ls-evpn role to allow easier extenstion.

Add support for 3 node CVP cluster

Add capability in l3leafs/l2leafs node_groups to filter VLANs and VRFs by Tenants and/or Tags

Add following to the mlag leafs VXLAN config:

interface Vxlan1
   vxlan virtual-router encapsulation mac-address mlag-system-id

"Guide for contribution" is referenced in README.md, but does not exist.
As value of this guide is not incredibly high, I suggest to remove the reference from the README.md

Create initial documentation on how to use the EVPN design guide roles!

Document important design assumptions, like tenancy model, etc.
Explain what data structures are related to every assumption.
Add the list of design assumptions to be documented into this issue and do not close till the list looks complete.

When defining a port-profile, allow a method to add all VLANs that present on the leaf switch.

for example:

  VM_Servers:
    mode: trunk
    vlans: "all"

This "all" keyword would result in adding all VLANs defined on the switch -> accessible via the leaf.vlans key

Example interface description correction

DC1-LEAF2A:

interface Ethernet7
   description DC1-L2LEAF6A_Ethernet1
   channel-group 7 mode active
!
interface Ethernet8
   description DC1-L2LEAF6B_Ethernet2 -> Ethernet1
   channel-group 7 mode active

DC1-LEAF2B:

interface Ethernet7
   description DC1-L2LEAF6A_Ethernet1 -> Ethernet2
   channel-group 7 mode active
!
interface Ethernet8
   description DC1-L2LEAF6B_Ethernet2
   channel-group 7 mode active

example:

interface Ethernet2
   speed forced 10000full

• note, does not apply to vEOS-LAB

support for interface breakout:

• 40 -> 4x10
• 100 -> 4x10 or 4x25
• 400 -> 4x100

interface Ethernet3/1/1
description P2P_UPLINK_TO_LEAF-1_Ethernet53/1

Perhaps when the description is relative to a Spine's perspective down to a leaf, maybe "DOWNLINK" or "LINK" is cleaner.

Validate syntax and more importantly duplicate keys!

Remove dependency on eos_config_gen
Remove when: eosconfig.changed from task.

After running pip install -r requirements.txt in a clean environment, we have following error message:

fatal: [DC1-SPINE1 -> localhost]: FAILED! => changed=false 
  msg: 'AnsibleFilterError: The ipaddr filter requires python''s netaddr be installed on the ansible controller'

This library is missing from requirements.txt

Fix is:

$ pip install netaddr
Collecting netaddr
  Using cached https://files.pythonhosted.org/packages/ba/97/ce14451a9fd7bdb5a397abf99b24a1a6bb7a1a440b019bebd2e9a0dbec74/netaddr-0.7.19-py2.py3-none-any.whl
Installing collected packages: netaddr
Successfully installed netaddr-0.7.19

Is this README required? If yes, make a reference to the main one.

add docker file to enable consistent use and deployment of Ansible Arista Validated Design Collection.

Provide docker file for:

• Ansible 2.8
• Ansible 2.9(devel)

Add the capability to define static routes in the tenant data model.

• The goal when creating this data model is to reduce user input, and also think about it as a service.
• For example, the data model could be used to configure the EVPN fabric elements, but also the peering device itself.
• Initial data model to define L3 peers should support the following:
  • Peering with SVI
  • Peering with routed ports
  • Peering using BGP with peer groups

• Adjust MLAG Reload-Delay Timers (MLAG Only)

R series Devices:

mlag configuration
reload-delay mlag 1020
reload-delay non-mlag 780

All other Platforms (Trident/Tomahawk/XP ASIC):

mlag configuration
reload-delay mlag 360
reload-delay non-mlag 300

• dual primary detection:

dual-primary detection delay 5 action errdisable all-interfaces

move "leaf_as_range:" unders spines
example:

spine:
  leaf_as_range: 65101-65132

move "virtual_router_mac_address " under L3Leafs

l3leafs:
  virtual_router_mac_address : 00:1c:73:00:dc:01

To Be Fixed:

1.

Here to be changed from:

As mentioned in the overview, if desired, the role can be extended to leverage data from dynamic sources such as an IPAM or CMDB.

to:

If desired, the role can be extended to leverage data from dynamic sources such as an IPAM or CMDB.

To track missing section here

Allow management interface in default/global routing table

Updates to the following templates/data model will be required:
https://github.com/aristanetworks/ansible-avd/blob/master/ansible_collections/arista/avd/roles/eos_l3ls_evpn/templates/base/mgmt-interface.j2

https://github.com/aristanetworks/ansible-avd/blob/master/ansible_collections/arista/avd/roles/eos_l3ls_evpn/templates/base/mgmt-vrf.j2