New validation for Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object by Harinadh-Saladi · Pull Request #394 · datacenter/ACI-Pre-Upgrade-Validation-Script

Harinadh-Saladi · 2026-06-01T17:57:42Z

Added a new pre-upgrade validation for Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object.

Enclosed comprehensive logs for the same after testing in the lab with new scenarios addition and after addressing all final review comments.

Comprehensive Test Logs.txt

Full Script Run Logs.txt

Pytest_Logs.txt

Pytest_Full_Logs.txt

muthu-ku · 2026-06-02T04:57:33Z

+        relation_dn = relation_attributes["dn"].strip()
+        if not relation_dn:
+            continue
+        target_dn = get_target_dn(relation_attributes)


dn is the full path of the relationship object, and tDn is the path of the target interface object it is attached to.

No need of check for tDN.

i agree. its not resolved. at all.

Comparison now uses full relation DN instead of tDn and handles rscIfAtt vs rscIfAttN differences before matching.

muthu-ku · 2026-06-02T04:59:51Z



+@check_wrapper(check_title="Cleanup vnsRsCIfAtt usage in services")
+def vns_rscifatt_cleanup_check(tversion, **kwargs):


change the proper function name and title

Updated name and title

muthu-ku · 2026-06-02T06:53:57Z

+
+Impact:
+
+If any `vnsRsCIfAtt` relation exists without a matching `vnsRsCIfAttN` for the same concrete interface target (`tDn`), the upgrade is outage-risky and should be treated as affected.


please update the document as per impact and requirement.

muthu-ku · 2026-06-02T06:56:32Z

+            continue
+        missing_dn = old_relation_dn_by_key[relation_key]
+        tenant_name, device_name, logical_interface, concrete_interface = parse_relation_context(missing_dn)
+        data.append([tenant_name, device_name, logical_interface, concrete_interface, missing_dn])


where is that fault case handled for post upgrade case..

fault : F1690
uni/tn-CSCwj49418/lDevVip-test/lIf-intf-cons/vnsConfIssue-lif-invalid-CIf
Configuration is invalid due to LIf has an invalid CIf

As per below comment added by Lovkesh,

"After doing upgarde from 605h to 615e.

fab3-apic# moquery -c vnsRsCIfAtt | grep dn
fab3-apic# moquery -c vnsRsCIfAttN | grep dn
dn : uni/tn-CSCwj49418/lDevVip-test/lIf-intf-prov/rscIfAttN-[uni/tn-CSCwj49418/lDevVip-test/cDev-cdev/cIf-[prov]]
fab3-apic#

Gui shows cIf-[prov] deleted from concrete device interface.
and fault raised
F1690
Minor
2026-05-29T13:37:55.525+00:00
Raised
uni/tn-CSCwj49418/lDevVip-test/lIf-intf-cons/vnsConfIssue-lif-invalid-CIf
Configuration is invalid due to LIf has an invalid CIf
Config
configuration-failed
ignorable:no, issue:lif-invalid-CIf. this Fault removed asap i attached the cluster interface."

It'll be seen after upgrade to 6.1(5e). But if older mo config is not there in the new mo config, we are recommending cu to add the missing cluster interface in the lower version itself before doing upgrade. Then we will not see the fault post upgradation and that's the reason current check exists what I feel.

do not consider any fault in this case. You can ignore that. please do repro and test the pre-post upgrade and script.

Yes, have recreated the issue in 5.2(4d) and 5.3(2f) and upgraded to 6.0(5h) and validated the script. I can do the validation one more time by upgrading to 6.1(5e)

lovkeshsharma702 · 2026-06-04T06:24:44Z

 [N9K-C9408 with more than 5 N9K-X9400-16W LEMs][d31] | CSCws82819   | :white_check_mark: | :no_entry_sign:
 [Multi-Pod Modular Spine Bootscript File][d32]  | CSCwr66848   | :white_check_mark: | :no_entry_sign:
 [Inband Management Policy Misconfiguration][d33]| CSCwd40071   | :white_check_mark: | :no_entry_sign:
+[Cleanup vnsRsCIfAtt usage in services][d34]    | CSCwr51759   | :white_check_mark: | :no_entry_sign:


