VXLan on GNS3 - on GCP
A, nearly completed BG, Spine, Leaf, VXLan architecture running on NX-OS9kV's in GNS3, on Running on Google Cloud Project. (n1-highmem-8, 8 core, 52gb Ram, 100gb SSD persistant drive)
Running GNS3 on Google Cloud Platform
Checking a VM's persistent storage, as I just got some out of memory errors on the GNS3 server.
root@gns3server:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 97G 73G 25G 76% /
devtmpfs 26G 0 26G 0% /dev
tmpfs 26G 0 26G 0% /dev/shm
tmpfs 26G 996K 26G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 26G 0 26G 0% /sys/fs/cgroup
/dev/sda15 105M 3.6M 101M 4% /boot/efi
/dev/loop0 89M 89M 0 100% /snap/core/5897
/dev/loop1 88M 88M 0 100% /snap/core/5742
/dev/loop2 55M 55M 0 100% /snap/google-cloud-sdk/62
/dev/loop3 55M 55M 0 100% /snap/google-cloud-sdk/61
tmpfs 5.2G 0 5.2G 0% /run/user/1001
root@gns3server:~# ls
IOSv_startup_config.img vios-adventerprisek9-m.vmdk.SPA.156-1.T
cisco-iosvl2.gns3a vios_l2-adventerprisek9-m.03.2017.qcow2
juniper-vsrx.gns3a viptela-edge-18.3.1-genericx86-64.qcow2
media-vsrx-vmdisk-15.1X49-D60.7.qcow2 viptela-smart-18.3.1-genericx86-64.qcow2
nxosv-final.9.2.1.qcow2 viptela-vcontainer-18.3.1-genericx86-64.qcow2
snap vqfx10k-pfe-20160609-2.vmdk
vios-adventerprisek9-m.vmdk.SPA.155-3.M vqfx10k-re-15.1X53-D60.vmdk
root@gns3server:~# cd snap/
root@gns3server:~/snap# ls
google-cloud-sdk
root@gns3server:~/snap# cd google-cloud-sdk/
root@gns3server:~/snap/google-cloud-sdk# ls
61 62 common current
root@gns3server:~/snap/google-cloud-sdk# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 101445540 76153612 25275544 76% /
devtmpfs 26788700 0 26788700 0% /dev
tmpfs 26791888 0 26791888 0% /dev/shm
tmpfs 26791888 996 26790892 1% /run
tmpfs 5120 0 5120 0% /run/lock
tmpfs 26791888 0 26791888 0% /sys/fs/cgroup
/dev/sda15 106858 3682 103177 4% /boot/efi
/dev/loop0 90368 90368 0 100% /snap/core/5897
/dev/loop1 89984 89984 0 100% /snap/core/5742
vQFX10k firstboot
For testing some of what I use, I've downloaded the Juniper vQFX image.
It's interesting in the need to run separate VMs for the Routing engine and packet forwarding engine. It's Juniper, so it makes sense, though.
It's interesting in the need to run separate VMs for the Routing engine and packet forwarding engine. It's Juniper, so it makes sense, though.
