Lab N3: NSX Intelligence / VCF Operations for Networks — DFW Rule Generation

Verify NSX Intelligence / VCF Operations for Networks deployment. NSX Manager → System → Appliances → NSX Intelligence (or navigate to the VCF Operations for Networks UI). Verify: Status='Active', Data Collection='Enabled'. If not deployed, deploy the Intelligence appliance via OVA: 4 vCPU / 32 GB RAM / 200 GB disk minimum. It connects to NSX Manager and automatically begins collecting flow data from all transport nodes.

Enable flow collection for target workloads. NSX Manager → Plan & Troubleshoot → Discover & Take Action (DFW 1-2-3-4 workflow). Step 1 'Discover': select the application scope — choose VMs by tag, name, or segment. For this lab, select all VMs tagged with env=production (from Lab net-virt-03). Enable flow collection for these VMs. The system begins recording every connection: source, destination, port, protocol, byte count, duration.

Generate application traffic (if not already flowing). Simulate real application patterns: (a) From web VMs, run repeated HTTP requests to app VMs: while true; do curl -s http://10.10.2.11; sleep 1; done. (b) From app VMs, run MySQL queries to db VMs: mysql -h 10.10.3.11 -u app -p -e 'SELECT 1'. (c) From web VMs, generate DNS lookups and NTP sync. Let traffic flow for at least 1 hour (24-48 hours in production) to build a representative baseline.

Explore traffic visualization. In the DFW 1-2-3-4 workflow, Step 2 'Analyze': the flow visualization dashboard shows a bubble chart or force-directed graph of all communication patterns. VMs are nodes, connections are edges. Look for: (a) Tightly coupled groups — these are application tiers; (b) Unexpected connections — potential lateral movement or misconfigured services; (c) High-volume flows — database connections, backup traffic. This visual map is invaluable for understanding actual application behavior vs. documented architecture.

Generate DFW rule recommendations. Step 3 'Plan': click 'Recommend Rules' for the selected application scope. The engine analyzes observed flows and proposes: (a) Security groups — based on communication patterns and tags; (b) DFW rules — allow rules for observed traffic, organized by tier; (c) A default deny rule for everything not observed. Review each recommended rule: check for false positives (one-time scanning traffic that shouldn't be permanently allowed) and false negatives (legitimate traffic that wasn't observed during the collection window).

Review recommendation quality. For each recommended rule, the engine provides: (a) Confidence score — how many times this flow was observed (high-frequency = high confidence); (b) Flow count — total connections matching this pattern; (c) Byte volume — traffic impact. Prune recommendations: remove rules for management tools that ran during observation (e.g., vulnerability scanners, backup agents that connect to all VMs), and add any known flows that didn't occur during the observation window (e.g., monthly batch jobs).

Apply rules in monitor (detect-only) mode. Step 4 'Act': publish the recommended rules with Action='Detect' (not 'Allow/Drop'). This creates the DFW policy but does not enforce it — traffic flows normally while the rule engine logs which connections would be allowed and which would be denied. Monitor for 24-48 hours. Review: Security → DFW → Statistics — the 'Would Block' column shows flows that will be denied after enforcement. Investigate each 'Would Block' entry — is it legitimate traffic that needs a new allow rule?

Iterate and refine. Based on detect-mode results: (a) Add allow rules for legitimate flows that were missed; (b) Remove allow rules for one-time or testing traffic that shouldn't persist; (c) Verify management plane traffic (vCenter, NSX Manager, monitoring agents) has Infrastructure-category allow rules. Re-run the analysis to see updated recommendations. This iterate-verify cycle typically takes 2-3 rounds before the policy is production-ready.

Switch to enforcement mode. Once confident the policy is correct (zero unexpected 'Would Block' entries), change the rules from Detect to their intended actions: Allow for known traffic, Drop for the default deny. Publish. Monitor closely for the first 24 hours — have a rollback plan ready (switch all rules back to Detect if issues arise). The DFW 1-2-3-4 workflow tracks this lifecycle: Discover → Analyze → Plan → Act.

DFW Rule Analysis (post-enforcement optimization). After enforcement, use the rule analysis features. NSX Manager → Security → DFW → select policy → Actions → Analyze Rules. The analyzer identifies 7 optimization types: (a) Shadowed rules — never hit because a higher-priority rule matches first; (b) Redundant rules — duplicate of another rule; (c) Conflicting rules — two rules match same traffic with different actions; (d) Unused rules — no hits over a configurable period; (e) Over-permissive rules — allow broader than observed traffic; (f) Mergeable rules — multiple rules that can be consolidated; (g) Reorderable rules — rules that would be more efficient in a different order. Act on these findings to keep the rule set lean.