Fix for ANYCAST_RP_IP_RANGE on ND 3.1 for eBGP fabrics

[skaszlik]

[ND3.1.x] [eBGP fabric] ANYCAST_RP_IP_RANGE is not deploying on NDFC

Related Issue(s)

Fixes #688

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

Test Notes

Cisco Nexus Dashboard Version

Checklist

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

[mkilar123]

seems fine

[juburnet]

🔍 Code Review Summary

Overall Assessment

This PR correctly fixes a critical bug where ANYCAST_RP_IP_RANGE was not being deployed on NDFC 3.1.x for eBGP fabrics with multicast replication mode. The fix relocates the conditional block to the proper location in the template hierarchy.

🟢 Positive Changes

1. Correct Fix: Moves ANYCAST_RP_IP_RANGE to align with the same pattern used in dc_vxlan_fabric_resources.j2
2. Proper Conditional Logic: Now correctly checks for:
   • NOT manual_underlay_allocation
   • NOT enable_ipv6_underlay
   • replication_mode == 'Multicast'
3. Consistency: Matches the established pattern in the OSP/ISIS fabric templates

🟡 Areas for Improvement

1. Missing Test Coverage: No automated tests to validate this template rendering scenario
2. Documentation: The PR description lacks detail about the root cause and testing performed
3. Trailing Whitespace: Lines 21 and 23 have trailing spaces that should be removed

🐛 Root Cause Analysis

Previous Bug: The ANYCAST_RP_IP_RANGE was nested inside a multicast-specific conditional block (lines 38-40 in old code) that was itself nested inside another IPv6 check. This caused it to be skipped when:

• enable_ipv6_underlay = false (IPv4 underlay)
• manual_underlay_allocation = false (auto allocation)
• replication_mode = Multicast

Fix: Moves the setting to lines 21-23, which is:

• Inside the NOT manual_underlay_allocation block
• Inside the NOT enable_ipv6_underlay block
• Directly after LOOPBACK1_IP_RANGE
• Only conditionally rendered when replication_mode == 'Multicast'

This matches the exact pattern used in dc_vxlan_fabric_resources.j2 (lines 8-10).

📊 Review Status

• Decision: APPROVE with minor suggestions
• Critical Issues: 0
• Warnings: 0
• Suggestions: 2 (trailing whitespace, test coverage)
• Code Quality: ✅ Good

🎯 Recommendations

1. Remove trailing whitespace on lines 21 and 23
2. Add test case to prevent regression (e.g., validate template rendering with multicast mode + auto allocation)
3. Update PR description with root cause analysis and test evidence

✅ Verification

The change is minimal (3 lines moved), logic is sound, and aligns with established patterns. Safe to merge after addressing trailing whitespace.

---

Reviewed by: Claude Code (Sisyphus)
Review Date: 2026-02-02
Commit SHA: 93aa925

[juburnet]

@mtarking - I tested this before and after the fix for eBGP on ND 3.1.
The fix successfully sets the ANYCAST_RP_IP_RANGE condition with our fabric that meets the conditions:
enable_ipv6_underlay = false (IPv4 underlay)
manual_underlay_allocation = false (auto allocation)
replication_mode = Multicast

The conditions and placement in the jinja template function correctly.

Before it was failing to set the value and failing robot tests.
Before:

After:

[skaszlik]

Hi @mtarking ,

The current template (develop branch) include ENABLE_TRMv6 unconditionally under multicast. The fix wraps it with a version check (>= 12.2.2), since TRMv6 is only supported on NDFC 12.2.2+.

[juburnet]

Approved. ANYCAST_RP_IP_RANGE wasn't being set for ND 3.1 in the previous location because it was under a version requirement "if" statement. Tested working

[mkilar123]

lgtm

[skaszlik]

I've identified new root cause for that issue:

The multicast block is wrapped in this version guard (line 29):

{% if ( ((ndfc_version | version_compare('12.2.1', '<=')) and (not enable_ipv6_underlay))
        or (ndfc_version | version_compare('12.2.2', '>=')) ) %}

version_compare uses packaging.version.Version. ND 3.1 reports a 4-segment
build string, e.g. 12.2.1.316, which sorts greater than 12.2.1:

Version('12.2.1.316') <= Version('12.2.1')   -> False
Version('12.2.1.316') >= Version('12.2.2')   -> False
=> guard = (False and ...) or False = False   -> whole multicast block skipped

So a 12.2.1.x build (which is a 12.2.1 release and supports IPv4 multicast RP
config) lands in the dead-zone between 12.2.1 and 12.2.2 and is wrongly excluded.
12.2.2+ builds (ND 3.2 12.2.3.70, ND 4.1 12.4.1.321) match the >= 12.2.2 arm and
work fine — which is why this only reproduces on ND 3.1.

Affected / not affected (verified live)

Controller	ndfc_version	guard	multicast block
ND 3.1.1	12.2.1.316	False	❌ dropped (bug)
ND 3.2.2	12.2.3.70	True	✅ deployed
ND 4.1.1	12.4.1.321	True	✅ deployed

Fix

Change the lower boundary from <= 12.2.1 to < 12.2.2 so every 12.2.1.x build is
captured, and no other version's behavior changes:

- {% if ( ((ndfc_version | cisco.nac_dc_vxlan.version_compare('12.2.1', '<=')) and
+ {% if ( ((ndfc_version | cisco.nac_dc_vxlan.version_compare('12.2.2', '<')) and
          (not (vxlan.underlay.general.enable_ipv6_underlay | default(...) | ansible.builtin.bool))) or
          (ndfc_version | cisco.nac_dc_vxlan.version_compare('12.2.2', '>=')) ) %}

File: roles/dtc/common/templates/ndfc_fabric/ebgp_vxlan_fabric/evpn/ebgp_vxlan_fabric_evpn.j2 (line 29).

Why it's safe: for any version, the arms partition at 12.2.2. Versions < 12.2.2
(all 12.2.1.x) now render the IPv4 multicast block; versions >= 12.2.2 are unchanged.
The only behavioral change is the previously-broken [12.2.1, 12.2.2) range — i.e. exactly
the ND 3.1 builds — so there is zero regression on ND 3.2 / 4.1 (confirmed live).

[juburnet]

@mtarking will review the updates