"Check missing vnsRsCIfAttN" ---> change the name

lovkeshsharma702 · 2026-06-04T06:26:49Z

 [d31]: #n9k-c9408-with-more-than-5-n9k-x9400-16w-lems
 [d32]: #multi-pod-modular-spine-bootscript-file
 [d33]: #inband-management-policy-misconfiguration
+[d34]: #cleanup-vnsrscifatt-usage-in-services


"check-missing-vnsRsCIfAttN"

lovkeshsharma702 · 2026-06-04T06:27:23Z


 This check will verify the count of the `svccoreCtrlr` Managed Object and raise and alarm with the bug if object count found more than 240. Remove the content or objects of `svccoreCtrlr` or `svccoreNode`. Contact Cisco TAC or upgrade to a release containing the fix for CSCws84232 before proceeding with an upgrade.

+### Cleanup vnsRsCIfAtt usage in services


change the name accordingly.

lovkeshsharma702 · 2026-06-04T06:27:48Z


+### Cleanup vnsRsCIfAtt usage in services
+
+Due to [CSCwr51759][70], when targeting 6.0(3)+, having only `vnsRsCIfAtt` without the corresponding `vnsRsCIfAttN` under the same `vnsLIf` can leave service graph interface attachment in an inconsistent state.


wrong buug mentioned. Please do the cleanup for bogus info.

when upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf. this will leave service graph interface attachment in an inconsistent state

lovkeshsharma702 · 2026-06-04T06:33:03Z

+
+Impact:
+
+If any `vnsRsCIfAtt` relation exists without a matching `vnsRsCIfAttN` for the same concrete interface target (`tDn`), the upgrade is outage-risky and should be treated as affected.


no need for this ---> If any vnsRsCIfAtt relation exists without a matching vnsRsCIfAttN for the same concrete interface target (tDn), the upgrade is outage-risky and should be treated as affected.

lovkeshsharma702 · 2026-06-04T06:33:38Z

+
+Suggestion:
+
+Before the upgrade, add the missing `vnsRsCIfAttN` relation under the same cluster interface (`vnsLIf`) with the same concrete interface target (`tDn`).


specify the GUI path.. as discussed earlier

lovkeshsharma702 · 2026-06-04T06:34:26Z

        return Result(result=ERROR, msg="Error occurred while fetching svccore object counts: {}".format(str(e)), doc_url=doc_url)


+@check_wrapper(check_title="Cleanup vnsRsCIfAtt usage in services")


change the name accordingly.

lovkeshsharma702 · 2026-06-04T06:34:59Z

