[OPNFLWPLUG-61] ping between hosts not working with mininet OF 1.0 Created: 29/Jan/14  Updated: 27/Sep/21  Resolved: 25/Mar/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Hideyuki Tai Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Issue Links:
Blocks
blocks OPNFLWPLUG-67 OpenFlow 1.3 plugin does not discover... Resolved
Duplicate
duplicates CONTROLLER-232 Packet loss on first time ping test Resolved
External issue ID: 384

 Description   

I used the the base edition of the release artifact for Hydrogen.

http://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/distributions-base/0.1.0/distributions-base-0.1.0-osgipackage.zip

I run a controller with -of13 option, and run a Mininet OF 1.0.

mininet@mininet-vm:~$ sudo mn --controller=remote,ip=192.168.60.180 --topo tree,2

I executed ping command from h1 to h3, but all packets does not reach to h3.

mininet> h1 ping h3
^CPING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.

— 10.0.0.3 ping statistics —
3008 packets transmitted, 0 received, 100% packet loss, time 3031057ms

At the time, I saw an ERROR message on the OSGi console.

2014-01-28 20:55:35.835 EST [pool-26-thread-4] ERROR o.o.o.o.m.c.t.PortStatusMessageToNodeConnectorUpdatedTranslator - PortStatusMessage: version 1 dataPathId 2 portNo 1
2014-01-28 20:55:40.127 EST [md-sal-binding-commit-14] WARN o.o.c.t.internal.TopologyManagerImpl - Ignore edge that contains invalid node connector: (MD_SAL|openflow:1:2@MD_SAL|openflow:1->MD_SAL|openflow:3:3@MD_SAL|openflow:3)
2014-01-28 20:55:45.121 EST [md-sal-binding-commit-5] WARN o.o.c.t.internal.TopologyManagerImpl - Ignore edge that contains invalid node connector: (MD_SAL|openflow:1:2@MD_SAL|openflow:1->MD_SAL|openflow:3:3@MD_SAL|openflow:3)

On the other hand ping between h1 and h2 worked well.

mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=0.156 ms
64 bytes from 10.0.0.2: icmp_req=3 ttl=64 time=0.037 ms

I think this issues is related to the following issue.

https://bugs.opendaylight.org/show_bug.cgi?id=354

 Comments   
Comment by Sheena goyal [ 07/Feb/14 ]

Hi Hideyuki Tai ,

Following are my observation while trying to reproduce this bug :

1)Start Mininet,then start Controller .Ping between h1 to h3 unreliable.Rest all pings work fine.

2)Start Controller, start mininet within 1 minute of starting controller,ping works.

3)Start Controller,once the controller is up and running then start Mininet. Ping only works between the hosts connected to same switch.

For 1,3 Observations,I found out that getAllHosts method in hostTracker.java class returns only source host whereas in (2) it returns source and destination host.

I am looking further into this.

Comment by Abhijit Kumbhare [ 17/Mar/14 ]

This should be working - can we check?

Comment by Michal Rehak [ 18/Mar/14 ]

It is working, but during the first round usually not all pings succeed. Reason is probably in strategy - how the controller pushes flows to switches. The second round is then always 100% success. Question is if this is expected behavior.

I believe that as soon as the topology is explored, the controller must be able to manage all ping packets to be delivered.

Comment by Madhusudhan Ananderi [ 18/Mar/14 ]

This ping is working fine after the first attempt.

Downloaded the latest controller and started the mininet OF10

mininet> pingall

      • Ping: testing ping reachability
        h1 -> X h3 h4
        h2 -> h1 h3 h4
        h3 -> h1 h2 X
        h4 -> h1 h2 h3
      • Results: 16% dropped (10/12 received)
        mininet> pingall
      • Ping: testing ping reachability
        h1 -> h2 h3 h4
        h2 -> h1 h3 h4
        h3 -> h1 h2 h4
        h4 -> h1 h2 h3
      • Results: 0% dropped (12/12 received)

I think the issue is fixed!

Comment by Abhijit Kumbhare [ 20/Mar/14 ]

We need to fix this for the first ping attempt. However this may not be critical for immediate service release (end of March).

Comment by Hideyuki Tai [ 20/Mar/14 ]

(In reply to Abhijit Kumbhare from comment #5)
> We need to fix this for the first ping attempt. However this may not be
> critical for immediate service release (end of March).

agreed.

In the bug report #384, I originally reported that ping failed with the following errors.

2014-01-28 20:55:35.835 EST [pool-26-thread-4] ERROR o.o.o.o.m.c.t.PortStatusMessageToNodeConnectorUpdatedTranslator - PortStatusMessage: version 1 dataPathId 2 portNo 1
2014-01-28 20:55:40.127 EST [md-sal-binding-commit-14] WARN o.o.c.t.internal.TopologyManagerImpl - Ignore edge that contains invalid node connector: (MD_SAL|openflow:1:2@MD_SAL|openflow:1->MD_SAL|openflow:3:3@MD_SAL|openflow:3)
2014-01-28 20:55:45.121 EST [md-sal-binding-commit-5] WARN o.o.c.t.internal.TopologyManagerImpl - Ignore edge that contains invalid node connector: (MD_SAL|openflow:1:2@MD_SAL|openflow:1->MD_SAL|openflow:3:3@MD_SAL|openflow:3)

Therefore, I think it is ok to close this bug report if ping not failed with the above errors.

I think the problem in the first ping attempt is caused by delay for topology discovery.
Through some tests on OpenDaylight Controller, we figure out that the performance of the controller for topology discovery is very low.

Comment by Hideyuki Tai [ 20/Mar/14 ]

(In reply to Hideyuki Tai from comment #6)
> (In reply to Abhijit Kumbhare from comment #5)
> > We need to fix this for the first ping attempt. However this may not be
> > critical for immediate service release (end of March).
>
> agreed.
>
(snip)
>
> Therefore, I think it is ok to close this bug report if ping not failed with
> the above errors.
>

I'll test it with the latest code this weekend.

Comment by Luis Gomez [ 25/Mar/14 ]

I created CONTROLLER-232 to collect this issue.

Generated at Wed Feb 07 20:31:28 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.