On 03/04/2015 11:19 AM, ppnaik wrote: > 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.
Then this doesn't look like a Neutron problem. You need to figure out why the iperf server did not respond. If you run it in the foreground it will print a message when it receives a connection request. -Brian > 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