+    headers = ["Tenant", "Device Name", "Cluster Interface", "Missing Concrete Interface", "vnsRsCIfAtt DN"]
+    data = []
+    recommended_action = (
+        "Mo vnsRsCIfAtt is deprecated >=6.0(3d). Before upgrade, under Services, add the missing concrete interface as vnsRsCIfAttN under the same cluster interface"


this is not explainatery enough. please work on it.

Updated recommended action with additional details.

lovkeshsharma702 · 2026-06-04T06:37:12Z

+
+    vnsRsCIfAttNs = icurl("class", "vnsRsCIfAttN.json?rsp-prop-include=config-only")
+
+    def get_target_dn(relation_attributes):


look for whole DN, not just Tdn. . this seems wrong to me.
you will see one small diff there for RsCifAtt/RsCifAttN --> make sure you cover this while comparing DN.

Updated by considering full DN.

Harinadh-Saladi

Addressed all the comments

Harinadh-Saladi · 2026-06-04T06:53:29Z

 [N9K-C9408 with more than 5 N9K-X9400-16W LEMs][d31] | CSCws82819   | :white_check_mark: | :no_entry_sign:
 [Multi-Pod Modular Spine Bootscript File][d32]  | CSCwr66848   | :white_check_mark: | :no_entry_sign:
 [Inband Management Policy Misconfiguration][d33]| CSCwd40071   | :white_check_mark: | :no_entry_sign:
+[Cleanup vnsRsCIfAtt usage in services][d34]    | CSCwr51759   | :white_check_mark: | :no_entry_sign:


Harinadh-Saladi · 2026-06-04T06:54:00Z

 [d31]: #n9k-c9408-with-more-than-5-n9k-x9400-16w-lems
 [d32]: #multi-pod-modular-spine-bootscript-file
 [d33]: #inband-management-policy-misconfiguration
+[d34]: #cleanup-vnsrscifatt-usage-in-services


Harinadh-Saladi · 2026-06-04T06:55:15Z


 This check will verify the count of the `svccoreCtrlr` Managed Object and raise and alarm with the bug if object count found more than 240. Remove the content or objects of `svccoreCtrlr` or `svccoreNode`. Contact Cisco TAC or upgrade to a release containing the fix for CSCws84232 before proceeding with an upgrade.

+### Cleanup vnsRsCIfAtt usage in services


Harinadh-Saladi · 2026-06-04T06:59:30Z


+### Cleanup vnsRsCIfAtt usage in services
+
+Due to [CSCwr51759][70], when targeting 6.0(3)+, having only `vnsRsCIfAtt` without the corresponding `vnsRsCIfAttN` under the same `vnsLIf` can leave service graph interface attachment in an inconsistent state.


Harinadh-Saladi · 2026-06-04T07:00:27Z

+
+Impact:
+
+If any `vnsRsCIfAtt` relation exists without a matching `vnsRsCIfAttN` for the same concrete interface target (`tDn`), the upgrade is outage-risky and should be treated as affected.


Harinadh-Saladi · 2026-06-04T07:20:12Z



+@check_wrapper(check_title="Cleanup vnsRsCIfAtt usage in services")
+def vns_rscifatt_cleanup_check(tversion, **kwargs):


Updated name and title

Harinadh-Saladi · 2026-06-04T07:44:07Z

+    headers = ["Tenant", "Device Name", "Cluster Interface", "Missing Concrete Interface", "vnsRsCIfAtt DN"]
+    data = []
+    recommended_action = (
+        "Mo vnsRsCIfAtt is deprecated >=6.0(3d). Before upgrade, under Services, add the missing concrete interface as vnsRsCIfAttN under the same cluster interface"


Updated recommended action with additional details.

Harinadh-Saladi · 2026-06-04T09:44:49Z

+
+    vnsRsCIfAttNs = icurl("class", "vnsRsCIfAttN.json?rsp-prop-include=config-only")
+
+    def get_target_dn(relation_attributes):


Updated by considering full DN.

Harinadh-Saladi · 2026-06-04T09:52:43Z

+        relation_dn = relation_attributes["dn"].strip()
+        if not relation_dn:
+            continue
+        target_dn = get_target_dn(relation_attributes)


Comparison now uses full relation DN instead of tDn and handles rscIfAtt vs rscIfAttN differences before matching.

Harinadh-Saladi · 2026-06-04T11:11:22Z

+            continue
+        missing_dn = old_relation_dn_by_key[relation_key]
+        tenant_name, device_name, logical_interface, concrete_interface = parse_relation_context(missing_dn)
+        data.append([tenant_name, device_name, logical_interface, concrete_interface, missing_dn])


As per below comment added by Lovkesh,

"After doing upgarde from 605h to 615e.

fab3-apic# moquery -c vnsRsCIfAtt | grep dn
fab3-apic# moquery -c vnsRsCIfAttN | grep dn
dn : uni/tn-CSCwj49418/lDevVip-test/lIf-intf-prov/rscIfAttN-[uni/tn-CSCwj49418/lDevVip-test/cDev-cdev/cIf-[prov]]
fab3-apic#

Gui shows cIf-[prov] deleted from concrete device interface.
and fault raised
F1690
Minor
2026-05-29T13:37:55.525+00:00
Raised
uni/tn-CSCwj49418/lDevVip-test/lIf-intf-cons/vnsConfIssue-lif-invalid-CIf
Configuration is invalid due to LIf has an invalid CIf
Config
configuration-failed
ignorable:no, issue:lif-invalid-CIf. this Fault removed asap i attached the cluster interface."

It'll be seen after upgrade to 6.1(5e). But if older mo config is not there in the new mo config, we are recommending cu to add the missing cluster interface in the lower version itself before doing upgrade. Then we will not see the fault post upgradation and that's the reason current check exists what I feel.

lovkeshsharma702 · 2026-06-04T12:45:07Z

        fabric_link_redundancy_check,
        apic_downgrade_compat_warning_check,
        svccore_excessive_data_check,
+        vns_rscifattn_missing_check,


vns_rscifattn_missing_check --> should be vnsrscifattn_missing_check correct it everywhere.

lovkeshsharma702 · 2026-06-04T12:45:57Z

+            continue
+        missing_dn = old_relation_dn_by_key[relation_key]
+        tenant_name, device_name, logical_interface, concrete_interface = parse_relation_context(missing_dn)
+        data.append([tenant_name, device_name, logical_interface, concrete_interface, missing_dn])


do not consider any fault in this case. You can ignore that. please do repro and test the pre-post upgrade and script.

lovkeshsharma702 · 2026-06-04T12:47:24Z


+### Check missing vnsRsCIfAttN
+
+When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf will leave the service graph interface attachment in an inconsistent state


When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted without creating 'vnsRsCIfAttN' under 'vnsLIf' . this leave the service graph interface attachment in an inconsistent state

Updated by correcting a few grammatical errors.

lovkeshsharma702 · 2026-06-04T12:55:47Z

+
+When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf will leave the service graph interface attachment in an inconsistent state
+
+Before the upgrade, in APIC GUI navigate to Tenant > Services > L4-L7 > Device and open cluster interface `intf-prov`. If concrete interface `cons` is missing, re-add concrete interface `cons` under the same cluster interface. so the corresponding `vnsRsCIfAttN` relation exists.


For all impacted Dn in this check, re-attach the Concrete interfaces associated to cluster interface under Devices in Services L4-L7 tab.

Tenant --> Services --> L4-L7 --> Devices (Device_name) --> cluster interface --> Concrete interfaces

Updated by correcting a few grammatical errors.

lovkeshsharma702

please work on given logic.,. validate this in lab again.

Harinadh-Saladi

Yesterday have recreated the issue in 5.3(2f) and validated the script. Enclosed updated script validation logs, pytest and full script run logs

Harinadh-Saladi · 2026-06-05T03:44:39Z


+### Check missing vnsRsCIfAttN
+
+When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf will leave the service graph interface attachment in an inconsistent state


Updated by correcting a few grammatical errors.

Harinadh-Saladi · 2026-06-05T03:45:54Z

+
+When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf will leave the service graph interface attachment in an inconsistent state
+
+Before the upgrade, in APIC GUI navigate to Tenant > Services > L4-L7 > Device and open cluster interface `intf-prov`. If concrete interface `cons` is missing, re-add concrete interface `cons` under the same cluster interface. so the corresponding `vnsRsCIfAttN` relation exists.


Updated by correcting a few grammatical errors.

Harinadh-Saladi · 2026-06-05T03:49:27Z

+            continue
+        missing_dn = old_relation_dn_by_key[relation_key]
+        tenant_name, device_name, logical_interface, concrete_interface = parse_relation_context(missing_dn)
+        data.append([tenant_name, device_name, logical_interface, concrete_interface, missing_dn])


Yes, have recreated the issue in 5.2(4d) and 5.3(2f) and upgraded to 6.0(5h) and validated the script. I can do the validation one more time by upgrading to 6.1(5e)

Harinadh-Saladi · 2026-06-05T03:49:42Z

        fabric_link_redundancy_check,
        apic_downgrade_compat_warning_check,
        svccore_excessive_data_check,
+        vns_rscifattn_missing_check,


Harinadh-Saladi

Addressed the comments and tested in the lab with code changes and enclosed the latest logs

muthu-ku · 2026-06-10T03:17:56Z

+
+        if old_dn.replace("/rscIfAttN-[", "/rscIfAtt-[", 1) in new_dn_keys:
+            continue
+


add this check

if none of vnsRsCIfAtt and vnsRsCIfAttN present. only in case Both of Mo missing attached to given vnsLif—> vnsLIf has NEITHER relation - service graph broken, ask Cu to do manual check warning only

Added manual check warning when both old and new mo config is unavailable.

muthu-ku · 2026-06-10T03:19:22Z

+            old_dn,
+        ])
+
+    data.sort(key=itemgetter(-1))


