Ability to Use Different Router IDs per VRF defined in Network Services

jrecchia1029 commented 1 year ago

Enhancement summary

Within a VRF defined under the Network Services data model, a user should be able to specify the pool used to assign router IDs from. This way, different VRFs can have unique router IDs.

Which component of AVD is impacted

eos_designs

Use case example

During a recent project, one of the requirements was to create a BGP peering between two different VRFs on the same device through a firewall. Since this BGP peering was between two VRFs on the same device, AVD originally generated the configuration for both VRFs with the same router id. This prevented the BGP peering from coming up and some additional tweaks were necessary.

Describe the solution you would like

In my example, the unique router IDs per VRF were only required on a single set of switches connected to the firewall. One solution that would've resolved my needs would be if there were a dictionary under VRF's bgp key where the dictionary itself had keys for nodes, eos_cli, structured_config. For example,

<vrf-name>:
  bgp:
    nodes:
      - [<node-1>, <node-2>]
         eos_cli:
         structured_config:

Another more seamless solution could be a router_id_pool field under the VRF from which Router ID addresses for the VRF are automatically allocated. For example,

<vrf-name>:
  router_id_pool: <router-id-pool>

Describe alternatives you have considered

No response

Additional context

No response

Contributing Guide

[X] I agree to follow this project's Code of Conduct

gmuloc commented 1 year ago

Hi Joe - thanks for opening the issue

As of today indeed network_services code will use the router_id of the switch in all the VRFs indeed. https://github.com/aristanetworks/ansible-avd/blob/devel/ansible_collections/arista/avd/roles/eos_designs/python_modules/network_services/router_bgp.py#L159

To clarify, the issue was that you were not able to limit to a single host the allocation of a structured_config? As of now in each VRF, AVD supports raw_eos_cli and structured_config under tenants[tenant_name].vrfs[vrf_name].bgp (https://avd.sh/en/stable/roles/eos_designs/doc/network-services.html#tenant-network-service-definitions):

        bgp:
          # EOS CLI rendered directly on the Router BGP, VRF definition in the final EOS configuration
          raw_eos_cli: |
            < multiline eos cli >
          # Custom structured config added under router_bgp.vrfs.<vrf> for eos_cli_config_gen
          structured_config: < dictionary >

Though that would apply to all the hosts (nodes) on which the VRF is defined so I guess this is what was not working for you?

Regarding the router_id pool. What would you expect the formula to be to allocate a router_id

jrecchia1029 commented 1 year ago

Hey Guillaume,

The fact that the raw_eos_cli or structured_config gets applied on all nodes is exactly the issue here.

With regards to the formula for allocating router_ids, I believe it would be just like allocating a router_id in the underlay where a device's id + an offset is used to allocate an address from a pool of addresses assigned to the VRF by the AVD user.

ClausHolbechArista commented 1 year ago

Instead of adding another pool, we already have the vtep_diagnostic_loopback which supports ip pools etc, and it will create a loopback inside the VRF. We could have a simple boolean to use this loopback IP as the router_id for the VRF. So under OSPF and BGP have use_vtep_diagnostic_loopback_as_router_id: true.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed

aristanetworks / avd