[Openstack] iperf not working between VMs
Brian Haley
brian.haley at hp.com
Wed Mar 4 17:13:10 UTC 2015
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.haley at 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 <ppnaik at cse.iitb.ac.in
>>> >>>> <mailto:ppnaik at 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 <
>>> ppnaik at cse.iitb.ac.in
>>> >>>>> <mailto:ppnaik at 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 at lists.openstack.org
>>> >>>>> <mailto:openstack at 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 at 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 at 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 at 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 at 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 at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
More information about the Openstack
mailing list