VCF Extension Network Insight: Using the GUI

Version: 2026.1.1.1

The VCF Extension Network Insight GUI is used entirely from the browser. It always shows a plan before it writes anything to NSX, and it never creates blocking rules. This section walks through a rollout from an empty environment to a finished policy that the Management Pack then monitors.

Tagging the machines in vCenter

A rollout starts in vCenter, before the GUI is opened. The GUI does not guess which machine belongs to which application; it reads the tags that are set. A machine with no tags is invisible to it, and a machine with incomplete tags is reported, never silently skipped.

Create two tag categories in vCenter (Tags and Custom Attributes > Categories > New), both with Applies to: Virtual Machine and cardinality one tag per object:

Category	Applies to	Cardinality	Example values	Purpose
application	Virtual Machine	one tag per object	CRM, BILLING, ERP	the application the machine belongs to. Short, uppercase, no spaces
tier	Virtual Machine	one tag per object	WEB, APP, DB, INT	the role the machine plays inside the application

Cardinality has to be single: with multiple tags a machine can belong to two applications and ends up on hold instead of being segmented. Cardinality cannot be changed after the category is created, so getting it right now saves recreating the category later. The category names are a setting, so the names already used in the organisation can be entered on the Settings tab.

The application tag value becomes part of every object name in NSX, so keep it short, uppercase, without spaces and stable over time. The default set of tiers is:

Value	Meaning
WEB	anything that terminates user traffic: reverse proxies, front ends
APP	application servers, business logic, integration components
DB	databases and anything that stores the application state
INT	integration and messaging components, if kept apart
ACC	access and jump hosts belonging to the application
INF	infrastructure machines that belong to this application only
OTR	everything else that belongs to the application but fits nowhere above

The allowed list of tiers is a setting; keep it short. Every extra tier multiplies the number of rules, because rules are created per pair of tiers.

One machine, one application. If a machine genuinely serves two applications, it is a shared service, not a member of either. Leave it untagged and let it come up as a decision, then point the rule at a group.

Tag a machine with Actions > Tags and Custom Attributes > Assign Tag, or in bulk by selecting several machines in the VMs list. For large environments, PowerCLI is faster:

Get-VM -Name 'swpp-*' | New-TagAssignment -Tag 'SWPP'
Get-VM -Name 'swpp-web*' | New-TagAssignment -Tag 'WEB'

The Applications tab (below) shows what the GUI found and which machines have incomplete tags. Fix what it lists before planning anything: tags are the input, and nothing downstream can be better than they are.

Environment and access

The GUI reaches vCenter, NSX and Aria Operations for Networks on 443 and Aria Operations for Logs on 9543, all outbound; the only inbound connection is the administrator browser on 8443 (443 behind an ingress). The full network access and account table — including the least-privilege roles and the two ports people get wrong — is in Deploying the GUI, under Requirements.

First configuration

After signing in, open the Settings tab:

1. System addresses. Type the host name or IP only; the GUI adds the scheme and the port itself, including 9543 for Aria Operations for Logs:

   vcenter.company.local   ->  https://vcenter.company.local
   10.30.11.70             ->  https://10.30.11.70
   logs.company.local      ->  https://logs.company.local:9543
   

2. Test connections. Every system is checked and reported separately, so a failing account is identified immediately instead of hiding behind one generic error.

3. Tag taxonomy. Enter the tag category names used in vCenter and the list of allowed tiers. The environment category is off by default: an empty value disables it completely. Turn it on only if somebody really maintains that tag.

4. Naming convention. Templates for group and rule names, with a live preview (explained below).

5. Save the settings.

Two things are deliberately not in the interface: rule numbering and the DFW policy category. An administrator has no decision to make about either, and wrong numbering would break the catch-all mechanism silently.

Naming: what the objects are called

Every object the GUI creates in NSX gets its name from a template, and every template is a setting. In the templates below, {ba} is the application tag value (shown here as SWPP), {tier} is the tier tag, and {src}/{dst} are the source and destination tiers. The defaults are:

Template	Default	Result	What it is
Group name	{ba}-{tier}	SWPP-WEB, SWPP-ALL	one group per tier, plus one for the whole application
Rule name	{ba}-{src}-to-{dst}	SWPP-WEB-to-APP	one rule per pair of tiers that actually talk
Catch-all rule name	{ba}-ALL-{direction}	SWPP-ALL-ALL, SWPP-ALL-OUT, SWPP-ALL-IN	the three logging rules at the end of the policy
Peer group name	{ba}-peer-{peer}	SWPP-peer-mon01	a group for a machine outside the application that was approved
Service name	{prefix}-svc-{proto}-{port}	msg-svc-tcp-8080	created only when the NSX catalog has no equivalent
Identifier prefix	msg	msg-SWPP-WEB	how the GUI recognises its own objects

The application name has to be in every template, so a rule name reads left to right as a sentence: SWPP-WEB-to-APP is inside application SWPP, from the WEB tier to the APP tier. Without the application name, two applications would produce objects with the same name.

The three catch-all rules are worth knowing by sight:

Rule	Matches	Why it exists
SWPP-ALL-ALL	traffic inside the application that no detailed rule matched	shows the tiers talk in ways not yet described
SWPP-ALL-OUT	traffic leaving the application	shows what the application reaches for
SWPP-ALL-IN	traffic entering the application	shows who reaches into it

All three are ALLOW with logging. They change nothing about what passes; they exist so their counters can tell how much traffic is still undescribed.

