BGP neighbor's ip address should not be the key in the YAML schema

Let’s say you have the following in host_vars for the switch myswitch.foo.bar

uplink1: 128.66.0.2/31
uplink2: 128.66.1.2/31
uplink3: 128.66.2.2./31
uplink4: 128.66.3.2/31

And so on and so forth. For every uplink you have been given, your remote end is using the first IP address in the block and you’ve been given the second.

Now, it’s time to configure your BGP neighbors using the ansible-avd collection, and the eos_cli_config_gen role specifically.

Now, previously you had code that used https://github.com/ansible-collections/arista.eos/blob/main/docs/arista.eos.eos_bgp_global_module.rst - so you were able to do a couple neat little tricks to reduce the amount of variables you’re carrying around

bgp_neighbors:
  - peer: "{{ uplink1 | ansible.netcommon.ipmath(-1) }}"
    remote_as: "{{ upstream_asn }}"
  - peer: "{{ uplink2 | ansible.netcommon.ipmath(-1) }}"
    remote_as: "{{ upstream_asn }}"

The point being, that the YAML schema used an array for all the bgp neighbors, with each neighbor being a dictionary, and a peer attribute that had the IP address of the neighbor as the value.

It is not possible with Ansible-AVD to do something similar, since each BGP neighbor is a dictionary in YAML, with each key in the dictionary being the IP address, which is not valid YAML and Ansible does not substitute the Jinja2 expression

router_bgp:
  as: "{{ our_asn }}"
  neighbors:
   "{{ uplink1 | ansible.netcommon.ipmath(-1) }}":
      remote_as: "{{ upstream_asn }}"

This results in an invalid config

router bgp 65000
   router-id 96.216.37.2/30
   neighbor {{ uplink1 | ansible.netcommon.ipmath(-1) }} remote-as 65002
!

https://github.com/ansible/ansible/issues/17324

[ClausHolbechArista]

@sc68cal I did a small mock up of your variables, and with some extra json conversion it can work.

uplink1: 128.66.0.2/31
uplink2: 128.66.1.2/31
uplink3: 128.66.2.2/31
uplink4: 128.66.3.2/31
our_asn: 123
upstream_asn: 321

custom_structured_configuration_router_bgp: 
  as: "{{ our_asn }}"
  neighbors: "{{ { uplink1 | ansible.netcommon.ipmath(-1) : { 'remote_as': upstream_asn },
                   uplink2 | ansible.netcommon.ipmath(-1) : { 'remote_as': upstream_asn },
                   uplink3 | ansible.netcommon.ipmath(-1) : { 'remote_as': upstream_asn },
                   uplink4 | ansible.netcommon.ipmath(-1) : { 'remote_as': upstream_asn } } }}"

Produces this (ignore the custom_structured_configuration_ prefix for your usecase):

router_bgp:
  as: 123
  neighbors:
    128.66.0.1:
      remote_as: 321
    128.66.1.1:
      remote_as: 321
    128.66.2.1:
      remote_as: 321
    128.66.3.1:
      remote_as: 321

Could be optimized by setting a var like uplink_bgp_template to ease setting multiple bgp knobs:

uplink_bgp_template:
  remote_as: 321

custom_structured_configuration_router_bgp: 
  as: "{{ our_asn }}"
  neighbors: "{{ { uplink1 | ansible.netcommon.ipmath(-1) : uplink_bgp_template,
                   uplink2 | ansible.netcommon.ipmath(-1) : uplink_bgp_template,
                   uplink3 | ansible.netcommon.ipmath(-1) : uplink_bgp_template,
                   uplink4 | ansible.netcommon.ipmath(-1) : uplink_bgp_template } }}"

[sc68cal]

@ClausHolbechArista thank you for the example. We’ve done something similar to that for a different set of Ansible automation with different devices, but it was implemented poorly and was awful to look at and read, so as a general rule we avoid doing the JSON-> YAML conversion trick. Your style is more compact and concise, so this is certainly something to look at further.