[ovs-dev] Problems on controller set up

Hugo Alfonso Zúñiga Calvo hzc9107 at gmail.com
Mon Oct 29 17:35:06 UTC 2018


I am a new developer for openvswitch, I am currently trying to use the
experimenter messages in order to try out an extension of the protocol for
my master thesis. The switch I am using runs openvswitch, therefore I have
already extended the openvswitch to add my custom experimenter messages.
Nevertheless when I try to connect the switch to the controller it seems
that the communication drops on the switch side. At some point at the
beginning of the communication the messages from the switch to the
controller are not sent to the bridge interface anymore.

In order to further debug this problem, I have enabled debugging on the
vconn module and run tcpdump on the bridge interface of the openvswitch.
What I have been able to realize is that at the beginning of the
communication the messages sent according to vconn can be traced on the
tcpdump. But after some messages, both start mismatching, vconn log states
that it has sent messages that can not be tracked on the bridge interface
through tcp dump. Below are a couple of extracts of the logs and the
tcpdump to show the issue.

Trackable message sent:

listening on TNbr, link-type EN10MB (Ethernet), capture size 262144 bytes
17:27:22.742260 IP > Flags [P.], seq
3549276819:3549276843, ack 4229037109, win 227, options [nop,nop,TS val
1361403001 ecr 468839421], length 24: OpenFlow
        version unknown (0x04), type 0x00, length 16, xid 0x00000015
        version unknown (0x04), type 0x05, length 8, xid 0x00000776
17:27:22.742321 IP > Flags [.], ack 24,
win 229, options [nop,nop,TS val 468839518 ecr 1361403001], length 0
17:27:22.743372 IP > Flags [P.], seq
1:33, ack 24, win 229, options [nop,nop,TS val 468839519 ecr 1361403001],
length 32: OpenFlow
        version unknown (0x04), type 0x06, length 32, xid 0x00000776
17:27:22.743487 IP > Flags [.], ack 33,
win 227, options [nop,nop,TS val 1361403002 ecr 468839519], length 0
17:27:22.754692 IP > Flags [P.], seq
24:32, ack 33, win 227, options [nop,nop,TS val 1361403013 ecr 468839519],
length 8: OpenFlow
        version unknown (0x04), type 0x14, length 8, xid 0x00000000
17:27:22.755024 IP > Flags [P.], seq
33:41, ack 32, win 229, options [nop,nop,TS val 468839530 ecr 1361403013],
length 8: OpenFlow
        version unknown (0x04), type 0x15, length 8, xid 0x00000000

openvswitch log:
2018-10-29T17:27:22.742Z|00253|vconn|DBG|tcp: received:
OFPT_FEATURES_REQUEST (OF1.3) (xid=0x776):
2018-10-29T17:27:22.743Z|00254|vconn|DBG|tcp: sent
(Success): OFPT_FEATURES_REPLY (OF1.3) (xid=0x776): dpid:000000534e554c00
n_tables:254, n_buffers:0


2018-10-29T17:27:22.754Z|00255|vconn|DBG|tcp: received:
2018-10-29T17:27:22.755Z|00256|vconn|DBG|tcp: sent
(Success): OFPT_BARRIER_REPLY (OF1.3) (xid=0x0):

Mismatch message:

17:27:24.077463 IP > Flags [P.], seq
128:152, ack 6665, win 362, options [nop,nop,TS val 1361404335 ecr
468840838,nop,nop,sack 1 {8113:8433}], length 24: OpenFlow
        version unknown (0x04), *type 0x18*, length 24, xid 0x00000007

17:27:24.126131 IP > Flags [.], ack
152, win 229, options [nop,nop,TS val 468840902 ecr 1361404335], length 0
17:27:24.408006 IP > Flags [P.], seq
152:160, ack 6665, win 362, options [nop,nop,TS val 1361404666 ecr
468840838,nop,nop,sack 1 {8113:8433}], length 8: OpenFlow
        version unknown (0x04), *type 0x14*, length 8, xid 0x00000008

openvswitch log:
2018-10-29T17:27:24.087Z|00271|vconn|DBG|tcp: received:
OFPT_ROLE_REQUEST (OF1.3) (xid=0x7): role=nochange
2018-10-29T17:27:24.088Z|00272|vconn|DBG|tcp: sent
(Success): OFPT_ROLE_REPLY (OF1.3) (xid=0x7): role=equal
2018-10-29T17:27:24.408Z|00273|vconn|DBG|tcp: received:
*OFPT_BARRIER_REQUEST* (OF1.3) (xid=0x8):
2018-10-29T17:27:24.408Z|00274|vconn|DBG|tcp: sent
(Success): OFPT_BARRIER_REPLY (OF1.3) (xid=0x8):
2018-10-29T17:27:28.777Z|00275|rconn|DBG|TNbr<->tcp: idle 5
seconds, sending inactivity probe
2018-10-29T17:27:28.777Z|00276|rconn|DBG|TNbr<->tcp: entering
2018-10-29T17:27:28.777Z|00277|vconn|DBG|tcp: sent
(Success): OFPT_ECHO_REQUEST (OF1.3) (xid=0x0): 0 bytes of payload

Checking the code it says that the fact that vconn reports it as sent only
means it has been queued, therefore I am thinking maybe the messsages are
dropped somewhere but I cannot figure out where. This problems are
happening with openvswitch2.10.0. Could anyone help me with this issue, I
have already given it a week of debugging but I haven't been able to pin it

Best Regards,

Hugo Zuniga Calvo

More information about the dev mailing list