Unused config on Fabric switches

[hassan_yousif2005]

If we make changes in DNAC there will be some unused configurations left on fabric switches even after provisioning those switches . For example if we assigned an IP pool to a VN then an SVI corresponding to that pool will be created on all edge switches . But if we removed that pool from the VN, the SVI will still remain on all switches .

If we add a new switch to the fabric and provision it then it will be configured by the current DNAC settings and it will not have an SVI corresponding to that IP pool which has been removed from the VN . At the end we have old switches have that SVI and the new switch doesn't have it .

Is there any way to have switches config clean up and sync all fabric switches configurations.

Thanks in advance 

[ldanny · Accepted solution]

This should not be the case.

When IP Pool is removed from VN the SVI should be removed from FE.

I recommend opening a ticket with TAC to further troubleshoot.

Have tried to remove the VN after removing the IP Pool?

[hassan_yousif2005]

Hello Idanny and thanks for your input.

No I haven't deleted the VN , just removed the IP pool from it . 

I will open the TAC case but in this situation what would be the expected issues when the SVI is not removed from FE after removing the IP pool from the VN.

Thanks

[Mike.Cifelli]

I agree with @ldanny.  That behavior is very odd.

I can tell you that from my experience over the last 1.5 years running an SDA fabric that I have experienced the following scenario: Skipping some detail, but here is the overview:

Create and assign a new IP pool to VN <whatever>, DNAC then provisions the new vlan/SVI/etc. Then you decide you no longer need or want to use that pool so you remove it in DNAC from the VN assignment, etc.  DNAC then removes the vlan/SVI on fabric edge devices.  Then the next go round of deploying a new pool, DNAC skips the previously used vlan id and assigns the next one in line.  For example, if 1029 was originally used, then removed, DNAC will skip 1029 (even though it is available) and deploy 1030.  We have had discussions with Cisco BU folks and were advised that DNAC will continue to loop through and deploy vlans, and once done it will start back over and eventually use 1029 again (obviously skipping the default critical/voice/AP vlan ids & the 3000 series that gets used for EBN connectivity to FRs).  Apparently this is normal behavior.  HTH!

[hassan_yousif2005]

Thanks Mike

In my case if I removed the IP pool  from the VN then the vlan/SVI 1059  stays there on the switch . Its status is up/down .

If I added the same pool to a different VN and provision the switch then I have a new vlan/SVI vlan1060 with the same IP in the new VN . So I have the same IP address assigned to two different SVIs in different VNs.

I got below error when the IP pool assigned to the different VN

 Internal error, Lisp CB bad context 0x7F8787F090F8                                     control", ipl= 0, pid= 603
-Traceback= 1#382e63cec4f976e0e9944c03c8de18e9  iosd_shr_m_uk9_IPV6_Core_crb:7F886D5C7000                                    hr_m_uk9_LISP_Core_crb:7F886ACD1000+59379F iosd_shr_m_uk9_LISP_Core_crb:7F886ACD1000+5934                                    6ACD1000+593069 :5616F37CF000+40DF955 iosd_shr_m_uk9_IPV6_Core_crb:7F886D5C7000+2FC74F :5                                    ISP_Core_crb:7F886ACD1000+59379F iosd_shr_m_uk9_LISP_Core_crb:7F886ACD1000+59344E iosd_sh                                    93069**MSG 00003 TRUNCATED**
**MSG 00003 CONTINUATION #01** iosd_shr_m_uk9_LISP_Core_crb:7F886ACD1000+5931C2 iosd_shr_                                    FC9 iosd_shr_m_uk9_LISP_Core_crb:7F886ACD1000+4768F2 iosd_shr_m_uk9_LISP_Core_crb:7F886AC  

Thanks