search

GNS3 / gns3-vm

FOR DEVELOPMENT ONLY GO TO GNS3.COM FOR THE VM WITH GNS3 INCLUDED
http://www.gns3.com
GNU General Public License v3.0
88 stars 31 forks source link

GNS3 VM migration fails because new GNS3 VM has same mac address #175

Closed josephmhiggins closed 1 year ago

josephmhiggins commented 1 year ago

The new gns3 vm is version 2.2.41. I chose decimal values for the eth interrfaces. Please note that I did not know how to change /sys/class/net/eth0/address it would not let me edit it and I had no idea what service, if any, I had to stop. I rewrote netplan. I chose to embed a decimal representation of the gns3 version in the 4th and 5th octet and left the 6th octet for the eth number.

If linux only supports < 128 vmnets, then the 1st order bit can be reserved for 2.2.40.1 linux vmware supports either 90 or 190 vmnets - I forget which and I can not find it now.

My fix works with ipv6 also, for those who only want an ipv6 network only. All ipv6 link-local addresses will be unique for each gns3 version.

nano 80_gns3vm_default_netcfg.yaml

! This file describes the network interfaces available on your system ! For more information, see netplan(5). network: version: 2 renderer: networkd ethernets: eth0: match: macaddress: 00:0c:29:7a:1b:6a macaddress: 00:0c:29:22:41:00 dhcp4: yes dhcp-identifier: mac eth1: match: macaddress: 00:0c:29:7a:1b:74 macaddress: 00:0c:29:22:41:01 dhcp4: yes dhcp-identifier: mac eth2: match: macaddress: 00:0c:29:7a:1b:7e macaddress: 00:0c:29:22:41:02 dhcp4: yes optional: true dhcp-identifier: mac eth3: match: macaddress: 00:0c:29:7a:1b:88 macaddress: 00:0c:29:22:41:03 dhcp4: yes optional: true dhcp-identifier: mac eth4: dhcp4: yes optional: true dhcp-identifier: mac eth5: dhcp4: yes optional: true dhcp-identifier: mac eth6: dhcp4: yes optional: true dhcp-identifier: mac eth7: dhcp4: yes optional: true dhcp-identifier: mac eth8: dhcp4: yes optional: true dhcp-identifier: mac

sudo netplan –debug apply ip link show ! mac address changes require a reboot sudo shutdown -r now

josephmhiggins commented 1 year ago

ipv6 runs duplicate address detection when it brings a network up so...duplicate mac address can easily be detected if someone has 2 GNS3 VMs with the same version on the same subnet. putting a new gns3 vm on a different subnet is impossible for a new gns3 user assigning an ip address in netplan on a new gns3 vm is impossible for windows users

josephmhiggins commented 1 year ago

Either i write up a procedure to install a new gns3 vm on a different vmnet so that the configuration can be changed via ip address and not modifying netplan. the procedure will be difficult to write up and difficult for gns3 users to implement. But gns3 users that want to upgrade to a new gns3 vm and then rollback need to be skilled. i will have to try the vmware export configuration - it is not portable obviously. vmware rest api is too complicated for gns3 users. if the export/import configuration does not work then it will have to be screenshots - which takes hours to do.

Or my GNS3 End Project goes into full effect. My GNS3 End Project is super easy. ..and it is already written up - except for the adosztal/network_automation conundrum - it is tried and tested.

josephmhiggins commented 1 year ago

I published a procedure to effortlessly rollback to the "previous" gns3 version that was being used on Windows 10 with the GNS3 VM on gns3.com. It is tested and working and super easy to implement. It can never fail UNLESS a windows update comes in. A windows update can destroy anything.