search

networkop / k8s-topo

Topology builder for network simulations inside K8S
BSD 3-Clause "New" or "Revised" License
72 stars 18 forks source link

VMX random topology configuration #6

Closed tahir24434 closed 4 years ago

tahir24434 commented 4 years ago

There are two things which can be improved here

  1. Generation of random VMX topology also generates the router configuration files like examples/builder/config-random/vmx-192-0-2-0. However, the configuration file, generated for VMX topology, holds the cisco based configuration rather than Junos.

  2. While we are attaching these conf files to the pod using configmap, I'm still not sure whether we actually execute these configurations on router? I could not find anything in the code which load the attached configurations in the router device. Am I missing something here? If my assumption, that we do not load the conf file automatically, is true, then adding that capability would be a huge improvement.

networkop commented 4 years ago

The random topology builder was not designed to be multi-vendor. I used it just for tests and as far as I remember it only supports Quagga-style and Arista EOS style startup configs.

Regarding the startup configuration mounting - I've responded in the disqus comment in my blog. I'll duplicate it here for searchability.

This problem is solved differently depending on what image you use. If you use native container image (e.g. cEOS or Quagga), then it's simply a matter of mounting a volume inside a container where it expects to find the startup configuration. For KVM-based images there are two approaches:

  1. Mount the startup config inside the container, then inside the entrypoint, create a CD-ROM with that config inside and mount it to the VM. Inside the VM, you'd need to have a script that gets called early in the boot process that mounts CDROM, extracts and copies the startup file where it should be. Example of this approach is https://github.com/networkop/docker-topo/tree/master/topo-extra-files/veos
  2. For vrnetlab images, the startup configuration is fixed and includes a pre-defined management IP and standard username/password. The idea is to give that image a minimal configuration in order to be able to access it remotely. The rest of the configuration can be applied after the VM is booted via either ssh, netconf or any other protocol.
tahir24434 commented 4 years ago

Thanks for sharing your thoughts. It helped me. I follow the idea of creating drive image from conf file and attach the drive to the VM. I did this by modifying the vrnetlab code.