what is the need of this sort and new library imported?

The above suggested optimized loop logic works functionally, but without sorting it can return rows in different orders based on API/input order. Our Pytest case compares as an ordered list, so it fails intermittently on order only. I added sorting to make pytest stable and output consistent.

Have removed new library imported and replaced with lambda instead.

muthu-ku · 2026-06-10T03:23:59Z

 [d31]: #n9k-c9408-with-more-than-5-n9k-x9400-16w-lems
 [d32]: #multi-pod-modular-spine-bootscript-file
 [d33]: #inband-management-policy-misconfiguration
-


resolve this all removed lines diff

Harinadh-Saladi

Addressed the comments and tested the code with changes in lab and enclosed comprehensive logs.

Harinadh-Saladi · 2026-06-11T03:26:21Z

+            old_dn,
+        ])
+
+    data.sort(key=itemgetter(-1))


The above suggested optimized loop logic works functionally, but without sorting it can return rows in different orders based on API/input order. Our Pytest case compares as an ordered list, so it fails intermittently on order only. I added sorting to make pytest stable and output consistent.

Have removed new library imported and replaced with lambda instead.

Harinadh-Saladi · 2026-06-12T00:57:27Z

+
+        if old_dn.replace("/rscIfAttN-[", "/rscIfAtt-[", 1) in new_dn_keys:
+            continue
+


