Skip to main content

 

Splunk Lantern

Enhancing network automation with event-driven architecture

Configuration and change-management failures now cause nearly 45 percent of all network related outages, making configuration drift a top threat to uptime and resilience. 

Your traditional network automation probably functions something like this:

  • You write an automation script. 
  • It reads from the source of truth.
  • It checks network devices. 
  • It compares changes or makes changes. 
  • It stores an audit log.

The model works fairly well for you, but there are two big downsides: managing all the API calls and working around the automation when a developer doesn't follow your workflow, such as making a network configuration change some other than in the source of truth.

Now that your company has bought in to agentic AI solutions, you image there are ways to improve this automation. This article present a solution: event-driven architecture.

How to use Splunk software for this use case

 Event-driven architecture (EDA) is a software design pattern where decoupled components communicate through events. The components are:

  • Event producers: Generate events when actions occur and produce different data sets that you want to take action on, for example, Cisco Meraki dashboards.
  • Event brokers: Transport events from producers to consumers, for example, webhooks.
  • Event consumers: Listen for and process events, for example, the Splunk platform.

Some consumers can also be producers.

This article looks at an example NetDevOps use case that is managed through event-driven architecture. In this example, you are tasked with the following:

  • Manage a 10K+ devices multi-site Meraki Network, making sure to automate configuration changes and prevent configuration drift.
  • Maintain a single source of truth for the network using NetBox. This is your producer. You can use other another solution but it must be a system or application that supports APIs.
  • Use n8n as your middleware consumer that runs the agents that update configurations. This consists of a supervisor agent, run on AWS Bedrock in this example, and multiple agents connected via an MCP server to Meraki, NetBox, and the Splunk platform. These agents control all the APIs so you don't have to. You can use other agent management tools as needed.
  • Maintain an audit log of changes in the Splunk platform. This log will help you uncover:
    • What happened
    • Where the problem happened
    • Who caused the problem
    • What kind of outage was caused

First, you need to set up NetBox and Meraki, as demonstrated in the following video. Since NetBox is the source of truth, it is the only place what you, or anyone on your team, will ever make changes. When you make changes, NetBox will fire off a webhook, so you'll need to configure an n8n webhook URL in Meraki to receive it. You'll also need to configure which alerts to send to the Splunk platform and a Splunk HTTP event collector (HEC) to receive those. Your HEC URL must include /raw at the end (example, https://<splunk-server>:8088/services/collector/event/raw).

This next video demonstrates the agentic workflow, including setting up the agents and designing specific instructions for those agents.

Now that the configuration is complete, let's see the workflow in action. In this first scenario, a change is properly made in NetBox and the agents work through the flow as intended.

And finally, the biggest benefit of this event-driven architecture - managing rogue activity. In this last video, a fictional developer makes an IP address change to a switch in the Meraki dashboard, rather than in NetBox. The system recognizes the drift, is able to correct the problem before the border gateway protocol fails due to the change, and provides a clear remediation report so you can take any additional steps you find necessary.

Additional resources

Now that you have an idea of how you can upgrade your network automation processes using agentic AI, watch the full talk from Cisco Live EMEA 2026, Enhancing Network Automation with Event-Driven Architecture. In the talk, you'll learn more detail on the software tools used in this use case and more about the configuration of each device.

In addition, the following resources might be of interest to you: