Adding support for VLAN ID override, CLI Freeform and SVI admin status (ND >=4.1) under network attachments

[juarocha]

Related Issue(s)

Fixes #807
Fixes #820
Fixes #831
Fixes #863

Related Collection Role

• cisco.nac_dc_vxlan.validate
• cisco.nac_dc_vxlan.dtc.create
• cisco.nac_dc_vxlan.dtc.deploy
• cisco.nac_dc_vxlan.dtc.remove
• other

Related Data Model Element

• vxlan.fabric
• vxlan.global
• vxlan.topology
• vxlan.underlay
• vxlan.overlay
• vxlan.overlay_extensions
• vxlan.policy
• vxlan.multisite
• defaults.vxlan
• other

Proposed Changes

New key under network, switch_attach_overrides that will handle this 3 new features for each networks

vxlan:
  overlay:
    networks:
      - name: Network1
        vlan_id: 2301
        network_attach_group: attach_group
        switch_attach_overrides:               <<<<<
          - hostname: leaf1
            vlan_id: 10
            svi_enabled: false
            freeform_config: |
              interface Vlan3101
              no autostate
          - hostname: leaf2
            vlan_id: 10
    network_attach_groups:
      - name: attach_group
        switches:
          - hostname: leaf1
            ports: [Ethernet1/13]
          - hostname: leaf2
            ports: [Ethernet1/13]

Test Notes

Depends on base collection PR #711

Cisco Nexus Dashboard Version

3.1, 3.2, 4.1 and 4.2

Checklist

• Latest commit is rebased from develop with merge conflicts resolved
• New or updates to documentation has been made accordingly
• Assigned the proper reviewers

[dacasti2mx]

Completed end-to-end validation on ND 4.1 / NDFC 12.4.1.321, and the core functionality looks solid.

Offline — schema, rules and render

#	Test	Result
O1	Rule 405 — equal VLAN on vPC peers	PASS
O2	Rule 405 — unequal VLAN on vPC peers	FAIL (as required) — 405 HIGH

Standalone (FAB1) — Leaf-101 · control 103/104 · port Eth1/6

Stage	Change	NDFC	NX-OS	Control	Res
L0	Create (no override)	VLAN 2402	SVI up Eth1/6 → 2402	—	✅
L1	vlan_id 2402 → 2403	2403	SVI Vlan2403 up Eth1/6 → 2403	2402	✅
L2	+ freeform	—	no ip redirects on Vlan2403	2402	✅
L3	+ svi_enabled: false	svi=false	SVI Vlan2403 admin-down	2402	✅
L4	Idempotency	= L3	= L3	2402	✅
L5	Update 2403 → 2404	2404	SVI Vlan2404 Eth1/6 → 2404	2402	✅
L6	Removal	2402	SVI up Eth1/6 → 2402 freeform gone	2402	✅

Standalone vPC — Leaf-103/104 · control Leaf-101

Stage	Change	NDFC (pair)	NX-OS (pair)	Control	Res
V1	vlan_id: 2405 equal	Both 2405	Both SVI Vlan2405 up	2402	✅
V2	VLAN + freeform + svi_enabled: false	Both svi=false	Both admin-down + freeform ×2	2402	✅
V3	Removal	Both 2402	Both SVI up freeform gone	2402	✅

MCFG — Leaf-101 · control BGW-1/103/104

Stage	Change	NDFC	NX-OS	Control	Res
M1	vlan_id 2301 → 2401	2401	SVI Vlan2401 up	2301	✅
M2	+ freeform	—	Freeform on Vlan2401	2301	✅
M3	+ svi_enabled: false	svi=false	SVI Vlan2401 admin-down	2301	✅
M4	Idempotency	= M3	= M3	2301	✅
M5	Update 2401 → 2411	2411	SVI Vlan2411 admin-down	2301	✅
M6	Removal	2301	SVI Vlan2301 up 2401/2411 absent	2301	✅

These results confirm that vlan_id, freeform_config and svi_enabled work through the tested lifecycle, including per-switch isolation, vPC consistency, physical-port VLAN updates, update, removal and idempotency.

Requested change — unresolved switch identifier

I found one input-resolution case that should be considered. I tested the management IP of Leaf-101:

switch_attach_overrides:
  - hostname: 192.168.1.101
    vlan_id: 2401

Validation passed because rule 401 accepts a switch name, IPv4 address or IPv6 address. However, prep_105_fabric_overlay.py and prepare_msite_data.py resolve overrides only by comparing the value with the switch hostname.

Consequently, mgmt_ip_address was not added to the override and BUILD failed with:

'dict object' has no attribute 'mgmt_ip_address'

This failed safely before dcnm_network: no request was sent to NDFC and
Leaf-101 remained on its original VLAN.

I recommend two complementary changes:

1. Update validation rule 401 to enforce the intended identifier contract and verify that the switch belongs to the selected network attach group.
2. Add fail-loud handling in both preparation plugins when an override cannot be resolved to mgmt_ip_address.

The templates should not simply skip an unresolved override, because that would silently discard explicit user intent.

[juarocha]

Filed a new bug #863, since this behavior is not only for the overrides, it affects also network attach groups

[dacasti2mx]

I agree that this problem is not limited to switch_attach_overrides and can also affect network_attach_groups.

Just one clarification about the scenario I reproduced: I did not use an unknown IP. I used the valid management IP of an existing switch. Rule 401 accepted
it, but the preparation plugins only tried to resolve it as a hostname. Because of that, mgmt_ip_address was never added and the template failed during
BUILD.

I understand that MCFG/MSD do not have a topology section, so the same early validation cannot be used everywhere. However, prepare_msite_data.py already
discovers the switches from the child fabrics. I think that information can be used to resolve the value as:

• hostname;
• management IPv4 address;
• management IPv6 address.

For standalone fabrics, the same resolution could be added to prep_105_fabric_overlay.py.

After resolving the switch, I think we should also confirm that it belongs to the network_attach_group selected by the network. If it cannot be resolved, or
it is not part of that attach group, the preparation stage should fail clearly before reaching the template, for example:

Network '<network>' switch_attach_overrides identifier '<identifier>' could not be resolved to a switch attached through network_attach_group '<group>'.

I would not recommend silently skipping the override in the template because that would ignore an explicit user request.

For the tests, I think these focused cases should be enough:

• valid hostname → PASS;
• valid management IP → PASS;
• unknown identifier → fail before render;
• existing switch outside the selected attach group → fail before render;
• standalone and MCFG paths.

If these cases are covered, I would be comfortable moving the review to LGTM without repeating the complete live validation matrix.

[juarocha]

Added some rule changes

[dacasti2mx]

LGTM