> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Suggested Use Cases for the Aviatrix Enterprise MCP Server
> Validated prompts and example outputs for using an AI assistant with the Aviatrix MCP server, covering health checks, security audits, CVE exposure analysis, upgrade planning, incident response, and infrastructure-as-code.
The Aviatrix MCP server gives an AI assistant read access to your Controller and
CoPilot: gateways, tunnels, BGP, Distributed Cloud Firewall (DCF) policies,
SmartGroups, firewall and intrusion logs, audit trails, traffic analytics, and
network diagnostics such as ping, traceroute, and FlightPath. This page collects
prompts that have been validated against a live Aviatrix fabric, organized by
the role most likely to run them, with abridged example outputs.
All example outputs on this page come from a demo fabric: 25 gateways across
AWS, Azure, GCP, and OCI, with 5 full-mesh transits, 3 edge sites, 47
SmartGroups, and a 30-policy DCF chain. Threat indicators shown, including
domains such as `malware.net` and exploit source IPs, are synthetic data
seeded into the demo environment. Your results reflect your own fabric.
The depth and formatting of responses varies with your MCP client and the
model behind it. The prompts below describe what the MCP server returns; how
your assistant assembles, summarizes, and renders that data depends on the
client you use.
## Start here: fabric health sweep
The best first prompt after connecting the MCP server. It exercises gateway
inventory, tunnel state, Site-to-Cloud (S2C) connections, BGP diagnostics,
controller logs, and DCF in a single pass, and gives you an immediate baseline
for everything else on this page.
```text theme={null}
Give me the current health of my network. Which gateways have issues right
now, any tunnels or site-to-cloud connections that are down or flapping,
and anything that needs my attention today?
```
After the summary lands, drill into any finding with a short follow-up such as
"expand on the egress finding" or simply the finding number if your assistant
numbered them.
**Fabric health: 25/25 gateways up, 5/5 S2C tunnels active. Three findings need
attention.**
1. **Egress to a flagged domain on one spoke.** `operations-aws-spoke-k8s`
permits traffic to `malware.net` (synthetic demo indicator) while the
identical SNI is denied on `marketing-azure-spoke-all` and
`accounting-aws-spoke-dev`. Root cause: the strict SNI WebGroup is attached
on two spokes but missing on `operations-aws-spoke-k8s`. This is policy
drift, not a detection gap.
2. **IPS is in monitor-only mode.** Roughly 2,000 alerts over 7 days, 0 blocks.
Detection without enforcement.
3. **BGP session reset 6 days ago** on `sv-equinix` (145 prefixes in / 158 out).
Session is currently established; worth correlating with any change that day.
Everything else checked clean: no gateway CPU or memory distress, no tunnel
flaps in the current log window, default-deny DCF rule active and terminal.
## Security
### Security posture audit and auditor evidence
Ask for a full posture sweep when you need to know what is inspected, what
bypasses inspection, and what you could show an auditor. This is one of the
heaviest prompts on the page; expect the assistant to make dozens of MCP calls.
```text theme={null}
What is the security posture of my network? Which spokes are inspected or
not, what is bypassing inspection, where are my policy gaps, and what would
I show an auditor to prove segmentation and egress control are enforced?
```
The MCP server does not care which language you ask in. The same prompt in
French, German, or Japanese runs the same tools and returns the same evidence.
**Inspection coverage: 13 of 14 spokes covered, 1 blind.** Ten spokes enforce
DCF locally and log continuously; the accounting spokes are inspected by the
vendor firewall on `transit-aws-us-east-1` (FireNet).
`operations-oci-spoke-shared` has no DCF logs and is not in the FireNet
inspection list: it moved 680 MB in 7 days with zero policy visibility. That is
your single blind spot.
**Bypassing inspection:** a leftover `test-lambda-egress` rule (priority 50)
permits any protocol and port from the Lambda group to the internet; HTTPS
egress carries no IDS because the combined http+https IDS policy at priority 999
has never matched (0 hits in 7 days, a dead rule).
**Correlation finding:** the number 2 top talker by volume (13.5 GB in 7 days,
synthetic demo source IP) is also the source of a permitted HeartBleed exploit
attempt against `marketing-app-prod`. That is not a coincidence, that is a
pattern.
**Auditor evidence pack:** 30-policy DCF export ending in an explicit
default-deny-all that fired 7,033,384 times in 7 days with zero allows, plus
timestamped cross-segment deny samples (marketing to accounting on 8443: Denied;
marketing to enterprise-data on 1433: Denied) alongside same-segment permits.
### CVE exposure analysis
When a scanner flags a package on your gateways, exposure depends on
reachability and traffic direction, not just package presence. The assistant can
reason about both because it can read your DCF policy chain and security
posture.
```text theme={null}
CVE-XXXX-XXXXX (libssh2) was flagged on some of my spoke gateways. Which
gateways have this package, is it actually reachable or exploitable given
my security groups and how these gateways are configured, and what is my
exposure? Give me a remediation summary I can hand to my SOC.
```
**Reframing the question.** This CVE targets the SSH client side, so "is port 22
reachable on the gateway" is the wrong question. The right question is "what on
these gateways initiates outbound SSH to untrusted endpoints", and the answer
is: nothing in the observed traffic or configuration.
**Policy evidence:** exactly one TCP/22 permit exists in the 30-policy DCF
chain, scoped to a management SmartGroup. No gateway-initiated outbound SSH
appears in 7 days of flow data.
**Verdict:** the scanner undersold the footprint (all 14 spokes share the same
base image, not just the flagged ones) and oversold the risk (no viable attack
path under current policy). Recommended remediation: patch on the normal cycle
as P3, not emergency P1; add a detection for unexpected outbound SSH as a
compensating control.
A SOC-ready handoff table with per-gateway package status and a P1-P4 action
plan follows.
### Kubernetes SmartGroup and DCF coverage
If you run Kubernetes behind Aviatrix, ask the assistant to map your SmartGroup
selectors against your cluster reality. The mental model is close to a network
policy label selector, enforced at the cloud network layer instead of the node.
```text theme={null}
Can you break down the Kubernetes SmartGroups in DCF? Which namespaces and
selectors are covered, and where are the gaps?
```
**47 SmartGroups total, 9 with native Kubernetes selectors.** Three findings:
1. The `gcp-demo` namespace selector is over-broad: it matches every pod in the
namespace rather than the intended app labels.
2. `azure-aks` is Kubernetes in name only: membership is CIDR-based with no
label selectors, so pod churn silently breaks the mapping.
3. The qa environment has zero Kubernetes SmartGroup coverage.
**A note on the follow-up "which pods are covered":** the MCP server has no pod
inventory tool. Kubernetes SmartGroups are dynamic; the selector is the
definition. To verify actual membership, compare the selector against
`kubectl get pods --show-labels` output, or check DCF logs for traffic
attributed to the SmartGroup.
## Operations
### Pre-upgrade risk assessment
Before a controller or gateway upgrade, ask what tends to break. The assistant
checks for the known risk patterns (custom SNAT, non-standard routing, missing
HA, legacy features) with configuration evidence rather than folklore.
```text theme={null}
I'm planning a controller upgrade. Which of my gateways are at risk:
anything running custom SNAT policies, non-standard routing, single
gateways with no HA, or config that tends to break on upgrade? Flag what
I should check first.
```
The assistant also checks your premise. In one validated run, a request for a
"7.2 to 8.0 pre-upgrade check" was refused because every gateway already
reported 9.0: the assistant flagged the version mismatch instead of performing a
meaningless pre-flight.
**Cleared risks:** no custom SNAT found (`snat_target` empty, `enable_nat=no`
across inspected gateways); no customized CIDRs, BGP over LAN, or PBR; at 25
gateways, scale is a non-issue.
**Risk register, ranked:**
1. **Zero HA fabric-wide.** No gateway has an HA peer, so every image upgrade is
a hard data-plane outage for that VPC: 25 sequential micro-outages. Plan
waves (dev, qa, prod) with transits in a dedicated window.
2. **`transit-aws-us-east-1` is a single point of failure.** FireNet, S2C
termination, 4 transit peerings, 8 attachments, no HA peer. Verify vendor
firewall re-registration behavior before and after.
3. **An apparently orphaned legacy FQDN gateway** with zero tags attached.
Legacy code paths are the most common upgrade casualties; identify the owner
or decommission before upgrading.
4. **A Public Subnet Filtering gateway on a t3.micro.** Niche legacy feature on
a burstable instance; confirm filter behavior immediately post-upgrade.
### On-call incident walk
When an application is reported down, one prompt can chain IP classification,
path computation, gateway health, and policy verdicts.
```text theme={null}
Pretend I'm on call and just got paged that an app is down. Walk the whole
path for me: classify the source and destination IPs, run flightpath,
check the gateways in between, and check for any matching firewall drops
or intrusions.
```
**Path walk for 10.2.2.100 to 10.1.2.10:8443:**
1. **Classification:** source is `marketing-app-prod` (marketing segment,
Azure); destination is `accounting-backend-api-prod` (accounting segment,
AWS).
2. **FlightPath:** route exists end to end; security group and NACL checks pass
on both sides. The cloud path is clean.
3. **Gateway health:** all gateways on the path up, no resource distress,
tunnels established.
4. **Policy verdict:** DCF logs show the flow hitting `default-deny-all`.
Marketing to accounting is not covered by any permit rule. This is
segmentation working as designed, not an outage. If this flow is newly
required, it needs an explicit policy, not a ticket to networking.
### Investigating a log delivery gap
When a log type stops appearing in CoPilot, the fastest diagnosis is a binary
search over log counts, then eliminating causes layer by layer. This method
generalizes to any telemetry gap.
```text theme={null}
DCF firewall logs stopped appearing in CoPilot at some point in the last
few months. Find exactly when they stopped, verify whether policies are
still enforcing and gateways are still healthy, rule out configuration
changes, and narrow down where in the delivery path the logs are being
lost.
```
**When:** log counts over successive time ranges pin the cutoff to a single
timestamp (in the validated run, 792,393 entries before the cutoff, zero after).
**What still works:** enforcement is intact. The last logged entries show both
Permit and Deny with `is_enforced: True`, all producing gateways are up and
passing traffic, and other log types (gateway syslogs, NetFlow) continue to
flow. So the gap is in DCF log delivery, not in the firewall and not in the
gateways.
**What was ruled out, with evidence:** no policy changes (audit timeline empty
around the cutoff), per-rule logging still enabled on all 29 policies, syslog
profile enabled and pointed at CoPilot, no external syslog redirect configured.
**Conclusion:** every layer the API can verify is healthy, which isolates the
fault to the log delivery pathway between controller and CoPilot. The cutoff
coincides with a controller upgrade. Recommended next step: open a support
ticket citing the exact cutoff timestamp, the build number, and the elimination
evidence above. That evidence chain typically saves days of back-and-forth.
## Network engineering and IaC
### Topology diagram generation
Ask for a diagram of the fabric the MCP server can see. This use case depends on
your client's ability to write files; the MCP server supplies the topology data
(gateways, peerings, attachments, edge sites), and the client renders it.
```text theme={null}
Build a draw.io diagram of my fabric topology.
```
An editable `.drawio` file reflecting the live fabric: 5 transit gateways in
full mesh across AWS, Azure, GCP, and OCI, 10 transit peerings, 14 spokes
grouped by segment, 3 edge sites, and the FireNet transit marked with its
inspection role. Because the data comes from the live Controller, the diagram
matches reality rather than the last time someone updated a slide.
### Terraform generation with live verification
The assistant can generate Aviatrix Terraform grounded in your actual fabric:
real VPC IDs, real transit names, real account names, pulled through the MCP
server instead of guessed.
```text theme={null}
Build Terraform to provision an Aviatrix spoke gateway in one of the VPCs.
```
The assistant first asks clarifying questions (which cloud, which VPC, HA or
not, attach to which transit), then produces a module using the current provider
schema with real values from the fabric: the target VPC ID, region, account
name, and transit gateway name for attachment. Validate with
`terraform validate` and review before applying, as with any generated IaC.
## Capability boundaries
The MCP server is honest about what it cannot answer, and you should be aware of
these limits before relying on it:
* **Gateway syslog retention is short**, on the order of 24 hours. A question
like "how many times did this tunnel flap in the past 6 months" is
unanswerable from gateway syslogs, and the assistant should say so rather than
guess. For long-horizon history, ship logs to a SIEM.
* **There is no pod inventory.** Kubernetes SmartGroups are defined by their
selectors; verifying actual pod membership requires cluster-side tooling.
* **Some data is not exportable via API in all builds**, for example WebGroup
domain contents in certain versions. The assistant will tell you when a value
must be read from the CoPilot UI instead.
* **Scheduled rekeys are not flaps.** IPsec IKE reauthentication appears
periodically in logs as make-before-break events; a good response
distinguishes these from real tunnel instability.
A refusal backed by a stated limitation is more useful than a fabricated answer.
If your assistant confidently reports six months of tunnel history, be
suspicious.
## Prompting tips
* **Drill down instead of re-asking.** After a sweep, reply with the finding
number or a short phrase ("expand on finding 2"). The assistant reuses the
data it already fetched.
* **State your premise and let it be checked.** Include your assumed versions,
topology, or timeline in the prompt. Validated runs show the assistant
correcting a wrong upgrade premise rather than executing it.
* **Phrase time windows within retention.** Ask about "the last 24 hours" or
"the current log window" for gateway syslogs; use CoPilot-backed data (DCF
logs, flow data) for multi-day windows.
* **Ask for a deliverable, not just an answer.** "Give me a remediation summary
I can hand to my SOC" or "what would I show an auditor" produces a structured
artifact you can forward, not a chat reply you have to rewrite.
* **Any language works.** The tools are language-agnostic; ask in the language
your team works in.