-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device links fail. Source IP is wrong. #76
Comments
How do you connect the GUI to remote server? You use a VPN? |
I've used a couple methods. I can replicate the issue on the CLI using dynagen, and also running gns3server and remotely tunneling in with SSH in a VPN. GNS3 GUI seems to have no trouble connecting and issuing commands to gns3server and dynamips. Thanks! |
A SSH tunnel will bug because on the remote the other side of the tunnel will be see as 127.0.0.1. Both dynamips need to have different IP and be able to communicate with each other via all the port. In this script you have a sample for setting up an OpenVPN: |
I don't think the SSH or VPN are an issue here. I'm having this problem running all the simulations on the same AWS instance. This bad behavior occurs with a single dynamips instance running in hypervisor mode and controlled locally by dynagen, with two routers simulated. It also occurs with a local instance of gns3server starting two separate instances of dynamips locally (one for each router), and controlled remotely by the GNS3 GUI. I haven't tried splitting the simulation load between my local machine and AWS. My goal here is to have a long term simulation running 100% on AWS, for testing some network management tools and producing realistic monitoring data. If they leak memory or fall over eventually, that's fine - I'll just have them restarted. Other complications of this setup are docker and its bridges are running there too. Along with a TAP interface and a GRE and IPIP tunnel to another host. Connecting dynamips to tap0 works, and pinging that simulated router from the native host, or from across the GRE tunnel both work. Just inter-simulated router traffic fails. |
How do you start dynamips? I think you need to tell to it that he need to bind on 127.0.0.1 otherwise he bind on his public ip and the AWS firewall block it. |
When running with dynagen, I start it like this: When gns3server starts it, it's like this: Both bind to 0.0.0.0:7200, and when I start the sims, the 'nio create_udp' commands from dynagen or gns3 create those connections from 127.0.0.1:1000<->127.0.0.1:10001 etc. Looks like the man page and CLI help have a discrepancy - I didn't realize I could give it an IP and port for '-H'. Trying it like this: I get the same behavior, except the hypervisor binds to 127.0.0.1 instead of 0.0.0.0. The UDP tunnel traffic still has the source address of eth0. |
I found a workaround. Instead of relying on dynagen (or GNS3 GUI) to infer and create the correct links, I specified the nio_udp parameters manually to use the eth0 address instead of localhost: Broken dynagen .net snippet. Creates UDP connections to/from localhost:
Working Dynagen.net snippet. Creates UDP connections to/from external IP, since that's where dynamips will source the traffic from anyway:
Dynamips logs, much like before, but not using the loopback address for UDP tunnels:
Netstat shows these connections:
I can now ping to/from R1 and R2 using ethernet and serial links. Traffic on the host still has the external IP as the source IP address, it just happens to be correct now. It would be nice to figure out why dynamips is behaving badly in this environment, but not on others. Then I could go back to letting dynagen/GNS3 do more of the conveniences of counting ports and inferring the other sides of the links. That'll definitely get tedious with larger configs. But I'm not stuck anymore at least. Thanks for looking into this! Still happy to provide logs or tcpdumps or whatever. |
I've got an issue with dynamips 0.2.11 and 0.2.16 on an AWS instance of Ubuntu 14.04. All the links between simulated devices (ethernet and serial) are unable to pass any traffic. The key difference I see between this instance and a working instance on my Mac is that the UDP tunneled traffic on the loopback uses the wrong source IP.
Tcpdump on loopback for working instance on Mac OS X, pinging R2 FA0/0 from R1 FA0/0. All traffic is sourced from 127.0.0.1:
Broken instance on AWS Ubuntu 14.04, pinging R2 from R1. All pings and some other traffic are sourced from the external IP address of the AWS instance:
On the broken instance I see these logs:
And these Established UDP connections:
Appreciate any help, and I'm happy to produce more logs or test results,
Chris Vazquez
The text was updated successfully, but these errors were encountered: