Persistent Serial Numbers?

[petercrocker]

Question: How do we keep serial sumbers of the network devices persistent with Netsim before and after restarting the lab? The SN is the primary key we're using to compare across two points in time.

Here’s what I tried:

• Setup node ID
• tried to edit VMs XML config with virsh edit … & reloaded the VM afterwards
• added serial tag to multiple locations in the file without any success
• tried updating the vagrant file with a list of serial numbers and hostnames
  • config.vm.serial is not existing property
  • config.vm.uuid doesn’t work
• hardcoding a serial into a config is not available for all vendors (we need a vendor neutral solution)

Any suggestions how else we could do this?

[ipspace]

Let's start with the basics:

• netlab can only work its magic if it recreates the lab from scratch (Vagrant boxes or containers)
• While it might be possible to resume an existing lab (and retain serial numbers), resuming network device virtual machines doesn't always work (as in 'I tried and failed')

As netlab rides on top of existing orchestration systems (= Vagrant), it makes sense to use whatever those systems can offer. Trying to go around them should be the absolute last resort.

Now for the hard question: where do network device VMs get their serial numbers from and how could we influence that? I'm afraid the first part is device-specific and have no idea what to do with the second part of the question until we have a definitive answer to the first part.

[ipspace]

... no idea whether this could work in your environment, but you could try to identify the devices by the management interface MAC address in case the serial number check fails.

[milanzapletal]

Hi @ipspace,

thank you for the comment. The issue is that the SN is the main ID for our DB records for the whole platform. When changed after the lab reboot, the new snapshot is not comparable to any previous snapshot (those are then completely different devices).

[ipspace]

Yeah, I get that, but it looks like you have three options:

• Fight the windmills (= networking vendors). Apart from an occasional public naming-and-shaming I stopped doing that years ago, it's not worth the effort.
• Use something else for device identifier (or create fake serial numbers during the polling process if you're working with lab devices)
• Give up

[ssasso]

I would say that a VM Serial Number is derived from SMBIOS Data, i.e. https://libvirt.org/formatdomain.html#smbios-system-information .
If that is the case, sysinfo can be written by vagrant-libvirt. - https://vagrant-libvirt.github.io/vagrant-libvirt/configuration.html

@petercrocker can you try with that?

[milanzapletal]

Hi @ssasso,
thanks for the answer. I tried to change the serial number of the newly virtualized box from the main VagrantFile (located at ~/.vagrant.d/boxes/) and I tried plenty of different options. But unfortunately, none of them worked.

The closest one was to use the list of specific values at https://github.com/rgl/pxe-vagrant/blob/master/Vagrantfile (line 101) - that was even producing some on-screen information during the boot:

==> artest1: -- Command line args:
==> artest1: -> value=-smbios,
==> artest1: -> value=type=1,serial=type01serial,
==> artest1: -> value=-smbios,
==> artest1: -> value=type=3,serial=type03serial,

But still, the SN of the device remained unchanged. I appreciate any advice. Thank you.

[ipspace]

@milanzapletal It might be helpful to know what device you're talking about ;)

From a more generic perspective, none of us can influence how vendors create serial numbers for virtual devices, and in many cases that's not even documented. Worst case: it gets burned into the Vagrant box, so all devices from the same vendor have the same serial number.

Someone might have an idea how to solve the problem for a particular device (but it would help to know what device we're talking about ;), but there's no generic solution -- that's why I suggested using something else.

[milanzapletal]

Hi @ipspace,

Thank you for the suggestions. I appreciate it.

The box I am testing modifying the SN is Arista 4.27.0F, but the lab is full of other vendors. Therefore, I am searching for a vendor-agnostic solution.

My lack of knowledge about virtualization software doesn't help, but I will keep looking and testing for some time and I will see whether I find any other option.

[ipspace]

Looks like you're not the only one with this problem, and it seems there's no solution:

https://arista.my.site.com/AristaCommunity/s/question/0D52I00007ERq5HSAT/using-veos-for-ztp-tests-cannot-find-any-serial-number

[jbemmel]

In case of Nokia SR OS, the license is tied to the VM UUID which can be configured as follows (in Containerlab):
https://containerlab.dev/manual/kinds/vr-sros/#license

[sdargoeuves]

Related to this subject, there is this option for Arista vEOS which I thought was worth sharing here: Override SN in Arista vEOS

As of vEOS 4.14.0, the serial number and system mac address can be configured with a file in /mnt/flash/veos-config. After modifying SERIALNUMBER or SYSTEMMACADDR, a reboot is required for the changes to take effect.

SERIALNUMBER=ABC12345678
SYSTEMMACADDR=1122.3344.5566

[ipspace]

I think we came to a conclusion that this is a Mission Impossible.

[sdargoeuves]

As part of a project I am working on (more to come in a different discussion), I have found a solution that works for me: netlab up --snapshot.

When you reboot your server, your lab will be down. I initially thought that was it, and I would need to perform netlab restart, which would DELETE and RECREATE the lab. The problem was that I did not know about the command netlab up --snapshot: it will restart the lab without deleting it, using the netlab.snapshot.yml file.

It's written in the docs:

You can use netlab up to create configuration files and start the lab, or use netlab up --snapshot to start a previously created lab using the transformed lab topology stored in netlab.snapshot.yml snapshot file.

With this in mind, if someone restarts my server, there's no need to cry and scream for hours; I just need to:

netlab up --snapshot

And magically, the lab will go back to its initial state. I'm sure there are caveats depending on configuration changes, so it may not be exactly the initial state, but it could be close!
In my situation, it's not an issue, and at least I've got my devices with their initial SN!

I hope that helps :)

[ipspace]

Thanks a million for the feedback.