Cisco c8000v#

The Cisco Catalyst 8000V is identified with cisco_c8000v kind in the topology file.

Cisco c8000v is a successor of Cisco CSR1000v and is a different product from Cisco 8000 platform emulator.

Hardware resource requirements#

Each c8000v node is started with 1vCPU and 4GB of RAM by default.

Managing c8000v nodes#

docker logs -f <container-name/id>

docker exec -it <container-name/id> bash

Credentials#

Default credentials: admin:admin

Interface naming#

You can use interfaces names in the topology file like they appear in Cisco Catalyst 8000V.

The interface naming convention is: GigabitEthernetX (or GiX), where X is the port number.

With that naming convention in mind:

• Gi2 - first data port available
• Gi3 - second data port, and so on...

The example ports above would be mapped to the following Linux interfaces inside the container running the Cisco Catalyst 8000V VM:

• eth0 - management interface connected to the containerlab management network (rendered as GigabitEthernet1 in the CLI)
• eth1 - first data interface, mapped to the first data port of the VM (rendered as GigabitEthernet2)
• eth2+ - second and subsequent data interfaces, mapped to the second and subsequent data ports of the VM (rendered as GigabitEthernet3 and so on)

When containerlab launches Cisco Catalyst 8000V node the GigabitEthernet1 interface of the VM gets assigned 10.0.0.15/24 address from the QEMU DHCP server, unless you use the Transparent Management, in which case the management interface will use the same network as the container host. This interface is transparently stitched with container's eth0 interface such that users can reach the management plane of the Cisco Catalyst 8000V using containerlab's assigned IP.

Data interfaces GigabitEthernet2+ need to be configured with IP addressing manually using CLI or other available management interfaces and will appear unset in the CLI:

node1#sh ip int br
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       10.0.0.15       YES manual up                    up      
GigabitEthernet2       unassigned      YES unset  administratively down down

Features and options#

Operating Modes#

The c8000v supports three modes via the type parameter:

• autonomous (default): Traditional IOS-XE routing
• controller: SD-WAN controller-managed mode
• ztp: day-zero boot for DHCP-based Zero Touch Provisioning

Controller mode#

topology:
  nodes:
    edge:
      kind: cisco_c8000v
      type: controller  # For SD-WAN managed devices
      image: vrnetlab/vr-c8000v:controller-17.11.01a

The controller mode requires an image tagged with the controller-$VERSION tag where the install phase is skipped.

When using controller mode, the device can either take a full SD-WAN bootstrap config or a regular device-config. If no config is provided the management interface will be in vrf 513 as a temporary management vrf. This is required as vpn 512 cannot be created without being in vManage mode in newer IOS-XE releases.

ZTP mode#

In ztp mode the node boots without any bootstrap configuration, which instructs IOS XE to start a DHCP client on every interface it has. It requires an image tagged with the ztp-$VERSION tag where the install phase is skipped.

For in-band ZTP start the node with network-mode: none. The container is not attached to the management network (no eth0), however endpoint links for data interfaces may still be added by containerlab directly.

topology:
  nodes:
    dut:
      kind: cisco_c8000v
      type: ztp
      image: vrnetlab/vr-c8000v:ztp-17.18.02
      network-mode: none   # no management interface -> ZTP runs in-band
    ztp-server:
      kind: linux
      image: <dhcp + artifact server>

  links:
    - endpoints: ["dut:Gi1", "ztp-server:eth1"]

For out-of-band ZTP start the node with CLAB_MGMT_PASSTHROUGH: true. This will bridge the routers management port onto the management network, where you also start a DHCP server.

topology:
  nodes:
    dut:
      kind: cisco_c8000v
      type: ztp
      image: vrnetlab/vr-c8000v:ztp-17.18.02
      env:
        CLAB_MGMT_PASSTHROUGH: "true"   # bridge the mgmt port onto the mgmt network
    dhcp:
      kind: linux
      image: <dhcp server>
      mgmt-ipv4: 172.20.20.10

Use DHCP option 67 to provide a full URL to the config, the file or script may be hosted in the same container as the DHCP server.

IOS-XE starts ZTP provisioning only on an empty startup-config. A startup-config on a ztp node is therefore rejected at deploy time. A lab may set startup-config at the kind or defaults level. To opt one node out of it, set suppress-startup-config on that node.

User defined config#

Use startup-config to provide a custom configuration file:

name: c8000v
topology:
  nodes:
    c8000:
      kind: cisco_c8000v
      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¹.

Lab examples#

name: c8000v
topology:
  nodes:
    node1:
      kind: cisco_c8000v
      image: vrnetlab/vr-c8000v:17.11.01a
    node2:
      kind: cisco_c8000v
      image: vrnetlab/vr-c8000v:17.11.01a

  links:
    - endpoints: ["node1:Gi2", "node2:Gi2"]