On Mon, Nov 2, 2015 at 1:04 PM, <[email protected]> wrote: > Thanks for the reply. My main concern here is the set of default flows > that must already be running in each OF-only Switch in order for the > Controller to reach them and program them. >
There are not necessarily any pre-existing flows - that is an implementation detail. What there must be is *some* kind of pre-existing "configuration" - implementation as flows or something else doesn't really matter. > It seems that those default flows have to allow for certain traffic > to/from all next-hop devices... just as the existing OVS default flows do. > But > as mentioned, the current OVS default flows seem to be intended for a > hybrid Switch. In a true OF-only Switch, it seems that we have to just > send requests to port LOCAL. The Switch will respond to requests such as > ARP... so we get a ARP (response) packet from port LOCAL and we have to > send it out. Without any hybrid type intelligence (port/MAC > associations?), we are left to flood that response out all ports. That > seems less than ideal, but perhaps is what has to be done... short of > something that requires more direct configuration via a UI or some other > less general set up option. There are many ways this can work, although it's best not to think about this with only the constraints of openflow (e.g. LOCAL port). Pure OF switches have functionality and configuration that is outside the purview of the OpenFlow specification. Two common mechanisms are to configure the control plane connection as either being on a specific front-panel port (which also handles data-plane traffic, so this is still "in-band"), or on a specific VLAN. In the case of a specific port the initial ARP is sent out that port, and assuming your controller is directly connected to it (for the first switch), or has properly configured flows (for later switches in the tree), this ARP reaches your controller host and the response is sent back. After that you can establish a control plane connection and then insert flows for the next downstream hop. Note that the switch implementation must take particular care not to drop the control connection as soon as it creates it (this is sortof what the "hidden flows" are for - so you never lose your connection when the flow table is empty but you're in fail-secure mode, but whether those are hidden flows or some other implementation is not relevant). If the configuration is by VLAN then this is similar, but the ARP is flooded out all ports, tagged with the management VLAN. Ultimately using a specific port isn't a good long-term plan, as it significantly limits your ability to handle link failures. There are other options as well, but really the implementation is not particularly important - the way this works is the controller is the root of a spanning tree, and the switches are configured in whatever way they support to allow them to become functioning members of the control network. If a switch claims to support "in-band" control, it will have *some* mechanism that works to configure this (otherwise your vendor is lying to you). -- Nick
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
