Help Enhancing EOS_Designs output

[ryanmerolle]

I am able to add non-vxlan VLANs & SVIs with ease using the custom_configuration approach.

My challenge is that if I want to, for example, add pim v4 sparse mode to all l3leaf interfaces on a spine, Ansible complains about recursive loop in the template. I know this is a working approach when we just rename the var to something else (so we do not apply the custom configuration logic) and debug it, the jinja based var works as planned.

Example EOS_Designs output:

ethernet_interfaces:
  Ethernet1:
    peer: Leaf-CAMPUS-1-a
    peer_interface: Ethernet1
    peer_type: l3leaf
    description: P2P_LINK_TO_Leaf-CAMPUS-1-a_Ethernet1
    mtu: 1500
    type: routed
    shutdown: false
    ip_address: 10.0.255.8/31
  Ethernet2:
    peer: Leaf-CAMPUS-1-b
    peer_interface: Ethernet1
    peer_type: l3leaf
    description: P2P_LINK_TO_Leaf-CAMPUS-1-b_Ethernet1
    mtu: 1500
    type: routed
    shutdown: false
    ip_address: 10.0.255.12/31
  Ethernet3:
    peer: Leaf-CAMPUS-2-a
    peer_interface: Ethernet1
    peer_type: l3leaf
    description: P2P_LINK_TO_Leaf-CAMPUS-2-a_Ethernet1
    mtu: 1500
    type: routed
    shutdown: false
    ip_address: 10.0.255.16/31
  Ethernet4:
    peer: Leaf-CAMPUS-2-b
    peer_interface: Ethernet1
    peer_type: l3leaf
    description: P2P_LINK_TO_Leaf-CAMPUS-2-b_Ethernet1
    mtu: 1500
    type: routed
    shutdown: false
    ip_address: 10.0.255.20/31

Example custom_structured_configuration_ethernet_interfaces

custom_structured_configuration_ethernet_interfaces: "{%- set temp_interface_dict = {} -%}
                                                      {%- for interface in ethernet_interfaces | dict2items| selectattr('value.peer_type', 'equalto', 'l3leaf') -%}
                                                      {%-     set _ = temp_interface_dict.update( {interface['key']: (interface['value'] | combine ({'pim':{'ipv4': {'sparse_mode': true}}})) } )  -%}
                                                      {%- endfor -%}
                                                      {{- temp_interface_dict -}}"

@carlbuchmann recently suggested my hacks put in place deserved to be properly addressed in the eos_designs model.

The more I look at this, the more I think, similar to #995 this should be an option in the design to allow for pim to be applied to uplinks & ibgp peer links. Yes PIM is multicast is still very much a work in progress in EVPN, BUT that does not mean people do not setup multicast/pim in their underlay.

Any other suggestions?

[carlbuchmann]

@ryanmerolle, in our chat, I was referring to extending with adding your own template to the "stack" with yaml_template_to_facts

https://avd.sh/en/latest/plugins/#yaml-templates-to-facts

templates:
  # Templates defined per design
  l3ls-evpn:
    facts:
      # Set general "switch.*" variables
      - template: "facts/main.j2"
      # Set design specific "switch.*" variables
      - template: "designs/l3ls-evpn/facts/main.j2"
    structured_config:
      # Render Structured Configuration
      # Base features
      - template: "base/main.j2"
      # MLAG feature
      - template: "mlag/main.j2"
      # Underlay feature
      - template: "designs/l3ls-evpn/underlay/main.j2"
      # Overlay feature
      - template: "designs/l3ls-evpn/overlay/main.j2"
      # L3 Edge feature
      - template: "l3_edge/main.j2"
      # Tenants feature
      - template: "designs/l3ls-evpn/tenants/main.j2"
      # Connected Endpoints feature
      - template: "connected_endpoints/main.j2"
      # Merge custom_structured_configuration last
      - template: "custom-structured-configuration-from-var.j2"
        options:
          list_merge: "{{ custom_structured_configuration_list_merge }}"
          strip_empty_keys: false
      ### Ryan's custom templates ### 
      # Add PIM multicast configuration
      - template: "custom-ethernet-interface-configuration.j2"

[ryanmerolle]

This makes perfect sense for new designs where I am not building on top of the l3ls-evpn AVD model. I can just append new templates to the templates dictionary.

For extending l3ls-evpn, the way I read this suggested approach to work is that I would copy the logic used in eos_designs l3ls-evpn as it exists today, with the addition of my special template. Basically, overwrite the dictionary with my own, as you showed above. My understanding of that approach, and why I did not jump to it myself is that (please correct my assumptions as needed):

• Since my custom-ethernet-interface-configuration.j2 would be the last template in the list creating an ethernet_interfaces dictionary, I would be overwriting the output of eos_designs/templates/designs/l3ls-evpn/underlay/interfaces/ethernet-interfaces.j2 when instead I want to build upon said template and add a single pim option to it.
• Any project updates to the role's templates['l3ls-evpn']['facts'] found in roles/eos_designs/defaults/main.yml would not be included if I did not also update my defined templates dictionary to match the greater project's updates. IE similar to a fork of the project.
• If the above template structure/logic gets updated in the collection, it would most certainly break my own custom-defined templates logic.

