Use Existing Machine Configurations in netlab « ipSpace.internet weblog

Anne Baretta decided to use netlab to take a look at a proposed DMVPN topology. As netlab doesn’t guidance DMVPN (and likely hardly ever will), he determined to use netlab capabilities to get started the lab topology and conduct first configuration, adding DMVPN configuration instructions as customized configurations. Here’s how he described the system:

---

In this circumstance I employed netlab as a rapid way to get a topology up and functioning, and then incorporate the DMVPN configuration by hand.

I created a ‘3rd party’ underlay community in the lab, which include the IPsec tunnel to the IoT company, as properly as the redundant hub DMPVPN overlay with two NHRP scenarios, and it behaves as envisioned.

I (mis)utilized the netlab config command to merge complete configuration files gathered with netlab gather to restrict the copying and pasting (for instance just after changing the topology). For every single device I’d execute a command like netlab config config/hub1.cfg -l hub1, which I could also enhance with a Bash for loop:

for i in spoke1 spoke2 hub1 hub2 firewall iotprovider do
  netlab config config/$i.cfg -l $i
accomplished

It’s a little bit hacky, but it works (certainly within limits…). I am hunting at a proper Jinja2 template, but even though it is much less strains it is far too ‘custom’ to be of substantially use 😕

---

An alternate solution would be to use for each-node config parameter, for case in point:

nodes:
  spoke1:
    config: config/spoke1.cfg
  spoke2:
    config: config/spoke2.cfg
  hub1:
    config: config/hub1.cfg
  ...

Finally, a few gotchas:

• Naturally a single would not have the configuration data files when starting up the lab for the very first time, which would crash the final phase in the product configuration method. That is not a large offer (the lab would be working and configured), but if it bothers you, skip the personalized configuration section of the lab initialization by operating netlab up --no-config (start off the lab but really do not configure it) followed by netlab original -i -m (perform initial configuration and configure modules, but really don’t use the customized configuration templates).
• Transforming lab topology may possibly transform interface names, connection IP prefixes, and interface IP addresses. It may possibly be a very good idea to clean up the gathered machine configurations soon after functioning netlab gather.

Revision Record

2023-04-27

Modified a website link to netlab 1.5.2 documentation