Added manual check warning when both old and new mo config is unavailable.

…etection

…hyphens

…ile with right title name

muthu-ku · 2026-07-06T07:11:11Z

 [d33]: #inband-management-policy-misconfiguration
-[d34]: #bgpProto-timer-policy-already-existing
-[d35]: #wred-with-affected-fm-models
-[d36]: #n9k-c93180yc-fx3-switch-memory-less-than-32gb


why this links removed?

I think during conflicts resolving, mistakenly got removed. Added back.

muthu-ku · 2026-07-06T07:12:07Z

+@check_wrapper(check_title="Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object")
+def verify_cluster_interface_config_for_rscifatt_use_check(tversion, cversion, **kwargs):
+    result = PASS
+    doc_url = "https://datacenter.github.io/ACI-Pre-Upgrade-Validation-Script/validations/#check-missing-vnsrscifattn"


update the correct doc url.. check-missing-vnsrscifattn is not present in validation.md

Updated the URL after changing the function name.

lovkeshsharma702

looks good to me.

Harinadh-Saladi

Addressed the comments

Harinadh-Saladi · 2026-07-06T07:26:41Z

 [d33]: #inband-management-policy-misconfiguration
-[d34]: #bgpProto-timer-policy-already-existing
-[d35]: #wred-with-affected-fm-models
-[d36]: #n9k-c93180yc-fx3-switch-memory-less-than-32gb


I think during conflicts resolving, mistakenly got removed. Added back.

Harinadh-Saladi · 2026-07-06T07:44:41Z

+@check_wrapper(check_title="Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object")
+def verify_cluster_interface_config_for_rscifatt_use_check(tversion, cversion, **kwargs):
+    result = PASS
+    doc_url = "https://datacenter.github.io/ACI-Pre-Upgrade-Validation-Script/validations/#check-missing-vnsrscifattn"


Updated the URL after changing the function name.

lovkeshsharma702

All test passed.

…eneral check

monrog2

please triple check that the number of API requests being asked for here are the smallest dataset that we need to perform this check.

if they are indeed switch objects, we will not be able to requests them on the intersight side.

if there is a scale fabric with these obejcts, how long does this take to run? the old VLAN validation check had to be removed due to time it took to complete, so i'm worried this one will have similar results.

monrog2 · 2026-07-20T14:15:13Z

+        recommended_action = "Please review the concrete interface attachments under the flagged device cluster interfaces and reattach them using the UI: Tenant → Services → L4-L7 → Devices → Cluster Interface → Concrete Interface → + → Select the respective interface from the drop-down list → Submit"
+    else:
+        headers = ["Tenant", "Device Name", "Cluster Interface", "Missing Concrete Interface", "vnsRsCIfAtt DN"]
+        recommended_action = "Please reattach concrete interfaces again using the UI (without deleting the existing attachment objects): Tenant → Services → L4-L7 → Devices → Cluster Interface → Concrete Interface → + → Select the respective interface from the drop-down list → Submit"


