What the analysis looks like
This is a real example of Gemini's output when analyzing a BGP log from the lab where SP1's static protocol was missing and sessions were dropping.
The response structure is consistent for every analysis: SEVERITY, ANOMALY_DETECTED, ISSUES_FOUND, ROOT_CAUSE, RECOMMENDED_ACTION, and URGENCY. This makes the output programmatically parseable for the automated pipeline, while also being readable for humans during a manual incident review.
How severity is determined
Gemini assigns one of four severity levels based on the impact of the anomaly. The tool parses the response to extract the severity and uses it to decide whether to trigger an immediate alert in the automated pipeline.
A BGP session flap that recovered within 30 seconds might be LOW. A spine with zero routes in its routing table is CRITICAL. An interface cycling every few minutes is HIGH because it is causing route instability even if traffic is still flowing on redundant paths.
Log types and anomalies the tool recognizes
BGP routing
Session state issues (Active, Idle, Connect instead of Established), route table anomalies, prefix limit violations, MED flapping, AS path loops, missing route advertisements, blackhole routing problems.
Interface and Layer 2
Interface flaps, error counters exceeding thresholds, CRC errors, input/output drops, duplex mismatches, LLDP topology mismatches, spanning tree topology changes.
DDoS and traffic anomalies
Traffic spikes from unusual source IPs, high packet rates on specific interfaces, ICMP flood patterns, BGP prefix hijacking signatures, route instability correlated with traffic patterns.
Security events
Failed authentication attempts, unauthorized BGP peer connections, unexpected OSPF neighbor formations, ACL hit rate spikes, management plane access from unusual sources.
EVPN and VXLAN
MAC/IP route advertisement failures, ARP suppression issues, VTEP reachability problems, NVE interface state, BGP EVPN route type distribution across the fabric.
General syslog
Any structured or unstructured syslog output. Gemini reads the log holistically and identifies patterns rather than matching against fixed rules, which means it handles novel issues that rule-based systems miss.
Under the hood
-
1Engineer pastes the logRaw log output is pasted directly into the browser interface. No preprocessing needed. The tool handles any format: Cisco IOS, Juniper JunOS, BIRD2, syslog, show commands, debug output.
-
2Optional: select environment contextThe engineer can specify the environment type (production, staging, lab), network type (data center, WAN, campus), and focus area (BGP, OSPF, interface errors). These parameters are included in the prompt to Gemini to tune its analysis.
-
3Log is sent to Gemini AI with a structured promptThe log and context are wrapped in a structured prompt that instructs Gemini to act as a senior network operations engineer. The prompt specifies the exact output format so the response is always parseable. Gemini reads the entire log and reasons through it before generating a response.
-
4Response is parsed and displayedThe structured response is parsed to extract severity, anomaly status, issues, root cause, and recommendation. Each field is displayed in a clear, color-coded format. The full analysis text is also shown for engineers who want the complete reasoning.
In the automated AIOps pipeline, the same analysis happens automatically every 15 minutes without any engineer involvement. The Flask API collects logs from network devices, runs redaction, sends to Gemini, and the n8n workflow sends an email alert if anomalies are found. The browser tool and the automated pipeline use the same underlying logic.
What AI adds that regex cannot
Traditional network monitoring uses rule-based alerting: if BGP session goes down, send an alert. This works for simple thresholds but fails in three important ways.
First, rules require someone to anticipate every failure mode in advance. A new bug in BIRD that causes routes to be present but not installed in the kernel routing table would not match any existing rule. Gemini would identify it immediately from the pattern of 0 routes despite Established sessions.
Second, rules cannot reason about correlation. A single interface error is noise. Interface errors on three devices simultaneously during a scheduled maintenance window means something different than the same pattern with no maintenance. Gemini reads the full context and reasons about what it implies.
Third, rules produce binary alerts with no explanation. Gemini produces a full analysis including root cause and recommended action. For a junior engineer during an incident, the difference between “BGP session down” and “BGP session active because static routes are missing from the BIRD config, run fix_bird_configs.py to restore” is the difference between a 2-hour incident and a 10-minute one.