I am trying to measure the latency between one of my machines, and an EC2 instance. EC2 instances cannot be pinged. So I tried using application level timestaps (using gettimeofday()). I send a tcp packet with a timestamp in the payload.
Upon receiving this packet, I calculate the timestamp on my machine, and obtain the difference. It always comes out to be negative. My guess was that the clocks in the two machines could be skewed. So I used ntp to synchronize both the machines, but the problem still persists.
Can someone please help.
EC2 instances can be pinged, if configured to allow it. I set one up for this today while trying to track down packet drops in us-west-2. In the security group protecting the instance, you add a rule to permit "ICMP Echo Request" from the source address of the machine where you're originating the ping.
See the AWS FAQ for this quote.
Why can't I ping my instance? Ping uses ICMP ECHO, which by default is
blocked by your firewall. You'll need to grant ICMP access to your
instances by updating the firewall restrictions that are tied to your
security group.
ec2-authorize default -P icmp -t -1:-1 -s 0.0.0.0/0
Check out the latest developer guide for details.
Section: Instance Addressing and Network Security -> Network Security
-> Examples
Related
I am testing my application against three ConQuest DICOM servers running:
one on localhost, another one on a different computer in the local network, and still another one on a remote machine in the VPN network. The requesting application is present in both local and the VPN networks.
When I am trying to retrieve an image (via C-MOVE) from each of those three instances of ConQuest, both local servers duly respond the request and send me the image. The remote server on VPN, however, responds
"Host 'XXX' did not accept the connection"
and, after a timeout, closes.
I was unable to understand the reason, or, the difference - the corresponding settings in the configuration files on all three machines seem to be identical and correct.
I can successfully verify the VPN ConQuest server. I can also send images to it. But the C-MOVE retrieve does not work.
This is certainly not a firewall problem (I switched out firewall on all computers, and it did not help).
Can the problem have to do with the form of the host name? Do I need to indicate which network I mean, apart from the IP address?
Thanks A_J and everybody involved. After a while, we gathered enough experience with ConQuest and also with a couple of other PACS in real hospitals. There are principally three things to check:
The network parameters (AET, IP, port) of the PACS must be correctly registered with your application (all three you shall learn from the network admin);
The PACS must know the same three parameters of your system in its configuration (its physical implementation depending on the system). The port is the number of port on which your C-MOVE listener runs, the IP you can find with ipconfig (ifconfig), and the AET is that you chose. These data you shall tell the network administrator, so that (s)he registers them with the PACS;
Configure a firewall inbound rule on the machine where your application runs to allow connection on the port number of your C-MOVE listener.
To our experience, this is all what one needs for all practical purposes.
Hi all and thanks in advance for your help.
I have a situation where I have a need to test an unstable Internet connection on one internal network and send out an email alert on any issues (obviously requiring an Internet connection) through another network - .
I have hardware with dual nic and plan on writing something simple in vb.
Is there a way I can disable ping on my 'good' connection forcing it through the test network yet allowing smtp?
I've looked into routing and done some basic testing but it seems the ping automatically reroutes through the good network shortly after the bad network fails?
Any advice warmly received.
You should not even think about blocking ICMP. This is a good way to cause many, many problems. Instead, you should explicitly specify which interface to use for the ping requests.
If you're using a command-line ping, you usually do this by specifying the source IP to use for sending the packets. For example, on OS X, you can run the command
ping -c 5 -S 10.0.1.13 8.8.8.8
to ping Google's public DNS server (8.8.8.8) using the interface whose IP address is 10.0.1.13. If the interface with that IP is down, the ping will fail.
The specific flag varies from implementation to implementation.
If you're writing your own ping code, IIRC, you just need to bind the socket to that source address with the bind() system call.
I have DPDK set up, with two NICs taken over by DPDK, i.e. the interfaces
are not visible to userspace applications.
Now, I need to run netperf/iperf to measure throughput performance of port-to-port
configuration of DPDK, as described here https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurations/00_Phy-Phy.md
However netperf server requires to be bound to the network interface, and netperf client
has to know the netserver's IP address. But since the interfaces were taken
by DPDK, and netperf can't see their IP addresses any longer, how could I
run tests? Is there a way to redirect netperf right in network port,
regardless of IP addressess.
iptables, ebtables.. ?
Thanks.
If you're going by that diagram, your netperf and netserver should both be on the traffic generator. On the DPDK host, traffic coming in one interface is simply routed out the other interface by OVS, and back to your generator. There are a variety of tricks to get your generator to send traffic out on the wire rather than short circuiting over loopback, but they have been addressed here already.
If what you really want to do is have netserver running on the DPDK host, then you simply need to create a virtual interface, attach it to OVS, give it an IP, and direct your netperf traffic to it.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
I did a script that launch several amazon instances with the same security group which is the default one, with ICMP and all the TCP/UDP connection allowed... so no firewall problem.
I am running an ubuntu 11.4 64 bits ami working fine.
Usually in the bunch of machine I launch some do not respond to any ping or telnet connection. They can ping other machines but cannot be pinged. The other machines can ping each other in two directions without any problem, but usually one or two just don't respond to any ping. There is no difference in the way I launch them, so I don't understand where this bug comes from...
How to avoid this problem and recover from it without restarting the EC2 instance?
Thanks a lot tender developpers :D.
try this
Log into AWS account.
Click on Security Groups. Choose the required security group.
Click on the Inbound tab.
Create a new rule:
Custom ICMP rule
Type: Echo request
Source: 0.0.0.0/0
0.0.0.0 will allow everyone to ping your server. You can specify your own addresses if you want.
Assuming all the instances you launch have the same security group and same ami, you need to contact amazon about this.
https://forums.aws.amazon.com/thread.jspa?threadID=22640