Sorry for the non-specific response. The main thing you want (need) to avoid is having the traffic for an OpenFlow controller connection travel over a data plane that is itself controlled by the same connection. In theory this can be made to work, but probably not without firmware changes to one or more of the devices involved.
-Dan On Thursday, May 10, 2012 at 12:09 PM, Heming Wen wrote: > Hi KK, > > Thanks for the heads up. I am currently trying approach #1 (using extra > switch to connect everything under 1 subnet). Before doing that though, I was > trying to test the connection between nox and the PC engine AP. When I was > using pyswitch to test the connection, it seems that the AP's connection to > the controller is constantly on and off (join and left the network > constantly). I am not sure if this is the normal behavior because pyswitch > probably was not designed for controlling the APs. Right now, the AP keeps > disconnecting from the controller. However, it did recognize the DPID I set > for the AP (which was "1"). > > I am not sure if this is because I am using pyswitch instead of the intended > OpenRoads controller. I will be using a different controller eventually but I > wanted to know if there was something wrong with the AP-controller connection > to start off with. > > Thank you again, > > Heming > ________________________________________ > From: yap...@gmail.com (mailto:yap...@gmail.com) [yap...@gmail.com > (mailto:yap...@gmail.com)] on behalf of kk yap [yap...@stanford.edu > (mailto:yap...@stanford.edu)] > Sent: May 10, 2012 13:55 > To: Heming Wen > Cc: Dan Talayco; openflow-discuss@lists.stanford.edu > (mailto:openflow-discuss@lists.stanford.edu) > Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP > > Hi Heming, > > Some comments inline. > > Regards > KK > > On 10 May 2012 09:18, Heming Wen <heming....@mail.mcgill.ca > (mailto:heming....@mail.mcgill.ca)> wrote: > > Hi KK, > > > > In terms of physical hardware, I believe we have the exact same set of > > hardware mentioned in the Stanford OpenRoads testbed. We are using PC > > Engine AP and Pronto 3290 switches with Indigo installed. Right now, a > > controller VM is running on a PC workstation connected to the management > > port of the Pronto switch. Using simple pyswitch.py controller to detect > > devices, a successful connection has been established between the switch > > and the controller. > > > > When you say "make sure the controller is also accessible to the AP on the > > datapath", I am not extremely sure about the approach I should take. Do you > > mean using a second switch (a smaller one, D-Link desktop switch for > > instance) to connect the control port of the switch, the port of the Pc > > workstation controller and the switching plane of the switch (on which the > > AP is attached) together? > > This should work in theory. I assume Indigo allows this. Dan should > be able to comment on this. It is setting up an out-of-band control > network. > > > Or do you mean by having an extra network card installed on the controller > > PC in order to be connected to both the control port of the switch and the > > switching plane (using two subnets). > > Yes, this is what Dan was describing and we have done this before. > With a NEC though. > > > Or are you referring to something else entirely? Is it possible for us to > > use the same approach you used in your setup so we can recreate it? > > We had this setup in various forms over time, using different switches > and APs. There isn't a "particularly right" way to do this. It all > depends on the equipment you have at hand and what you are trying to > do. > > > > > Sorry for asking so many questions at once as I am still relatively new > > with networking in general. > > > > Thank you for your swift response and support. > > > > Heming > > ________________________________________ > > From: yap...@gmail.com (mailto:yap...@gmail.com) [yap...@gmail.com > > (mailto:yap...@gmail.com)] on behalf of kk yap [yap...@stanford.edu > > (mailto:yap...@stanford.edu)] > > Sent: May 9, 2012 22:19 > > To: Heming Wen > > Cc: Dan Talayco; openflow-discuss@lists.stanford.edu > > (mailto:openflow-discuss@lists.stanford.edu) > > Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP > > > > Hi Heming, > > > > One way is to have only the AP in inband mode. Get your switch to the > > controller, then make sure the controller is also accessible to the AP > > on the datapath. We have had such a setup before. It should work. > > > > Regards > > KK > > > > On 9 May 2012 18:42, Heming Wen <heming....@mail.mcgill.ca > > (mailto:heming....@mail.mcgill.ca)> wrote: > > > Hi Dan, > > > > > > Actually, I was wondering about how the OpenRoads deployment was setup. I > > > thought the APs were attached to the OpenFlow switches? Or are they not > > > Pronto switches? In other words, how is the OpenRoads controller setup in > > > order to control both the switches and the AP at the same time? > > > > > > Thank you, > > > > > > Heming > > > ________________________________________ > > > From: Dan Talayco [dan.tala...@bigswitch.com > > > (mailto:dan.tala...@bigswitch.com)] on behalf of Dan Talayco > > > [dtala...@stanford.edu (mailto:dtala...@stanford.edu)] > > > Sent: May 9, 2012 18:00 > > > To: Heming Wen > > > Cc: openflow-discuss@lists.stanford.edu > > > (mailto:openflow-discuss@lists.stanford.edu) > > > Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine > > > AP > > > > > > I believe you're basically asking the switch to route (or at least > > > switch) between the management port and the dataplane. The short answer > > > is that the switch won't do this and it's not planned to be supported. > > > > > > You probably want "physical in-band management" where the Pronto switch > > > is managed by a connection accessed through a data plane port. This > > > feature is not yet fully supported on the Pronto platforms, although some > > > people are working with it now. Note that although physically on a > > > dataplane port, the connection may still be logically separated from the > > > OpenFlow controlled traffic. > > > > > > If you take this approach (of physical in-band) would you expect to be > > > able to dedicate a VLAN to management (including the controller traffic)? > > > The alternative is to have OpenFlow controlling the traffic to the > > > controller, something that has enough pitfalls that no one has really > > > gotten it to work reliably. > > > > > > -Dan > > > > > > > > > On Wednesday, May 9, 2012 at 1:17 PM, Heming Wen wrote: > > > > > > Greetings, > > > > > > We are currently setting up a basic Openflow Wireless testbed with three > > > PC Engine AP and a Pronto 3290 switch in our labs. We have a few > > > questions regarding the connection between the elements: > > > > > > 1) There are three controller path setups possible: L3 inband, tunneling > > > and L2 inband. If we want to setup a small demo (n-casting for instance), > > > is there a preference for a particular configuration? > > > > > > 2) How must the Openflow controller connected to the network in order to > > > control the AP? Right now, the openflow controller is connected to the > > > special ethernet port of the Pronto switch (in order to control the > > > switch). The default pyswitch controller can detect the Indigo/Pronto > > > switch. However, the AP is connected to the switching plane of the Pronto > > > switch. Is there a way to access the switching plane ports from the > > > control port or must the controller be connected in a different fashion? > > > Right now, pinging doesn't work between the switching plane and the > > > control plane. > > > > > > Thank you for your help, > > > > > > Heming > > > _______________________________________________ > > > openflow-discuss mailing list > > > openflow-discuss@lists.stanford.edu<mailto:openflow-discuss@lists.stanford.edu> > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > > > > _______________________________________________ > > > openflow-discuss mailing list > > > openflow-discuss@lists.stanford.edu > > > (mailto:openflow-discuss@lists.stanford.edu) > > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > > > > > > > > >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
