Operating System: Windows
Platform: PC

This testcase is working fine. Moved the status to FIXED

Hi Madhusudhan,
I tried with cpqd (ofsoftswitch) with no success. It seems like there is no LLDP packet even sent back to controller at all - which explains missing links in topology and failing pings (controller will never get alerted regarding ping packets).

On the other hand it all works fine with ovs (openvswitch) which by default sends all packets (not covered by any flow) up to controller. So the controller gets the topology discovered and also reacts upon ping packet by creating appropriate flows.

Are you sure, you get ping working in cpqd and not ovs? If yes, can you attach flows on your virtual devices?

After adding flow in order to forward all packets to controller I got links in topology and ping in --topo tree,2 looks liek this:
h1 -> X h3 h4
h2 -> X h3 h4
h3 -> h1 h2 X
h4 -> h1 h2 X

• • • Results: 33% dropped (4/12 lost)

I never get h1 <> h2 and h3 <> h4 pinged.

Hi Michal,

Yes. I tried with cpqd (ofsoftswitch) with no success. Maybe there is no LLDP packet even sent back to controller at all.

I used this sudo mn --topo tree,2 --mac --switch user --controller=remote,ip=127.0.0.1 for CPqD

I am able to see the topology on the GUI and when I do pingall, I get the following:

mininet> pingall

• • • Ping: testing ping reachability
      h1 -> h2 X X
      h2 -> h1 X X
      h3 -> X X h4
      h4 -> X X h3
    • Results: 66% dropped (8/12 lost)

Using OVS, it is found to be working fine. So, the problem lies in CPqD switch.

Note: I normally try with OVS. Guys from India will be tested against CPqD.

However, I am going to try in both the switches going forward.

Hi Michal,

GET topology fails against CPqD switch.

1. Download and start latest controller using ./run.sh -of13

2. sudo mn --topo tree,2 --mac --switch user --controller=remote,ip=127.0.0.1

3. Check the topology on the GUI and check whether you are able to see the links between the switches (In my case, I could not see the links)

4. Use GET http://127.0.0.1:8080/controller/nb/v2/topology/default and I could not see the topology. Thus the ping fails using CPqD.

https://git.opendaylight.org/gerrit/#/c/5650/

Attachment flow-f54t0.xml has been added with description: flow sending all packets up to controller

One of the differences between cpqd and ovs is that ovs sends packets not covered by any flow up to controller by default. And cpqd drops them.

In order to alter this behavior of cpqd I added the flow (attached - flow-f54t0.xml) to each switch (tableId=0, priority=0, all packets, action=send to controller port).

Then the topology got discovered and ping worked (sometimes I get <100% success on 1st try).

Steps:

• start controller
• start cpqd
• wait till connected
• add flows to all nodes:

for i = 1 .. x:
action: POST
url: http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:i/table/0
content: attached file

1. Or do it via osgi console command (change 5650 is lowering the priority of this flow to 0):
   osgi> addMDFlow openflow:i f54 0

• observe packetIn in wireshark
• run pingall in mininet

Could you replicate this, please? (the attached xml already contains priority = 0, higher priority of this flow is causing this: h1 never pings h2, h3 never pings h4)

Exactly. Using CPqD, OF packets are not forwarded to the controller by default. It worked only after inserting a flow of action, Output=CONTROLLER to all the nodes. Eventually, ping worked!

I think the issue is in CPqD switch and believe that, it started behaving like this recently. Maybe, we need to file a bug for CPqD people to start looking into it.

Thanks for the resolution.

Assuming this is cpqd specific behavior and wont be fixed on controller side.

Reopened,
since this behaviour is not CPQD specific, but may be observed on switches which
faitfully implement openflow specification.

Section 5.1 of OF 1.3 specification clearly states that packet may be forwarded to controller or dropped based on table configuration and this behaviour is left to table configuration.

In order for controller to reliably perfom LLDP topology discovery controller must not depend on "unknown conditions" such as forwarding all packet misses to controller.

So controller needs to install flows, which will forward LLDP packets to controller, in order to do topology discovery reliable and to not be dependent
on out-of-the-band configuration of table.

Same recommendation as in https://bugs.opendaylight.org/show_bug.cgi?id=974 to add an explicit LLDP flow to punt the LLDP packets to the controller.