dcnm_vrf - Omission of Loopback Routing Tag during VRF creation causes later issue when editing VRF in NDFC

[allenrobel]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Ansible Version and collection version

cisco.dcnm        2.0.1  

ansible [core 2.12.4]
  config file = /Users/foobar/tmp_ndfc/ndfc-roles/ansible.cfg
  configured module search path = ['/Users/foobar/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/foobar/py310/lib/python3.10/site-packages/ansible
  ansible collection location = /Users/foobar/.ansible/collections:/usr/share/ansible/collections
  executable location = /Users/foobar/py310/bin/ansible
  python version = 3.10.3 (v3.10.3:a342a49189, Mar 16 2022, 09:34:18) [Clang 13.0.0 (clang-1300.0.29.30)]
  jinja version = 3.0.3
  libyaml = True

DCNM version

• V 12.0(2f) (NDFC)

Affected module(s)

• dcnm_vrf

Ansible Playbook

  cisco.dcnm.dcnm_vrf:
    fabric: f1
    state: replaced
    config:
    - vrf_name: v1
      vrf_id: 9003031
      vlan_id: 3031
      vrf_template: Default_VRF_Universal
      vrf_extension_template: Default_VRF_Extension_Universal
      service_vrf_template: null
      attach:
        - ip_address: 1.2.3.4
        - ip_address: 5.6.7.8

Debug Output

Debug Output: dcnm_vrf - Omission of Loopback Routing Tag during VRF creation causes later issue when editing VRF in NDFC

Expected Behavior

A Loopback Routing Tag field should be present in the REST POST sent to the switch, even if the value is an empty string ("").

Actual Behavior

The Loopback Routing Tag field is not present during VRF creation, which causes later (manual) edits of the VRF in NDFC to push a config-profile with unresolved tag parameter. The issue, on Cisco's side, is being tracked with CSCwb74982. However, it would be good to ensure that all required parameters are present to avoid possibly similar issues in the future when a combination of Ansible and GUI (NDFC) are used.

Steps to Reproduce

1. Run the above playbook, or similar
2. After the VRF is created, in DCNM/NDFC 12.0.(2f) do the following
3. Click on Topology in the NDFC sidebar
4. Double-click on fabric f1
5. Double-click on VRFs
6. Double-click on VRF v1
7. Right-click on a device and select "Edit Attachment"
8. Click the slider to change the attachment state from Detach to Attach
9. Enter 111 into the Loopback Id field
10. Enter 1.2.3.4 into the Loopback IPv4 Address
11. The other fields do not matter and can be ignored for the purpose of this reproduce
12. Click Save
13. Right-click on the device, and select Preview
14. In the Pending Config column, click the config (should say '36 lines')
15. Observe that the loopback config looks as follows

  interface loopback111
    vrf member v1
    ip address 1.2.3.4/32 tag $$tag$$

If you try to Deploy this above config, NDFC will return the following error.

CLI command 'refresh profile v1 v1_new overwrite' failed with following error:Delivery failed with message:ERROR: Cannot refresh to parameterized destination profile

Looking at the Detailed History for this error, it occurred when the following CLI was attempted:

refresh profile v1 v1_new overwrite

Manually issuing the above (on the switch) produces the same error.

If the config-profile is manually edited to replace $$tag$$ with '12345', the command succeeds.

References

[mikewiebe]

@allenrobel Thanks for raising this issue and including the detailed recreate instructions. We will work on a fix for this.