In general UDP packets does not have an acknowledgement. Is your client or the server runs using the -u option of the iperf tool?
Regards, Krishnaprasad -----Original Message----- From: ppnaik [mailto:ppn...@cse.iitb.ac.in] Sent: Mittwoch, 4. März 2015 17:20 To: openstack@lists.openstack.org Subject: Re: [Openstack] iperf not working between VMs Sir, Yes.ping connectivity is there.the tcpdump on server shows the syn packets from the client. But the server does not reply syn/ack. Thanks, Priyanka On 2015-03-04 21:23, abhishek jain wrote: > Have you checked ping connectivity between the VMs? > On Mar 4, 2015 9:19 PM, "Brian Haley" <brian.ha...@hp.com> wrote: > >> Please keep replies on the list. >> >> I would suggest running tcpdump on the server side and see if the >> packet is making it to the stack then. Perhaps there are other UFW >> rules dropping things? >> You can just use something like 'telnet 192.168.1.42 5001' to verify >> that. >> >> -Brian >> >> On 03/04/2015 10:25 AM, ppnaik wrote: >> > Sir, >> > I added rule tcp 1 65535 but it still did not work. >> > >> > Thanks, >> > >> > Priyanka >> > >> > >> > On 2015-03-04 20:29, Brian Haley wrote: >> >> Like Krishna asked, have you added a security group rule for TCP >> port >> 5001? >> >> Otherwise ingress traffic on that port will be dropped. >> >> >> >> -Brian >> >> >> >> On 03/04/2015 05:45 AM, Priyanka Naik wrote: >> >>> Hi, >> >>> >> >>> Sorry my mistake . I was actually trying it for different ports >> and >> copied the >> >>> earlier command on client VM. On client VM I am running >> >>> >> >>> iperf -c 192.168.1.42 >> >>> >> >>> and on server >> >>> >> >>> iperf -s >> >>> >> >>> yes the server is listening on port 5001. >> >>> >> >>> netstat -anp | grep 5001 >> >>> (Not all processes could be identified, non-owned process info >> >>> will not be shown, you would have to be root to see it all.) >> >>> tcp 0 0 0.0.0.0:5001 0.0.0.0:* >> LISTEN >> >>> 20227/iperf >> >>> >> >>> Thanks, >> >>> Priyanka >> >>> >> >>> On 03/04/2015 04:10 PM, nithish B wrote: >> >>>> Hi Priyanka, >> >>>> Sorry for that. My bad. I actaully meant to say, check if >> that >> client is >> >>>> indeed listening on the port. >> >>>> >> >>>> And wait a minute, I didn't notice!!! >> >>>> >> >>>> Your output says: >> >>>> >> >>>> On iperf server VM >> >>>> >> >>>> | iperf -s >> >>>> >> ------------------------------------------------------------ >> >>>> Server listening on TCP *port **5001* >> >>>> TCP window size: 85.3 KByte (default) >> >>>> >> ------------------------------------------------------------| >> >>>> >> >>>> On iperf client VM >> >>>> >> >>>> | iperf -c 192.168.1.42 *-p 8042* -i 1 -t 10 >> >>>> >> >>>> | >> >>>> |Kindly let me know as to why are you using port 8042 in the >> client >> while >> >>>> the server >> >>>> is listening on port 5001? >> >>>> | >> >>>> >> >>>> Regards, >> >>>> Nitish B. >> >>>> >> >>>> On Wed, Mar 4, 2015 at 3:58 PM, Priyanka Naik >> <ppn...@cse.iitb.ac.in >> >>>> <mailto:ppn...@cse.iitb.ac.in>> wrote: >> >>>> >> >>>> Hi Nitish, >> >>>> >> >>>> I am able to ping the client VM(192.168.1.41) from the >> server >> >>>> VM(192.168.1.42). >> >>>> >> >>>> ping 192.168.1.41 >> >>>> PING 192.168.1.41 (192.168.1.41) 56(84) bytes of data. >> >>>> 64 bytes from 192.168.1.41 <http://192.168.1.41>: >> icmp_req=1 >> ttl=64 >> >>>> time=1.02 ms >> >>>> 64 bytes from 192.168.1.41 <http://192.168.1.41>: >> icmp_req=2 >> ttl=64 >> >>>> time=0.495 ms >> >>>> 64 bytes from 192.168.1.41 <http://192.168.1.41>: >> icmp_req=3 >> ttl=64 >> >>>> time=0.598 ms >> >>>> 64 bytes from 192.168.1.41 <http://192.168.1.41>: >> icmp_req=4 >> ttl=64 >> >>>> time=0.462 ms >> >>>> ^C >> >>>> --- 192.168.1.41 ping statistics --- >> >>>> 4 packets transmitted, 4 received, 0% packet loss, time >> 2999ms >> >>>> rtt min/avg/max/mdev = 0.462/0.645/1.025/0.225 ms >> >>>> >> >>>> I am sorry I did not understand pinging a specified port. >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Priyanka >> >>>> >> >>>> >> >>>> On 03/04/2015 03:49 PM, nithish B wrote: >> >>>>> Hi Priyanka, >> >>>>> First check if you are able to ping the client VM from >> the >> server VM >> >>>>> on the specified port. If not, then there is an issue with >> the >> network >> >>>>> configuration. >> >>>>> Else, if you are able to ping on the specific port, >> then >> there is some >> >>>>> tunnelling issue and we can fix that! >> >>>>> Let me know this and we can proceed. >> >>>>> >> >>>>> >> >>>>> Regards, >> >>>>> Nitish B. >> >>>>> >> >>>>> On Wed, Mar 4, 2015 at 3:15 PM, Priyanka Naik < >> ppn...@cse.iitb.ac.in >> >>>>> <mailto:ppn...@cse.iitb.ac.in>> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> I have a multinode openstack juno setup. Iperf does >> not work >> between >> >>>>> VMs( on the same compute node asw ell as different >> compute >> nodes) >> >>>>> >> >>>>> On iperf server VM >> >>>>> >> >>>>> | iperf -s >> >>>>> >> ------------------------------------------------------------ >> >>>>> Server listening on TCP port 5001 >> >>>>> TCP window size: 85.3 KByte (default) >> >>>>> >> ------------------------------------------------------------| >> >>>>> >> >>>>> On iperf client VM >> >>>>> >> >>>>> | iperf -c 192.168.1.42 -p 8042 -i 1 -t 10| >> >>>>> >> >>>>> The mtu of the VM interface is 1400. It does not work >> even >> after >> >>>>> increasing or decreasing this value. >> >>>>> >> >>>>> |ifconfig >> >>>>> eth0 Link encap:Ethernet HWaddr >> fa:16:3e:ac:70:99 >> >>>>> inet addr:192.168.1.41 Bcast:192.168.1.255 >> >>>>> Mask:255.255.255.0 >> >>>>> inet6 addr: fe80::f816:3eff:feac:7099/64 >> Scope:Link >> >>>>> UP BROADCAST RUNNING MULTICAST MTU:1400 >> Metric:1 >> >>>>> RX packets:5781941 errors:0 dropped:0 >> overruns:0 >> frame:0 >> >>>>> TX packets:7096888 errors:0 dropped:0 >> overruns:0 >> carrier:0 >> >>>>> collisions:0 txqueuelen:1000 >> >>>>> RX bytes:3028179379 (3.0 GB) TX >> bytes:3594331790 >> >>>>> <tel:3594331790> (3.5 GB)| >> >>>>> >> >>>>> Please help me solve this issue. >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> Priyanka >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Mailing list: >> >>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >>>>> Post to : openstack@lists.openstack.org >> >>>>> <mailto:openstack@lists.openstack.org> >> >>>>> Unsubscribe : >> >>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >>> Post to : openstack@lists.openstack.org >> >>> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> >> Post to : openstack@lists.openstack.org >> >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > >> >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack@lists.openstack.org >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
