Announcing the new RouteFlow design

Christian Esteve Rothenberg

unread,

May 31, 2012, 1:08:42 PM5/31/12

to routeflo...@googlegroups.com

What's new

We're glad to announce an entirely new version of RouteFlow, with many new features in response to our first year´s experiences and the requests from users and developers!
The version has been in an experimental branch for some time now and is stable enough to become mainstream.

In this new version, we have introduced:

Centralized database and IPC

We leverage MongoDB for storing the core system´s state and the OpenFlow network statistics. A JSON-based IPC service (aka RouteFlow protocol) is also implemented on top of it.

Cleaner code base

Much of the code was rewritten and organized, making it easier for developers to play with RouteFlow.
This includes the renaming of some components: RF-Slave becomes RFClient, RF-Controller becomes RFProxy.

POX support

Support for using the new POX controller was added.

Web monitoring interface (requires POX)

Inspect network topology, RouteFlow internal messages and network state.

Open vSwich v1.4

To attach the virtual interfaces (eth1 to ethX) of the VMs.
Used also in the control network that (attaching et0) and running in bridge mode removes the requirement of a second controller instance to act as a simple L2 switch.

Tools for testing

A new module (rftest) introduces several scripts to facilitate testing and environment creation.

SNMP support

Export OpenFlow stats via SNMP. [Contribution by Joe Stringer]

The detailed description of these new features is available in the README file.

You can download the new pre-configured VM (3.7GB) from here: ftp://ftp.cpqd.com.br/pub/routeflow/RouteFlow.zip
or get it via github.

What's next

The list is long!

Foremost we want to make RouteFlow more and easier configurable. Currently, there's no trivial way to associate VMs and datapaths statically, but we want to solve this through a new configuration apporach.
RouteFlow with NOX requires Ubuntu 11.04 (POX users should be fine in newer versions). We will be adding support for Ubuntu 11.10 and 12.04.
Embrace OpenFlow v1.X. We have working prototypes of NOX and software-based reference switch using OpenFlow 1.1 and 1.2.
Extensions to support LDP label information.
Exploration of possibilities opened by the use of a central database (e.g., keep state history and allow queries like "show me flow table at timestamp x").
Address High Availability.
New routing abstractions implemented as Services on top of the RF-Server.
... a number of additions under investigation by students and project collaborators.

Stay tuned for further news!

Thank you all!

--
Christian Esteve Rothenberg, Ph.D.
Converged Networks Business Unit
CPqD - Center for Research and Development in Telecommunications
Tel. (+55 19) 3705 4479 / Cel. (+55 19) 8193-7087

joshb

unread,

Jun 4, 2012, 5:14:42 AM6/4/12

to RouteFlow

Hi Christian;

Nice to see! Definitely fewer moving pieces in the new design which is
great! Also being able to use pox as well will be helpful.

Unfortunately the new setup doesn't appear to work for me with neither
nox nor pox - no packets are received by the control VM rfvm1. I used
Ubuntu 11.0.4 (x64).

I can build fine (though I had to add CPPFLAGS=-fPIC, LDFLAGS=-fPIC).
It's also a bit scary that mongodb is built with prefix /usr which
would overwrite any packaged distribution - but no big deal.

Also the README says to use --nox vs --pox for testing. The scripts
though are actually rftest1 and rftest1_pox and they don't take
command line arguments - and the default user password is root/root
not routeflow.

Anyway - on to the actual problem. :-) switch1 is correctly set up and
when I ping from b1 or b2, ARP packets are tunnelled to the
controller. However rfvm1 never sees them. I uncommented the logging
line in RouteFlow/pox/ext/rfproxy.py:

results = rftable.find({VS_ID: str(event.dpid)})
if results.count() == 0 or results[0][VM_ID] == "":
results = rftable.find({VS_ID: {"$ne": ""}, DP_ID:
str(event.dpid), DP_PORT: str(event.port)})
if results.count() == 0:
log.info("Datapath not associated with a VM")
return

And I see now "Datapath not associated with a VM" on each ping
attempt.

Please let me know if you have any suggestions? Otherwise I will
continue to troubleshoot.

Thanks.

