On Fri, Jun 18, 2010 at 03:18:09PM -0700, Neil McKee wrote:
> 
> 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?

The current implementation of controller discovery links discovery of
the switch's IP address and discovery of the controller.  The idea was
that the special DHCP daemon that the switches talk to would run on the
controller itself.  The controller's DHCP daemon will ignore request
that don't include the OVS vendor extension, and OVS will ignore DHCP
replies that don't include it, so this inter-operates OK with any
existing DHCP servers on the network.

It's not really circular.  It grows outward from the controller.  The
switches directly connected to a controller come up first, then the
switches directly connected to those switches, and so on.

SRV is another way, that makes more sense if the switch already has an
IP address.

_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org

Reply via email to