New validation for missing vnsRsCIfAttN 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 to detect missing vnsRsCIfAttN relations for existing vnsRsCIfAtt entries under the same cluster interface and target concrete interface.

Enclosed comprehensive logs for the same.

vns_rscifattn_missing_check_Test_Logs.txt

vns_rscifattn_missing_check_Pytest_Logs.txt

Full_script_run_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:03Z

+            continue
+        relation_attributes = vnsRsCIfAttN["vnsRsCIfAttN"]["attributes"]
+        if "dn" not in relation_attributes:
+            continue


when mo is not configured, vnsRsCIfAttNs will be empty.. above if conditions not needed.

Removed if conditions already when mo is not configured

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,


muthu-ku · 2026-06-05T04:37:32Z


 To avoid this issue, change the target version to another version. Or verify that the `bootscript` file exists in the bootflash of each modular spine switch prior to upgrading to 6.1(4h). If the file is missing, you have to do clean reboot on the impacted spine to ensure that `/bootflash/bootscript` gets created again. In case you already upgraded your spine and you are experiencing the traffic impact due to this issue, clean reboot of the spine will restore the traffic.

-


remove unwanted new lines

Removed unwanted lines at line numbers 43 and 210

muthu-ku · 2026-06-05T05:15:54Z

+        (
+            {
+                vnsRsCIfAtt_api: read_data(dir, "vnsRsCIfAtt_match.json"),
+                vnsRsCIfAttN_api: read_data(dir, "vnsRsCIfAttN_missing_cons.json"),


add case for empty vnsRsCIfAttN.

Added test case for empty vnsRsCIfAttN scenario

muthu-ku · 2026-06-05T05:20:19Z

+    old_relation_dn_by_key = {}
+    for vnsRsCIfAtt in vnsRsCIfAtts:
+        if "vnsRsCIfAtt" not in vnsRsCIfAtt:
+            continue


Can you try this optimized script.

new_dn_keys = set()
for new_no in vnsRsCIfAttNs:
try:
dn = new_no["vnsRsCIfAttN"]["attributes"]["dn"].strip()
except (KeyError, TypeError, AttributeError):
continue
if dn:
new_dn_keys.add(dn.replace("/rscIfAttN-[", "/rscIfAtt-[", 1))

for old_mo in vnsRsCIfAtts:
try:
old_dn = old_mo["vnsRsCIfAtt"]["attributes"]["dn"].strip()
except (KeyError, TypeError, AttributeError):
continue
if not old_dn:
continue

if old_dn.replace("/rscIfAttN-[", "/rscIfAtt-[", 1) in new_dn_keys: continue match = re.search( r"uni/tn-(?P<tenant>[^/]+)/lDevVip-(?P<device>[^/]+)/lIf-(?P<lif>[^/]+)/" r"rscIfAtt-\[.*?/cIf-\[(?P<cif>[^\]]+)\]\]", old_dn, ) data.append([ match.group("tenant") if match else "", match.group("device") if match else "", match.group("lif") if match else "", match.group("cif") if match else "", old_dn, ])

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.

Harinadh-Saladi

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

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


 To avoid this issue, change the target version to another version. Or verify that the `bootscript` file exists in the bootflash of each modular spine switch prior to upgrading to 6.1(4h). If the file is missing, you have to do clean reboot on the impacted spine to ensure that `/bootflash/bootscript` gets created again. In case you already upgraded your spine and you are experiencing the traffic impact due to this issue, clean reboot of the spine will restore the traffic.

-


Removed unwanted lines at line numbers 43 and 210

Harinadh-Saladi · 2026-06-05T05:46:45Z

+        (
+            {
+                vnsRsCIfAtt_api: read_data(dir, "vnsRsCIfAtt_match.json"),
+                vnsRsCIfAttN_api: read_data(dir, "vnsRsCIfAttN_missing_cons.json"),


Added test case for empty vnsRsCIfAttN scenario

Harinadh-Saladi · 2026-06-05T10:05:55Z

+    old_relation_dn_by_key = {}
+    for vnsRsCIfAtt in vnsRsCIfAtts:
+        if "vnsRsCIfAtt" not in vnsRsCIfAtt:
+            continue


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.

muthu-ku · 2026-06-10T03:16:45Z

+    if not tversion:
+        return Result(result=MANUAL, msg=TVER_MISSING, doc_url=doc_url)
+
+    if tversion.older_than("6.0(3d)"):


Add cversion check
current code is pre-6.0.3

As discussed, cversion check is not required. When we are providing tversion as 6.0(3) and above if both old mo and new mo are not configured then we are alerting the customer with recommended action. This is equivalent by checking the cversion <6.0(3) and verifying the old and new mo config unavailability and alerting the customer.

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:22:53Z

+            continue
+        relation_attributes = vnsRsCIfAttN["vnsRsCIfAttN"]["attributes"]
+        if "dn" not in relation_attributes:
+            continue


Removed if conditions already when mo is not configured

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:56:28Z

+    if not tversion:
+        return Result(result=MANUAL, msg=TVER_MISSING, doc_url=doc_url)
+
+    if tversion.older_than("6.0(3d)"):


As discussed, cversion check is not required. When we are providing tversion as 6.0(3) and above if both old mo and new mo are not configured then we are alerting the customer with recommended action. This is equivalent by checking the cversion <6.0(3) and verifying the old and new mo config unavailability and alerting the customer.

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.

Harinadh-Saladi added 2 commits June 1, 2026 17:45

New validation for CSCwr51759

46f4dfe

Updated validations.md

b9570ad

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

Addressed the review comments

a9a1a69

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

Addressed the review comments

c3e9dcc

Harinadh-Saladi commented Jun 5, 2026

View reviewed changes

Updated check name in all the places

99ccead

muthu-ku reviewed Jun 5, 2026

View reviewed changes

Addressed review comments

7112c53

Harinadh-Saladi commented Jun 5, 2026

View reviewed changes

muthu-ku reviewed Jun 10, 2026

View reviewed changes

Addressed new comments

4e493ad

Harinadh-Saladi commented Jun 12, 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.


		To avoid this issue, change the target version to another version. Or verify that the `bootscript` file exists in the bootflash of each modular spine switch prior to upgrading to 6.1(4h). If the file is missing, you have to do clean reboot on the impacted spine to ensure that `/bootflash/bootscript` gets created again. In case you already upgraded your spine and you are experiencing the traffic impact due to this issue, clean reboot of the spine will restore the traffic.


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

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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

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