# ./rftest1_pox
Resetting and stopping LXC VMs...
Stopping any running instances and data of rfserver, POX, OVS and
MongoDB...
Starting MongoDB...
all output going to: /dev/null
Starting the rfvm1 virtual machine...
Starting the management network (br0)...
Starting POX and the RouteFlow network controller...
POX 0.0.0 / Copyright 2011 James McCauley
2012-06-04 01:57:41,092 - ext.rfproxy - INFO - RFProxy running.
2012-06-04 01:57:42,538 - openflow.topology - INFO - Switch 60-
eb-69-21-5b-92 connected
DP is up, installing config flows... `?i![
Starting the RouteFlow server...
Starting the control plane network (dp0 OVS)...
2012-06-04 01:57:46,241 - openflow.topology - INFO - Switch
76-73-72-66-76-73|29286 connected
DP is up, installing config flows... rfvsrfv
Starting the sample network...
2012-06-04 01:57:49,744 - openflow.topology - INFO - Switch f6-39-
ee-55-73-49 connected
DP is up, installing config flows... ?9?Us
Now we'll open this test's log.
Try pinging b1 from b2:
$ sudo lxc-console -n b1
Login and run:
$ ping 172.31.2.2
Jun 04 01:57:22|00042|bridge|WARN|bridge dp0: using default bridge
Ethernet address c6:04:a7:73:d2:45
Jun 04 01:57:22|00043|ofproto|INFO|datapath ID changed to
7266767372667673
Jun 04 01:57:22|00044|rconn|INFO|dp0<->tcp:127.0.0.1:6633:
connecting...
Jun 04 01:57:22|00045|rconn|WARN|dp0<->tcp:127.0.0.1:6633: connection
failed (Connection refused)
Jun 04 01:57:22|00046|rconn|INFO|dp0<->tcp:127.0.0.1:6633: waiting 1
seconds before reconnect
Jun 04 01:57:22|00047|bridge|WARN|bridge switch1: using default bridge
Ethernet address 9a:2c:80:a6:9b:47
Jun 04 01:57:22|00048|ofproto|INFO|datapath ID changed to
00009a2c80a69b47
Jun 04 01:57:22|00049|rconn|INFO|switch1<->tcp:127.0.0.1:6633:
connecting...
Jun 04 01:57:22|00050|rconn|WARN|switch1<->tcp:127.0.0.1:6633:
connection failed (Connection refused)
Jun 04 01:57:22|00051|rconn|INFO|switch1<->tcp:127.0.0.1:6633: waiting
1 seconds before reconnect

# ovs-ofctl dump-flows switch1
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
udp,nw_dst=224.0.0.9 actions=CONTROLLER:65535
cookie=0x0, duration=580.692s, table=0, n_packets=6, n_bytes=252, arp
actions=CONTROLLER:65535
cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
tcp,tp_dst=179 actions=CONTROLLER:65535
cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
ip,nw_proto=89 actions=CONTROLLER:65535
cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0, icmp
actions=CONTROLLER:65535
# ovs-ofctl show switch1
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000f639ee557349
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
1(b1.0): addr:1e:74:db:7a:d2:ce
config: 0
state: 0
current: 10GB-FD COPPER
2(b2.0): addr:ee:1c:48:59:6c:2e
config: 0
state: 0
current: 10GB-FD COPPER
LOCAL(switch1): addr:f6:39:ee:55:73:49
config: 0
state: 0
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0

On Jun 1, 5:08 am, Christian Esteve Rothenberg <est...@cpqd.com.br>
wrote:
> *What's new*

> We're glad to announce an entirely new version of RouteFlow, with many new
> features in response to our first year´s experiences and the requests from
> users and developers!
> The version has been in an experimental branch for some time now and is
> stable enough to become mainstream.
>
> In this new version, we have introduced:
>

> - Centralized database and IPC
> - We leverage MongoDB for storing the core system´s state and the

> OpenFlow network statistics. A JSON-based IPC service (aka RouteFlow
> protocol) is also implemented on top of it.

> - Cleaner code base
> - Much of the code was rewritten and organized, making it easier for

> developers to play with RouteFlow.
> This includes the renaming of some components: RF-Slave becomes
> RFClient, RF-Controller becomes RFProxy.

> - POX support
> - Support for using the new POX controller was added.
> - Web monitoring interface (requires POX)
> - Inspect network topology, RouteFlow internal messages and network
> state.
> - Open vSwich v1.4
> - To attach the virtual interfaces (eth1 to ethX) of the VMs.
> - Used also in the control network that (attaching et0) and running

> in bridge mode removes the requirement of a second controller instance to
> act as a simple L2 switch.

> - Tools for testing
> - A new module (rftest) introduces several scripts to facilitate
> testing and environment creation.
> - SNMP support
> - Export OpenFlow stats via SNMP. [Contribution by Joe
> Stringer<https://github.com/joestringer>
> ]
>
> <https://sites.google.com/site/routeflow/updates/announcingthenewroute...>

>
> The detailed description of these new features is available in the README

> <https://github.com/CPqD/RouteFlow/blob/master/README>file.

>
> You can download the new pre-configured VM (3.7GB) from

> here<ftp://ftp.cpqd.com.br/pub/routeflow/RouteFlow.zip>:ftp://ftp.cpqd.<https://sites.google.com/site/routeflow/updates/goog_66211347>
> com.br/pub/routeflow/RouteFlow.zip
> or get it via github <https://github.com/CPqD/RouteFlow/>.
>
> *What's next*
> The list is long!
>
> - Foremost we want to make RouteFlow more and easier configurable.

> Currently, there's no trivial way to associate VMs and datapaths
> statically, but we want to solve this through a new configuration apporach.

> - RouteFlow with NOX requires Ubuntu 11.04 (POX users should be fine in

> newer versions). We will be adding support for Ubuntu 11.10 and 12.04.

> - Embrace OpenFlow v1.X. We have working prototypes of NOX and

> software-based reference switch using OpenFlow 1.1 and 1.2.

> - Extensions to support LDP label information.
> - Exploration of possibilities opened by the use of a central database

> (e.g., keep state history and allow queries like "show me flow table at
> timestamp x").

> - Address High Availability.
> - New routing abstractions implemented as Services on top of the
> RF-Server.
> - ... a number of additions under investigation by students and project

Allan Vidal

unread,

Jun 4, 2012, 8:28:57 AM6/4/12

to routeflo...@googlegroups.com

Hi Josh,

About Mongo in /usr: yep, that's not the ideal. We plan to support Ubuntu 12.04 soon, and then it will be a matter of apt-getting mongo :)

As for the testing, the default user/password for the prebuilt VM is routeflow/routeflow. The LXC containers are root/root.

Anyhow, I changed the scripts a lot in the last commits a few days ago. Try pulling from the repository. I believe they're much better, though not quite flawless :) You might have run into some troublesome commit.

There's a small glitch: in the first run of the tests after booting, OVS behaves badly sometimes. You have to close the script and try again, then it should work.

Please, let me know if you run into any problems :)

Allan

Josh Bailey

unread,

Jun 4, 2012, 7:02:01 PM6/4/12

to routeflo...@googlegroups.com

Hi Allan;

Thanks, things are a bit closer now but still not working. The rfvm1 VM
now receives packets but eth1 (for example) drops them all:

eth1 Link encap:Ethernet HWaddr 12:b1:b1:b1:b1:b1
inet addr:172.31.1.1 Bcast:172.31.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:43 errors:0 dropped:43 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3655 (3.6 KB) TX bytes:0 (0.0 B)

I'll keep troubleshooting but any suggestions appreciated.

--
Josh Bailey

Josh Bailey

unread,

Jun 5, 2012, 8:29:26 AM6/5/12

to routeflo...@googlegroups.com

Hi Allan;

OK, I find the problem. Firstly there's a lot of startup races in rftest1.
For example, if MongoDB fails in time to start nothing else works and just
crashes. I added some checks to make sure MongoDB starts before
proceeding. I'll send a patch.

But the actual problem is, that RFServer gets a datapath join event for
"0x60eb69215b92", which happens to be br0. The control plane datapath
joins no problem, but then switch1 tries to join. br0 has already claimed
the control plane VM so nothing works.

I just hacked rfserver.cc to never associate 0x60eb69215b92 with a VM.
Then when switch1 comes up the VM is free and everything works.

I'm not sure how the code as is currently checked in can work at all,
unless I am missing something - Eg, br0 just happens to very slow to come
up so it comes up last. Probably the right solution is to add a more
robust check for br0 to ignore it no matter when it comes up.

Thanks,

--
Josh Bailey

Allan Vidal

unread,

Jun 5, 2012, 9:04:26 AM6/5/12

to routeflo...@googlegroups.com

Hi Josh,

br0 shouldn't be connecting to the controller, as it should be managed by OVS itself. But it's what seems to be happening. I'll look into it and get back to you ASAP.

Allan

Allan Vidal

unread,

Jun 5, 2012, 9:50:01 AM6/5/12

to routeflo...@googlegroups.com

Hi Josh,

I tested here, and br0 never connects to either NOX or POX. Which version of OVS are you using?

What happens here is the following:

-> Starting the control plane network (dp0 VS)...

INFO:openflow.of_01:[Con 1/8243406406160905843] Connected to 76-73-72-66-76-73|29286

[...]

-> Starting the sample network...

INFO:openflow.of_01:[Con 2/34042236714307] Connected to 1e-f6-13-6d-3d-43

The DP IDs are:

~$ sudo ovs-vsctl get Bridge br0 datapath-id

"0000b69ab5a1b348"

~$ sudo ovs-vsctl get Bridge switch1 datapath-id

"00001ef6136d3d43"

And OVS says the configured controllers are:

~$ sudo ovs-vsctl get-controller br0

~$ sudo ovs-vsctl get-controller switch1

tcp:127.0.0.1:6633

I'm very curious as to why your br0 is connecting to the controller... Based on the OVS man pages, I believe this shouldn't be happening (man ovs-vsctl):

ovs-vswitchd can perform all configured bridging and switching locally,

or it can be configured to communicate with one or more external Open‐

Flow controllers. The switch is typically configured to connect to a

primary controller that takes charge of the bridge's flow table to

implement a network policy. In addition, the switch can be configured

to listen to connections from service controllers. Service controllers

are typically used for occasional support and maintenance, e.g. with

ovs-ofctl.

Does this behavior persist? Do you have any theories?

As for the Mongo and other race conditions, you're right, we're still too dependent on the order of the events. Your patch will be very helpful :)

Thank you,

Allan

joshb

unread,

Jun 5, 2012, 6:18:30 PM6/5/12

to RouteFlow

Thanks! It's completely consistent - without my hack nothing works.
Bit of a puzzle why we see something different.

I am using OVS 1.4.1 per the instructions. ovs-ofctl list-br shows
only br0 dp0 and switch1.

I'll keep investigating and let you know (and also send the startup
patch).

> >>>> Jun 04 01:57:22|00042|bridge|WARN|**bridge dp0: using default

> >>>> bridge
> >>>> Ethernet address c6:04:a7:73:d2:45

> >>>> waiting 1
> >>>> seconds before reconnect

> >>>> Jun 04 01:57:22|00047|bridge|WARN|**bridge switch1: using default

> >>>> bridge
> >>>> Ethernet address 9a:2c:80:a6:9b:47

> >>>> waiting
> >>>> 1 seconds before reconnect
>
> >>>> # ovs-ofctl dump-flows switch1
> >>>> NXST_FLOW reply (xid=0x4):
> >>>> cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
> >>>> udp,nw_dst=224.0.0.9 actions=CONTROLLER:65535
> >>>> cookie=0x0, duration=580.692s, table=0, n_packets=6,
> >>>> n_bytes=252, arp
> >>>> actions=CONTROLLER:65535
> >>>> cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
> >>>> tcp,tp_dst=179 actions=CONTROLLER:65535
> >>>> cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
> >>>> ip,nw_proto=89 actions=CONTROLLER:65535
> >>>> cookie=0x0, duration=580.692s, table=0, n_packets=0, n_bytes=0,
> >>>> icmp
> >>>> actions=CONTROLLER:65535
> >>>> # ovs-ofctl show switch1
>

> ...
>
> read more »

Josh Bailey

unread,

Jun 5, 2012, 7:25:25 PM6/5/12

to routeflo...@googlegroups.com

Hi Allan;

Here's my patch to rftest1 (essentially just removes all the sleeps and
waits for ports to be listening instead).

--
Josh Bailey

rftest1.patch

Josh Bailey

unread,

Jun 5, 2012, 11:48:13 PM6/5/12

to routeflo...@googlegroups.com

OK. I am now able to swap out "switch1" with a hardware OpenFlow switch
and have pings work. However I had to fix another problem along the way.

This problem is in RFServer.cc. My hardware switch has lots of ports, of
course, so I want to add them all. However, RFServer.cc only handles
VM_MAP messages where there are no existing entries with VS_ID set. So it
handles the first ports and then silently drops the rest because the first
ones to add, add entries with VS_ID...

I just commented out query[VS_ID] = "" (see below) and now all VM_MAP
messages are processed.

Would it be possible to commit a fix for this?

Thanks,

else if (type == VM_MAP) {
VMMap *mapmsg = dynamic_cast<VMMap*>(&msg);
syslog(LOG_INFO, "Mapping message arrived from vm=0x%llx",
mapmsg->get_vm_id());

// Search for VM's with no mapping
map<string, string> query;
vector<RFEntry> results;
query[VM_ID] = to_string<uint64_t>(mapmsg->get_vm_id());
// query[VS_ID] = "";
^^^^^^^^^^^^^^^^^^^^^
// Querying for VS_ID is enough, but we could play it safe
and query all mapping attributes
results = this->rftable->get_entries(query);

--
Josh Bailey

Allan Vidal

unread,

Jun 6, 2012, 1:49:22 PM6/6/12

to routeflo...@googlegroups.com

Hi Josh,

I'm not sure I understand the problem. You said RFServer handles the first ports and then silently drops the rest, but that's not what should happen.

When a switch joins RFServer and there's an idle VM to connect, it will create N entries, where N is the number of switch ports. The format of these entries will be:

vm_id, -, -, -, dp_id, -

After that, the VM will be instructed to send mapping packets on each of its interfaces. When a mapping message arrives at the controller and is redirected to RFServer, we check if there's an unmapped entry in the format above (thus, the check for VS_ID=""). When there's, we make it an active entry:

vm_id, vm_port, vs_id, vs_port, dp_id, dp_port

Removing the check for VS_ID="" could potentially cause valid entries to be overwritten in the association table.

Are you running RouteFlow under POX?

If you are, it will be interesting to see what happens (with and without your modification) in the association table through the web interface. You can start it by going to rfweb, running "python rfweb_server.py" and then access http://localhost:8080/index.html

You will need pymongo as instructed in the README file.

And thanks for the patch! We really appreciate your efforts :)

Allan

Christian Esteve Rothenberg

unread,

Jun 6, 2012, 3:05:13 PM6/6/12

to routeflo...@googlegroups.com

Thanks Josh for your efforts in debugging and the patch!

We shall extend our tests with hardware OpenFlow switches, beyond the
4-port NetFPGAs.

What is really strange is that OVS br0 uses the OpenFlow channel to
connect to the OpenFlow controller, that should not be the case when
initiating OVS in bridge mode...

We will work on a stable fix for the port mapping issue once we can
reproduce it.

Cheers,
Christian

Josh Bailey

unread,

Jun 6, 2012, 7:52:45 PM6/6/12

to routeflo...@googlegroups.com

So I have some good news on that one - the br0 problem was due to a left
over OVS config database. I got rid of that and now br0 no longer tries to
connect.

--
Josh Bailey

Josh Bailey

unread,

Jun 6, 2012, 8:09:22 PM6/6/12

to routeflo...@googlegroups.com

Here is a dump of the table with my patch (I used --pox here):

> db.rftable.find()
{ "_id" : ObjectId("4fcfee5af11787ac125f25d8"), "dp_id" :
"106564197374866", "dp_port" : "10", "vm_id" : "1701698025116532",
"vm_port" : "10", "vs_id" : "8243406406160905843", "vs_port" : "10" }
{ "_id" : ObjectId("4fcfee5af11787ac125f25d8"), "dp_id" :
"106564197374866", "dp_port" : "2", "vm_id" : "1701698025116532",
"vm_port" : "2", "vs_id" : "8243406406160905843", "vs_port" : "2" }
{ "_id" : ObjectId("4fcfee5af11787ac125f25d8"), "dp_id" :
"106564197374866", "dp_port" : "11", "vm_id" : "1701698025116532",
"vm_port" : "11", "vs_id" : "8243406406160905843", "vs_port" : "11" }

Note 2, 10, 11 are all up.

Here's without the patch:

> db.rftable.find()
{ "_id" : ObjectId("4fcff02a8eefc05e4c94de33"), "dp_id" :
"106564197374866", "dp_port" : "1", "vm_id" : "8680158250242133",
"vm_port" : "1", "vs_id" : "8243406406160905843", "vs_port" : "1" }
{ "_id" : ObjectId("4fcff02a8eefc05e4c94de34"), "dp_id" :
"106564197374866", "dp_port" : "2", "vm_id" : "8680158250242133",
"vm_port" : "2", "vs_id" : "8243406406160905843", "vs_port" : "2" }

As you can see ports 10 and 11 among others are missing. So I don't think
my patch is the correct solution but it does illustrate the problem.

When I ping from port 11, without the patch, I see:

DEBUG:ext.rfproxy:Datapath not associated with a VM

Which is true - it's not in rftable. Even though clearly the VM_MAP
messages are arriving.

I tweaked the logging messages slightly to make it more clear:

Jun 6 17:04:58 project-w-2 rf-server[14199]: Mapping message arrived from
vm=0x1ed68ed5199055
Jun 6 17:04:58 project-w-2 rf-server[14199]: Adding entry for
vs_id=1919317619, vs_port=1, vm_port=1, dp_port=1
Jun 6 17:04:58 project-w-2 rf-server[14199]: Mapping message arrived from
vm=0x1ed68ed5199055
Jun 6 17:04:58 project-w-2 rf-server[14199]: Adding entry for
vs_id=1919317619, vs_port=2, vm_port=2, dp_port=2
Jun 6 17:04:58 project-w-2 rf-server[14199]: Mapping message arrived from
vm=0x1ed68ed5199055
Jun 6 17:06:02 project-w-2 rf-server[14199]: last message repeated 8
times

As you can see the VM_MAP messages are arriving but RFServer only adds the
first two and ignores the rest.

--
Josh Bailey

Josh Bailey

unread,

Jun 6, 2012, 9:58:23 PM6/6/12

to routeflo...@googlegroups.com

So just running rftest1 --pox with unmodified code, here's what happens:

VM has registered, but switch1 is not up yet. register_vm() adds this
entry.

> db.rftable.find()
{ "_id" : ObjectId("4fd00a19a784d5bdd7305713"), "vm_id" :
"1142171972022649", "vm_port" : "", "vs_id" : "", "vs_port" : "", "dp_id"
: "", "dp_port" : "" }

Now switch1 has come up.

> db.rftable.find()
{ "_id" : ObjectId("4fd00a38a784d5bdd730571c"), "dp_id" :
"270793501641551", "dp_port" : "1", "vm_id" : "1142171972022649",
"vm_port" : "1", "vs_id" : "1919317619", "vs_port" : "1" }
{ "_id" : ObjectId("4fd00a38a784d5bdd730571d"), "dp_id" :
"270793501641551", "dp_port" : "2", "vm_id" : "1142171972022649",
"vm_port" : "2", "vs_id" : "1919317619", "vs_port" : "2" }

The "wild card" VS_ID = "" is gone. Because it's gone no new entries can
be added.

--
Josh Bailey

Allan Vidal

unread,

Jun 11, 2012, 8:47:37 AM6/11/12

to routeflo...@googlegroups.com

Hi Josh,

What's the number of ports informed by the switch? It's in the DatapathJoin message that goes through the rfserver<->rfproxy channel (the collection is named the same).

A possibility is that the config from previous runs is being kept. The Mongo database is deleted in each run of the script so we have a clean testing environment each time, but if isn't and the switch informed it had two ports in a previous run, it will remain as the expected value. Again, we plan to change that soon in a new scheme of manual, updatable configuration.

Allan

Josh Bailey

unread,

Jun 11, 2012, 9:11:51 PM6/11/12

to routeflo...@googlegroups.com

It's 11. And I confirm that the database is being deleted.

--
Josh Bailey

Allan Vidal

unread,

Jun 12, 2012, 3:02:39 PM6/12/12

to routeflo...@googlegroups.com

Hi Josh,

I tried to setup a similar test based on your scenario, using OVS. It's basically rftest1 modified to include more ports (1 and 2 are connected to hosts b1 and b2, respectively, and the rest is inactive).

I had to change a few things:

1) The config file for rfvm1 to include the new interfaces (now rfvm1.0-rfvm1.11)

2) /etc/network/interfaces in rfvm1 to setup the new interfaces

3) rftest1 to include the new ports. This is the interesting part:

For the linked interfaces in switch1 (b1.0 and b2.0), I just add them.

For the inactive interfaces in switch1 (b3.0 to b11.0), I needed to add "-- set interface b*.0 type=internal" to the add-port command so that they're created regardless of being linked.

After we do that, we have 11 ports in the switch, so RFServer creates 11 entries in RFTable. When the mapping packets come from the VM, they should fill the table appropriately.

I also needed to add the ports a command at a time. This is so that the ports are added in order: we want port 1 in the switch to be associated with port 1 in the control plane (dp0). If we add the ports in a single command, b2.0 might end up as port 5 in the switch for example, messing with what we configured in rfvm1. Actually, this is an issue I identified modifying rftest1 and I will fix it soon.

I'm very puzzled by your issue. Could you try this modified version of rftest1 to see what happens?

Are you using a hardware switch? If it's informing 11 ports in the datapath join event, this number of entries should've been created, even if they're blank at first.

What might be happening is that only some (the active?) ports are being communicated by the switch. In this case, fewer entries will be created, and so mapping messages will be discarded when they arrive from the VM.

Allan

rftest1_mod

interfaces

config

Josh Bailey

unread,

Jun 12, 2012, 5:16:09 PM6/12/12

to routeflo...@googlegroups.com

Ah! Thanks! I'll follow your suggestions and update you with the result.
Makes sense to me that there will be a mismatch based on whether ports are
active or not.

--
Josh Bailey

Josh Bailey

unread,

Jun 25, 2012, 6:55:52 AM6/25/12

to routeflo...@googlegroups.com

Hi Allan;

I finally was able to test this (add all ports on the hardware OpenFlow
switch, one at a time, in order, and do the same with the RouteFlow VM's
interfaces). Then I am able to pass traffic.

Great! Thanks for all the help.

I think the key thing now is to identify via configuration, which ports on
what switch are associated with what VM/interface. Are there any specific
plans in this area?

Thanks,

--
Josh Bailey

Allan Vidal

unread,

Jun 25, 2012, 9:01:50 AM6/25/12

to routeflo...@googlegroups.com

Hi Josh,

I'm very glad it worked!

Currently, the only possibility of configuration is manually editing RFTable through MongoDB. But even in this case, the only configuration we can change is the VM-DP association. The ports and interfaces are still associated automatically.

We plan a new algorithm in which there will be a static configuration file (a CSV file, maybe), that will be read when RFServer starts. Association will then only be performed when there's a full match in the config file.

The plan is to implement it ASAP, but we can't give any hard deadlines. I expect we will have something in the next two or three months.

Allan

What's the number of ports informed by the switch? It's in the DatapathJoin message that goes through theárfserver<->rfproxy channel

(the collection is named the same).
A possibility is that the config from previous runs is being kept. The Mongo database is deleted in each run of the script so we
have a clean testing environment each time, but if isn't and the switch informed it had two ports in a previous run, it will remain
as the expected value. Again, we plan to change that soon in a new scheme of manual, updatable configuration.

Allan

On Wed, Jun 6, 2012 at 10:58 PM, Josh Bailey <jo...@google.com> wrote:

á á áSo just running rftest1 --pox with unmodified code, here's what happens:

á á áVM has registered, but switch1 is not up yet. register_vm() adds this entry.

á á á á á ádb.rftable.find()

á á á{ "_id" : ObjectId("4fd00a19a784d5bdd7305713"), "vm_id" : "1142171972022649", "vm_port" : "", "vs_id" : "", "vs_port" :
á á á"", "dp_id" : "", "dp_port" : "" }

á á áNow switch1 has come up.

á á á á á ádb.rftable.find()

á á á{ "_id" : ObjectId("4fd00a38a784d5bdd730571c"), "dp_id" : "270793501641551", "dp_port" : "1", "vm_id" :
á á á"1142171972022649", "vm_port" : "1", "vs_id" : "1919317619", "vs_port" : "1" }
á á á{ "_id" : ObjectId("4fd00a38a784d5bdd730571d"), "dp_id" : "270793501641551", "dp_port" : "2", "vm_id" :
á á á"1142171972022649", "vm_port" : "2", "vs_id" : "1919317619", "vs_port" : "2" }

á á áThe "wild card" VS_ID = "" is gone. Because it's gone no new entries can be added.

á á áOn Wed, 6 Jun 2012, Allan Vidal wrote:

á á á á á áHi Josh,

á á á á á áI'm not sure I understand the problem. You said RFServer handles the first ports and
á á á á á áthen silently drops the rest, but that's not what should happen.

á á á á á áWhen a switch joins RFServer and there's an idle VM to connect, it will create N
á á á á á áentries, where N is the number of switch ports. The format of these entries will be:
á á á á á ávm_id, -, -, -, dp_id, -

á á á á á áAfter that, the VM will be instructed to send mapping packets on each of its
á á á á á áinterfaces. When a mapping message arrives at the controller and is redirected to
á á á á á áRFServer, we check if there's an unmapped entry in the format above (thus, the check
á á á á á áfor VS_ID=""). When there's, we make it an active entry:
á á á á á ávm_id, vm_port, vs_id, vs_port, dp_id, dp_port

á á á á á áRemoving the check for VS_ID="" could potentially cause valid entries to be
á á á á á áoverwritten in the association table.

á á á á á áAre you running RouteFlow under POX?
á á á á á áIf you are, it will be interesting to see what happens (with and without your
á á á á á ámodification) in the association table through the web interface. You can start it by
á á á á á ágoing to rfweb, running "python rfweb_server.py" and then access
á á á á á áhttp://localhost:8080/index.html
á á á á á áYou will need pymongo as instructed in the README file.

á á á á á áAnd thanks for the patch! We really appreciate your efforts :)

á á á á á áAllan

á á á á á áOn Wed, Jun 6, 2012 at 12:48 AM, Josh Bailey <jo...@google.com> wrote:

á á á á á áá á áOK. I am now able to swap out "switch1" with a hardware OpenFlow switch
á á á á á áá á áand have pings work. However I had to fix another problem along the way.

á á á á á áá á áThis problem is in RFServer.cc. My hardware switch has lots of ports, of
á á á á á áá á ácourse, so I want to add them all. However, RFServer.cc only handles
á á á á á áá á áVM_MAP messages where there are no existing entries with VS_ID set. So it
á á á á á áá á áhandles the first ports and then silently drops the rest because the first
á á á á á áá á áones to add, add entries with VS_ID...

á á á á á áá á áI just commented out query[VS_ID] = "" (see below) and now all VM_MAP
á á á á á áá á ámessages are processed.

á á á á á áá á áWould it be possible to commit a fix for this?

á á á á á áá á áThanks,

á á á á á áá á áá á á á á áelse if (type == VM_MAP) {
á á á á á áá á áá á á á á á á áVMMap *mapmsg = dynamic_cast<VMMap*>(&msg);
á á á á á áá á áá á á á á á á ásyslog(LOG_INFO, "Mapping message arrived from vm=0x%llx",
á á á á á áá á ámapmsg->get_vm_id());

á á á á á áá á áá á á á á á á á// Search for VM's with no mapping
á á á á á áá á áá á á á á á á ámap<string, string> query;
á á á á á áá á áá á á á á á á ávector<RFEntry> results;
á á á á á áá á áá á á á á á á áquery[VM_ID] = to_string<uint64_t>(mapmsg->get_vm_id());
á á á á á áá á áá á á á á á á á// query[VS_ID] = "";
á á á á á áá á áá á á á á á á á^^^^^^^^^^^^^^^^^^^^^
á á á á á áá á áá á á á á á á á// Querying for VS_ID is enough, but we could play it safe
á á á á á áá á áand query all mapping attributes
á á á á á áá á áá á á á á á á áresults = this->rftable->get_entries(query);

á á á á á áá á áOn Tue, 5 Jun 2012, Josh Bailey wrote:

á á á á á áá á á á á áHi Allan;

á á á á á áá á á á á áOK, I find the problem. Firstly there's a lot of startup races
á á á á á áá á á á á áin rftest1. For example, if MongoDB fails in time to start
á á á á á áá á á á á ánothing else works and just crashes. I added some checks to
á á á á á áá á á á á ámake sure MongoDB starts before proceeding. I'll send a patch.

á á á á á áá á á á á áBut the actual problem is, that RFServer gets a datapath join
á á á á á áá á á á á áevent for "0x60eb69215b92", which happens to be br0. The
á á á á á áá á á á á ácontrol plane datapath joins no problem, but then switch1
á á á á á áá á á á á átries to join. br0 has already claimed the control plane VM so
á á á á á áá á á á á ánothing works.

á á á á á áá á á á á áI just hacked rfserver.cc to never associate 0x60eb69215b92
á á á á á áá á á á á áwith a VM. Then when switch1 comes up the VM is free and
á á á á á áá á á á á áeverything works.

á á á á á áá á á á á áI'm not sure how the code as is currently checked in can work
á á á á á áá á á á á áat all, unless I am missing something - Eg, br0 just happens
á á á á á áá á á á á áto very slow to come up so it comes up last. Probably the
á á á á á áá á á á á áright solution is to add a more robust check for br0 to ignore
á á á á á áá á á á á áit no matter when it comes up.

á á á á á áá á á á á áThanks,

á á á á á áá á á á á áOn Mon, 4 Jun 2012, Josh Bailey wrote:

á á á á á áá á á á á á á á áHi Allan;

á á á á á áá á á á á á á á áThanks, things are a bit closer now but still not
á á á á á áá á á á á á á á áworking. The rfvm1 VM now receives packets but
á á á á á áá á á á á á á á áeth1 (for example) drops them all:

á á á á á áá á á á á á á á áeth1 á á áLink encap:Ethernet áHWaddr
á á á á á áá á á á á á á á á12:b1:b1:b1:b1:b1
á á á á á áá á á á á á á á áá á á á inet addr:172.31.1.1 áBcast:172.31.1.255
á á á á á áá á á á á á á á ááMask:255.255.255.0
á á á á á áá á á á á á á á áá á á á UP BROADCAST RUNNING MULTICAST áMTU:1500
á á á á á áá á á á á á á á ááMetric:1
á á á á á áá á á á á á á á áá á á á RX packets:43 errors:0 dropped:43
á á á á á áá á á á á á á á áoverruns:0 frame:0
á á á á á áá á á á á á á á áá á á á TX packets:0 errors:0 dropped:0 overruns:0
á á á á á áá á á á á á á á ácarrier:0
á á á á á áá á á á á á á á áá á á á collisions:0 txqueuelen:1000
á á á á á áá á á á á á á á áá á á á RX bytes:3655 (3.6 KB) áTX bytes:0 (0.0 B)

á á á á á áá á á á á á á á áI'll keep troubleshooting but any suggestions
á á á á á áá á á á á á á á áappreciated.

á á á á á áá á á á á á á á áOn Mon, 4 Jun 2012, Allan Vidal wrote:

á á á á á áá á á á á á á á á á á áHi Josh,
á á á á á áá á á á á á á á á á á áAbout Mongo in /usr: yep, that's not
á á á á á áá á á á á á á á á á á áthe ideal. We plan to support Ubuntu
á á á á á áá á á á á á á á á á á á12.04 soon, and then it will be a
á á á á á áá á á á á á á á á á á ámatter of apt-getting mongo :)

á á á á á áá á á á á á á á á á á áAs for the testing, the default
á á á á á áá á á á á á á á á á á áuser/password for the prebuilt VM is
á á á á á áá á á á á á á á á á á árouteflow/routeflow. The LXC
á á á á á áá á á á á á á á á á á ácontainers are root/root.

á á á á á áá á á á á á á á á á á áAnyhow, I changed the scripts a lot in
á á á á á áá á á á á á á á á á á áthe last commits a few days ago. Try
á á á á á áá á á á á á á á á á á ápulling from the repository. I believe
á á á á á áá á á á á á á á á á á áthey're much better, though not quite
á á á á á áá á á á á á á á á á á áflawless :) You might have run into
á á á á á áá á á á á á á á á á á ásome troublesome commit.

á á á á á áá á á á á á á á á á á áThere's a small glitch: in the first
á á á á á áá á á á á á á á á á á árun of the tests after booting, OVS
á á á á á áá á á á á á á á á á á ábehaves badly sometimes. You have to
á á á á á áá á á á á á á á á á á áclose the script and try again, then
á á á á á áá á á á á á á á á á á áit
á á á á á áá á á á á á á á á á á áshould work.

á á á á á áá á á á á á á á á á á áPlease, let me know if you run into
á á á á á áá á á á á á á á á á á áany problems :)

á á á á á áá á á á á á á á á á á áAllan

á á á á á áá á á á á á á á á á á áOn Mon, Jun 4, 2012 at 6:14 AM, joshb
á á á á á áá á á á á á á á á á á á<jo...@google.com> wrote:

á á á á á áá á á á á á á á á á á áá á áHi Christian;

á á á á á áá á á á á á á á á á á áá á áNice to see! Definitely fewer
á á á á á áá á á á á á á á á á á ámoving pieces in the new design
á á á á á áá á á á á á á á á á á áá á áwhich is
á á á á á áá á á á á á á á á á á áá á ágreat! Also being able to use pox
á á á á á áá á á á á á á á á á á áas well will be helpful.

á á á á á áá á á á á á á á á á á áá á áUnfortunately the new setup
á á á á á áá á á á á á á á á á á ádoesn't appear to work for me with
á á á á á áá á á á á á á á á á á áá á áneither
á á á á á áá á á á á á á á á á á áá á ánox nor pox - no packets are
á á á á á áá á á á á á á á á á á áreceived by the control VM rfvm1. I
á á á á á áá á á á á á á á á á á áá á áused
á á á á á áá á á á á á á á á á á áá á áUbuntu 11.0.4 (x64).

á á á á á áá á á á á á á á á á á áá á áI can build fine (though I had to
á á á á á áá á á á á á á á á á á áadd CPPFLAGS=-fPIC,
á á á á á áá á á á á á á á á á á áá á áLDFLAGS=-fPIC).
á á á á á áá á á á á á á á á á á áá á áIt's also a bit scary that
á á á á á áá á á á á á á á á á á ámongodb is built with prefix /usr
á á á á á áá á á á á á á á á á á áá á áwhich
á á á á á áá á á á á á á á á á á áá á áwould overwrite any packaged
á á á á á áá á á á á á á á á á á ádistribution - but no big deal.

á á á á á áá á á á á á á á á á á áá á áAlso the README says to use --nox
á á á á á áá á á á á á á á á á á ávs --pox for testing. The
á á á á á áá á á á á á á á á á á áá á áscripts
á á á á á áá á á á á á á á á á á áá á áthough are actually rftest1 and
á á á á á áá á á á á á á á á á á árftest1_pox and they don't take
á á á á á áá á á á á á á á á á á áá á ácommand line arguments - and the
á á á á á áá á á á á á á á á á á ádefault user password is
á á á á á áá á á á á á á á á á á áá á ároot/root
á á á á á áá á á á á á á á á á á áá á ánot routeflow.

á á á á á áá á á á á á á á á á á áá á áAnyway - on to the actual
á á á á á áá á á á á á á á á á á áproblem. :-) switch1 is correctly set
á á á á á áá á á á á á á á á á á áá á áup and
á á á á á áá á á á á á á á á á á áá á áwhen I ping from b1 or b2, ARP
á á á á á áá á á á á á á á á á á ápackets are tunnelled to the
á á á á á áá á á á á á á á á á á áá á ácontroller. However rfvm1 never
á á á á á áá á á á á á á á á á á ásees them. I uncommented the
á á á á á áá á á á á á á á á á á áá á álogging
á á á á á áá á á á á á á á á á á áá á áline in
á á á á á áá á á á á á á á á á á áRouteFlow/pox/ext/rfproxy.py:

á á á á á áá á á á á á á á á á á áá á áá á á áresults =
á á á á á áá á á á á á á á á á á árftable.find({VS_ID: str(event.dpid)})
á á á á á áá á á á á á á á á á á áá á áá á á áif results.count() == 0 or
á á á á á áá á á á á á á á á á á áresults[0][VM_ID] == "":
á á á á á áá á á á á á á á á á á áá á áá á á á á áresults =
á á á á á áá á á á á á á á á á á árftable.find({VS_ID: {"$ne": ""},
á á á á á áá á á á á á á á á á á áDP_ID:
á á á á á áá á á á á á á á á á á áá á ástr(event.dpid), DP_PORT:
á á á á á áá á á á á á á á á á á ástr(event.port)})
á á á á á áá á á á á á á á á á á áá á áá á á á á áif results.count() ==
á á á á á áá á á á á á á á á á á á0:
á á á á á áá á á á á á á á á á á áá á áá á á á á á á álog.info("Datapath
á á á á á áá á á á á á á á á á á ánot associated with a VM")
á á á á á áá á á á á á á á á á á áá á áá á á á á á á áreturn

á á á á á áá á á á á á á á á á á áá á áAnd I see now "Datapath not
á á á á á áá á á á á á á á á á á áassociated with a VM" on each ping
á á á á á áá á á á á á á á á á á áá á áattempt.

á á á á á áá á á á á á á á á á á áá á áPlease let me know if you have
á á á á á áá á á á á á á á á á á áany suggestions? Otherwise I will
á á á á á áá á á á á á á á á á á áá á ácontinue to troubleshoot.

á á á á á áá á á á á á á á á á á áá á áThanks.

á á á á á áá á á á á á á á á á á áá á á# ./rftest1_pox
á á á á á áá á á á á á á á á á á áá á áResetting and stopping LXC VMs...
á á á á á áá á á á á á á á á á á áá á áStopping any running instances
á á á á á áá á á á á á á á á á á áand data of rfserver, POX, OVS
á á á á á áá á á á á á á á á á á áá á áand
á á á á á áá á á á á á á á á á á áá á áMongoDB...
á á á á á áá á á á á á á á á á á áá á áStarting MongoDB...
á á á á á áá á á á á á á á á á á áá á áall output going to: /dev/null
á á á á á áá á á á á á á á á á á áá á áStarting the rfvm1 virtual
á á á á á áá á á á á á á á á á á ámachine...
á á á á á áá á á á á á á á á á á áá á áStarting the management network
á á á á á áá á á á á á á á á á á á(br0)...
á á á á á áá á á á á á á á á á á áá á áStarting POX and the RouteFlow
á á á á á áá á á á á á á á á á á ánetwork controller...
á á á á á áá á á á á á á á á á á áá á áPOX 0.0.0 / Copyright 2011 James
á á á á á áá á á á á á á á á á á áMcCauley
á á á á á áá á á á á á á á á á á áá á á2012-06-04 01:57:41,092 -
á á á á á áá á á á á á á á á á á áext.rfproxy - INFO - RFProxy running.
á á á á á áá á á á á á á á á á á áá á á2012-06-04 01:57:42,538 -
á á á á á áá á á á á á á á á á á áopenflow.topology - INFO - Switch 60-
á á á á á áá á á á á á á á á á á áá á áeb-69-21-5b-92 connected
á á á á á áá á á á á á á á á á á áá á áDP is up, installing config
á á á á á áá á á á á á á á á á á áflows... `?i![
á á á á á áá á á á á á á á á á á áá á áStarting the RouteFlow server...
á á á á á áá á á á á á á á á á á áá á áStarting the control plane
á á á á á áá á á á á á á á á á á ánetwork (dp0 OVS)...
á á á á á áá á á á á á á á á á á áá á á2012-06-04 01:57:46,241 -
á á á á á áá á á á á á á á á á á áopenflow.topology - INFO - Switch
á á á á á áá á á á á á á á á á á áá á á76-73-72-66-76-73|29286 connected
á á á á á áá á á á á á á á á á á áá á áDP is up, installing config
á á á á á áá á á á á á á á á á á áflows... rfvsrfv
á á á á á áá á á á á á á á á á á áá á áStarting the sample network...
á á á á á áá á á á á á á á á á á áá á á2012-06-04 01:57:49,744 -
á á á á á áá á á á á á á á á á á áopenflow.topology - INFO - Switch
á á á á á áá á á á á á á á á á á áá á áf6-39-
á á á á á áá á á á á á á á á á á áá á áee-55-73-49 connected
á á á á á áá á á á á á á á á á á áá á áDP is up, installing config
á á á á á áá á á á á á á á á á á áflows... ?9?Us
á á á á á áá á á á á á á á á á á áá á áNow we'll open this test's log.
á á á á á áá á á á á á á á á á á áá á áTry pinging b1 from b2:
á á á á á áá á á á á á á á á á á áá á áá$ sudo lxc-console -n b1
á á á á á áá á á á á á á á á á á áá á áLogin and run:
á á á á á áá á á á á á á á á á á áá á áá$ ping 172.31.2.2
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00042|bridge|WARN|bridge dp0:
á á á á á áá á á á á á á á á á á áusing default
á á á á á áá á á á á á á á á á á áá á ábridge
á á á á á áá á á á á á á á á á á áá á áEthernet address
á á á á á áá á á á á á á á á á á ác6:04:a7:73:d2:45
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00043|ofproto|INFO|datapath
á á á á á áá á á á á á á á á á á áID changed to
á á á á á áá á á á á á á á á á á áá á á7266767372667673
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00044|rconn|INFO|dp0<->tcp:127.0.0.1:6633:
á á á á á áá á á á á á á á á á á áá á áconnecting...
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00045|rconn|WARN|dp0<->tcp:127.0.0.1:6633:
á á á á á áá á á á á á á á á á á áá á áconnection
á á á á á áá á á á á á á á á á á áá á áfailed (Connection refused)
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00046|rconn|INFO|dp0<->tcp:127.0.0.1:6633:
á á á á á áá á á á á á á á á á á áá á áwaiting 1
á á á á á áá á á á á á á á á á á áá á áseconds before reconnect
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00047|bridge|WARN|bridge
á á á á á áá á á á á á á á á á á áswitch1: using default
á á á á á áá á á á á á á á á á á áá á ábridge
á á á á á áá á á á á á á á á á á áá á áEthernet address
á á á á á áá á á á á á á á á á á á9a:2c:80:a6:9b:47
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00048|ofproto|INFO|datapath
á á á á á áá á á á á á á á á á á áID changed to
á á á á á áá á á á á á á á á á á áá á á00009a2c80a69b47
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00049|rconn|INFO|switch1<->tcp:127.0.0.1:6633:
á á á á á áá á á á á á á á á á á áá á áconnecting...
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00050|rconn|WARN|switch1<->tcp:127.0.0.1:6633:
á á á á á áá á á á á á á á á á á áá á áconnection failed (Connection
á á á á á áá á á á á á á á á á á árefused)
á á á á á áá á á á á á á á á á á áá á áJun 04
á á á á á áá á á á á á á á á á á á01:57:22|00051|rconn|INFO|switch1<->tcp:127.0.0.1:6633:
á á á á á áá á á á á á á á á á á áá á áwaiting
á á á á á áá á á á á á á á á á á áá á á1 seconds before reconnect

á á á á á áá á á á á á á á á á á áá á á# ovs-ofctl dump-flows switch1
á á á á á áá á á á á á á á á á á áá á áNXST_FLOW reply (xid=0x4):
á á á á á áá á á á á á á á á á á áá á áácookie=0x0, duration=580.692s,
á á á á á áá á á á á á á á á á á átable=0, n_packets=0, n_bytes=0,
á á á á á áá á á á á á á á á á á áá á áudp,nw_dst=224.0.0.9
á á á á á áá á á á á á á á á á á áactions=CONTROLLER:65535
á á á á á áá á á á á á á á á á á áá á áácookie=0x0, duration=580.692s,
á á á á á áá á á á á á á á á á á átable=0, n_packets=6,
á á á á á áá á á á á á á á á á á áá á án_bytes=252, arp
á á á á á áá á á á á á á á á á á áá á áactions=CONTROLLER:65535
á á á á á áá á á á á á á á á á á áá á áácookie=0x0, duration=580.692s,
á á á á á áá á á á á á á á á á á átable=0, n_packets=0, n_bytes=0,
á á á á á áá á á á á á á á á á á áá á átcp,tp_dst=179
á á á á á áá á á á á á á á á á á áactions=CONTROLLER:65535
á á á á á áá á á á á á á á á á á áá á áácookie=0x0, duration=580.692s,
á á á á á áá á á á á á á á á á á átable=0, n_packets=0, n_bytes=0,
á á á á á áá á á á á á á á á á á áá á áip,nw_proto=89
á á á á á áá á á á á á á á á á á áactions=CONTROLLER:65535
á á á á á áá á á á á á á á á á á áá á áácookie=0x0, duration=580.692s,
á á á á á áá á á á á á á á á á á átable=0, n_packets=0, n_bytes=0,
á á á á á áá á á á á á á á á á á áá á áicmp
á á á á á áá á á á á á á á á á á áá á áactions=CONTROLLER:65535
á á á á á áá á á á á á á á á á á áá á á# ovs-ofctl show switch1
á á á á á áá á á á á á á á á á á áá á áOFPT_FEATURES_REPLY (xid=0x1):
á á á á á áá á á á á á á á á á á áver:0x1, dpid:0000f639ee557349
á á á á á áá á á á á á á á á á á áá á án_tables:255, n_buffers:256
á á á á á áá á á á á á á á á á á áá á áfeatures: capabilities:0xc7,
á á á á á áá á á á á á á á á á á áactions:0xfff
á á á á á áá á á á á á á á á á á áá á áá1(b1.0): addr:1e:74:db:7a:d2:ce
á á á á á áá á á á á á á á á á á áá á áá á config: á á 0
á á á á á áá á á á á á á á á á á áá á áá á state: á á á0
á á á á á áá á á á á á á á á á á áá á áá á current: á á10GB-FD COPPER
á á á á á áá á á á á á á á á á á áá á áá2(b2.0): addr:ee:1c:48:59:6c:2e
á á á á á áá á á á á á á á á á á áá á áá á config: á á 0
á á á á á áá á á á á á á á á á á áá á áá á state: á á á0
á á á á á áá á á á á á á á á á á áá á áá á current: á á10GB-FD COPPER
á á á á á áá á á á á á á á á á á áá á ááLOCAL(switch1):
á á á á á áá á á á á á á á á á á áaddr:f6:39:ee:55:73:49
á á á á á áá á á á á á á á á á á áá á áá á config: á á 0
á á á á á áá á á á á á á á á á á áá á áá á state: á á á0
á á á á á áá á á á á á á á á á á áá á áOFPT_GET_CONFIG_REPLY (xid=0x3):
á á á á á áá á á á á á á á á á á áfrags=normal miss_send_len=0

á á á á á áá á á á á á á á á á á áá á áOn Jun 1, 5:08áam, Christian
á á á á á áá á á á á á á á á á á áEsteve Rothenberg
á á á á á áá á á á á á á á á á á áá á á<est...@cpqd.com.br>
á á á á á áá á á á á á á á á á á áá á áwrote:
á á á á á áá á á á á á á á á á á áá á á> *What's new*
á á á á á áá á á á á á á á á á á áá á á> We're glad to announce an
á á á á á áá á á á á á á á á á á áentirely new version of RouteFlow,
á á á á á áá á á á á á á á á á á áá á áwith many new
á á á á á áá á á á á á á á á á á áá á á> features in response to our
á á á á á áá á á á á á á á á á á áfirst year┤s experiences and the
á á á á á áá á á á á á á á á á á áá á árequests from
á á á á á áá á á á á á á á á á á áá á á> users and developers!
á á á á á áá á á á á á á á á á á áá á á> The version has been in an
á á á á á áá á á á á á á á á á á áexperimental branch for some time
á á á á á áá á á á á á á á á á á áá á ánow and is
á á á á á áá á á á á á á á á á á áá á á> stable enough to become
á á á á á áá á á á á á á á á á á ámainstream.
á á á á á áá á á á á á á á á á á áá á á>
á á á á á áá á á á á á á á á á á áá á á> áIn this new version, we have
á á á á á áá á á á á á á á á á á áintroduced:
á á á á á áá á á á á á á á á á á áá á á>
á á á á á áá á á á á á á á á á á á> á á- Centralized database and IPC
á á á á á áá á á á á á á á á á á á> á á á - We leverage MongoDB for
á á á á á áá á á á á á á á á á á ástoring the core system┤s state and
á á á á á áá á á á á á á á á á á áthe
á á á á á áá á á á á á á á á á á á> á á á OpenFlow network statistics. A
á á á á á áá á á á á á á á á á á áJSON-based IPC service (aka
á á á á á áá á á á á á á á á á á áRouteFlow
á á á á á áá á á á á á á á á á á á> á á á protocol) is also implemented
á á á á á áá á á á á á á á á á á áon top of it.
á á á á á áá á á á á á á á á á á á> á á- Cleaner code base
á á á á á áá á á á á á á á á á á á> á á á - Much of the code was
á á á á á áá á á á á á á á á á á árewritten and organized, making it
á á á á á áá á á á á á á á á á á áeasier for
á á á á á áá á á á á á á á á á á á> á á á developers to play with
á á á á á áá á á á á á á á á á á áRouteFlow.
á á á á á áá á á á á á á á á á á á> á á á This includes the renaming of
á á á á á áá á á á á á á á á á á ásome components: RF-Slave
á á á á á áá á á á á á á á á á á ábecomes
á á á á á áá á á á á á á á á á á á> á á á RFClient, RF-Controller
á á á á á áá á á á á á á á á á á ábecomes RFProxy.
á á á á á áá á á á á á á á á á á á> á á á á- POX support
á á á á á áá á á á á á á á á á á á> á á á - Support for using the new
á á á á á áá á á á á á á á á á á áPOX controller was added.
á á á á á áá á á á á á á á á á á á> á á- Web monitoring interface
á á á á á áá á á á á á á á á á á á(requires POX)
á á á á á áá á á á á á á á á á á á> á á á - Inspect network topology,
á á á á á áá á á á á á á á á á á áRouteFlow internal messages and
á á á á á áá á á á á á á á á á á ánetwork
á á á á á áá á á á á á á á á á á á> á á á state.
á á á á á áá á á á á á á á á á á á> á á- Open vSwich v1.4
á á á á á áá á á á á á á á á á á á> á á á - To attach the virtual
á á á á á áá á á á á á á á á á á áinterfaces (eth1 to ethX) of the VMs.
á á á á á áá á á á á á á á á á á á> á á á á- Used also in the control
á á á á á áá á á á á á á á á á á ánetwork that (attaching et0) and
á á á á á áá á á á á á á á á á á árunning
á á á á á áá á á á á á á á á á á á> á á á in bridge mode removes the
á á á á á áá á á á á á á á á á á árequirement of a second controller
á á á á á áá á á á á á á á á á á áinstance to
á á á á á áá á á á á á á á á á á á> á á á act as a simple L2 switch.
á á á á á áá á á á á á á á á á á á> á á á á- Tools for testing
á á á á á áá á á á á á á á á á á á> á á á - A new module (rftest)
á á á á á áá á á á á á á á á á á áintroduces several scripts to
á á á á á áá á á á á á á á á á á áfacilitate
á á á á á áá á á á á á á á á á á á> á á á testing and environment
á á á á á áá á á á á á á á á á á ácreation.
á á á á á áá á á á á á á á á á á á> á á- SNMP support
á á á á á áá á á á á á á á á á á á> á á á - Export OpenFlow stats via
á á á á á áá á á á á á á á á á á áSNMP. [Contribution by Joe
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á áStringer<https://github.com/joestringer>
á á á á á áá á á á á á á á á á á á> á á á ]
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á>á<https://sites.google.com/site/routeflow/updates/announcingthenewroute...>

á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> áThe detailed description of these
á á á á á áá á á á á á á á á á á ánew features is available in the
á á á á á áá á á á á á á á á á á áREADME
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á<https://github.com/CPqD/RouteFlow/blob/master/README>file.
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> You can download the new
á á á á á áá á á á á á á á á á á ápre-configured VM (3.7GB) from
á á á á á áá á á á á á á á á á á á>here<ftp://ftp.cpqd.com.br/pub/routeflow/RouteFlow.zip>:ftp://ftp.cpqd.<htt
á á á á á áá á á á á á á á á á á áps://sites.google.com/site/routeflow/updates/goog_66211347>
á á á á á áá á á á á á á á á á á á> com.br/pub/routeflow/RouteFlow.zip
á á á á á áá á á á á á á á á á á á> or get it via github
á á á á á áá á á á á á á á á á á á<https://github.com/CPqD/RouteFlow/>.
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> á*What's next*
á á á á á áá á á á á á á á á á á á> The list is long!
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> á á- Foremost we want to make
á á á á á áá á á á á á á á á á á áRouteFlow more and easier
á á á á á áá á á á á á á á á á á áconfigurable.
á á á á á áá á á á á á á á á á á á> á áCurrently, there's no trivial way
á á á á á áá á á á á á á á á á á áto associate VMs and datapaths
á á á á á áá á á á á á á á á á á á> á ástatically, but we want to solve
á á á á á áá á á á á á á á á á á áthis through a new configuration
á á á á á áá á á á á á á á á á á áapporach.
á á á á á áá á á á á á á á á á á á> á á- RouteFlow with NOX requires
á á á á á áá á á á á á á á á á á áUbuntu 11.04 (POX users should be
á á á á á áá á á á á á á á á á á áfine in
á á á á á áá á á á á á á á á á á á> á ánewer versions). We will be
á á á á á áá á á á á á á á á á á áadding support for Ubuntu 11.10 and
á á á á á áá á á á á á á á á á á á12.04.
á á á á á áá á á á á á á á á á á á> á á- Embrace OpenFlow v1.X. We have
á á á á á áá á á á á á á á á á á áworking prototypes of NOX and
á á á á á áá á á á á á á á á á á á> á ásoftware-based reference switch
á á á á á áá á á á á á á á á á á áusing OpenFlow 1.1 and 1.2.
á á á á á áá á á á á á á á á á á á> á á- Extensions to support LDP label
á á á á á áá á á á á á á á á á á áinformation.
á á á á á áá á á á á á á á á á á á> á á - Exploration of possibilities
á á á á á áá á á á á á á á á á á áopened by the use of a central
á á á á á áá á á á á á á á á á á ádatabase
á á á á á áá á á á á á á á á á á á> á á(e.g., keep state history and
á á á á á áá á á á á á á á á á á áallow queries like "show me flow
á á á á á áá á á á á á á á á á á átable at
á á á á á áá á á á á á á á á á á á> á átimestamp x").
á á á á á áá á á á á á á á á á á á> á á- Address High Availability.
á á á á á áá á á á á á á á á á á á> á á- New routing abstractions
á á á á á áá á á á á á á á á á á áimplemented as Services on top of the
á á á á á áá á á á á á á á á á á á> á áRF-Server.
á á á á á áá á á á á á á á á á á á> á á - ... a number of additions
á á á á á áá á á á á á á á á á á áunder investigation by students and
á á á á á áá á á á á á á á á á á áproject
á á á á á áá á á á á á á á á á á á> á ácollaborators.
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> áStay tuned for further news!
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> Thank you all!
á á á á á áá á á á á á á á á á á á>
á á á á á áá á á á á á á á á á á á> --
á á á á á áá á á á á á á á á á á á> Christian Esteve Rothenberg, Ph.D.
á á á á á áá á á á á á á á á á á á> Converged Networks Business Unit
á á á á á áá á á á á á á á á á á á> CPqD - Center for Research and
á á á á á áá á á á á á á á á á á áDevelopment in Telecommunications
á á á á á áá á á á á á á á á á á á> Tel. (+55 19) 3705 4479 / Cel. (+55
á á á á á áá á á á á á á á á á á á19) 8193-7087

á á á á á áá á á á á á á á á--
á á á á á áá á á á á á á á áJosh Bailey

á á á á á áá á á á á á--
á á á á á áá á á á á áJosh Bailey

á á á á á á--
á á á á á áJosh Bailey