Good point -- I should have mentioned the two NIC option! I skipped it because
I've never found it practical/desirable myself, but it is certainly the
simplest conceptually.
-- Murphy
On Apr 21, 2014, at 2:50 AM, Andrew Ferguson <a...@cs.brown.edu> wrote:
>
> On Apr 21, 2014, at 3:50 PM, Murphy McCauley <murphy.mccau...@gmail.com>
> wrote:
>> A more straightforward approach is to actually have the controller machine
>> exist on the data network. This is always the case when doing "in-band
>> control". If your switches are, for example, Open vSwitch, the most
>> straightforward way is using the "local" interface of the OVS instance.
>> This interface is usually down by default, but you can up it. This connects
>> the switch machine's local networking stack (which can obviously reach the
>> controller because this is how the switch reaches the controller!) to the
>> data network. Obviously, you'll need to install appropriate table entries
>> to allow communication between the controller machine (via the local port)
>> and the host (via whatever port it's connected to).
>
> or you can just add a second interface to your controller, placing it on the
> data-plane. :-) this keeps the simplicity and isolation of out-of-band
> networking, while giving our controller and hosts easy communication.
>
> I usually do this by creating a "controller host" in Mininet where I run my
> controller (in your case, it would be POX). however, I don't put that host in
> a separate namespace, which means that its loopback interface is in the same
> namespace as all the switches (and gets used as the "control-plane" in
> mininet). the regular eth-pair device gets attached to the switch
> ("data-plane"). see, for example:
> https://github.com/brownsys/pane-demo-vm/blob/master/demos/PaneDemo.py#L56
>
> in the physical testbed, we just use two NIC cards.
>
>
> Andrew
