aristanetworks / avd

Arista Validated Designs
https://avd.arista.com
Apache License 2.0
260 stars 193 forks source link

Updating source ports to ma0 for modular switches #1539

Open dgonzalez85 opened 2 years ago

dgonzalez85 commented 2 years ago

Enhancement summary

Currently when we set modular platform, the management port is correctly set to "Management0"

spine:
  defaults:
    platform: 7500R3

However some services such as ntp, logging etc are still set to source Management1 by default. Ansible does not allow not setting the source interface or it will report an error:

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ansible.errors.AnsibleUndefinedVariable: 'dict object' has no attribute 'source_interface'
fatal: [spine01 -> localhost]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'source_interface'"}

Then all the services (in this case the spines) need to be overwritten to set the source to the correct port Management0. We would like this to be automatically set as well when selecting a modular platform and avoid the following configuration and avoid the following explicit configuration:

---
type: spine

custom_structured_configuration_logging:
...
  vrfs:
    MGMT:
      source_interface: Management0
      ...

custom_structured_configuration_snmp_server:
  local_interfaces:
    Management0:
      vrf: MGMT

custom_structured_configuration_ntp:
  local_interface:
    vrf: MGMT
    name: Management0 

custom_structured_configuration_ip_tacacs_source_interfaces:
    - name: Management0
      vrf: MGMT

custom_structured_configuration_ip_ssh_client_source_interfaces:
    - name: Management0
      vrf: MGMT

Which component of AVD is impacted

eos_designs

Use case example

Using modular switches as spines.

Describe the solution you would like

Update the source interfaces correctly as part of selecting the modular platform.

Describe alternatives you have considered

No response

Additional context

No response

Contributing Guide

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days

tgodaA commented 2 years ago

You can use the AVD magic variable (switch.mgmt_interface), instead of specifying the interface name itself.

For example:

custom_structured_configuration_logging:
...
  vrfs:
    MGMT:
      source_interface: "{{ switch.mgmt_interface }}"
      ...

custom_vrf_config:
  vrf: MGMT

custom_structured_configuration_snmp_server:
  local_interfaces:
    "{{ { switch.mgmt_interface: custom_vrf_config } }}"

custom_structured_configuration_ntp:
  local_interface:
    vrf: MGMT
    name: "{{ switch.mgmt_interface }}"

custom_structured_configuration_ip_tacacs_source_interfaces:
    - name: "{{ switch.mgmt_interface }}"
      vrf: MGMT

custom_structured_configuration_ip_ssh_client_source_interfaces:
    - name: "{{ switch.mgmt_interface }}"
      vrf: MGMT
dgonzalez85 commented 2 years ago

Hi @tgodaA thanks for following up on this. I think even with this they still need a separate yaml file for the spines isnt it? What the customer was looking is to set automatically the source port for the required services based on the platform.

Today we already set the management port based on this: https://avd.sh/en/latest/roles/eos_designs/doc/platform-settings.html

But ntp, logging etc still require a separate custom config to overwrite the default Management1 port. Hence the ask, to automate this with eos_designs with the right source port.

@gmuloc will follow up with the customer since im currently working in another project, to double check the functionality that they expect.

Many thanks, David

tgodaA commented 2 years ago

This will set the management port based on the switch specific platform. This is common for all switches.

markcheverton commented 2 years ago

Hi @tgodaA , I am working with @gmuloc on this request from customer side.

I have updated our config reflecting the changes mentioned under EOS_designs config and this is working however i'm unsure how i would reflect the "{{ switch.mgmt_interface }}" magic variable for snmp as this structure references Management1 as a variable under local_interfaces: ie

snmp_server: local_interfaces: Management1: vrf: MGMT

https://avd.sh/en/latest/roles/eos_cli_config_gen/index.html#snmp-settings

Above shows ability to define multiple interfaces but doesn't seem to allow for magic variable?

snmp_server: local_interfaces: < interface_name_1 >: vrf: < vrf_name > < interface_name_2 >: < interface_name_3 >: vrf: < vrf_name >

Would this still require a custom_structured_snmp_server: under a separate file?

Thanks Mark

tgodaA commented 2 years ago

I addressed the snmp_server in the above example. Please use the exact example:

custom_structured_configuration_logging:
...
  vrfs:
    MGMT:
      source_interface: "{{ switch.mgmt_interface }}"
      ...

custom_vrf_config:
  vrf: MGMT

custom_structured_configuration_snmp_server:
  local_interfaces:
    "{{ { switch.mgmt_interface: custom_vrf_config } }}"

custom_structured_configuration_ntp:
  local_interface:
    vrf: MGMT
    name: "{{ switch.mgmt_interface }}"

custom_structured_configuration_ip_tacacs_source_interfaces:
    - name: "{{ switch.mgmt_interface }}"
      vrf: MGMT

custom_structured_configuration_ip_ssh_client_source_interfaces:
    - name: "{{ switch.mgmt_interface }}"
      vrf: MGMT

This example uses the below snippet to solve the problem for snmp_server:

custom_vrf_config:
  vrf: MGMT

custom_structured_configuration_snmp_server:
  local_interfaces:
    "{{ { switch.mgmt_interface: custom_vrf_config } }}"

custom_vrf_config is a temporary var (not an avd variable) and it can be anything (please make sure this wasn't used anywhere else). I used that variable just to create the dictionary: { switch.mgmt_interface: custom_vrf_config }

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days

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

github-actions[bot] commented 3 months 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