Cisco IOS XR Base Configuration
Foundational configuration for Cisco IOS XR routers (ASR 9000, NCS 5500, CRS). Covers hostname, AAA, SSH, management VRF, NTP, and syslog.
What is it?
IOS XR is Cisco's carrier-grade operating system designed for service provider core and edge routers such as the ASR 9000, NCS 5500, and CRS platforms. Unlike IOS/IOS-XE, IOS XR uses a distributed architecture where each process runs independently — this means the system can upgrade individual processes without a full reload. Configuration is transaction-based: changes are staged in a candidate configuration and only applied to the running configuration when you issue a 'commit'. This prevents partial configurations from taking effect and allows rollback if errors are detected. IOS XR also enforces user groups and task-based authorization for granular access control.
When to use
- ·Service provider core, edge, and peering routers (ASR 9000, NCS 5500, CRS, 8000 series)
- ·Any environment requiring carrier-grade high availability and in-service software upgrades (ISSU)
- ·Deployments needing MPLS, Segment Routing, or 400G+ scale interfaces
- ·Networks where transaction-based configuration management and rollback are required
- ·Multi-chassis and distributed routing deployments at scale
When NOT to use
- ·Enterprise branch or access routers — use IOS-XE (ISR 4000, Catalyst 8000) which is simpler
- ·Small networks where the learning curve and licensing cost of IOS XR is not justified
- ·Environments where engineers are exclusively IOS/IOS-XE trained and no retraining budget exists
How it compares
Prerequisites
- →Physical or virtual access to the console port for initial configuration
- →Basic understanding of IOS XR's commit-based configuration model (changes are staged)
- →TACACS+ or RADIUS server reachable via management network for AAA
- →Management network planned with a dedicated VRF for out-of-band access isolation
- →NTP sources and syslog collectors identified as separate addresses, both reachable from the management VRF — a time source is not a log collector
Config Generator
e.g. UTC, America/New_York, Europe/Madrid
Where the router sends its logs. These are NOT the NTP servers — a syslog collector and a time source are different boxes, and pointing logging at the NTP servers leaves the device with no centralised logging while the config still commits cleanly.
Verification commands
show running-configView the committed running configuration
ExpectedShows only committed changes. Pending changes are in 'show configuration' before commit.
show interfaces MgmtEth0/RP0/CPU0/0Verify management interface is up/up with correct IP
ExpectedLine protocol is Up, correct IPv4 address shown
show ntp statusVerify NTP synchronization
ExpectedClock is synchronized, stratum should be <= 4
show aaaVerify AAA configuration is loaded
ExpectedAuthentication and authorization methods visible
Debug commands
show configuration failedShow why the last commit failed
WarningRun immediately after a failed commit to see validation errors
show configuration commit listShow commit history for rollback reference
WarningUse 'rollback configuration last 1' to undo the most recent commit
Common mistakes & fixes
Further learning
Recommended books to go deeper on this topic.
CCNA 200-301 Official Cert Guide Library
Wendell Odom · Cisco Press · Best starting point for Cisco IOS fundamentals — CLI, interfaces, basic routing
CCNP Enterprise Core ENCOR 350-401 Official Cert Guide
Brad Edgeworth et al. · Cisco Press · For engineers ready to go deeper — routing, switching, security, automation