nd_manage_vpc_pair rejects vpcPairDetails for supported ToR pairs on VXLAN fabrics

[mikewiebe]

Description

The nd_manage_vpc_pair module rejects vpc_pair_details on all iBGP/eBGP VXLAN fabrics based solely on fabric type. However, Nexus Dashboard accepted vpcPairDetails for the tested ToR pair.

The complete support matrix should be investigated across all supported fabric types and switch-role combinations, then reflected in the module validation and documentation.

Affected Module Name(s):

• nd_manage_vpc_pair

ND version and ND Platform

• ND 4.2.1, build 4.2.1.10
• Platform: to be confirmed

APIC version and APIC Platform for Site related issues

• N/A

Collection versions

• cisco.nd 1.5.0

Output/ Error message

Invalid nd_manage_vpc_pair input: 'vpc_pair_details' is not supported
for iBGP/eBGP VXLAN fabrics.

Expected Behavior

nd_manage_vpc_pair should allow vpc_pair_details for supported combinations of:

• Fabric type
• Switch roles
• Pairing type, such as leaf-to-leaf, ToR-to-ToR, and leaf-to-ToR

Unsupported combinations should produce a precise validation error.

Actual Behavior

The module currently blocks vpc_pair_details for the entire vxlanIbgp or vxlanEbgp fabric before sending the request. The validation does not inspect switch roles.

Other fabric types and role combinations are also not covered by a documented support matrix.

Playbook tasks to Reproduce

- name: Configure ToR vPC pair with vpcPairDetails
  cisco.nd.nd_manage_vpc_pair:
    fabric_name: nac-msd-fabric1
    state: merged
    config_actions:
      save: false
      deploy: false
      type: switch
    config:
      - peer1_switch_id: "10.122.84.197"
        peer2_switch_id: "10.122.84.198"
        use_virtual_peer_link: false
        vpc_pair_details:
          type: default
          domain_id: 3
          switch_keep_alive_local_ip: "10.122.84.197"
          peer_switch_keep_alive_local_ip: "10.122.84.198"
          keep_alive_vrf: management
          keep_alive_hold_timeout: 3
          enable_mirror_config: false
          is_vpc_plus: false
          is_vteps: false
          nve_interface: 1
          switch_domain_config: "auto-recovery reload-delay 360"
          peer_switch_domain_config: "auto-recovery reload-delay 360"
          switch_po_id: 1
          peer_switch_po_id: 1
          switch_member_interfaces:
            - Ethernet1/3
          peer_switch_member_interfaces:
            - Ethernet1/3
          po_mode: active
          admin_state: true
          allowed_vlans: all

Important Factoids

• The OpenAPI schema defines vpcPairDetails as an optional property of a VPC pairing request.
• The OpenAPI schema does not define restrictions based on fabric type or switch role.
• The tested switches are ToR switches.
• The controller accepted the vpcPairDetails PUT for 10.122.84.197 and 10.122.84.198.
• The test used save: false and deploy: false.
• A temporary module bypass was required because of the current blanket fabric-type rejection.
• Fabric types requiring investigation include VXLAN iBGP, VXLAN eBGP, LANClassic, External Connectivity, and ISN.
• Switch-role combinations requiring investigation include leaf-to-leaf, ToR-to-ToR, leaf-to-ToR, border, and border-gateway combinations where applicable.

Proposed Investigation

Build and document a support matrix covering:

1. Each supported fabric type.
2. Each valid switch-role pairing.
3. Whether vpcPairDetails is accepted.
4. Whether default and custom detail templates behave differently.
5. Whether save and deploy operations succeed after pairing.

Then update nd_manage_vpc_pair to use that matrix or an authoritative runtime capability check instead of the current blanket restriction.

References

• OpenAPI vpcPairDetails request schema
• nd_manage_vpc_pair fabric-type validation
• Nexus Dashboard vPC pair support and recommendation APIs
• Related issue: nd_manage_vpc_pair: physical vPC peer-link creation fails (deploys via fabric actions/configSave; switchActions/deploy works) #335