Workaround details/clarity should be documented directly within the bug Release note. The script should never be the source of truth, if a bug or FN is at play, that should always be the SSOT and the script can pull out snips from it as required for flesh out the result.

monrog2 · 2026-07-20T14:17:11Z

+    ldev_ctx_query = (
+        "vnsLDevCtx.json?rsp-prop-include=config-only"
+        "&rsp-subtree=full"
+        "&rsp-subtree-class=vnsLIfCtx,vnsRsLIfCtxToLIf"
+        "&rsp-subtree-include=required"
+    )


this is a switch object? and we are pulling subtree.

have we been able to test this on a scale fabric and what are the implications of the response time?

monrog2 · 2026-07-20T14:18:35Z

+            ):
+                continue
+        elif not contract or not graph:
+            continue  # Fallback mode: skip incomplete contexts


# Fallback mode: skip incomplete contexts

Can this logic be applied directly within the API call? I see that rsp-subtree-include=required is being used above to so some first level 'if filtering, is there another point where similar could be applied?

monrog2 · 2026-07-20T14:20:41Z

+    sg_data = []
+    has_implicit_objects = False
+    for lif_dn in sorted(lif_dns):
+        lif_query = "{}.json?query-target=subtree&target-subtree-class=vnsRsCIfAttN&rsp-prop-include=config-only".format(lif_dn)


this will cascade out even further per DN identified

monrog2 · 2026-07-20T14:23:42Z

+    if tversion.older_than("6.0(3d)"):
+        return Result(result=NA, msg=VER_NOT_AFFECTED, doc_url=doc_url)
+
+    post_upgrade = bool(cversion and (cversion.same_as("6.0(3d)") or cversion.newer_than("6.0(3d)")))


post_upgrade actually means version_with_new_obj?

we already defined POST within this script as a result when a check needs to be re-run POST APIC upgrade, before switch upgrade.

monrog2 · 2026-07-20T14:27:41Z

 [APIC downgrade compatibility when crossing 6.2 release][g19]| :white_check_mark: | :no_entry_sign:
 [Supported Hardware Compatibility][g20]                      | :white_check_mark: | :no_entry_sign:
 [Svccore Excessive Data Check][g21]                          | :white_check_mark: | :no_entry_sign:
+[Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object][g22]                            | :white_check_mark: | :no_entry_sign:


simple names please.
something like:
vnsRsCIfAtt deprecation check

Also if there are multiple bug IDs at play, we should include them in teh documentation.

deprecation of vnsRsCIfAtt is not CSCwr51759. Which ID is for that?

monrog2 · 2026-07-20T14:30:40Z

 Contact Cisco TAC for next steps. For more details, refer to the workaround in [CSCwt69100][75].

+### Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object
+


Simplify the source of the problem:

vnsRsCIfAtt is officially deprecated (is this documented in a release note?) as of 6.0(3).

The 'new' object for this, vnsRsCIfAttN has been supposed as of 5.x (get this version).

This check scans your objects for ysage of the deprecated object, and if found, warns the user that they must migrate their config to the newly supported object.

Failure to do so can result in an outage of the service graph... etc etc.

ensure that we have docs/external bugs to back up all claims above.

monrog2 · 2026-07-20T14:31:11Z

        fabric_link_redundancy_check,
        apic_downgrade_compat_warning_check,
        svccore_excessive_data_check,
+        verify_cluster_interface_config_for_rscifatt_use_check,


simplify check name/function name

monrog2 · 2026-07-20T14:32:15Z

+            return Result(result=FAIL_O, msg=msg, headers=headers, data=[[r[0], r[1], r[2]] for r in sg_data], recommended_action=recommended_action, doc_url=doc_url)
+        return Result(result=PASS, msg="All deployed service graph interfaces have vnsRsCIfAttN.", doc_url=doc_url)
+
+    # Pre-upgrade: fetch both relation object classes for further checks


pre_upgrade is a misnomer, this means version_not _having_new_object.

monrog2

Additional findings beyond my previous review:

monrog2 · 2026-07-21T15:28:16Z

