Hi, If you are having the connection to AP come and go, you are probably having a connection. Question is why is the AP disconnecting. Look at the log of the controller. That should say something.
Regards KK On 10 May 2012 12:30, Dan Talayco <dtala...@stanford.edu> wrote: > 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 [yap...@gmail.com] on behalf of kk yap > [yap...@stanford.edu] > Sent: May 10, 2012 13:55 > To: Heming Wen > Cc: Dan Talayco; 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> 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 [yap...@gmail.com] on behalf of kk yap > [yap...@stanford.edu] > Sent: May 9, 2012 22:19 > To: Heming Wen > Cc: Dan Talayco; 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> 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] on behalf of Dan Talayco > [dtala...@stanford.edu] > Sent: May 9, 2012 18:00 > To: Heming Wen > Cc: 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 > 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
