NewValidation: Service Graph VRF Mismatch Detection

[gautvenk]

(use upvote 👍 for attentions)

Validation Type

[x] - Fault

[ ] - Config

[ ] - Bug

[ ] - Other

What needs to be validated

Validate that service graphs with PBR (Policy-Based Redirect) have service device interfaces in a VRF that matches either the consumer or provider VRF.

Fault Code: F1690
Example fault message: "Configuration failed for uni/tn-/GraphInst_C-[...] due to Invalid Service Graph VRF Config"

High-level Algorithm:

Cache contract VRF info to avoid repeated lookups per vnsLDevCtx

contract_vrf_cache = {}

for each vnsLDevCtx:
contract_dn = resolve contract from ctrctNameOrLbl

# Get consumer/provider VRFs (cached)
if contract_dn not in contract_vrf_cache:
    consumer_vrfs = set of VRFs from all fvRsCons/fvRsConsIf pointing to contract
    provider_vrfs = set of VRFs from all fvRsProv/fvRsProvIf pointing to contract
    contract_vrf_cache[contract_dn] = {
        'consumer_vrfs': consumer_vrfs,
        'provider_vrfs': provider_vrfs
    }

consumer_vrfs = contract_vrf_cache[contract_dn]['consumer_vrfs']
provider_vrfs = contract_vrf_cache[contract_dn]['provider_vrfs']

for each vnsLIfCtx under vnsLDevCtx:
    # Skip if no redirect policy (not PBR)
    if no vnsRsLIfCtxToSvcRedirectPol:
        continue
    
    # Get service VRF from BD or L3Out
    if vnsRsLIfCtxToBD exists:
        service_vrf = BD -> fvRsCtx -> fvCtx
    elif vnsRsLIfCtxToInstP exists:
        service_vrf = l3extInstP -> l3extOut -> l3extRsEctx -> fvCtx
    
    # Validate: service VRF must match consumer OR provider VRF
    if service_vrf not in consumer_vrfs AND service_vrf not in provider_vrfs:
        FLAG AS INVALID

Why it needs to be validated

CSCwj49418 (and subsequently CSCwn14462) introduced VRF validation for service graphs to detect invalid configurations where service device interfaces are in a different VRF than both consumer and provider EPGs.

Before 6.1(2b), invalid service VRF configurations were silently ignored and no fault was raised. After upgrade to 6.1(2b)+, F1690 informational faults will be raised for any invalid VRF configurations. Note that graph rendering and switch programming remain unaffected - this is purely a visibility/fault notification improvement.

Note: CSCwv29846 addresses a false-positive F1690 fault that can be raised by CSCwn14462 in certain MSite upgrade scenarios. Detecting the configuration issue before upgrade avoids inconsistencies in general.

This pre-upgrade validation allows customers to:

• Identify invalid service graph VRF configurations before upgrade
• Proactively fix misconfigurations rather than discovering them via post-upgrade faults
• Maintain a clean fault dashboard after upgrade

Additional context

• Related defects:
  • CSCwj49418 , CSCwn14462 (introduced VRF validation, integrated in 6.1(2))
  • CSCwv29846 (false-positive F1690 fix for MSite render path)
• Reference: Cisco ACI PBR White Paper (c11-739971) - Section "Requirements and design considerations"
  • Key requirement: "The PBR node bridge domain and the L3Out for PBR node must belong to the same VRF instance as either the consumer bridge domain (EPG) or provider bridge domain (EPG)."
  • Figure 5: "The PBR node must be in either the consumer or provider VRF instance"
  • https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739971.html