+            sg_data.sort(key=lambda r: r[-1])
+            msg = "Graph is rendered with implicit objects" if has_implicit_objects else "vnsRsCIfAttN is missing under deployed L4-L7 cluster interfaces."
+            return Result(result=FAIL_O, msg=msg, headers=headers, data=[[r[0], r[1], r[2]] for r in sg_data], recommended_action=recommended_action, doc_url=doc_url)
+        return Result(result=PASS, msg="All deployed service graph interfaces have vnsRsCIfAttN.", doc_url=doc_url)


[Blocking] Please do not return PASS solely because every deployed LIF has vnsRsCIfAttN. For current versions 6.2(3)+, the CSCwr51759 release-note content recommends removing deprecated vnsRsCIfAtt objects when a matching vnsRsCIfAttN exists, but this branch never queries the old class, so that state silently passes. Please add explicit handling and regression coverage for it. Before deciding the exact result and recommended action, we need Development signoff on whether these old objects must be cleaned up on 6.2(3)+, or whether the risk of leaving them is minimal enough to allow the check to pass; please document the decision and its authoritative source.

monrog2 · 2026-07-21T15:28:16Z

+                for contract_name in (contract, contract_without_prefix)
+                for graph_name in (graph, graph_base_name)
+            ):
+                continue


[Medium] Please include tenant identity when correlating applied graphs. graph_keys retains only contract and graph names, so if tenant A has an applied graph and tenant B reuses the same names, tenant B's context is also treated as deployed and can produce a false FAIL_O with unnecessary reattachment guidance. Please key the correlation by tenant as well as contract/graph name, preserve the intended imported/common-tenant behavior, and add a duplicate-name-across-tenants regression test.

muthu-ku reviewed Jun 2, 2026

View reviewed changes

Comment thread aci-preupgrade-validation-script.py

muthu-ku reviewed Jun 2, 2026

View reviewed changes

lovkeshsharma702 reviewed Jun 4, 2026

View reviewed changes

lovkeshsharma702 suggested changes Jun 4, 2026

View reviewed changes

Harinadh-Saladi commented Jun 4, 2026

View reviewed changes

lovkeshsharma702 reviewed Jun 4, 2026

View reviewed changes

lovkeshsharma702 suggested changes Jun 4, 2026

View reviewed changes

Harinadh-Saladi changed the title ~~New validation for CSCwr51759 Cleanup vnsRsCIfAtt usage in service~~ New validation for missing vnsRsCIfAttN Jun 5, 2026

Harinadh-Saladi commented Jun 5, 2026

View reviewed changes

muthu-ku reviewed Jun 5, 2026

View reviewed changes

Comment thread docs/docs/validations.md

muthu-ku reviewed Jun 5, 2026

View reviewed changes

Comment thread ...config_for_rscifatt_use_check/test_verify_cluster_interface_config_for_rscifatt_use_check.py

muthu-ku reviewed Jun 5, 2026

View reviewed changes

Comment thread aci-preupgrade-validation-script.py

Harinadh-Saladi commented Jun 5, 2026

View reviewed changes

Comment thread docs/docs/validations.md

Comment thread ...config_for_rscifatt_use_check/test_verify_cluster_interface_config_for_rscifatt_use_check.py

Comment thread aci-preupgrade-validation-script.py

muthu-ku reviewed Jun 10, 2026

View reviewed changes

Comment thread aci-preupgrade-validation-script.py

muthu-ku reviewed Jun 10, 2026

View reviewed changes

Harinadh-Saladi commented Jun 12, 2026

View reviewed changes

Harinadh-Saladi added 12 commits July 3, 2026 05:34

New validation for CSCwr51759

b892413

Updated validations.md

371cf75

Addressed the review comments

b216729

Addressed the review comments

3b9654c

Updated check name in all the places

ddde9ad

Addressed review comments

1774d91

Addressed new comments

643d553

Added new scenarios with respect to service graph missing interface d…

2f9033d

…etection

Addressed review comments

be39aa3

Addressed Dev review comments

e81c3bd

Addressed the review comments

74acfe9

Addressed dev comments on contract and interface names with multiple …

c217115

…hyphens

Harinadh-Saladi force-pushed the feature/vns-rscifatt-cleanup-check branch from 08d7fef to c217115 Compare July 3, 2026 05:41

