Why NSX Name Fields Should Be Case-Insensitive

Creating Security Groups

The example below is why NSX name fields should be case-insensitive. When creating security groups with the names: “SG-01”, “Sg-01”, “sG-01”, and “sg-01” one might think this won’t be allowed as they’re the same name. Actually, NSX allows this due to the fact that the name field is case-sensitive resulting in four security groups created as shown in Figure-1:

Why NSX Name Fields Should Be Case-Insensitive
Figure-1

Again, the above example shows why NSX name fields should be case-insensitive. This would prevent such behavior, for example, security group “SG-01” already exists and when attempting to create another security group with the name “sg-01” would fail with a message similar to “Another object with the same name already exists in the current scope: Global”.

This issue also occurs in the following objects:

  • Security Groups
  • Security Policies
  • Custom Services
  • IP Sets
  • MAC Sets
  • Service Groups
  • IP Pools
  • Logical Switches
  • Creating NSX Edges

Surprisingly, Security Tags prevents the above problem, as shown in Figure-2:

Why NSX Name Fields Should Be Case-Insensitive
Figure-2

Granted, this issue “could” be resolved with standardized naming schemes, however, simply forgetting to capitalize or not capitalize a letter could accidentally create an unintended object. When attempting to filter for “SG-01” in the GUI or in PowerNSX all four security groups are returned, as seen in Figure-3 which is not what the Emoji wants.

Luckily with PowerNSX, we can leverage PowerShell’s -cmatch comparison operator to help narrow down our selection as shown in Figure-4. That’s going to wrap up this post.

Why NSX Name Fields Should Be Case-Insensitive
Figure-3

Why NSX Name Fields Should Be Case-Insensitive
Figure-4

 

Leave a reply:

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.