Anne Baretta decided to use netlab to test a proposed DMVPN topology. As netlab doesn’t support DMVPN (and probably never will), he decided to use netlab capabilities to start the lab topology and perform initial configuration, adding DMVPN configuration commands as custom configurations. Here’s how he described the process:
In this case I used netlab as a quick way to get a topology up and running, and then add the DMVPN configuration by hand.
I built a ‘3rd party’ underlay network in the lab, including the IPsec tunnel to the IoT provider, as well as the redundant hub DMPVPN overlay with two NHRP instances, and it behaves as expected.
I (mis)used the netlab config command to merge complete configuration files collected with netlab collect to limit the copying and pasting (for instance after changing the topology). For every device I’d execute a command like
netlab config config/hub1.cfg -l hub1, which I could also optimize with a Bash
for i in spoke1 spoke2 hub1 hub2 firewall iotprovider; do netlab config config/$i.cfg -l $i done
It’s a bit hacky, but it works (obviously within limits…). I am looking at a proper Jinja2 template, but while it’s fewer lines it is too ‘custom’ to be of much use 😕
An alternate solution would be to use per-node config parameter, for example:
nodes: spoke1: config: config/spoke1.cfg spoke2: config: config/spoke2.cfg hub1: config: config/hub1.cfg ...
Finally, a few gotchas:
- Obviously one wouldn’t have the configuration files when starting the lab for the first time, which would crash the final step in the device configuration process. That’s not a big deal (the lab would be running and configured), but if it bothers you, skip the custom configuration part of the lab initialization by running
netlab up --no-config(start the lab but don’t configure it) followed by
netlab initial -i -m(perform initial configuration and configure modules, but don’t use the custom configuration templates).
- Changing lab topology might change interface names, link IP prefixes, and interface IP addresses. It might be a good idea to clean up the collected device configurations after running netlab collect.
- Changed a link to netlab 1.5.2 documentation