Troubleshooting¶
In general troubleshooting network issues follows a quite wide array of possible and probable faults. In general a good approach is to troubleshoot from lower layers of the TCP/IP stack and upwards, i.e: - check that cables are connected (In GNS3, check that links are attached to correct interfaces) - check that the link is active (Check that the devices notice that there is a connected device on the interface) - check that there is IP connectivity (Check that you can ping from one device to the next) - then move on to application specific troubleshooting.
There are certain issues that might arrise through the lab-enviroment, specified below:
Problems with OSPFD /BGPD on FRR¶
Check the startup command which you can find in the FRR configuration. Make sure that the following command is used: /bin/bash -c "/usr/lib/frr/watchfrr -d zebra ospfd bgpd && vtysh"
BGP won't advertise routes on FRR¶
You can try running no bgp ebgp-requires-policy within the bgp process to see if it advertises routes if you disable the requirement for advertisement specification, but it is not recommended to run with this option set.
VyOS won't boot, with error "could not rebase image"¶
this happens if there is a vyos process running in the background when it shouldn't. so the fix is to simply shut this vyos instance off. But you can't do this through gns3 so you have to do it from the terminal.
The first thing you need to do is shut off all the routers in the project and the run this comand to find the port number belonging to the vyos router. Notice that this command must be run whilst logged in on an ssh-session to the VM:
The output should look something like this:
The important place to look here is the column with 127.0.0.1:xxxx
you will need to test out the different ports that show up, and in this case there are 3080 and 5041.
the port number usually starts with 5 so i'll test the 5041 port first:To connect to the router we use the following telnet command telnet localhost <portnumber> and the result should look something like this:
then you can run sudo shutdown now which should solve the problem and you should be able to run vyos.
If this solution does not give desired results, it is possible to simply reboot the VM from an SSH-session. Enable sudo user by writing sudo su, then reboot.
Remember to save any configuration changes, and extract any desired files from the manager device before shutting down.
Shared folder is no longer visible¶
Sometimes the "shared folder" might disappear from the VM. Turning automount off and on does not help. The issue is fixed by completely removing the respective path. Save your changes, and then readd the path.
Sudden dissappearal of configuration on all devices¶
For some, as of writing, unknown reason GNS3 duplicates projects in an unsafe manner, leading to lost configurations. We beleive this issue is due to projects trying to read across project file-structures, which is undesirable. To remediate this issue, we have to point the projects to the correct file-structure, and differentiate them in a way that makes the full suite of duplicates accessible from GNS3.
The first control if this is an issue on the server, is to access the project files in the terminal of the GNS3-server. From an SSH-session with a user with sudo privelege, run:
From here, you can read out the content of the different project directories (Which have random Project-ID names) to see if you might have the duplication error. If you find projects that have the same name, then you likely have duplications:
In this example, the project Ipv4.gns3 is present in multiple folders, which likely means it has the error. When we want to remediate, we might be lucky and have clear idenfiers that some of the projects have fresher configuration.
In this case, we check the age of the different folders:
In our case, we see that 4 of the folders have roughly the same time and date of being edited last, which prevents us from targetting projects efficiently based on time.
If there is a clear difference in date of when the projects were last edited, it is probably efficient to mostly target the latest project-folder.
The issue that we are actually trying to remediate is an error of project-file linking. Within each project-file, within the different "project-ID" directories, there is a value that references which project-ID the project is a part of. If this project-ID is mismatched with which project file (.gns3 file) is loaded, it seems like GNS3 is unable to access the correct files, which leads to read/write errors on the configurations.
As an example, in the following, we open the project file (.gns3 file) in the "caa6..." project-ID directory, and see that the reference is to a different project-id than the directory we are using:
We suspect that this mismatch is the source of the error.
To remediate, we first correct the project-ID-value to the folder that the project-file is located in. We also change the name referenced in the project, so that GNS3 is able to differentiate the projects.
To edit the files, open the file in a text-editor of choice, like vim or nano:
Lastly, although I am unsure if it is necessary, I rename the project-files (the .gns3 files) to include an identifier from the project-ID:
mv $Project-ID/$Project-file.gns $Project-ID/($Project-file + "-" + (first numbers from project-ID)).gns3
When all this is done, the GNS3 projects-library should show a clear differentiation on the different projects. You then have to sweep through the projects to find which one holds the most current configuration:
