Showing results for 
Search instead for 
Did you mean: 

Fabric interface change


Hi all,

we were on APIC ver. 4.2(5) and upgraded to 4.2(7), but after upgrade we could not

change interface description anymore as we did before:

Fabric – Inventory - <Pod> - <Leaf-Switch> - Interface – physical interface - <Interface>

as soon as l change anything in Description-Feld  the „Submit"-Button is active, but when l click nothing goes...

we could change Interface-Description this way:

„Fabric – Access Policies – Interfaces – Leaf Interfaces – Overrides

did anything changed or we should do it another way ?


6 Replies 6

Robert Burns
Cisco Employee
Cisco Employee

I tested this on both 5.2(2) and 4.2(7f) and it worked as expected. 

Two things to try. Change the description from CLI.  If this works, then its a UI/Browser issue on your hands and I'd suggest you try a different browser and/or clearing your cache.



it works from CLI, but it does not when we change the browser or PC.

Also if the interface description was not configured before upgrade , now after upgrade we can change description.


Hi @BorislavPenchev0962 ,

[Edit:2012.12.07 - after heading down this rabbit-hole, I wrote a blog post that tells the story better. Your favourite search engine should find it.]

The Interface Description is a WEIRD attribute - the path you described to access the description: 

Fabric – Inventory - <Pod> - <Leaf-Switch> - Interface – physical interface - <Interface>

is very confusing.  In fact this is a kludge that Cisco added to put a description on an interface - and when you add a description here it does some weird stuff!


I'll show you what I mean in pictures

This is a picture from our lab showing a description on an interface of APIC1


Note particularly the DN of this interface (in the URI): topology/pod-1/node-1201/sys/phys-[eth1/1]

A quick look in the object browser shows that it is indeed the description of the interface:


Now let me add a description the way YOU described on interface 1/2 (which, BTW should work - clear your cache is probably the best idea as @Robert said)


And sure enough, it turns up as the description in the object store


So far, so good

BUT - this is where the weird stuff begins!

When I look in the other location you mentioned:

Fabric – Access Policies – Interfaces – Leaf Interfaces – Overrides

I see a NEW override has been created - AND given a name automatically (which BTW does NOT comply with MY naming standards)


Did you notice that there is NO override for the first interface I showed you - the one with the APIC1 description?

SO what's going on here?

To explore this, let's see what happens if I delete the override:


And - WOULD YOU BELIEVE IT? The description has gone from the Inventory path as well! (And of course the object browser shows the description value removed as well)


Now this is just Soooooooo weird - I have NO IDEA why Cisco's UI designers have decided that these two attributes need to be linked.

But - this just raises another question

How can a description (APIC1) exist on interface Eth1/1 WITHOUT having an Override?

The answer to this points to yet another Cisco kludge.

It turns out that IF you add a description to the Port Block of the Interface Selector that belongs to the Leaf Profile for that interface, (uni/infra/accportprof-IntProfName/hports-IntSelectorName-typ-range/portblk-blockn)...


...then the description is also copied to the interface properties (topology/pod-n/node-nnn/sys/phys-[ethn/n])

And THAT is how the APIC1 description was actually assigned to the interface description.


IF you add a description via Fabric > Inventory ... then an unwanted Leaf Interface Override is created and the description ALSO added there.


IF you create your own Leaf Interface Override policy for a particular interface and add a description, it is copied to the Physical Interface Description

IF you change either one of these descriptions, the other entry is also updated. It seems they are linked somehow, except...

IF you add a description to to the Port Block of the Interface Selector that belongs to the Leaf Profile for an interface,

THEN the description is also copied to the interface properties BUT ONLY IF THERE IS NOT AN OVERRIDE in place!

  • Future changes to the Port Block of the Interface Selector that belongs to the Leaf Profile for an interface are also reflected in the Physical Interface Description, BUT ONLY IF THERE IS NOT AN OVERRIDE in place
    • [Sidenote: If you make a change to the Port Block of the Interface Selector that belongs to the Leaf Profile, and after you click on Submit, you'll see the Nodes using this policy message, and if you click on the node, then on the interface...image.png... you'll see that the system TELLS you that the physical interface is affected, BUT the description DOES NOT change even after you hit Submit
  • Future changes to the Physical Interface  description ARE NOT reflected back in the Port Block of the Interface Selector that belongs to the Leaf Profile - instead, changing the Physical Interface description creates that pesky override again.

I haven't tried editing the interface description directly using Postman or by pushing a JSON/XML file, but I suspect that even if I did, the pesky Interface Override would also get created.

[Edit 2021.12.07 I DID try using Postman - and indeed, the Override also got created]


RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.

thank you for detailed check and to @Robert Burns as well

- tried over different browsers and machines PC/MAC with the same result as before ...

- we noticed that if interface had previously configured description on 4.2.5 - under 4.2.7 we experience this problem,

- if interface description was not configured under 4.2.5 - now under 4.2.7 we can configure it and even change description as many times we want;


 will try to change it from CLI and report



change from CLI worked , but change from other browser or other machine does not work ? would that be good to go to Cisco TAC ?

Yes.  I'd suggest including a set of APIC support logs with your SR and a quick recording of the issue. This will give them most of what they'll need to investigate.  Provide version info and timestamps when you're attempting to make the changes so they can isolate the appropriate logs quickly.


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers