Skip to content

Cisco IOL#

Cisco IOL (IOS On Linux or IOL for short) is a version of Cisco IOS/IOS-XE software which is packaged as binary, in other words it does not require a virtual machine, hence the name IOS On Linux.

It is identified with cisco_iol kind in the topology file and built using vrnetlab project and essentially is the IOL binary packaged into a docker container.

Getting and building Cisco IOL#

You can get Cisco IOL from Cisco's CML refplat .iso. It is identified by the iol or ioll2 prefix.

From the IOL binary you are required to build a container using the vrnetlab project.

IOL is distributed as two versions:

  • IOL - For usage as an L3 router, lacks L2 switching functionality.
  • IOL-L2 - For usage as a virtual version of an IOS-XE switch. Still has support for some L3 features. See usage information.

Resource requirements#

Cisco IOL is very light on resources compared to VM-based Cisco products. Each IOL node requires at minimum:

  • 1vCPU per node, you are able oversubscribe and run many IOL nodes per vCPU.
  • 768Mb of RAM.
  • 1Mb of disk space for the NVRAM (where configuration is saved).

Using KSM you can achieve a higher density of IOL nodes per GB of RAM.

Managing Cisco IOL nodes#

You can manage the Cisco IOL with containerlab via the following interfaces:

to connect to the IOL CLI

ssh admin@<container-name/id>

to connect to a bash shell of a running IOL container:

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

Note

Default credentials: admin:admin

Interface naming#

You can use interfaces names in the topology file like they appear in the Cisco IOL CLI.

The interface naming convention is: Ethernet0/X (or e0/X), where X is the port number.

With that naming convention in mind:

  • e0/1 - First data-plane interface available
  • e0/2 - Second data-plane interface, and so on...

Keep in mind IOL defines interfaces in groups of 4. Every four interfaces (zero-indexed), the slot index increments by one.

  • e0/3 - Third data-plane interface
  • e1/0 - Fourth data-plane interface
  • e1/1 - Fifth data-plane interface

The example ports above would be mapped to the following Linux interfaces inside the container running Cisco IOL:

  • eth0 - management interface connected to the containerlab management network. Mapped to Ethernet0/0.
  • eth1 - First data-plane interface. Mapped to Ethernet0/1 interface.
  • eth2 - Second data-plane interface. Mapped to Ethernet0/2 interface
  • eth3 - Third data-plane interface. Mapped to Ethernet0/3 interface
  • eth4 - Fourth data-plane interface. Mapped to Ethernet1/0 interface
  • eth5 - Fifth data-plane interface. Mapped to Ethernet1/1 interface and so on...

When containerlab launches Cisco IOL, the Ethernet0/0 interface of the container gets assigned management IPv4 and IPv6 addresses from docker. The Ethernet0/0 interface is in it's own management VRF so that configuration in the global context will not affect the management interface.

Interfaces can be defined in a non-contigous manner in your toplogy file. See the example below.

name: my-iol-lab
topology:
  nodes:
    iol-1:
      kind: cisco_iol
      image: vrnetlab/cisco_iol:17.12.01
    iol-2:
      kind: cisco_iol
      image: vrnetlab/cisco_iol:17.12.01

  links:
    - endpoints: ["iol-1:Ethernet0/1","iol-2:Ethernet0/1"] 
    - endpoints: ["iol-1:Ethernet1/3", "iol-2:Ethernet1/0"]

Warning

When defining interfaces non-contigiously you may see more interfaces than you have defined in the IOL CLI, this is because interfaces are provisioned in groups.

At minimum you will see all numerically-lower indexed interfaces in the CLI compared to the interface you have defined, you may also see interfaces with a higher numerical index.

Links/interfaces that you did not define in your containerlab topology will not pass any traffic.

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

iol#sh ip int br
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            172.20.20.5     YES TFTP   up                    up
Ethernet0/1            unassigned      YES unset  administratively down down
Ethernet0/2            unassigned      YES unset  administratively down down
Ethernet0/3            unassigned      YES unset  administratively down down

Usage and sample topology#

IOL-L2 has a different startup configuration compared to the regular IOL. You can tell containerlab you are using the L2 image by supplying the type field in your topology.

See the sample topology below

name: iol
topology:
  nodes:
    router1:
      kind: cisco_iol
      image: vrnetlab/cisco_iol:17.12.01
    router2:
      kind: cisco_iol
      image: vrnetlab/cisco_iol:17.12.01
    switch:
      kind: cisco_iol
      image: vrnetlab/cisco_iol:L2-17.12.01
      type: l2
  links:
    - endpoints: ["router1:Ethernet0/1","switch:Ethernet0/1"]
    - endpoints: ["router2:Ethernet0/1","switch:e0/2"]