Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addition of Cisco 1000v and 9300v with Containerlab Support #1168

Open
fluffytrlolz opened this issue May 9, 2024 · 1 comment
Open

Addition of Cisco 1000v and 9300v with Containerlab Support #1168

fluffytrlolz opened this issue May 9, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@fluffytrlolz
Copy link

I'm looking for support for the Cisco 9000v (9300v) and 1000v with the containerlab platform. I've tested it out, and it looks like it may be close, less the interface names that netlab sets up and passes into the clab.yml file. As an example :

interfaces:
- ifindex: 1
  ifname: Ethernet1/1
  ipv4: 10.1.0.1/30
  linkindex: 1
  name: r1 -> r2
  neighbors:

If the ifname was changed to "eth1", this would align with containerlab topology file and I believe the remaining pieces would not require change.

I'm happy to help with testing out any implementations to assist in this update.

Thanks!

@fluffytrlolz fluffytrlolz added the enhancement New feature or request label May 9, 2024
@ipspace
Copy link
Owner

ipspace commented May 10, 2024

CSR1000v should be a simple case of interface name mapping. The interfaces will have one name within the container, and another name within the virtual machine inside the container (I'm assuming you're doing this stuff: https://containerlab.dev/manual/kinds/vr-csr/)

To do that, you have to define a bunch of stuff under devices.csr.clab. The easiest way to start would be to define them in the topology file:

defaults:
  devices.csr.clab:
    image: <docker-image>
    node.kind: cisco_csr1000v
    interface.name: eth{ifindex+1}

I'm guessing the interface.name bit based on vMX definition.

Next, you'll have to write an 'are we ready' task list because the container starts "immediately" while the VM within the container takes "forever". See https://github.com/ipspace/netlab/blob/dev/netsim/ansible/tasks/readiness-check/vptx.yml for an example).

Alternatively, if you could somehow get the two Docker images over to me, I will try to figure it all out ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants