Open jgomezve opened 1 year ago
@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?
@mikewiebe it is customized template which we don't support as now, it is a work around
@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. 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 thevrfTemplateConfig
based on this key-valu pairs? This is similar approach, as the one use in the moduledcnm_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.
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
@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.
Community Note
Ansible Version and collection version
DCNM version
Affected module(s)
Ansible Playbook
Debug Output
The module
dcnm_rest
is being used to create/update a VRF, and then the moduledcnm_vrf
is used to deploy/ attach the VRF to the switchesThe 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
dcnm_rest
moduleReferences
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 clearedThe 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 keyvrfTemplateConfig
based on that input? Example: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 moduledcnm_vrf
is used only to deploy the VRFs on the switches