Cisco ASR 9000 IOS XR Show Commands: IM, SYSDB and uIDB

2026年9月2日 LOG admin

When a Cisco ASR 9000 router running IOS XR misbehaves - interfaces stuck in the wrong state, sysDB verification failures, or memory alarms - the first escalation step is a family of support-level show commands that inspect the interface manager (IM), the system database (SYSDB), the micro-interface descriptor blocks (uIDB) and the watchdog thresholds. This article walks through the Advanced System Command Reference chapter on troubleshooting commands and explains what each command actually shows.

How the IOS XR Control Plane Is Organised

IOS XR is not a monolithic image like classic IOS. It is a distributed operating system built from several hundred independent processes that run in protected memory spaces and talk to each other over a publish/subscribe messaging layer. Each process owns one slice of the system - an interface's state, a protocol's database, the forwarding table - and there is no single global running-config that describes everything at once.

That design is why troubleshooting IOS XR looks different from troubleshooting IOS. Instead of inspecting one database, you inspect the processes and the databases they own. Four components matter more than any other when an interface or the control plane misbehaves:

Interface Manager (IM) - the process that owns interface state, flags, MTU, encapsulation and the set of clients registered against each interface.
Interface Manager Distribution Server (IMDS) - the distribution layer that broadcasts interface state to every interested client across the chassis.
System Database (SYSDB) - the configuration and operational data store, arranged as a tree with per-process client connections and periodic verification.
Micro-Interface Descriptor Block (uIDB) - the small in-memory record that represents a single interface handle.

When a fault crosses a layer boundary - the config commits but the interface never comes up, or the interface is up but a protocol client never sees it - the commands below tell you which layer stopped doing its job.

show im database - Interface Manager State

RP/0/RSP0/CPU0:router# show im database verbose interface null 0

The interface manager (IM) is the IOS XR process that owns interface state. show im database dumps what IM believes about an interface - flags, MTU, encapsulation, owner views, state transitions and checkpoint data. Options like brief, summary, ifhandle and view filter the database, and every query takes a location argument in rack/slot/module notation because IM runs per-node.

The output is dense but predictable. Look first at the interface flags block: entries such as IM_FLAGS_IF_IS_UP, IM_FLAGS_OPER_IS_UP or IM_FLAGS_DELETED describe what IM thinks the state is right now. Then look at the MTU and encapsulation fields and compare them with the running configuration. A mismatch between what the config says and what IM reports is almost always a commit that did not propagate, a sysDB tree that failed verification, or a client that holds a stale view of the interface.

The view option is the one people forget. Every subsystem that cares about an interface - L2, IPv4, IPv6, MPLS, QoS - registers a view with IM, and each view can carry its own flags. When an interface is up but traffic is not forwarded, dump the views and find the one whose flags do not match the operational state. That single command has ended more escalations than any other on this platform.

show imds interface brief - Distribution Checks

RP/0/RSP0/CPU0:router# show imds interface brief location 0/0/CPU0

IMDS is the interface manager distribution server. The brief output shows interface state, encapsulation, MTU and the ifhandle for every interface, which makes it fast to spot an interface whose state or MTU is not what the config says it should be.

IM and IMDS should always agree, but they are separate processes and can disagree when one is mid-restart or has crashed. The standard drill is to run show imds interface brief on the node and show im database brief for the same location, then diff the two. If IMDS shows an interface as down while IM shows it up, a client has been left stale; if IMDS shows the interface at all while IM does not, IMDS is holding a deleted entry. Both conditions point at a restart or a card OIR that did not complete cleanly, and both are visible in the IMDS and IM trace logs.

show sysdb connections and Verification Traces

RP/0/RSP0/CPU0:router# show sysdb connections
RP/0/RSP0/CPU0:router# show sysdb trace verification location 0/RP0/CPU0

SYSDB is the configuration and operational database at the heart of IOS XR. show sysdb connections lists which processes hold client connections to the database, while the trace verification commands display recent database transactions and confirm whether configuration changes were verified and accepted on the local or shared plane.

The connections list is the map of who is subscribed to which part of the config tree. When a commit hangs in the "verifying" phase, the process that never returns its verification reply is on this list. Cross-reference the client PID against show processes to see whether it is spinning, blocked or has restarted. On the RP and DRP both planes run their own SYSDB, so a commit that works on one plane and stalls on the other points at a single process or a single card rather than the whole chassis.