[carlbuchmann]

@ryanmerolle

• It is an incorrect statement that you would override eos_designs/templates/designs/l3ls-evpn/underlay/interfaces/ethernet-interfaces.j2. Under the hood, the yaml_templates_to_facts action plugin leverages the Ansible jinja2 combine filter, and by default will append the data, all strategies supported by this filter are supported by the action plugin, so there are many option of how data is merged!

• You are right on the last two bullets, that this may change overtime, and we will make sure we call this out in the release notes, so updates can be done accordingly.

• The goal of this capabilities, provide us the foundation to support multiple use cases i.e: media, service provider, pure l3ls, etc... and additionally for advanced users create their own design and add their own specific logic to expand on our templates.

If this approach is not desired, the alternative is that you could have a role that executes before eos_designs, and leverage the yaml_templates_to_facts action plugin (this is similar result to doing template module followed by include_vars), to generate custom_structured_configuration output and save it to facts.

[ryanmerolle]

Thanks for the thoughtful and detailed response @carlbuchmann !

Having a role execute before the eos_designs role feels like the right approach for me to extend an existing design created by AVD instead of creating a role in parallel that I would have to maintain from version to version.

This is especially true since the devel branch, which I leverage, would not have release notes associated to it.

[carlbuchmann]

You are welcome!

• Note, as you know devel can change at any time, and we follow semantic versioning, so once we start working on 3.x release, data models for both eos_designs and eos_cli_config_gen will be impacted. A migration role for eos_designs will be provided to help with the transition.
• Once going production, we advise to track the release branch. This is why we have increased our release cadence , you can see the planned release timeframe by looking at the milestones.

[ClausHolbechArista]

Hi Ryan
I believe your example does not work, because there is no variable ethernet_interfaces at the time of the rendering. During rendering we place the structured configuration into a tmp variable called structured_config so it should be structured_config.ethernet_interfaces, but I tried testing with that, and it seems like the rendering of the inline template happens before it is passed to our code, so even structured_config is not available.
It could work from the leaf standpoint by iterating over the topology.links facts which are set in a previous stage.
Also note that you don't have to do the combine. We take care of that in the custom_structured_configuration code.

custom_structured_configuration_ethernet_interfaces: "{%- set temp_interface_dict = {} -%}
                                                      {%- for interface in topology.links | dict2items | selectattr('value.peer_type', 'equalto', 'spine') -%}
                                                      {%-     do temp_interface_dict.update( { interface.key: {'pim': {'ipv4': {'sparse_mode': true}}}} )  -%}
                                                      {%- endfor -%}
                                                      {{- temp_interface_dict -}}"

It patches the ethernet_interfaces:

The other direction is not set in topology, so we don't have a way of parsing that dynamically. You would need to replicate the entire logic for detecting downlink interfaces.

For this exact use case it would be much quicker to implement a new knob in eos_designs, to configure pim on uplinks.

[ClausHolbechArista]

We will change (align) a lot of the data models around the topology in AVD 3.0. See PR#1000 if you are curious. (In draft still!)
With those changes it would be very simple to add

< switch_key (ex. l3leaf, spine etc) >:
  defaults:
    uplink_pim:
      ipv4:
        sparse_mode: true

This would then get reflected on the upstream device as well.

So if you can wait for 3.0 or work from devel when we merge in #1000 (in around a week), I think this would be the way forward. Please submit an issue for this if you think it makes sense.

[ryanmerolle]

So if you can wait for 3.0 or work from devel when we merge in #1000 (in around a week), I think this would be the way forward. Please submit an issue for this if you think it makes sense.

I am happy to poke around the PR and test it once finalized/merged. I just cannot say how much time this project have saved me now that I no longer have to manage my own templates for everything.

[ryanmerolle]

Hello @ClausHolbechArista,

I have been reviewing your PR #1000 and the devel branch overall. common-settings.md#fabric-topology was very helpful. Given your example:

With those changes it would be very simple to add

< switch_key (ex. l3leaf, spine etc) >:
  defaults:
    uplink_pim:
      ipv4:
        sparse_mode: true

This would then get reflected on the upstream device as well.

I am just confused how uplink_pim would append its contexts of to the proper uplinks?

[ClausHolbechArista]

I have not implemented support for this key yet. We need to get #1000 merged in first, and then we can add extras like uplink_pim etc.
If your question is how this should be implemented, we would set a switch.uplink_pim in the facts/switch/switch.j2. This would be picked up in facts/topology/p2p-uplinks.j2 and added to the uplink definition. This in turn would be picked up by both this and the upstream switch in the templates under underlay folder.

[ryanmerolle]

Thanks for the clarification @ClausHolbechArista

Ah, my mistake. Not that this is your problem, but for now I will have to figure out the best way in which to add the config after configuration is output by avd.eos_designs.