The Cisco CSR 1000v build process includes updating the QCOW VM image (good) which results in the management MAC address being stored "somewhere". The build process tries to cope with that, but the current workaround no longer works with release 17.03.04a. Once the container is started, the VM consistently boots with the first interface being GigabitEthernet2 (not GigabitEthernet1) and then everything goes down the drain.
The fix is simple: make the MAC address of the management interface constant (not random). It shouldn't matter as the management MAC address is not visible outside of the container.
However, to be on the safe side, the static MAC address is used only when the child class requests it via the _static_mgmt_mac object property.
hellt
commented
5 months ago
The Cisco CSR 1000v build process includes updating the QCOW VM image (good) which results in the management MAC address being stored "somewhere". The build process tries to cope with that, but the current workaround no longer works with release 17.03.04a. Once the container is started, the VM consistently boots with the first interface being GigabitEthernet2 (not GigabitEthernet1) and then everything goes down the drain.
The fix is simple: make the MAC address of the management interface constant (not random). It shouldn't matter as the management MAC address is not visible outside of the container.
However, to be on the safe side, the static MAC address is used only when the child class requests it via the _static_mgmt_mac object property.