GNS3 "unable to create UDP NIO": how to fix it
Dynamips couldn't open the UDP port for a link. Find what holds the port, move GNS3's UDP tunneling port range, and start the project again.
You open a project or start a router and GNS3 shows something like this, with your own ID and port numbers:
Dynamips error when running command 'nio create_udp udp-520d2a72-7520-478d-ae3e-0e97ad207014 10002 127.0.0.1 10003
': unable to create UDP NIO
Dynamips tried to open a UDP socket for one end of a link and failed. Almost always the local
port (10002 here) is taken or blocked by something else on the computer.
Why it happens
GNS3 builds a link between two nodes as a pair of UDP tunnels. Each end gets a UDP port from the
UDP tunneling port range, and the GNS3 server config notes that two ports are allocated per
link. When a Dynamips router or switch gets a link, GNS3 sends Dynamips a command:
nio create_udp <name> <local port> <remote host> <remote port>.
Dynamips then binds the local port and connects it
to the remote host and port. If either step fails, the hypervisor replies
unable to create UDP NIO (hv_nio.c),
and GNS3 shows it with the command in front. The common reasons:
- Another program uses ports in the range. Several users in gns3-server issue #1271 and #1645 traced it to NVIDIA GeForce Experience. Others fixed it by moving GNS3's range.
- Windows reserved the ports. Windows can exclude blocks of ports for its own use, and a program can't bind to an excluded port.
- Leftovers from a crash. A
dynamipsorubridgeprocess from an earlier session can still hold ports. - The remote host can't be reached or resolved. For links between your computer and the
GNS3 VM, the remote host is the other machine, not
127.0.0.1.
For a Dynamips router, GNS3 2.2 puts uBridge between Dynamips and the cable, through a local
tunnel. That is why the command often shows 127.0.0.1 and two ports next to each other, even
when the cable goes to another node. In that case the problem is a local port on your own
computer, not the network.
The default range is 10000 to 20000 for the local server set up by the GNS3 GUI, and 20000 to 30000 for a server with no setting (such as the GNS3 VM).
Fix it
1. Read the full error
Open View > Docks > Console. Note the two port numbers and the host after create_udp. The
first number is the local port Dynamips couldn't open.
2. Find what holds the port
On Windows, in PowerShell (replace 10002 with your port):
Get-NetUDPEndpoint -LocalPort 10002 -ErrorAction SilentlyContinue |
ForEach-Object { Get-Process -Id $_.OwningProcess }
On Linux or macOS:
sudo lsof -nP -iUDP:10002
Then check the ports Windows has reserved. If one of the listed ranges overlaps GNS3's range, that is your conflict:
netsh interface ipv4 show excludedportrange protocol=udp
3. Clear leftover processes
Close GNS3. Then make sure nothing from the last session is still running:
Get-Process dynamips, ubridge -ErrorAction SilentlyContinue
On Linux or macOS, pgrep -a dynamips and pgrep -a ubridge do the same. If a process is
listed with GNS3 closed, end it (Stop-Process -Name dynamips or kill <pid>), or restart the
computer.
4. Move the UDP port range
- Open Edit > Preferences > Server, Main server tab.
- Under UDP tunneling port range, set a start and end that avoid the ports you found in step 2. Stay below 49152, where Windows' dynamic port range starts, as Microsoft documents.
- Click OK and restart GNS3 so the local server picks up the new range.
The GUI stores the range in the local server's config file, in the [Server] section. In GNS3
2.2 that file is %APPDATA%\GNS3\2.2\gns3_server.ini on Windows and
~/.config/GNS3/2.2/gns3_server.conf on Linux and macOS. If you run the server without the GUI,
edit it there:
[Server]
udp_start_port_range = 20000
udp_end_port_range = 30000
5. Remove the conflict for good
If step 2 named a program, such as GeForce Experience, either keep GNS3's range away from its ports or uninstall it. Users in the GitHub issues report both approaches working.
How to check it worked
- Open the project and start all nodes.
- The error should not come back in the Console dock, and every link should show green ends.
- Ping across a link, for example from one router to the router at the other end of a cable.
If it still fails
- The link goes to the GNS3 VM. Links between nodes on your computer and nodes in the GNS3 VM send UDP between the two machines. A firewall rule or a broken host-only network stops them. See Cannot connect to compute.
- You see
Could not find a free port between 10000 and 20000 on host .... The range is too small or mostly taken. Widen it. - You see
UDP port 10002 already in use on host .... GNS3 still thinks another node of the project owns that port. Close the project, check step 3, and open it again. - Security software. In issue #1498 a GNS3
developer's first question was whether an anti-virus or security suite was running. Try with
it paused, or add an exception for
dynamipsandubridge.
For a map of common GNS3 problems, see the GNS3 troubleshooting guide. If the routers start but use a whole CPU core each, read Dynamips at 100% CPU.
A lighter way to build the lab
If your lab is mainly Linux hosts, services and routing, you can draw it in
Isothrum's editor instead. It is free, runs in your browser with no account, and exports
a lab of containers as Docker Compose, or of VMs as Vagrant. You get
switches with VLANs and trunks, an automatic router or FRR, and link conditions such as latency
and loss. It can also open your .gns3 project as a starting point. It won't fix this error in
GNS3, but a lab of containers needs no GNS3 server and no GNS3 VM.