Discussion: Cisco ACI UI Inconsistencies. Please Contribute

[RedNectar]

Hello community,

This is NOT a post to complain about bugs or missing features, but an attempt to document as many NAMING inconsistencies as practical in the Cisco ACI APIC UI (NOT the MSO UI).

But I'd be happy for as many people as possible could contribute,

This post has come about in response to Robert Burns in an earlier thread, so I'll start with the UI inconsistency I mentioned in that thread, but first, some...

---

Ground Rules

1. Actual object name:
   I'm defining the object name as the name that is used when a user creates an object - even though I realise that objects can often be created in different ways and be given different names depending where the object is created.
   • In some cases it might be worth referring to the actual class name of the object as well
2. Screen Dumps:
   Please add screen dumps where possible - preferably pasted into the text (please DON'T use that stupid Drag and Drop thing - just click the Camera icon above and click in the grey area, then it Ctrl+v (or Cmd+v) to paste.

---

Leaf Interface Profile (infraAccPortP)

Created in Fabric>Access Policies>Interfaces>Leaf Interfaces>Profiles>+Create Leaf Interface Profile

This object is WRONGLY referred to as an Interface Selector Profile in the following places:

1. When viewing a Leaf Profiles: Fabric>Access Policies>Switches>Leaf Switches>Profiles>LeafProfileName
   
   
2. When creating a Leaf Profile: Fabric>Access Policies>Switches>Leaf Switches>Profiles>+Create Leaf Profile
   

Note: More on Access Module Profiles later...

---

Spine Interface Profile (infraSpAccPortP)

Created in Fabric>Access Policies>Interfaces>Spine Interfaces>Profiles>+Create Spine Interface Profile

This object is WRONGLY referred to as an Interface Selector Profile in the following places:

1. When viewing a Spine Profiles: Fabric>Access Policies>Switches>Spine Switches>Profiles>SpineProfileName
   
   
2. When creating a Spine Profile: Fabric>Access Policies>Switches>Spine Switches>Profiles>+Create Spine Profile
   

---

Inconsistency between Spine Profiles and Leaf Profiles 

I actually find the fact that I can select an Access Module Profile when creating a LEAF Profile but NOT when creating a SPINE profile quite amusing - given that Modular Switches CAN'T BE USED as Leaf switches, only SPINE switches. Perhaps Cisco got these dialogues the wrong way around?

In fact, the whole menu structure that only gives me a choice of Leaf Modules (when AFAIK NO such SKU exists - try dong a google search for buy cisco aci "Leaf Module" and see how many are for sale!!!!!)

---

Rinse and Repeat

The points noted above are repeated in the equivalent Fabric Policies ...

Fabric>Fabric Policies>Switches>Leaf Switches>Profiles>LeafSwitchProfileName

Fabric>Fabric Policies>Switches>Leaf Switches>Profiles>+Create Leaf Switch Profile

Fabric>Fabric Policies>Switches>Spine Switches>Profiles>SpineSwitchProfileName

Fabric>Fabric Policies>Switches>Spine Switches>Profiles>+Create Spine Switch Profile

...but with a completely new set of inconsistencies!  Now we see Switch Associations replacing Leaf Selectors (why?) and Interface Associations replacing Interface Selector Profiles (possibly less confusing, but not accurate) and similarly  Module Associations replacing Module Selector Profiles 

---

That's enough to begin with. Already I've spent too much time on this. Cisco has had 5 years to get this right, and I only have so much time I'm prepared to give for free. I'll probably add more later, but over to the community for now

KEEP READING - THERE ARE MANY MORE BELOW THIS

[RedNectar]

Not so much an inconsistency as an annoyance.

---

When you right-click on an object in the APIC GUI and choose Save As... the default options for saving are:

Content: All Properties
Scope: Self
Export Format: xml

---

Now, for most purposes, these defaults are USELESS - all you get it the base object with timestamps - and there's no way you can post the default format back.

The Default options SHOULD be:

Content: Only Configuration
Scope: Subtree
Export Format: xml or json (I prefer JSON, and anyone who is going to write python code would also probably prefer JSON)

If these become the defaults, then it will be MUCH easier to download configs and post them back - except for one more little annoyance that comes when you right-click on an object in the APIC GUI and choose Post

---

The Annoying part about this is that the default Parent DN is based on where the right-click was pressed - which almost NEVER where you want it to be pasted.

---

A default Parent DN of uni/ would be much more useful

[RedNectar]

In ACI, when creating a Bridge Domain, there is a Forwarding option that allows me to define as a group a set of forwarding behaviours. I can set the Forwarding option to Optimize or Custom.  The default is Optimize, and optimised forwarding  sets these values:

Option	Possible values, default bolded
L2 Unknown Unicast:	Hardware Proxy, Flood
L3 Unknown Multicast Flooding:	Flood, Optimized Flood
Multi Destination Flooding:	Flood in BD, Drop, Optimized Flood
ARP Flooding	Enabled -If created using the API or the GUI drag 'n drop method Disabled - If created using GUI right-click method

---

I call on the ACI developers to remove the Forwarding option from the Create Bridge Domain dialogue and replace it with the four hidden options they define. 

Or at the very least, be consistent with default values.

---

There are three main reasons for this:

1. Having different default values for these options depending on which method is used to create them IS JUST DOWNRIGHT CONFUSING
2. Since ACI v4.2, the meaning of the option has been changed, adding even more confustion. See this discussion on the community forum.
3. If I select Custom, then change any of these defaults, then re-select Optimize, none of the options return to the default "optimised" values - again making the option confusing.

[KELLEYD]

Somewhat related:

• L3 Unknown Multicast Flooding - Default should be Optimized Flood.
• IPv6 Unknown Multicast Flooding - Same. At the very least, should be configurable from the wizard, consistent with the v4 option.
• Is it necessary anymore? First-gen switches are no longer supported in 5.x and up, right?

[RedNectar]

Is ARP flooding a L2 or L3 property?

Yet another call for consistency.

When I create a Bridge Domain (using the right-click method), the ARP Flooding option appears as part of my L3 configuration during the creation process.

Similarly, if I use the "Drag-and-drop" method to create a bridge domain, ARP Flooding is part of the L3 configuration (albeit with a DIFFERENT default value as mentioned previously)

But once configured, irrespective of the method used, ARP Flooding disappears from the L3 Configuration. IT'S GONE!

Oh hold on - it's back here under "General"

For goodness sake Cisco, give us consistency. I don't CARE if it is L2/General or L3 - I JUST WANT CONSISTENCY

[RedNectar]

This is somewhat cosmetic, but I'll add it to the list as "low priority"

It never looks good when a global business company starts using coloquial language in applications.  This dialogue that appeared when I upgraded a lab fabric with one spine takes the cake!

I guess I can handle the "Watch out!" heading. But "Continue Anyways" - come on - was this page designed by a high-school work-experience student?

[RedNectar]

Not so much as an inconsistency, but a deviation from every other known normal system.

I'm talking about the default area type when creating a L3Out

SURELY the default area type SHOULD be Regular Area, NOT NSSA.

My gut feeling this is simply a hang-over from about 5 years ago when the ONLY type of OSPF are supported was NSSA. It's just that no-body has though "Oh, let's make this easier for users and change the default to something much more likely".

I'm suggesting that it's time someone had that thought!

[RedNectar]

Another inconsistency with every other thing that has been taught in routing until now is the use of the words Subnet when configuring L3Outs and even more out of line is the fact that you are asked to assign an IP address to this "Subnet" . (Objects of class l3extSubnet) Tenants>TenantName>Switches>Networking>L3Outs>L3OutName>External EPGs>ExternalEPGName>Subnets

Any networking engineer cringes whenever they see this rookie mis-use of the word "Subnet" and even more so at having to enter it under the heading "IP Address"

These objects are prefixes. I've spent 20 years teaching engineers the difference between a subnet, a route, and a prefix, and then I see this -HOW ON EARTH CAN I SERIOUSLY THINK CISCO UNDERSTANDS NETWORKING WHEN THIS SCREEN APPEARS?

 Here, I've designed a new page for you

And one more place here.  Seeing 0.0.0.0/0 listed as a SUBNET is just so wrong it makes my skin crawl

[Sergiu.Daniluk]

Chris, one thing which comes to my mind while seeing this specific post about subnets/ip address/prefixes, is what would happen with the MO classes and attributes IF cisco decides to correct this words.

For example, each line under "subnets" is a l3extSubnet class and the "Ip address" is an attribute called "ip".

If the GUI wording will change, then surely at least the attributes name should change, otherwise there will be this inconsistency between UI and underlying MO. But if attributes change, or even worse the classes, then it will break any scripts/automation tools made by anyone beforehand. So to me it looks like this will be an impossible task.

Cheers,

Sergiu 

[RedNectar]

Hi @Sergiu.Daniluk ,

Changing MOs is a MUCH bigger deal than changing the wording on the user screens.  I think we'll just have to live with names like l3extSubnet and its "ip" attribute - there are other examples where the GUI has changed but the underlying MIT has remained intact.  Here are some examples:

1. fvCtx - so called because originally the objects of this class were called "Contexts". Then they renamed them to "Private Networks". Then they reamed them to "VRFs" - so we could understand what was being talked about.
2. l3extOut - Always lovingly known as "L3Out" - was once referred to in the GUI as
   1. an "External Routed Network" (in the Navigation Tree)
   2. a "Routed Outside" when creating it,
   3. and as a "L3 Out" when associating it with a BD. That's one inconsistency I was glad to see cleaned up.
3. l3extInstP - In fact even the objects we happily know as External EPGs were once know as
   1. "Networks" in the Navigation Tree
   2. bit "External Networks" when creating them. Another improved GUI reference.

So I have no problem if the MIT object naming stays the same. In fact, I believe it has to remain constant, too many things would break if that was to change - as you say, any scripts or automation tools that refer to these objects, and any relationships that exist would no longer work..

Let's change the user interface to match the real world, and leave the object model alone.

[RedNectar]

I haven't added any for a while - so not sure if this tread is still alive. (For that matter, I have no idea if anyone who cares has even looked at it). But here's another suggestion.

Avoid confusion about Contract Subject by removing [x] Reverse Filter Ports option.

When I create a Subject for a Contract, I have two options regarding the way the filters are applied:

---

[x] Apply Both Directions

[x] Reverse Filter Ports

---

Now, these options are very confusing for most users, and to be fair, some of the confusion is removed by the fact the the UI will not let anyone select the [x] Reverse Filter Ports option if the [x] Apply Both Directions is not also set.

But I have no idea why it is possible to do this:

---

[x] Apply Both Directions

[  ] Reverse Filter Ports

---

Now please, someone tell me where this is useful? I mean USEFUL - not a weird corner-case scenario where you want to allow say two EPGs with AD servers to initiate connections in either direction (in which case you should tick both options, and then have the contract both provided AND consumed by both EPGs)

No takers?

No actual useful use for this combination?

Then my suggestion is that this scenario not be allowed via the GUI (like much of the other options that are controlled by the GUI, it would still be possible using the API).

And the way to remove the confusion, is to remove the Reverse Filter Ports option.

Here's how I see it working

By default, (as now) the  [x] Apply Both Directions option is set, but with a note under stating:

Filter ports are reversed for return traffic from Provider to Consumer

If the option is unchecked, the message changes to:

Filters need to be defined in each direction separately

Confusion (at least some of it) removed!

[RedNectar]

Another inconsistency is in the area of External EPGs (L3EPGs)

When I right-click on a regular Application EPG, I get a long list of actions, similar to the what appears under the Actions menu icon in the Policy pane.

But when I right-click on an External EPG, I get very few options - in particular I don't see the option to add a COnsumed or Provided Contract, which is most annoying

In fact, the whole structure of the External EPG is totally different to Application EPGs

Consistency would be GREATLY appreciated

[Robert Burns]

Great feedback community. I'm going to take this "batch" of feedback and pitch them into development next week.   I'll update this thread as decisions are made to action on the items above.

Regards,

Robert

[RedNectar]

Thanks @Robert Burns ,

When you have your meeting, don't forget to check up the items in the original post that precipitated in this one

https://community.cisco.com/t5/application-centric/dear-cisco-some-suggestions/td-p/4452180

[Sergiu.Daniluk]

1. When installing an app, it gives you alternative to use "Download" feature, but this is not present in Admin tab; it's actually in Apps tab:

2. Sorry for my laziness, I know this is not the best place to write this, but I will write it anyway: could it be possible to add the possibility to clear an EP from GUI? It would be very helpful to have this feature since from time to time, during a tshoot, you need to clear an EP.

Sergiu