Verification traces are timestamped. Read them from the bottom up and find the first transaction that never produced an accept or reject record - that is where the commit stopped. A commit that repeatedly produces verification timeouts against the same client, with the same timeout value, is usually a card that is up enough to hold a SYSDB connection but not healthy enough to service it.

show uidb data and show uidb index

Every IOS XR interface is represented by a micro-interface descriptor block (uIDB). When interface resources run out or handles look corrupt, these commands show the index data (show uidb data), the trace log of uIDB events (show uidb trace) and the handle-to-interface mapping (show uidb index) per location. uIDB exhaustion is a classic root cause of "interface created but never comes up" on large routers.

RP/0/RSP0/CPU0:router# show uidb index location 0/0/CPU0
RP/0/RSP0/CPU0:router# show uidb data interface GigabitEthernet0/0/0/0

uIDBs are allocated per node from a fixed pool. Subinterfaces, bundle members and VLAN sub-interfaces all consume them, and on a router carrying tens of thousands of sub-interfaces the pool can be exhausted long before the configuration runs out of address space. When that happens the interface is accepted by SYSDB and IM but never gets a uIDB, so it stays down with no obvious error in the ordinary interface counters. show uidb index gives you the current allocation count against the pool size; show uidb trace shows the recent allocate and free events with the owning interface.

Two patterns are worth recognising. The first is a slow leak - the allocated count drifts upward across reboots and OIR events but never comes down, which usually means a client is not releasing handles it no longer needs. The second is a hard ceiling hit - the count sits at the maximum and every new sub-interface fails to come up. Both are handled by clearing the stale clients, reloading the affected node, and in the worst case a reload of the line card; but the data you need to justify that step is in these two commands.

show watchdog and Memory Thresholds

RP/0/RSP0/CPU0:router# configure
RP/0/RSP0/CPU0:router(config)# watchdog threshold memory location 0/RP0/CPU0 minor 30 severe 20 critical 10

Watchdog alarms fire when memory availability drops below the minor/severe/critical percentages (defaults 20/10/5). The example above raises the thresholds on the RP to catch memory pressure earlier, which is useful on a router that runs close to the edge but must not be caught out by a burst.

Use show watchdog and show memory summary to correlate the configured thresholds with live memory usage. Watchdog is not only about memory - the same framework watches process heartbeats, so a process that stops responding to its heartbeat triggers a watchdog action even when memory is fine. When you see a watchdog reload in the log, show watchdog tells you whether it was a memory threshold breach or a missed heartbeat, and that distinction changes whether you chase a leak or a hung process.

Correlating the Four Views

The real skill is reading the four data sources together rather than in isolation. Each combination points at a different layer, and once you have seen the patterns a few times you can name the layer before you have run every command.

SYSDB shows the config committed, IM shows the interface deleted or down. The interface exists in configuration but the hardware or the port has not been claimed. Check line-card presence with show platform, then the OIR history.
IM shows the interface up, IMDS shows it down. A distribution problem - a client is stale or IMDS is holding old state after a restart. This is a control-plane fault, not a port fault.
IM shows the interface up, the uIDB index is at the pool ceiling. Resource exhaustion. New sub-interfaces will fail to come up even though the parent looks healthy.
SYSDB verification is timing out against one client. That client process is the fault; the commit is fine and will succeed once the process is healthy.
Watchdog fired with a memory breach. Look for a leak in the process that was growing; if it fired on a missed heartbeat instead, look for a hung process.

Because IM and IMDS both run on the line-card CPU complex as well as the RP, always scope a query to the node you suspect. A fault that follows a single line card - every interface on that card down, every other card fine - is a node-local problem, and the same commands run with location 0/<x>/CPU0 for that slot will show it. A fault that follows every card points at the RP or the shared plane, and the RP-scoped queries are the ones that matter.

Caution on Support Commands

Commands in this module carry the cisco-support task ID and are normally used with Cisco TAC: several can affect performance or system behavior if misused. Run them read-only first and check task-group permissions with your AAA administrator before changing anything. A few of the trace and database commands generate large output that can itself load the control plane if you run them across every location at once, so scope each command to the node you are actually investigating.