Providing real-time assurance for MPLS-to-SRv6 transitions

Prerequisites

The SRv6 topology

This is an example primary dashboard for an MPLS-SRv6 Operations Command Center. It shows BGP SRv6 service density (L3 and L2 service counts), Service-to-VRF Audit with SID-to-VRF Table ID mappings, and a VRF Route Leak Audit panel. 

Failure mode 1: Silent SID hardware exhaustion

The Cisco NCS 5500 ASIC enforces a hard limit of 16,000 segment IDs. When this ceiling is reached, the hardware stops programming new SIDs in the forwarding table without generating an alarm. Traffic using those SIDs is silently dropped. There is no native IOS-XR alert for this condition. 

The Splunk platform catches this by continuously tracking sids_count per locator against the known hardware limit, displayed as a utilization heatmap per router. In the dashboard below, the SID Utilization Heatmap panel shows R1 as 0.11% utilization—18 SIDs out of 16,000—well below the limit. As the migration progresses and more services are moved from MPLS to SRv6, the heatmap makes growth visible before the limit becomes a problem. Additionally, the Locator Age Timechart shows continuous uptime (no resets).  

Failure mode 2: Zombie SIDs 

Zombie SIDs appear correctly configured in software. They are visible in show commands and present in the YANG operational state with sid_functionvalue returning a value, but they haven't been successfully programmed into the hardware forwarding table. This causes several problems:

• Traffic forwarded to a zombie SID is silently dropped.
• No IOS-XR alarm fires.
• SNMP does not detect it. 

Detection requires cross-correlating the software SID state (sid_functionvalue: in-use vs. stale/pending) with the hardware FIB programming. When an SID is in-use in software but absent from the FIB routes, the Splunk platform flags it as a zombie. In the dashboard below, Router R1 has a Zombie SID alert at CRITICAL severity — a finding that would be invisible without this cross-layer validation. 

Additionally, in the TI-LFA (Topology-Independent Loop-Free Alternate) Resiliency Score panel, we see a score of 100%, which means the backup path is ready for a sub-50ms failover. Finally, we see the per-router compliance status from srv6/active/locator-all-sids data. 

Failure mode 3: Locator Age Resets

The SRv6 locator age, tracked via create_timestamp/age_in_nano_seconds in Cisco-IOS-XR-segment-routing-srv6-oper, measures the time since the locator was last established. A sudden drop in locator age to near-zero indicates that the locator process has restarted. This silent event can make all SIDs under that locator temporarily unreachable while the process re-initializes. 

The Locator Age Timechart panel makes this immediately visible: a healthy locator shows steadily increasing age. A drop to near-zero is an anomaly that warrants immediate investigation, even if no other alarm has fired.

Failure mode 4: Flex-Algorithm Path Compliance 

The Flex-Algorithm 128 in this environment is configured for low-latency path optimization. Traffic using Algo 128 should always follow the path with the minimum accumulated delay metric. When a router loses its Flex-Algo topology database, due to a process restart or a missing intermediate-system-to-intermediate-system (IS-IS) Flex-Algo advertisement, traffic can silently fall back to the standard interior gateway protocol (IGP) path, which violates latency SLAs. 

The SRv6 Topology Flow panel in the dashboard below displays a Sankey diagram derived from live FIB data. It shows actual traffic paths through the fabric. This makes Flex-Algo compliance visual: premium traffic following Algo 128 is traceable from the source router through each hop to the destination, confirming that the intended low-latency path is being used. 

Additional dashboards

Here, in the Percentage of Established BGP Neighbors panel, we see the value at 73%. This means that several neighbors are in an idle state, also shown in the BGP Session State Trends panel, which is determined from GNMI_BGP.session_state.  

Finally, this table shows the per-VRF prefix counts from Cisco-IOS-XR-fib-common-oper. ACI-MGMT is at 5 routes, and ACI_COMMON is at 172. These baseline values drop when upstream application centric infrastructure (ACI) bridge domain events occur.

The SPL behind the investigation

The information you will want to display in your Operations Network Command Center for SRv6 will vary by devices and topology. Here are some sample searches that you might want to include.

Purpose: Zombie SID detection. Cross-correlate SID software state with hardware FIB.

