eos_cli_config_gen & network_services

[durd]

Hi,

Just a quick question, is it possible to use network_services with only eos_cli_config_get and not eos_designs?

We are building a meshed l3leaf design without spines and leveraging eos_cli_config_get and structured_configs heavily as I'm not sure how to create my own device types. But now we aren't sure how to easily add vrf, vlans, svis to all devices without editing the config for every device.

Thanks!

[carlbuchmann]

@durd

Thanks for reaching out and for the great question!

To leverage network_services, you also need to leverage eos_designs.
That said, here are a few tips on eos_designs to customize it for your needs:

• eos_designs offers a lot of customization, which allows you to build any topology.
• To create your own device types, see Node type customization section: https://avd.arista.com/4.4/roles/eos_designs/docs/input-variables.html#node-type-customization
• There are two ways to define node-to-node connectivity:
  • Node type uplink management: https://avd.arista.com/4.4/roles/eos_designs/docs/input-variables.html#node-type-uplink-management
  • Core interfaces: https://avd.arista.com/4.4/roles/eos_designs/docs/input-variables.html#core-interfaces-settings
  • Both models support full mesh connectivity, the core interfaces data model might feel more natural to work with in this situation, but that is a personal preference.
• From eos_designs, you can leverage eos_cli_config_gen model using custom_structured_configuration prefix or structured_config in various areas of our data models.
  • https://avd.arista.com/4.4/roles/eos_designs/docs/how-to/custom-structured-configuration.html

Happy to get on a Zoom call to answer some of your questions live. I can be reached @ [email protected].

[durd]

Thanks for your tips regarding connectivity and device types. I appreciate the offer of a zoom call!
I'm stuck on a couple things, and will probably use core interfaces instead.

For instance we want to use a physical interface for mlag ibgp-peering instead of a vlan. I can't find any way to "disable/remove" that vlan. Closest I've gotten is enable_mlag_ibgp_peering_vrfs and mlag_peer_l3_vlan which do remove the bgp-neighbor and vlan but adds the mlag_peer_vlan to ospf.
Edit: I guess I could use mlag: false and manually create mlags in the node-groups.

This seems like a bug. In the example single-dc-l3ls I've commented out the spines in inventory.yml and in DC1.ymlcommented out uplink_switches and added DC1_L3_LEAF1 switches as uplink_switches to the node-group DC1_L3_LEAF2. I also commented out bgp_as in both node-groups.
In FABRIC.yml I changed underlay_routing_protocol to ospf, and overlay_routing_protocol to ibgp, and I added a bgp_as.
eos_designs adds ospf config with passive-interfaces and interface configuration, but it does not add any bgp neighbors as I would have expected.
I have forked and edited the example here.

[carlbuchmann]

@durd

For instance we want to use a physical interface for mlag ibgp-peering instead of a vlan. I can't find any way to "disable/remove" that vlan.

In AVD, we focus on implementing best practices for Arista deployments based on designs and deployment guides. We would not create such knob.

What design are you trying to achieve? A live conversation with your local SE and I would be more productive to answer your questions!

[durd]

@carlbuchmann
Sorry for the late reply, I came down with the flu.

@durd

For instance we want to use a physical interface for mlag ibgp-peering instead of a vlan. I can't find any way to "disable/remove" that vlan.

In AVD, we focus on implementing best practices for Arista deployments based on designs and deployment guides. We would not create such knob.

Now I'm more confused. I'm able to create custom designs with custom device types. But not...? I understand following best practices, but I haven't really seen any from Arista save from technical guides and documentation. Can't say that I've actively looked for best practices from Arista either, as most best practices are applicable regardless of vendor.

What design are you trying to achieve? A live conversation with your local SE and I would be more productive to answer your questions!

This is what we are trying to achieve: no spines, but all leaves, or if you will, classic design. Green is physical routed links, red is mlag peer-link and blue is L2 links or other.

Instead of the mlag_peer_l3_vlan we would have a physical link. But I couldn't find how to use the physical link instead of the vlan.

Yesterday while I was home sick, my colleagues met with our SE and he was going to get back to us with an embryo of a design to work off of.