Sending ZeroMQ messages from openvswitch to SDN controller

0
votes

I have been working with two C programs for the past few months, one is a ZeroMQ publisher and the other a ZeroMQ subscriber. They exchange simple string messages between Virtual Machines and everything works fine.

Now, in one of the VMs I've been working on (VM A) I configured an openvswitch and in another VM a Ryu controller. The diagram is the following:

enter image description here

I "bounded" the bridge interface of OVS to the eth3 interface of VM A. Everything works well and flow-entries are added by the Ryu controller or manually added by me.

Now, I want to add the ZeroMQ publisher-subscriber programs I had already used countless times. Here, the controller is the subscriber and OVS the publisher.

However, the messages never arrive to the controller... If I run the ZeroMQ publisher from another machine on net A that does NOT have OVS installed and configured, messages arrive to the Ryu controller successfully.

When I run the publisher and subscriber, this is the output of netstat -at on both machines. VM A is "OpenWrt" and the Ryu controller is "control" (consider only the last line in @control VM):

enter image description here

enter image description here

Is there something I'm missing? Is it really impossible to send TCP messages from de OVS to the controller? Should I create some kind of tunnel from VM A to the controller where messages would flow through? Or is it just an issue with ZeroMQ that does not work with Openflow enabled architectures?

If any of you ever worked with a message queueing technology in Openflow environments, please let me know.

I appreciate any kind of help, I've been stuck for weeks.

Note: I can ping VM A from controller and vice-versa.

1
zeromqopenflowopenvswitch

1 Answers

1
votes

Q : Is there something I'm missing?

Given no MCVE-code was provided, there is missing a pair of LoS-visibility test results, from:

<ZMQ_SUB_HOST>:~$ traceroute --sport=<ZMQ_TRANSPORT_PORT#> <ZMQ_PUB_HOST>

and

<ZMQ_PUB_HOST>:~$ traceroute --sport=<ZMQ_TRANSPORT_PORT#> <ZMQ_SUB_HOST>

Note: I can ping VM A from controller and vice-versa.

This remark sounds promising, yet both the LoS-visibility test results and the MCVE-code details are important, but missing.

Q : Should I create some kind of tunnel from VM A to the controller where messages would flow through?

Sure, you definitely can. This will isolate L3-level issues and your tunneling-path will provide a way to ignore all these, at a cost of some slight latency trade-off.

Q : Or is it just an issue with ZeroMQ that does not work with Openflow enabled architectures?

There is no specific reason for blaming ZeroMQ infrastructure to stop working but due to an L3/SDN-related yet unspecified so far issue. Given a fair tcp://-transport-class path exists and is used in a properly configured ZeroMQ transport-infrastructure consisting of ad-hoc, dynamic setup of
M-.bind( <class>://<addr>:<port> )-s : N-.connect( <class>://<addr>:<port> )-s relation, reporting no error-state(s) on respective operation(s), the ZeroMQ shall and will work as it always does.