StatsReply Not Received but Features Reply Received in OpenVswitch

[James Poh]

Dear Trema-Dev Team,

I am currently doing a load-balancing system for my school project and I got into a problem which I can't understand and solve.

While using the trema's virtual network, all functions work according to what it is programmed to do.(as in using the 'trema run <controller> -c <network>' command)

However, after migrating to the OpenVswitch on Ubuntu behind VMware, stats_reply stop invoking. Adding flows is okay, features reply were also working.

For simplicity and testing purposes, I created a simple controller file to test the replies.

The code is as follows:

class Test < Controller

        def start

                puts "System Start"

        end

        def switch_ready dpid

                puts "Switch #{dpid} Ready!"

                send_message dpid, PortStatsRequest.new

                send_message dpid, FeaturesRequest.new

        end

        def stats_reply dpid, stats

                puts "Switch #{dpid} Stats Received!"

        end

        def features_reply dpid, features

                puts "Switch #{dpid} Features Received!"

        end

end

The results are:

System Start

Switch 4 Ready!

Switch 4 Features Received!

Switch 1 Ready!

Switch 1 Features Received!

Switch 2 Ready!

Switch 2 Features Received!

Switch 3 Ready!

Switch 3 Features Received!

tcpdump seems to show that the switches are replying but I can't confirm it though. The tcpdump that I created is based on the following command "tcpdump -i eth1 ip host 192.168.0.1" and immediately after I invoked the tcpdump command, I launch the "trema run test.rb" command. I have attached the tcpdump log as a txt file to prevent the mail to look too messy.

(192.168.0.1 is the controller's ip address while eth1 is where the switches are connected to the controller via the control link.)

Hope the trema-dev team can assist me in solving this problem.

Thank you and please do tell me any information you may need.

Yours sincerely,

Poh Yong Xiang

[Denis Ovsienko]

> tcpdump seems to show that the switches are replying but I can't confirm it though. The tcpdump that I created is based on the following command "tcpdump -i eth1 ip host 192.168.0.1" and immediately after I invoked the tcpdump command, I launch the "trema run test.rb" command. I have attached the tcpdump log as a txt file to prevent the mail to look too messy.

The most recent version of tcpdump can decode this exchange but only if it uses TCP port 6633. This will make it clear if the controller receives the message from the switch. If it does receive but doesn't deliver to the application, the problem might be the message is considered malformed.

--
Denis Ovsienko

[James Poh]

Hi Denis Ovsienko,

Regarding port 6633, are you saying to ask trema to listen to 6633 or just set the openVswitches to send the controller message at port 6633?

Thank you for your quick reply.

[Denis Ovsienko]

10.02.2014, 20:06, "James Poh" <yxpo...@gmail.com>:

> Hi Denis Ovsienko,
> Regarding port 6633, are you saying to ask trema to listen to 6633 or just set the openVswitches to send the controller message at port 6633?

As far as I understand it, both things at once to make the debug session run. Alternatively you can recompile tcpdump with the change below and it will decode without the changes to the Trema/OVS setup:

--- a/tcp.h
+++ b/tcp.h
@@ -98,7 +98,7 @@ struct tcphdr {
#endif
#define NETBIOS_SSN_PORT 139
#ifndef OPENFLOW_PORT
-#define OPENFLOW_PORT 6633
+#define OPENFLOW_PORT 6653
#endif
#ifndef PPTP_PORT
#define PPTP_PORT 1723

--
Denis Ovsienko

[James Poh]

Hi Denis Ovsienko,

How do I go about doing the recompilation?

I found tcp.h in /usr/include/netinet/tcp.h. 

What's a/tcp.h and b/tcp.h and is -98, 7 and 98, 7 the line number in the file? 

Thank you for your help and sorry for the questions.

[Denis Ovsienko]

11.02.2014, 11:09, "James Poh" <yxpo...@gmail.com>:

> Hi Denis Ovsienko,
> How do I go about doing the recompilation?
> I found tcp.h in /usr/include/netinet/tcp.h.
>
> What's a/tcp.h and b/tcp.h and is -98, 7 and 98, 7 the line number in the file?

Hello.

The tcp.h from the diff belongs to the tcpdump source code: https://github.com/the-tcpdump-group/tcpdump

If you have difficulty reconfiguring/recompiling, you can send me the .pcap file and I will post its decoding to the list. Please take care to capture only the OpenFlow packets:

tcpdump -w openflow.pcap tcp port 6653

--
Denis Ovsienko

[James Poh]

Hi,

So I just change the 6653 port? Is that all? Where do I find openflow.pcap? Do I download from here?
https://code.google.com/p/s11interface/downloads/detail?name=openflow.pcap

Thank you for your advice.

Yours sincerely,

Poh Yong Xiang

Regards,

Yong Xiang

--
You received this message because you are subscribed to a topic in the Google Groups "trema-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/trema-dev/w-1zsm07OIA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to trema-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Denis Ovsienko]

11.02.2014, 12:53, "James Poh" <yxpo...@gmail.com>:

> Hi,
> So I just change the 6653 port? Is that all? Where do I find openflow.pcap? Do I download from here?
> https://code.google.com/p/s11interface/downloads/detail?name=openflow.pcap

I could try to explain but this page does it better (please see the "-w" flag): http://www.tcpdump.org/manpages/tcpdump.1.html

--
Denis Ovsienko

[James Poh]

Hi Denis Ovsienko,

I have attached the openflow.pcap file. Would you check if I did it correctly?

Thank you.

[Denis Ovsienko]

12.02.2014, 05:29, "James Poh" <yxpo...@gmail.com>:

> Hi Denis Ovsienko,
> I have attached the openflow.pcap file. Would you check if I did it correctly?

Yes, the capture is OK. Its decoding is attached. The port stats reply is missing because there is no request for it. I have checked your script with my OF switch and see that the following line doesn't emit an OFPT_STATS_REQUEST messsage with OFPST_PORT type:

send_message dpid, PortStatsRequest.new

I have also checked a different script (https://github.com/OFWorkshop/OFW-Trema/blob/master/Coverage/coverage.rb) with the same switch and the port stats request is missing too (around half a year ago it worked OK). This looks like a bug in Trema.

--
Denis Ovsienko

[James Poh]

Hi,

Can I say that the virtual network or the -c parameter uses another framework/sector of the trema system? 

Which is the reason why It was working before the migration to openvswitch?

Thank you for your help.

Yours sincerely,

Poh Yong Xiang

Regards,

Yong Xiang

[Denis Ovsienko]

12.02.2014, 12:05, "James Poh" <yxpo...@gmail.com>:

> Hi,
> Can I say that the virtual network or the -c parameter uses another framework/sector of the trema system?
> Which is the reason why It was working before the migration to openvswitch?

That's a worthwhile idea, but I cannot check right now. I would suggest to open a bug for this: https://github.com/trema/trema/issues

--
Denis Ovsienko

[James Poh]

Dear Denis Ovsienko,

Thank you very much.

I was given the solution in the issues section. I am not sure if you already know or interested in it but the following is the link to the solution.

https://github.com/trema/trema/commit/b7fa954aa12ef50f6378332787e7f9b93da129c5

I have to rebuild trema and use the manual installation/clone trema to run trema.

Yours sincerely,

Poh Yong Xiang