[pox-dev] A few general questions about POX

Murphy McCauley murphy.mccauley at gmail.com
Mon May 18 18:59:50 PDT 2015


On May 18, 2015, at 4:35 PM, David Li <dlipubkey at gmail.com> wrote:

> Hi Murphy,
> 
> I wasn't aware of the Open vSwitch extensions.

Ah.  Well to expand on it slightly, here's a quick quote from the (currently down) POX FAQ:

"POX currently supports OpenFlow 1.0.  It also supports a number of the Nicira / Open vSwitch ("nx") extensions (many of which are the basis for features in later OpenFlow versions)."

There's a section of the manual which discusses some of them.

> What I had in mind for a simple vlan support in a POX controller is
> something that uses the vlan APIs described in the POX Wiki pages
> (unfortunately it seems still offline).

Yes, the website is still offline.  I've been making inquiries to try to find out whether the Stanford folks are intending to bring it back up, or if they've just scrapped it.  For the time being, you can access a version from February here:

https://web.archive.org/web/20150203170807/https://openflow.stanford.edu/display/ONL/POX+Wiki

> I also found this one:
> https://github.com/brandonheller/riplpox/tree/master/riplpox
> what do you think?

It really depends on what you are trying to do.  IIRC, riplpox doesn't use VLANs for conventional VLAN purposes at all; it uses them basically as tags to select which of several equal cost paths to use.  I think the design I sketched out in my last email was a pretty reasonable starting point for isolation.  I mentioned a three-table design, but you could also "multiply out" all the rules and put them in a single table (which wouldn't necessarily require any OF 1.3 or OVS features).  And you could skip using POX's spanning tree module and just enable OVS's STP mode.  If you just wanted to do like a learning switch that also learned which VLAN a host thought it was on (i.e., it was like... "VLAN compatible", but not "VLAN enforcing"), that'd be even easier.  Or if you didn't mind sending to all ports on the VLAN (sort of emulating a segment with multiple attachments), that'd be easier too.  There are lots of options, depending on your goals and constraints.

Incidentally, if you are going to play with riplpox, you may be well served by using my fork, which has been updated for more recent versions of POX. It's available at:
https://github.com/murphymc/riplpox

> David
> 
> 
> 
> On Sun, May 17, 2015 at 5:02 AM, Murphy McCauley
> <murphy.mccauley at gmail.com> wrote:
>> On May 15, 2015, at 1:46 PM, David Li <dlipubkey at gmail.com> wrote:
>> 
>>> First the wiki pages seem to be down these days.
>> 
>> Hadn't noticed.  Sent an email to try to find out what's up.
>> 
>>> Second, does POX support OF 1.3? I am using the version packaged with
>>> mininet 2.2.0 VM and don't seem to see this support.
>> 
>> Nope, not yet, and there are no hard plans as to how/when this will happen.  If you're using it with Open vSwitch, POX does have support for a number of OVS extensions, though, and there's a fair amount of feature overlap.
>> 
>>> Third, does anyone know a POX sample code that supports L2 VLAN?
>> 
>> I don't know of one off the top of my head.
>> 
>> But it's also not clear exactly what "supports" means here.  To just get basic VLAN-based isolation, I think you could do it using the multiple table and register Nicira extensions pretty easily.  Start by having a config file which has lines of "<vlan-id> <dpid1>.<port-name1> <dpid2>.<port-name2> ...".  Component reads this in at startup.  Table 0 would be an input filter, which resubmits to table 1 if the VLAN tag is the expected one (or anything for unspecified/trunk ports) and drops otherwise.  Table 1 is a normal learning/forwarding table (code could come from l2_pairs or l2_multi, for example) except that instead of output actions, it loads the output port into a register and jumps to table 2.  Table 2 is the output stage, and it matches the output port and the VLAN tag to filter out attempts to output to ports not on the right VLAN, and also contains rules for flooding each VLAN.  Should be possible to mix with the spanning tree component (provided you don't mind one tree for all VLANs).
>> 
>> -- Murphy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20150518/999cdc2b/attachment-0001.html>


More information about the pox-dev mailing list