Harinadh-Saladi added 5 commits July 3, 2026 06:03

Rebased the code with latest changes by resolving merge conflicts

0da4087

Modified variable names with meaningful variable names

df5f5cb

Updated general check name

de1e487

Removed function name under bugs section and updated validations.md f…

24d00e8

…ile with right title name

Addressed Dev comments and modified variable names with meaningful names

697dee0

muthu-ku reviewed Jul 6, 2026

View reviewed changes

Comment thread docs/docs/validations.md Outdated

muthu-ku reviewed Jul 6, 2026

View reviewed changes

Comment thread aci-preupgrade-validation-script.py

lovkeshsharma702 approved these changes Jul 6, 2026

View reviewed changes

Addressed review comments

2538b2b

Harinadh-Saladi commented Jul 6, 2026

View reviewed changes

lovkeshsharma702 approved these changes Jul 6, 2026

View reviewed changes

Removed the bug link added earlier for this check, as it's added as g…

148d0ac

…eneral check

lovkeshsharma702 approved these changes Jul 6, 2026

View reviewed changes

monrog2 requested changes Jul 20, 2026

View reviewed changes

monrog2 requested changes Jul 21, 2026

View reviewed changes



		@check_wrapper(check_title="Cleanup vnsRsCIfAtt usage in services")
		def vns_rscifatt_cleanup_check(tversion, **kwargs):


		Impact:

		If any `vnsRsCIfAtt` relation exists without a matching `vnsRsCIfAttN` for the same concrete interface target (`tDn`), the upgrade is outage-risky and should be treated as affected.


		This check will verify the count of the `svccoreCtrlr` Managed Object and raise and alarm with the bug if object count found more than 240. Remove the content or objects of `svccoreCtrlr` or `svccoreNode`. Contact Cisco TAC or upgrade to a release containing the fix for CSCws84232 before proceeding with an upgrade.

		### Cleanup vnsRsCIfAtt usage in services


		### Cleanup vnsRsCIfAtt usage in services

		Due to [CSCwr51759][70], when targeting 6.0(3)+, having only `vnsRsCIfAtt` without the corresponding `vnsRsCIfAttN` under the same `vnsLIf` can leave service graph interface attachment in an inconsistent state.


		Suggestion:

		Before the upgrade, add the missing `vnsRsCIfAttN` relation under the same cluster interface (`vnsLIf`) with the same concrete interface target (`tDn`).

		return Result(result=ERROR, msg="Error occurred while fetching svccore object counts: {}".format(str(e)), doc_url=doc_url)


		@check_wrapper(check_title="Cleanup vnsRsCIfAtt usage in services")


		vnsRsCIfAttNs = icurl("class", "vnsRsCIfAttN.json?rsp-prop-include=config-only")

		def get_target_dn(relation_attributes):


		### Check missing vnsRsCIfAttN

		When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf will leave the service graph interface attachment in an inconsistent state


		When upgrading to 6.0(3) and above, 'vnsRsCIfAtt' get deleted and without creating the corresponding 'vnsRsCIfAttN' under the same vnsLIf will leave the service graph interface attachment in an inconsistent state

		Before the upgrade, in APIC GUI navigate to Tenant > Services > L4-L7 > Device and open cluster interface `intf-prov`. If concrete interface `cons` is missing, re-add concrete interface `cons` under the same cluster interface. so the corresponding `vnsRsCIfAttN` relation exists.


		if old_dn.replace("/rscIfAttN-[", "/rscIfAtt-[", 1) in new_dn_keys:
		continue

		Contact Cisco TAC for next steps. For more details, refer to the workaround in [CSCwt69100][75].

		### Verifying Cluster Interface Configuration For Deprecated RsCIfAtt Object

Uh oh!

Conversation

Harinadh-Saladi commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

muthu-ku Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lovkeshsharma702 Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Harinadh-Saladi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Harinadh-Saladi commented Jun 1, 2026 •

edited

Loading

muthu-ku Jun 2, 2026 •

edited

Loading

lovkeshsharma702 Jun 4, 2026 •

edited

Loading

lovkeshsharma702 Jun 4, 2026 •

edited

Loading