> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/switch-infrastructure/config-manager/llms.txt.

# Cisco IOS XR

Config Manager manages Cisco IOS XR routers over NETCONF (SSH subsystem, port 830). IOS XR supports most of what Juniper Junos supports (rescue configuration and OS image installation are not available yet, [as outlined in Limits](#limits)): [Configuration Backup](/switch-infrastructure/config-manager/user-guides/configuration-deploy/configuration-backup), [Site Configuration Backup](/switch-infrastructure/config-manager/user-guides/configuration-deploy/site-configuration-backup), [Configuration Deploy](/switch-infrastructure/config-manager/user-guides/configuration-deploy/configuration-deploy), [Multi-Device Deploy](/switch-infrastructure/config-manager/user-guides/configuration-deploy/multi-device-deploy), [Cable Validation](/switch-infrastructure/config-manager/user-guides/validation/cable-validation), [Device Password Rotation](/switch-infrastructure/config-manager/user-guides/lifecycle/device-password-rotation), [Site Password Rotation](/switch-infrastructure/config-manager/user-guides/lifecycle/site-password-rotation), a diagnostics catalog, and ZTP DHCP options. Hardware validation is Cumulus-only.

## Prerequisites

* The device's Nautobot platform is named `Cisco IOS XR`. The bundled bootstrap data creates it together with the `Cisco` manufacturer.
* NETCONF is enabled on the router and TCP port 830 is reachable from the Config Manager network. On the router (replace `MGMT` with the management VRF):

  ```text
  configure terminal
  netconf-yang agent ssh
  ssh server v2
  ssh server netconf vrf MGMT
  ssh server netconf port 830
  commit
  ```

  The exact syntax varies slightly between XR releases. The router must advertise the `:candidate` and `:confirmed-commit` NETCONF capabilities.
* The service account is present on the router with a task group that allows NETCONF (for example `root-lr`).
* The service account password is in the secrets store for the device's site. Config Manager tries each configured password in turn.
* A template plugin renders an intended configuration for the device. The Render Service selects it by `<platform>/<role>/<desired firmware>`, so the `cisco-ios-xr` directory is used for this platform. The rendered file is named `full-config`.

## How it behaves

| Operation             | What Config Manager does                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Backup                | Reads the running configuration through NETCONF (`show running-config`), removes lines that are not configuration (clock line, comments, `end`), redacts secret values, and stores the text.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| Drift and Deploy diff | The router computes the diff. Config Manager locks the candidate configuration, discards any pending candidate changes, copies the complete intended configuration onto the candidate (NETCONF `copy-config` of the `cli` leaf of `Cisco-IOS-XR-cli-cfg`), and asks the router for the difference with the `get-cli-config-diff` action. It then discards the candidate and unlocks it, so the running configuration is not changed. Lines only on the router start with `-` and lines only in the intended configuration with `+`. A line that exists on both sides with different text is listed as a pair that starts with `#` (the old line, then the new one). An empty diff means the router matches. On a large configuration the copy takes tens of seconds. |
| Deploy                | Replaces the router's configuration with the intended configuration: the same copy onto the candidate, a check that the router's diff equals the approved diff, and one atomic commit. A failed copy or commit leaves the router unchanged.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
| Commit timer          | When the timer is enabled, Config Manager commits with a NETCONF confirmed commit, opens a second NETCONF session to prove the account still works, copies the intended configuration onto the candidate again and checks that the router reports no differences, and only then confirms. If either check fails it does not confirm, and the router rolls itself back when the timer expires.                                                                                                                                                                                                                                                                                                                                                                        |

## Safety checks before a Deploy

A full-configuration Deploy removes everything the intended configuration omits. Before anything is loaded on the router, Config Manager refuses to continue when the intended configuration would remove or break any of the following:

* The account Config Manager logs in with (`username` block and its `group` lines)
* The interface that carries the management address, and every `MgmtEth` interface (the interface, its IPv4 address, its VRF). A change to shut any of these down is also refused.
* Any `ssh server` line (including `ssh server netconf`), the `netconf-yang agent` and its `ssh` transport, any `aaa authentication` line or VTY `transport` line that the router has
* The management default route

The refusal names the missing item. Add it to the template or the Nautobot data and render again.

## Secrets and other data the template needs

A Deploy removes whatever the intended configuration omits, so the template renders everything the router needs, and stops the render when something is missing instead of leaving it out. Nautobot holds names only; the values are in the secrets store of the device's site.

| On the router                                                          | Nautobot (names, never values)                                                                                            | Secrets store                                    |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ |
| Login accounts                                                         | `password_mappings` config context                                                                                        | `<secret>_<rotation>`, hashed with the site salt |
| `snmp-server community`                                                | `snmp_communities` config context: secret name, `authorization`, `clients` (IPv4 prefixes, rendered as an access list)    | the community string                             |
| MACsec `key chain`                                                     | `macsec_key_chains` config context: `name`, `start_time`, `secret`, `ckn`, optional `algorithm`, `policy`, `associations` | the `key-string` text and the key name           |
| Port breakout and `apply-group`                                        | interface custom fields `sub_port_count`, `port_speed`, `interface_profile`                                               | none                                             |
| `interface tunnel-te`, `router bgp / vrf`, `evpn` and `l2vpn xconnect` | the routing app (LSPs, peer groups with a VRF and its RD, EVPN-VPWS services)                                             | none                                             |

Both `snmp_communities` and `macsec_key_chains` must exist on the device (an empty list is fine), or the render stops. MACsec policies, configuration groups, and VRF definitions are static template baseline; the render stops if a key chain, policy, access list, or group is used and not defined.

## Limits

* Partial configuration is not supported. You must supply the full desired state. The copy replaces the whole candidate, so a partial configuration would remove everything it omits.
* The router can list stanzas such as prefix-sets in the commit with the same entries in a different order. These reorder-only rewrites are not in the approval diff, so a commit can be larger than the diff shown.
  * Lines that start with `#` are shown in the diff and count as changes.
* A Deploy with the commit timer does not report success when the router already matches an approved diff. An earlier attempt may have sent the confirmed commit and ended before confirming it, and the router rolls back when the timer expires. The run fails with a message; wait for the timer to expire, then run Config Diff. An empty diff means the change is permanent; otherwise run Deploy again.
* The Diagnostics workflow offers version, interfaces, LLDP neighbors, and ARP table for IOS XR. The route table and BGP summary are not available yet.
* Rescue configuration and the rollback diff are not supported for IOS XR: the router has copy and delete actions but none that reads or loads a file. Numbered rollback and ZTP initiation use the router's YANG actions; rollback commits at once and has no timer.
* [Switch OS Upgrade](/switch-infrastructure/config-manager/user-guides/lifecycle/switch-os-upgrade) rejects IOS XR devices: it needs an image install, which Config Manager does not do for XR yet.
* Secret values are redacted in backups and drift displays. The Deploy approval diff shows what will be sent, so treat it as sensitive. The intended configuration in the Config Store contains the rendered secret values.
* Not modelled: tunable-optics wavelength (the render stops), LSP attributes such as priorities and bandwidth, IPv6 SNMP client lists, and more than one MACsec key per chain.