[ovs-discuss] find controller using DNS Server-Discovery?

[Neil McKee]

On Jun 18, 2010, at 1:05 PM, Ben Pfaff wrote:

> On Thu, Jun 17, 2010 at 06:18:30PM -0700, Neil McKee wrote:
>> Was DNS Server-Discovery ever considered as a way for an Open VSwitch
>> to find it's controller?
>> 
>> We just implemented this for the host-sflow daemon and it seems to
>> work well.  The daemon is identical on every server, but you can
>> change the settings for the whole data-center just by tweaking one
>> file on the DNS server.  For example, if /var/named/mycompany.com.zone
>> is given:
>> 
>> _sflow._udp   300  SRV     0 0 6343  collector1
>> _sflow._udp   300  SRV     0 0 6343  collector2
>> _sflow._udp   300 TXT     (
>> "txtvers=1"
>> "polling=20"
>> )
> 
> I'm not sure whether you know that OVS already has a way to do
> controller discovery.  It does.  OVS can use a vendor extension to DHCP
> to discover its controller.  The protocol is described in the
> ovs-openflowd manpage:
>        http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-openflowd.8&format=pdf
> 
> The original motivation for controller discovery was the idea of
> allowing configuration of individual OpenFlow switch to be completely
> automatic and hands-off.  You just plug Ethernet and power cables into
> the switch and let it find its controller across the network
> automatically, with no user interface at the switch and nothing else to
> do.  This goal meant that we needed the switch to figure out its own IP
> address, which means DHCP.  Adding the controller configuration to the
> DHCP reply seemed like an obvious approach.  Also, DHCP already had
> provisions for relaying across L2 boundaries, which enterprise switches
> support, so it was nice to be able to piggyback on that.

I understand the motivation,  but this does seem a little circular:  relying on other switches to be up and running so that you can bring this switch up too.  It seems likely that physical switches would always be given a static IP,   in which case the situation more closely resembles that of the software openVSwitch.  Namely,  that you already have an IP address but you still need to hook up with your controller.  So when you run this controller-discovery on the Open VSwitch,  does it also make a DHCP request?  Does it end up with a lease on an IP address that it has no intention of using,  or is there a way to just ask for the vendor-extension config?

> 
> SRV records sound like another reasonable approach.  You do need to
> figure out what SRV record to look up.  How do you do that for sflow?

The lookup is for "_sflow._udp",  with "sflow" being an IANA-registered name (the scheme is described on http://dns-sd.org and in a number of RFCs).

> 
> But the elephant in the room here, in my opinion, is that, as far as I
> know, no one is using discovery for OVS anyhow.  If they were, then we'd
> be getting bug reports or questions about it, and I don't think I've
> ever received one.  I use discovery myself in my own test setup, so I
> know that it works, but I doubt that anyone else uses it.  So I'm not
> too enthused about enhancing or reworking discovery.

Understood.

The problem we are looking at is how to configure sFlow data collection for a whole data-center,  including switches, servers and more.  There are potentially many thousands of agents on a variety of platforms each contributing their piece of the puzzle,  and so the ability to direct them all using a single mechanism like this is highly desirable.

One option would be to have the host-sflow agent detect that there is a openVSwitch running on the same host and pass on the configuration to it using ovs-ctl commands,  but I think you'll agree that it would be much cleaner if the openVSwitch could pick up the settings independently.

Regards,
Neil