At Splunk .conf26, Cisco and Splunk made their case for correlated, cross-domain observability: the network, security operations, and AI infrastructure treated as one operational system, with Splunk as the layer that ties them together. The centerpiece for network teams is the new Network Intelligence App, which, in Cisco’s words, “brings Cisco network topology, device health, and events into Splunk, so network teams can trace an alert straight to the device behind it and the network around it.”
It is a genuinely useful direction. It also rests on a precondition that is easy to miss in the announcements, and the sharpest coverage of the event named it directly. Writing in Network World, Zeus Kerravala’s advice to network engineers was blunt: “First, normalize cross-domain telemetry. Correlated observability depends on accurate device inventory, topology information, timestamps, service ownership, and consistent tagging. Fix those foundational issues before expecting AI to deliver credible root-cause analysis.”
That is the whole story in one sentence. The correlation, the AI, the single operational view are only as good as the telemetry underneath them. And in most real networks, that telemetry is neither complete nor consistent, because real networks are not single-vendor.
Real Networks Are Multi-Vendor
The Network Intelligence App brings Cisco topology, device health, and events into Splunk, and for the Cisco estate that is a real step forward. The word worth noticing is simply the scope: it covers Cisco devices.
Most enterprise networks run more than one vendor. Campus, branch, data center, and cloud environments mix Cisco with Juniper, Arista, Palo Alto, Fortinet, Aruba, F5, and others. That is not a criticism of any vendor’s tooling; it is the nature of how networks are built. And it means correlated observability, which depends on normalized telemetry across the whole network, needs a foundation that spans every vendor, not only one. Wherever the estate includes non-Cisco devices, the shared operational view is only as complete as the telemetry feeding it from those devices too.
Correlated observability depends on normalized telemetry across the whole network. A device-health feed scoped to a single vendor delivers that foundation for part of the estate and leaves the rest as blind spots. Multi-vendor coverage is not a nice-to-have here. It is the difference between a correlation that holds and one that breaks at the first non-Cisco hop.
Where NetFlow Optimizer Fits
NetFlow Optimizer (NFO) exists to produce exactly the foundation Kerravala describes, across every vendor rather than one. It does the normalization work the correlated-observability vision assumes is already done.
- Multi-vendor device health. NFO polls network devices over SNMP, and receives streamed Model-Driven Telemetry where devices support it, for interface status, utilization, errors and discards, and device CPU and memory, across every vendor that speaks these standards, not one.
- Multi-vendor traffic telemetry. NFO parses the binary NetFlow, IPFIX, sFlow, and J-Flow that routers, switches, and firewalls export, which Splunk cannot ingest raw, and enriches each record with user identity, application, threat intelligence, and geographic context.
- Accurate device inventory. NFO’s SNMP auto-discovery keeps a current inventory of network devices rather than a hand-maintained list that drifts. That is the “accurate device inventory” the normalization recommendation puts first.
- Multi-vendor topology. Auto-discovery maps not just the devices but the connections between them, including L2 and L3 relationships and actual traffic paths derived from NEXT_HOP data. That is the “topology information” the same recommendation calls for, across vendors rather than one. NFO produces the topology; the visualization is rendered in Splunk.
- Consistent, CIM-aligned fields. NFO normalizes all of it to a common vocabulary, so a metric means the same thing regardless of which vendor or collection method it came from. That is the “consistent tagging” the same recommendation ends on.
The result is that the device health, traffic, inventory, and topology for the whole network, Cisco and everything else, arrive in Splunk already normalized and enriched, in the shape correlated observability needs.
| .conf26 foundation requirement | What NFO provides, all vendors |
| Accurate device inventory | SNMP auto-discovery, kept current |
| Topology information | Device connections, L2/L3, NEXT_HOP paths |
| Device and interface health | SNMP polling and MDT streaming |
| Consistent fields and tagging | Normalized to a common CIM vocabulary |
| Network traffic context | Enriched NetFlow, IPFIX, sFlow, J-Flow |
Complementary, Not Competing
This is not an argument against the Network Intelligence App. It is an argument for completing the picture it starts. The app brings Cisco topology and device health into Splunk with depth that a general-purpose pipeline does not attempt: Cisco-specific fabric detail and the topology understanding Cisco knows best for its own hardware. NFO does not do the synthetic testing that ThousandEyes Network Insights adds for paths beyond the enterprise edge. That is a real capability in its own lane.
What NFO adds is breadth: normalized device health, enriched traffic telemetry, and discovered topology from every vendor in the estate, plus the accurate inventory that correlation depends on. Cisco depth and multi-vendor breadth are not the same job, and correlated observability needs both. An organization running the Network Intelligence App for its Cisco fabric and NFO for normalized multi-vendor telemetry has the foundation the .conf26 vision assumes, across the whole network rather than part of it.
Why This Matters More in the AI Era
The .conf26 story is ultimately about AI: agents that run across campuses, branches, and data centers, generate less predictable east-west traffic, and may act at machine speed. Splunk’s own framing is that these systems must be observed and governed, not just deployed. Every part of that depends on the same foundation. An AI-assisted root-cause analysis, an agentic response, a cost-attribution decision about where to run inference, each is only as trustworthy as the telemetry it reasons over.
If that telemetry covers only the Cisco devices and leaves the rest of the network unnormalized, the AI reasons over a partial picture and reaches confident conclusions about an incomplete network. Normalized, multi-vendor telemetry is not a pre-AI concern that AI makes obsolete. It is the thing AI makes non-negotiable.
The Bottom Line
The .conf26 announcements point at a real and valuable future: correlated observability across network, security, and AI, with Splunk as the connecting layer. The coverage of the event named the precondition plainly, normalize cross-domain telemetry, maintain accurate inventory and topology, keep fields consistent, before expecting AI to deliver credible answers. The Network Intelligence App delivers that foundation for Cisco devices. NetFlow Optimizer delivers the same normalized device health, enriched traffic, topology, and accurate inventory across every vendor in the network.
Correlation is only as good as what it correlates. Make the foundation multi-vendor, and the vision holds across the whole network, not just the part that speaks one vendor’s telemetry.
Building the telemetry foundation for correlated observability in Splunk? Start a free 60-day trial of NetFlow Optimizer or schedule a technical demo with a NetFlow Logic engineer.
Start Free Trial | Schedule a Demo | Splunk Integration | NFO Documentation