Module dcnm_vrf clears unsupported VRF Template properties

[jgomezve]

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

• 2.12.3

DCNM version

• V 12.1.2e

Affected module(s)

• dcnm_vrf

Ansible Playbook

  - name: Merge vrfs
    cisco.dcnm.dcnm_vrf:
      fabric: myFabric
      state: merged
      config:
      - vrf_name: VRF-TEST
        vrf_id: 10010
        vrf_template: myVrfTemplate
        vrf_extension_template: myVrfExtensionTemplate
        vlan_id: 2010
        service_vrf_template: null
        attach:
        - ip_address: 1.2.3.4
          deploy: true

Debug Output

The module dcnm_rest is being used to create/update a VRF, and then the module dcnm_vrf is used to deploy/ attach the VRF to the switches

The playbook is executed without any problem however most of the VRF attributes, the ones not supported by the module, are cleared

Expected Behavior

Properties not supported by the module should be left untouched

Actual Behavior

Properties such as MTU, Tag, Max BGP paths etc are cleared from the VRF config

Steps to Reproduce

• Create a VRF manually in NDFC or using the dcnm_rest module
• Execute the playbook
• Attributes not supported by the modules are cleared

References

The root cause seem to be a "limitation" in the NDFC Rest API. I have manually created a VRF and then updated it via Postman with the payload below. The outcome is the same; VRF attributes not listed in vrfTemplateConfig are cleared

{
    "displayName": "VRF-TEST",
    "fabric": "myFabric",
    "vrfExtensionTemplate": "myVrfExtensionTemplate",
    "vrfId": 10011,
    "vrfName": "VRF-TEST",
    "vrfTemplate": "myVrfTemplate",
    "vrfTemplateConfig": "{\"vrfName\":\"VRF-TEST\",\"vrfVlanId\":2010,\"vrfSegmentId\":10011,\"nveId\":\"1\",\"asn\":\"\"}"
}

The keys in the vrfTemplateConfig are the ones that seem to be used by the module. See:

https://github.com/CiscoDevNet/ansible-dcnm/blob/851149a9334fb78a3d2d1ca2a8e7a8500ccddc6e/plugins/modules/dcnm_vrf.py#L1651

Suggested workaround

What if the module dcnm_vrf accepts a dictionary as an input, and the module builds the key vrfTemplateConfig based on that input? Example:

  - name: Merge vrfs
    cisco.dcnm.dcnm_vrf:
      fabric: myFabric
      state: merged
      config:
      - vrf_name: VRF-TEST
        vrf_id: 10010
        vrf_template: myVrfTemplate
        vrf_extension_template: myVrfExtensionTemplate
        vlan_id: 2010
        service_vrf_template: null
        template_vars :
          mtu: 9216
          maxIbgpPaths: 6
          isRPAbsent: false
        attach:
        - ip_address: 1.2.3.4
          deploy: true

We could also set a flag that forces the module to only deploy the VRFs. In that way the module dcnm_rest is used to create/update the VRF and the module dcnm_vrf is used only to deploy the VRFs on the switches

[mikewiebe]

@jgomezve Thanks for raising the issue. We have a PR open to support all of the VRF attributes so that might mitigate this problem but we will need to test and verify.

Here is the PR: https://github.com/CiscoDevNet/ansible-dcnm/pull/208

I am curious though, why are you not using dcnm_vrf to create/update the VRF?

[dsx1123]

@mikewiebe it is customized template which we don't support as now, it is a work around

[jgomezve]

@mikewiebe. As @dsx1123 mentioned, I am currently working with customized templates. What do you think about my suggestion of having a generic attribute in the Ansible module called template_vars, and let the Module to build the vrfTemplateConfig based on this key-valu pairs? This is similar approach, as the one use in the module dcnm_policy

[mikewiebe]

@mikewiebe. As @dsx1123 mentioned, I am currently working with customized templates. What do you think about my suggestion of having a generic attribute in the Ansible module called template_vars, and let the Module to build the vrfTemplateConfig based on this key-valu pairs? This is similar approach, as the one use in the module dcnm_policy

Hi @jgomezve I think this is a very interesting approach. We have considered this in the past also based on dcnm_policy and it's probably something we will have to do for customized templates.

[steele-ntwrk]

Hi @mikewiebe ,

When I am deploying a vrf I am unable to set route_map_out, this is a default configuration parameter but I also can enable a custom parameter that is apart of my custom VRF Extension template, is this expected and is this issue related to what I am experiencing?

Here is my playbook task:

   - name: Merge vrfs for each LEAF switch
      cisco.dcnm.dcnm_vrf:
       fabric: DEV-CB-FYSH-NMO-DC-NETWORK
       state: merged
       config:
        - vrf_name: TEST_VRF
          vrf_intf_desc: TEST_VRF
          vrf_description: TEST_VRF
          vrf_vlan_name: TEST_VRF
          vrf_id: 200999
          vrf_int_mtu: 9216
          vrf_template: Default_VRF_Universal
          vrf_extension_template: CUSTOM_Default_VRF_Extension_Universal_BGP_SUBINT_BFD
          vlan_id: 3500
          service_vrf_template: null
          deploy: no
          attach:
          - ip_address: 10.64.255.23
            vrf_lite:
              - interface: Ethernet1/53
                ipv4_addr: 10.74.96.225/29
                neighbor_ipv4: 10.74.96.230
                dot1q: 999
                ROUTE_MAP_OUT: TEST_VRF
              - interface: Ethernet1/54
                ipv4_addr: 10.74.100.225/29
                neighbor_ipv4: 10.74.100.230
                dot1q: 999
                ROUTE_MAP_OUT: TEST_VRF
                BFD: True

[praveenramoorthy]

@steele-ntwrk "route_map_out" parameter is not supported in vrf lite config as of now. and the behavior you are seeing is expected. We will try to support it in a future release.