Changing a template renames the existing objects, it does not create a second set: NSX identifiers derive from the prefix and the application name, while the template controls only the display name. The identifier prefix is what marks an object as the GUI's own; it only ever modifies or removes objects carrying it, and leaves rules and groups created by anyone else alone.

Applications

The Applications tab lists every application found in vCenter: how many machines it has, its tiers, how many rules already exist, and any tag problems. An application is either NEW (nothing of ours in NSX yet, or a policy with no detailed rules) or Ready (the policy exists with detailed rules). Machines with incomplete tags are called out here so they can be fixed before segmenting.

Flows

The Flows tab pulls the real traffic for one application from Aria Operations for Networks: source and tier, destination and tier, the service, the traffic class, and which existing rule already allows it. Traffic inside the application becomes rules automatically; traffic to shared services or to other applications is set aside for a decision.

Plan

The Plan tab shows the rules that will be in the policy. Each rule marks whether it already exists or is new, and the NSX service on it can be changed: it is chosen from the same NSX service catalog used by hand, and an entry marked "custom" is one the GUI would create because the catalog has nothing that fits. Three catch-all rules are added automatically at the end of the policy, allowing and logging whatever the detailed rules did not match, so their counters show how much traffic is still undescribed.

Traffic the GUI may not decide on its own appears in the same tab as a list with a yes and a no on each row: traffic to another application, to a shared service, or from a machine with no tags. Any number of rows can be settled and saved together.

Choosing yes for traffic to a machine outside the application asks what the rule should point at: a new group whose members are named (machine names are suggested from the NSX inventory, and a bare IP address can also be typed; the same group name on several rows gives one group in NSX), or an existing group that already contains that machine (the rule then only refers to it; the GUI does not modify a group it did not create). The approved rows become rules; the ones already handled elsewhere are listed as covered.

Choosing no removes the row from the questions and it does not come back. If the traffic keeps happening, it is reported separately as traffic against a decision. Decisions are stored as a CSV sheet in the data directory, so the record of decisions can be opened in a spreadsheet or reviewed in a merge request.

Choosing the service on a rule

Every rule shows the NSX service it will use, and it can be changed. The list is the NSX service catalog, the same one picked from when writing a rule by hand, with the services matching that protocol and port shown first. The default is automatic: a built-in NSX service is used when its name actually means something for that port, otherwise the GUI creates one of its own, named like msg-svc-tcp-1433. A manual choice wins over that default and applies to every rule that uses the same protocol and port, so the same thing is not named two ways in one policy; setting it back to automatic undoes it.

Apply

The Apply tab writes the plan to NSX: the groups, the rules and the catch-all rules. It stays disabled until a plan has been built, and confirmation requires typing the application name.

State

The State tab reads the live policy back from NSX: the rules with their packet and session counters, and the groups with their members. The catch-all counters are the readiness signal: while they keep rising there is traffic no detailed rule describes, so moving to blocking would break something; when they stop, the application is ready to enforce.

What appears in Aria Operations for Networks

Applying a plan also creates the matching Application in Aria Operations for Networks, with one tier per tier tag and the right machines in each. From then on vRNI shows the application as a whole — its traffic map, tier-to-tier flows and the usual vRNI analytics — without building the application definition by hand and without it drifting from the tags whenever a machine is added. If vRNI is unreachable, the NSX part still works and only this synchronisation is skipped, with a warning in the log.

What the Management Pack adds

Once a policy is in place, the Management Pack picks it up in Aria Operations. It reads the DFW logs through Aria Operations for Logs and attributes every dropped and observed connection to the rule that produced it, so "who is this rule blocking" becomes a fact from the logs rather than a guess from configuration. It builds the same application view from the same tags, gives per-rule traffic and drop counters, and raises alerts on newly blocked traffic. The dashboards, objects and alerts it provides are described in the Overview.

Security

The GUI holds an account with write access to NSX, so the instance is treated like a management machine: on a management network, with access limited to administrators, and a backup of the data directory.

• Passwords for the systems are encrypted in the configuration, with the key stored next to it. Values supplied through the environment take precedence and are never written to the configuration.
• There is one administrator account for the interface; the password is supplied at deployment.
• The container runs as a non-root user with a read-only file system.
• The GUI creates ALLOW rules only. This is enforced in the code, so no setting can change it.

Troubleshooting

"The configuration is incomplete" on the yellow bar. An address or an account is missing. Open Settings, fill it in and click Test connections.

vRNI returns HTTP 401 with the right password. The user name needs the domain suffix: admin@local, not admin.

Aria Operations for Logs returns an error that looks like a wrong password. The query API answers on port 9543 only. Enter the address alone and the port is added.

The application list is empty after a restart. The inventory lives in process memory, so a restart clears it. Click Refresh from vCenter.

An application shows no traffic although traffic exists. The GUI asks vRNI about the addresses of the machines from its own inventory. Check on the Flows tab how many addresses were found and whether those are the addresses the traffic actually uses; after an environment is rebuilt, vRNI can keep a historical mapping of a machine name to an old address.

A machine ends up in the on-hold section. Its tags are incomplete or doubled. The Applications tab shows what is missing. A machine with an incomplete description is never skipped quietly.

Flow range. vRNI retention is usually 31 days, and asking for a larger range ends with HTTP 400. With no range given, vRNI returns only the last day, which for a process run once a month misses most of its traffic.