Packet Analysis
Relevant source files
The following files were used as context for generating this wiki page:
Packet Analysis allows network engineers to inspect, summarize, and query finished network captures (pcaps) to identify protocol breakdowns, top talkers, or specific traffic patterns like TCP resets. It acts as a specialized assistant that reasons over already-collected capture data to help diagnose intermittent issues that standard logs might miss.
Sources: CLAUDE.md, backend/app/llm/prompts/init.py:228-232
1. Overview
The AI Network Operations Platform is a self-hosted assistant designed for enterprise network teams. It functions as an AI Network Engineer that you can interact with using plain English to manage multi-vendor environments, including Cisco, Juniper, Arista, Palo Alto, and Fortinet.
The platform follows a "local-first" philosophy, meaning it runs entirely within your own data center or cloud for maximum security. A critical safety feature is that every change the AI proposes requires a second human to approve it before execution. The platform uses specialized "Agents"—which you can think of as expert team members—to handle different tasks. For example, when you ask about traffic patterns in a specific file, the Master Architect (the team supervisor) routes your request to the Packet Analysis Agent.
Sources: README.md, CLAUDE.md, backend/app/llm/prompts/init.py:257-268
Key Features and Vendors
The platform supports a wide range of protocols and infrastructure providers to ensure comprehensive visibility across the network.
| Category | Supported Vendors / Protocols |
|---|---|
| Routing & Switching | Cisco (IOS, IOS-XE, NX-OS), Juniper (JunOS), Arista (EOS) |
| Security & Firewalls | Palo Alto (PAN-OS), Fortinet (FortiOS) |
| Load Balancing | F5 BIG-IP |
| Cloud & Virtualization | AWS, Azure, VMware |
| DDI (DNS/DHCP/IPAM) | BlueCat, Infoblox, Route53 |
| Packet Tools | tcpdump, tshark, Wireshark |
System Overview Diagram
This diagram shows how users interact with the platform and the various systems the platform connects to for discovery and management.
The platform acts as a central hub, authenticating users and translating their requests into actions across multi-vendor infrastructure and cloud environments.
Sources: CLAUDE.md, deploy/docker/README.md, deploy/kubernetes/netops/README.md
2. Architecture
The platform is composed of seven core components that work together to process your requests. These are deployed as isolated units to ensure reliability and security.
Platform Components
- frontend: The operations console where you chat with the AI, view the topology map, and manage approvals.
- api: The primary interface that handles user sessions, security, and coordinates between the frontend and the background engines.
- worker: The background engine that performs long-running tasks like discovery jobs, taking configuration backups, and processing packet analysis without blocking your user session.
- postgres: The main database (system of record) that stores your device inventory, audit logs, and AI reasoning traces.
- neo4j: A living topology map (graph database) that tracks how every device, interface, subnet, and DNS zone connects to everything else.
- redis: A fast, temporary storage used for queuing background jobs and caching data.
- ollama: An optional component that provides local AI reasoning, ensuring no data leaves your network.
Sources: README.md, deploy/docker/README.md, deploy/kubernetes/netops/README.md
Vendor Plugin System
The platform uses a standardized connector (plugin) for each vendor. No matter whether you are troubleshooting a Cisco Nexus switch or a BlueCat Address Manager, the platform normalizes the output into a consistent format before the AI agents process it. For instance, the Cisco NX-OS plugin uses specialized parsers to turn "show" command output into structured data the AI can understand.
Sources: README.md, backend/app/plugins/vendors/cisco_nxos/parsers.py:1-25
Deployment Options
The platform offers two primary ways to get up and running:
- Docker Compose: A single-server deployment suitable for lab environments or small teams. It uses a single
.envfile for all settings. - Kubernetes (Helm): A production-ready, multi-node deployment that provides higher availability and scales with your organization. It includes advanced security features like automated certificate rotation and deep network isolation.
Sources: deploy/docker/README.md, deploy/kubernetes/netops/README.md
Deployment Comparison Diagram
This diagram contrasts the simple, single-server Docker setup with the resilient, multi-node Kubernetes architecture.
Docker Compose is optimized for ease of use on one machine, while Kubernetes distributes the platform across multiple servers for fault tolerance.
Sources: deploy/docker/README.md, deploy/kubernetes/netops/README.md
3. Agent Routing and Workflows
Every user request follows a strict path to ensure the right expert handles the task and no unauthorized changes are made to the network.
Agent Routing Diagram
The Master Architect analyzes your plain-English request and selects the best specialist agent to help you.
The Master Architect acts as a dispatcher, ensuring tasks like packet analysis or DNS changes are handled by the appropriate expert agent.
Sources: backend/app/llm/prompts/init.py:186-270, CLAUDE.md
Change Approval Workflow
For security, the platform separates the drafting of a change from its execution. This ensures a human always has the final say.
- Draft: A specialist agent (like the DDI or Config Agent) creates a proposed change.
- Pending Approval: The change sits in a queue. A second network engineer must review the proposal.
- Approved: Once a human approves, the change is ready for execution. A pre-change configuration backup is automatically taken at this stage.
- Executing: The Automation Agent takes the approved plan and applies it to the devices.
- Completed/Rollback: If the change succeeds, it is marked complete. If it fails, the platform can use the backup to roll back the state.
Sources: README.md, backend/app/llm/prompts/init.py:233-247, deploy/docker/README.md
Change Approval Flow Diagram
This diagram shows the life cycle of a network change from the initial request to final verification.
No change is ever applied without a human reviewer's explicit approval, and a safety backup is always created beforehand.
Sources: README.md, backend/app/llm/prompts/init.py:245-247, CLAUDE.md
Topology Data Model
The platform's "living topology map" (Neo4j) understands how different network elements relate to one another.
This model allows the platform to understand dependencies, such as which applications will be affected if a specific subnet or VLAN is modified.
Sources: CLAUDE.md, README.md
4. Packet Analysis Implementation
Packet analysis is specifically hardened to handle untrusted data. When you ask to analyze a capture, the platform uses a dedicated Packet Analysis Sandbox.
- Isolation: The analysis engine runs in a "sandbox" (a restricted container) with no network access and no permissions to modify the system. This prevents a malicious packet from compromising the platform.
- Tools: The system leverages industry-standard tools like
tsharkto parse pcaps. - Summarization: The agent can answer questions such as "Which hosts talked the most?" or "How many DNS packets were in that pcap?" by querying the results from the sandbox.
Sources: deploy/docker/docker-compose.yml:78-100, deploy/kubernetes/netops/README.md, backend/app/llm/prompts/init.py:228-232
Security Configuration
The following table describes the security settings applied to the packet analysis environment to ensure safety.
| Security Control | Purpose |
|---|---|
| Seccomp Profile | A "deny-by-default" filter that only allows the specific system calls needed for packet parsing. |
| Capabilities Drop | Removes all special Linux permissions (like NET_RAW), ensuring the parser can't touch the network. |
| Read-Only Root | Prevents the parser from writing any permanent files to the system. |
| Resource Limits | Restricts CPU and memory so an unusually large or complex capture cannot crash the server. |
Sources: deploy/docker/docker-compose.yml:95-120, deploy/kubernetes/netops/README.md
Conclusion
Packet Analysis within the AI NetOps Platform provides a secure, AI-driven way to interrogate network traffic. By routing requests through specialized agents and executing analysis within a hardened sandbox, the platform ensures that engineers can gain deep visibility into network issues without sacrificing security or system stability. All findings are explained in plain English, allowing team members to quickly understand complex traffic patterns and make informed decisions.