| mstats latest(_value) as val WHERE index="cisco_metrics" AND metric_name="Cisco-IOS-XR-segment-routing-srv6-oper:srv6/active/locator-all-sids/locator-all-sid.sid_functionvalue" BY source, locator_name, sid, state  
| search source=$device$ 
| eval is_zombie = if(state!="in-use", 1, 0) 
| stats sum(is_zombie) as zombie_count, count AS total_sids BY source
| eval Status = if(zombie_count > 0, "CRITICAL: ZOMBIE SIDs DETECTED", "OK: All Clear") 
| rename source AS Router, total_sids AS "Total SIDs", zombie_count AS "Zombie SIDs" 
| table Router, "Total SIDs", "Zombie SIDs", Status 

Purpose: Locator age reset detection. Near-zero age signals silent process restart.

| mstats latest("Cisco-IOS-XR-segment-routing-srv6-oper:srv6/active/locators/locator/info.create_timestamp/age_in_nano_seconds") AS age_ns WHERE index=cisco_metrics AND source="$device$" BY source, name, span=5m  
| eval age_hours = round(age_ns / 3600000000000, 3)  
| timechart span=5m avg(age_hours) AS "Locator Age (hrs)" BY name 

Purpose: BGP SRv6 service count. Track L3VPN and EVPN service scale per router.

index=cisco_mdt sourcetype="cisco:mdt:bgp" 
| mstats latest("Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/process-info.global/prefix_sid_srv6_layer3_svc_count") AS l3_count latest("Cisco-IOS-XR-ipv4-bgp-oper:bgp/instances/instance/instance-active/default-vrf/process-info.global/prefix_sid_srv6_layer2_svc_count") AS l2_count WHERE index=cisco_metrics AND source="$device$" BY source, span=5m  
| timechart span=5m sum(l3_count) AS "L3 SRv6 Services" sum(l2_count) AS "L2 EVPN Services" by source

Purpose: FIB route count per VRF. Detect upstream prefix withdrawals affecting customer VRFs.

| mstats  
    latest("fib_summary.routes") as Prefixes 
    latest_time("fib_summary.routes") AS last_seen 
    WHERE index=cisco_metrics AND source="$device$" vrf_name="$vrf_name$" node_name="$node_name$" 
    BY source, node_name, protocol_name, vrf_name 
| eval "Last Updated" = strftime(last_seen, "%Y-%m-%d %H:%M:%S") 
| eval vrf_name=replace(vrf_name, "\\*+", "iid") 
 
| rename source AS "Device IP", node_name AS "Node", protocol_name AS "Protocol", vrf_name AS "VRF" 
| table "Device IP", "Node", "VRF", "Protocol", Prefixes, "Last Updated" 
| sort "VRF", "Protocol" 

Summary: What SRv6 migration operations actually require

Traditional monitoring tools monitor device state. They check if interfaces are up, if BGP sessions are established, and if SNMP traps have fired. This is sufficient for stable, mature technology. However, SRv6 interworking is neither stable nor mature in most deployments. It is an active transition with novel failure modes that don't map to traditional alarm conditions. 

The Splunk platform fills this gap by treating it as a data problem. The YANG paths for zombie SID detection, locator age monitoring, and SID hardware utilization exist in Cisco IOS-XR. The Cisco MDT collects them. SPL correlates them. The Network Monitor SRv6 dashboard surfaces them with operational context. None of this requires a proprietary SRv6 monitoring module. It requires a platform flexible enough to collect any telemetry, correlate any data sources, and surface any operational signal that matters. 

For network teams managing this transition today, that flexibility is exactly what the operational model demands. SRv6 is still evolving. New capabilities, new hardware platforms, and new failure modes will emerge. A platform that lets operations teams adapt their own telemetry collection and detection logic as the technology matures is the right foundation for managing a network that is still evolving.

Next steps

Ready to learn more about providing network assurance in your organization? Check out the other articles in this series:

• Troubleshooting cross-domain network problems in minutes
• Operating Meraki branch networks at scale
• Assuring enterprise WAN services with Splunk
• Creating cross-domain visibility in campus infrastructure
• Monitoring MPLS backbone infrastructure in real time