---
search:
  boost: 4
kind_code_name: cisco_c8000
kind_display_name: Cisco 8000
---
# -{{ kind_display_name }}-
[-{{ kind_display_name }}- platform emulator](https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000-emulator/cisco8000-hardware-emulator-datasheet.html) is identified with `-{{ kind_code_name }}-` kind in the [topology file](../topo-def-file.md).


The 8000 emulator is an enhanced KVM hypervisor that emulates Cisco boards and chassis. The 8000 emulator VM is launched inside a container for ease of integration with ContainerLab.

## Getting Cisco 8000 ContainerLab docker images

Cisco customers can contact their Cisco account team to get access to Cisco 8000 ContainerLab docker images.

The obtained image archive can be loaded to local docker image store with (example):

```bash
docker image load -i 8201-32fh-clab_7.9.1.tar.gz
```

## Supported platforms

- Fixed form platforms  
  8101-32H, 8102-64H, 8201-32FH, 8201, 8202-32FH-M, 8711-32FH-M, 8711-48Z-M
- Modular chassis (8808 and 8804)  
  8800-LC-36FH, 8800-LC-48H, 8800-LC-36FH-M

Additional platforms will be supported on "as needed" basis.

## Host server requirements

- [Open vSwitch](https://www.openvswitch.org)
- [KVM](https://www.linux-kvm.org/page/Main_Page)
- Limit `/proc/sys/kernel/pid_max` to 1048575  
  `sysctl -w kernel.pid_max=1048575`

## Hardware resource requirements

Memory and cpu usage depends on XR features enabled and control/data plane traffic

- Fixed form platforms  
  Recommended 20GB memory and 4 cores per router

- Modular chassis  
  Recommended 64GB memory and 8 cores per router

## Managing c8000 nodes

!!!info
    Cisco 8000 nodes may take a few minutes to come to XR prompt. To monitor boot progress:
    ```bash
    docker logs <container-name/id> -f
    ```
    Wait for `Router up` message.

=== "SSH"
    `ssh cisco@<node-mgmt-address>`
    Password: `cisco123`

=== "XR console"
    to connect to a XR console (via telnet):
    ```bash
    docker exec -it <container-name/id> telnet 0 60000
    ```

=== "bash"
    to connect to a `bash` shell of a running c8000 container:
    ```bash
    docker exec -it <container-name/id> bash
    ```

=== "Netconf"
    Netconf server runs on `830` port:
    ```
    ssh cisco@<node-mgmt-address> -p 830 -s netconf
    ```

!!!info
    Default credentials: `cisco:cisco123`

## Interface naming convention

c8000 container uses the following naming convention for its management and data interfaces:

- `eth0` - management interface connected to the containerlab management network
- `Fi0_0_0_X` - 50G data interface mapped to `FiftyGigE0/0/0/X` internal interface.
- `Hu0_0_0_X` - 100G data interface mapped to `HundredGigE0/0/0/X` internal interface.
- `FH0_0_0_X` - 400G data interface mapped to `FourHundredGigE0/0/0/X` internal interface.

When containerlab launches c8000 node, it will set IPv4 address as assigned by docker to the `eth0` interface and c8000 node will boot with this address configured for its `MgmtEth0`.

```
RP/0/RP0/CPU0:r1#sh ip int br
Wed Dec 21 12:04:13.049 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
MgmtEth0/RP0/CPU0/0            172.20.20.5     Up              Up       default
```

## Features and options

### Node configuration

#### Default node configuration

It is possible to launch nodes of `-{{ kind_code_name }}-` kind with a basic config or to provide a custom config file that will be used as a startup config instead.

When a node is defined without `startup-config` statement present, containerlab will generate an empty config from [this template](https://github.com/srl-labs/containerlab/blob/main/nodes/c8000/c8000.cfg) and copy it to the config directory of the node.

#### User defined config

With a [`startup-config`](../nodes.md#startup-config) property a user sets the path to the config file that will be mounted to a container and used as a startup-config:

```yaml
name: c8201
topology:
  nodes:
    c8000:
      kind: -{{ kind_code_name }}-
      startup-config: r1.cfg
```

When a config file is passed via `startup-config` parameter it will be used during an initial lab deployment. However, a config file that might be in the lab directory of a node takes precedence over the startup-config[^1].

With such topology file containerlab is instructed to take a file `r1.cfg` from the current working directory and copy it to the lab directory for that specific node under the `/first-boot.cfg` name. This will result in this config acting as a startup-config for the node.

To provide a user-defined config, take the [default configuration template](https://github.com/srl-labs/containerlab/blob/main/nodes/c8000/c8000.cfg) and add the necessary configuration commands without changing the rest of the file. This will result in proper automatic assignment of IP addresses to the management interface, as well as applying user-defined commands.

## Lab examples

```yaml
name: test
topology:
  nodes:
    Cisco8201-1:
      kind: -{{ kind_code_name }}-
      image: 8201-32fh-clab:7.9.1
      image-pull-policy: Never
                    
    Cisco8201-2:
      kind: -{{ kind_code_name }}-
      image: 8201-32fh-clab:7.9.1
      image-pull-policy: Never

  links:
    - endpoints: ["Cisco8201-1:FH0_0_0_0", "Cisco8201-2:FH0_0_0_0"]
```

[^1]: if startup config needs to be enforced, either deploy a lab with `--reconfigure` flag, or use [`enforce-startup-config`](../nodes.md#enforce-startup-config) setting.
