[nox-dev] Updating NOX features for 1.0 testing
Hi all, KK has pushed a version of NOX 0.6 to yuba that has the 1.0 wire compatible openflow.h file. The new branch name is nox-for-1.0 Can everyone who is tasked with adding features to NOX please update the NOX ETA column given that there is now a version of NOX that you can use. Guido has asked that the ETA be updated by tomorrow -- please update this column by 12pm (midday). (KK has actually already updated some features which he will mark as complete in the feature table.) Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] send_switch_config -- resending patch
Hi all,
A while ago I sent a patch to add the ability to send switch config
messages to switches from within Python apps. This diff appears not to
have made it into the 0.50 release.
Here's my patch once again. This patch was made against an old version
of the 0.40 branch -- as a result the patch refers to the old apps
directory instead of the new coreapps directory.
Thanks,
Glen
diff --git a/src/nox/apps/pyrt/context.i b/src/nox/apps/pyrt/context.i
index 9b53c4a..8676b8e 100644
--- a/src/nox/apps/pyrt/context.i
+++ b/src/nox/apps/pyrt/context.i
@@ -111,6 +111,8 @@ public:
ethernetaddr addr, uint32_t mask, uint32_t config);
void send_aggregate_stats_request(uint64_t datapath_ids, const
struct ofp_match match, uint8_t table_id);
+int send_switch_config(uint64_t datapath_id, uint16_t flags);
+
private:
PyContext();
diff --git a/src/nox/apps/pyrt/pycontext.cc b/src/nox/apps/pyrt/pycontext.cc
index a525ae3..3acdcd9 100644
--- a/src/nox/apps/pyrt/pycontext.cc
+++ b/src/nox/apps/pyrt/pycontext.cc
@@ -411,6 +411,31 @@ PyContext::send_port_mod(uint64_t datapath_id, uint16_t port_no, ethernetaddr ad
return error;
}
+int
+PyContext::send_switch_config(uint64_t datapath_id, uint16_t flags)
+{
+ofp_switch_config* osc = NULL;
+size_t msize = sizeof(ofp_switch_config);
+boost::shared_arrayuint8_t raw_sr(new uint8_t[msize]);
+
+// Send OFPT_STATS_REQUEST
+osc = (ofp_switch_config*) raw_sr.get();
+osc-header.type= OFPT_SET_CONFIG;
+osc-header.version = OFP_VERSION;
+osc-header.length = htons(msize);
+osc-header.xid = 0;
+osc-flags = htons(flags);
+osc-miss_send_len = htons(OFP_DEFAULT_MISS_SEND_LEN);
+
+int error = c-send_openflow_command(datapathid::from_host(datapath_id),
+ osc-header, false);
+if (error == EAGAIN) {
+vlog().log(vlog().get_module_val(pyrt), Vlog::LEVEL_ERR,
+ unable to send switch_config);
+}
+
+return error;
+}
bool
PyContext::unregister_handler(uint32_t rule_id) {
diff --git a/src/nox/apps/pyrt/pycontext.hh b/src/nox/apps/pyrt/pycontext.hh
index 5cc8222..814da6b 100644
--- a/src/nox/apps/pyrt/pycontext.hh
+++ b/src/nox/apps/pyrt/pycontext.hh
@@ -143,6 +143,7 @@ public:
ethernetaddr addr, uint32_t mask, uint32_t config);
void send_aggregate_stats_request(uint64_t datapath_ids, const
struct ofp_match match, uint8_t table_id);
+int send_switch_config(uint64_t datapath_id, uint16_t flags);
/* C++ context */
const container::Context* ctxt;
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Discovery sends packets out the local OpenFlow port
Hi all, Discovery seems to be sending out LLDP packets on the local OpenFlow port. This seems a little odd to me as I would expect we're unlikely to encounter any other switches on the local port. I'm running the 0.40 pre/beta nox (I haven't yet merged in the latest changes with 0.40 release). I should also mention that the switch I've connected to has no physical ports in case that would make any difference. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Ability to send switch_config messages from NOX
Hi Nicira,
I need to send switch_config messages to each switch to enable flow
expiry messages (OpenFlow 0.8.9 / 0x97). Since this functionality
doesn't appear to be in Nox by default I added it myself. If you're
interested you can pull the change from our repo -- commit
1802ee173609d45abb7ae03d282e0570109ece17.
Let me know if you don't know the location of our Nox repo.
Glen
PS. Here's the patch in case you're curious:
diff --git a/src/nox/apps/pyrt/context.i b/src/nox/apps/pyrt/context.i
index 8676b8e..9b53c4a 100644
--- a/src/nox/apps/pyrt/context.i
+++ b/src/nox/apps/pyrt/context.i
@@ -111,8 +111,6 @@ public:
ethernetaddr addr, uint32_t mask, uint32_t config);
void send_aggregate_stats_request(uint64_t datapath_ids, const
struct ofp_match match, uint8_t table_id);
-int send_switch_config(uint64_t datapath_id, uint16_t flags);
-
private:
PyContext();
diff --git a/src/nox/apps/pyrt/pycontext.cc b/src/nox/apps/pyrt/pycontext.cc
index 3acdcd9..a525ae3 100644
--- a/src/nox/apps/pyrt/pycontext.cc
+++ b/src/nox/apps/pyrt/pycontext.cc
@@ -411,31 +411,6 @@ PyContext::send_port_mod(uint64_t datapath_id,
uint16_t port_no, ethernetaddr ad
return error;
}
-int
-PyContext::send_switch_config(uint64_t datapath_id, uint16_t flags)
-{
-ofp_switch_config* osc = NULL;
-size_t msize = sizeof(ofp_switch_config);
-boost::shared_arrayuint8_t raw_sr(new uint8_t[msize]);
-
-// Send OFPT_STATS_REQUEST
-osc = (ofp_switch_config*) raw_sr.get();
-osc-header.type= OFPT_SET_CONFIG;
-osc-header.version = OFP_VERSION;
-osc-header.length = htons(msize);
-osc-header.xid = 0;
-osc-flags = htons(flags);
-osc-miss_send_len = htons(OFP_DEFAULT_MISS_SEND_LEN);
-
-int error =
c-send_openflow_command(datapathid::from_host(datapath_id),
- osc-header, false);
-if (error == EAGAIN) {
-vlog().log(vlog().get_module_val(pyrt), Vlog::LEVEL_ERR,
- unable to send switch_config);
-}
-
-return error;
-}
bool
PyContext::unregister_handler(uint32_t rule_id) {
diff --git a/src/nox/apps/pyrt/pycontext.hh b/src/nox/apps/pyrt/pycontext.hh
index 814da6b..5cc8222 100644
--- a/src/nox/apps/pyrt/pycontext.hh
+++ b/src/nox/apps/pyrt/pycontext.hh
@@ -143,7 +143,6 @@ public:
ethernetaddr addr, uint32_t mask, uint32_t config);
void send_aggregate_stats_request(uint64_t datapath_ids, const
struct ofp_match match, uint8_t table_id);
-int send_switch_config(uint64_t datapath_id, uint16_t flags);
/* C++ context */
const container::Context* ctxt;
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] 0.4 tag in noxrepo/nicira internal repo
Just a quick heads-up that no one has tagged the 0.4 release in either tree (noxrepo/nicira internal). Not critical, but thought you might want to do it before it gets forgotten completely. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] hw_addr in datapath_join (stats) is ugly
datapath_join events in Python pass in a dpid and stats dictionary. The hardware address in stats['ports']['hw_addr'] are ugly -- the data type is a string. To use the hardware address in Python I have to do the following (assuming I want an int): hw_addr = \0\0 + port[core.HW_ADDR] hw_addr = struct.unpack(!q, hw_addr)[0] Two questions: 1. Is there a cleaner way to do the above? 2. Would it make sense to change nox to return either a Long or an ethernetaddr object instead of the string? Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] install_datapath_flow and ofp_flow_mod.out_port -- NOX with OpenFlow 0x97
Hi all, Just a quick heads-up that calling install_datapath_flow from python seems to result in a bogus value in out_port. Not critical since this is an ADD FLOW command but perhaps it should be cleaned up? Attached is a capture of a flow mod from pyswitch. Note that the OpenFlow control channel is 2525. Glen offlowmod.pcap Description: application/cap ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] install_datapath_flow and ofp_flow_mod.out_port -- NOX with OpenFlow 0x97
Just to follow up on my own message, I don't understand how it's getting
the wrong value in out_port. Here's the code in send_flow_command in
pycontext.cc:
ofm-out_port = htons(OFPP_NONE);
ofm-priority = htons(priority);
ofm-reserved = htonl(0);
if (actions.size() 0) {
::memcpy(ofm-actions, actions.data(), actions.size());
}
It's definitely setting the outport to OFPP_NONE.
Glen Gibb wrote:
Hi all,
Just a quick heads-up that calling install_datapath_flow from python
seems to result in a bogus value in out_port. Not critical since this
is an ADD FLOW command but perhaps it should be cleaned up?
Attached is a capture of a flow mod from pyswitch. Note that the
OpenFlow control channel is 2525.
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] install_datapath_flow and ofp_flow_mod.out_port -- NOX with OpenFlow 0x97
One more follow-up to my own e-mail.
The code below is in your internal version but not in the version I just
pulled from noxrepo. Nothing you guys need to do -- I'll just expect to
see that change in noxrepo when you next push.
Have a good weekend,
Glen
Glen Gibb wrote:
Just to follow up on my own message, I don't understand how it's
getting the wrong value in out_port. Here's the code in
send_flow_command in pycontext.cc:
ofm-out_port = htons(OFPP_NONE);
ofm-priority = htons(priority);
ofm-reserved = htonl(0);
if (actions.size() 0) {
::memcpy(ofm-actions, actions.data(), actions.size());
}
It's definitely setting the outport to OFPP_NONE.
Glen Gibb wrote:
Hi all,
Just a quick heads-up that calling install_datapath_flow from python
seems to result in a bogus value in out_port. Not critical since this
is an ADD FLOW command but perhaps it should be cleaned up?
Attached is a capture of a flow mod from pyswitch. Note that the
OpenFlow control channel is 2525.
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] 0x97 nox on noxrepo.org
Hi Nicira, When you get a chance can you push a version of NOX that is compatible with 0x97 to noxrepo.org please? In the mean time I'll pull from your internal repo. Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] 0x97 nox on noxrepo.org
Ben Pfaff wrote: Glen Gibb [EMAIL PROTECTED] writes: When you get a chance can you push a version of NOX that is compatible with 0x97 to noxrepo.org please? In the mean time I'll pull from your internal repo. I'm not sure that we've yet added support for 0x97 to NOX, but we will certainly push it to noxrepo when we do. Thanks Ben/Martin, At this stage I'm happy without support for some of the new OpenFlow features -- I'm just after a version that compiles against 0x97. The noxrepo version doesn't compile due to the location of the openflow.h file in OpenFlow v0.8.9 (moved from include - include/openflow). For people wanting a version that compiles against the current version of nox you can link the 3 header files in include/openflow into include in your openflow directory: cd path to openflow cd include ln -s openflow/openflow.h ln -s openflow/openflow-netlink.h ln -s openflow/nicira-ext.h (Or people can actually update config/ac_check_openflow.m4 ;-) ) Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Signals (SIGHUP) sent to applications?
Actually, this specific problem doesn't have a cure in our local
branch, but one can work around it using the reactor.callFromThread
call which executes a function within the reactor's thread. The
example below worked just fine on our local branch and it *should*
work with the noxrepo.org version too:
def sig_install():
def sig_handler(signal_num, handler):
lg.debug('HUP!')
import signal
signal.signal(signal.SIGHUP, sig_handler)
from twisted.internet import reactor
reactor.callFromThread(sig_install)
HTH,
Teemu
No luck I'm afraid Teemu. Here's the error the above code generates:
--- exception caught here ---
File ./nox/apps/pyrt/pyoxidereactor.py, line 166, in
callPendingThreadCalls
f(*a, **kw)
File ./nox/apps/mobile_firewall/mobile_firewall.py, line 33, in
sig_install
signal.signal(signal.SIGHUP, sig_handler)
exceptions.ValueError: signal only works in main thread
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Signals (SIGHUP) sent to applications?
I'm afraid that trying to use signal gives the following error: ValueError: signal only works in main thread Martin Casado wrote: I think import signal signal(signal.SIGHUP, foo) should work. Is there an easy way to get a Nox python application to respond to SIGHUP? Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] nox-box occasionally sends flow expiry with no flow information
Hi all,
Just wanted to alert you to the fact that occasionally I see flow expiry
messages from one of our wireless APs running nox-box in which there is
no flow information: Here a sample event object as seen by Python:
{'datapath_id': 58939760960L, 'this': Swig Object of type 'pyevent *'
at 0xb610e278, 'flow': {}, 'packet_count': 0L, 'byte_count': 0L,
'duration': 0L}
These expiries are pretty infrequent. Also, as far as I know they're not
preventing my application from functioning correctly so this doesn't
need to be addressed with any urgency.
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] More questions about the new routing infrastructure exposed to Python
Yeah, just picked that up myself. Thanks, Glen Natasha Gude wrote: That gets fixed in commit a64fdb162f43b1bcacdeacd61a4541a539cb163b. Should be datapath_id (missing an 'a') On Sep 5, 2008, at 4:17 PM, Glen Gibb wrote: Actually if I explicitly list pyrouting and pyauthenticator (in conjunction with sample_routing) on the command line it *mostly* works. Now I get this error instead: Traceback (most recent call last): File ./nox/apps/routing/samplerouting.py, line 65, in handle_flow_in if pyrouting.dp_on_route(event.datpath_id, route): File ./nox/apps/pyrt/pycomponent.py, line 192, in lambda __getattr__ = lambda self, name: _swig_getattr(self, pyevent, name) File ./nox/apps/pyrt/pycomponent.py, line 34, in _swig_getattr raise AttributeError,name AttributeError: datpath_id Glen Glen Gibb wrote: Hmm... now I'm getting lots of messages like this: 2|pyrt|ERR:Flow_in_event has no C++ to Python event converter. Glen Natasha Gude wrote: Hey Glen, There were actually some name changes that occurred in that commit. 'pyrouting' just exposes the routing infrastructure to Python, it doesn't actually listen for Flow_in_events and route them. The app you need to run on the command line to route from Python is sample_routing. This app depends on pyrouting and pyauthenticator, so you don't have to include either of them on the command line. Let me know if this doesn't fix things, Natasha On Sep 5, 2008, at 3:40 PM, Glen Gibb wrote: Hi Natasha, I've been trying to move our NOX as close to OpenFlow 0x86 as I can get without requiring 0x86. One of the changes I was hoping to pull in is your Python routing infrastructure changes. However if I take your NOX tree and rewind to to 0eee89d198cf12911e3f9318f9b3962b608280dd then pyrouting breaks. I'm trying to run with pyrouting/pyauthenticator -- using ping as a test. If I test with NOX from the checkin before the commit mentioned above then things work, but they break as soon as I include your check-in. A couple of questions: 1. Is this failure to be expected? 2. Is there an easy workaround? 3. Is there a series of commits I can cherry-pick to fix this? I should mention I watched communication between NOX and the switches and NOX gets a packet in from the switch for an ICMP packet but doesn't produce a corresponding packet out. Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Spanning tree implementation (not 802.1D STP)
I discovered a topology that broke my previous implementation. An updated implementation is attached. Glen Glen Gibb wrote: Hi all, I've implemented basic spanning tree support for NOX as a Python app. I've attached my implementation as a diff. This requires the send_port_mod patch that I sent to the list earlier to use. I suspect the patch to configure.ac may not apply cleanly as my patch has reference to two apps that we've added locally. A couple of notes about my implementation: * This is *not* an implementation of IEEE 802.1D Spanning Tree Protocol and is *not* compatible. * The app uses the information gathered by the discovery module to identify links and construct the spanning tree. * I have made no attempt to optimize the algorithm that builds the spanning tree. It works well for a small number of switches -- I haven't tested in large topologies. * When a switch connects the app disables flooding to all ports initially. * Ports are only eligible for flooding after a waiting period. This waiting period is currently a fixed period but should probably adjust dynamically depending upon the number of ports in the system. (Look at discovery to understand why it should adjust dynamically with the number of ports.) * The switch with the lowest DPID will always be the root in any tree. * This implementation doesn't properly handle the case where one port is connected to multiple switches. * The app listens for packet in events to enable it to drop packets received on non-flood ports. It must be the first app that receives packet ins to allow it to return STOP before any other event can process the packet. I should point out that so far it has received relatively little testing. I've only run it in a topology with 3 switches connected in a triangle. Again, let me know if you have comments/questions. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org diff --git a/configure.ac b/configure.ac index 4c6813b..825cc40 100644 --- a/configure.ac +++ b/configure.ac @@ -96,6 +96,8 @@ ACI_MODULE([examples],[Set of example apps], [],[],[yes]) ACI_MODULE([mobilevms],[MobileVMs app for VM mobility], [],[],[yes]) +ACI_MODULE([spanning_tree],[Basic spanning tree support], + [],[],[yes]) ACI_MODULE([throughput],[Monitor link throughputs], [],[],[yes]) ACI_MODULE([hub],[dumb hub], @@ -117,6 +119,7 @@ ACI_MODULE([apps],[main source libarary], sepl storage tests topology discovery coreui simple_c_app simple_c_py_app noop hub switch examples exit directory + spanning_tree bindings_storage switchstats mobilevms throughput], [yes]) ACI_MODULES_VERIFY @@ -226,6 +229,7 @@ src/nox/apps/hub/Makefile src/nox/apps/examples/Makefile src/nox/apps/exit/Makefile src/nox/apps/mobilevms/Makefile +src/nox/apps/spanning_tree/Makefile src/nox/apps/throughput/Makefile ]) AC_OUTPUT diff --git a/src/nox/apps/spanning_tree/Makefile.am b/src/nox/apps/spanning_tree/Makefile.am new file mode 100644 index 000..d2271c6 --- /dev/null +++ b/src/nox/apps/spanning_tree/Makefile.am @@ -0,0 +1,17 @@ +include ../../../Make.vars + +EXTRA_DIST =\ + meta.xml\ +__init__.py \ + spanning_tree.py + +NOX_RUNTIMEFILES = meta.xml \ +__init__.py \ + spanning_tree.py + +all-local: + @dlist=$(NOX_RUNTIMEFILES);for f in $$dlist; do \ + if test -f $(srcdir)/$$f test ! -f $$f; then \ + ln -sf $(srcdir)/$$f $(builddir)/$$f;\ + fi;\ + done; diff --git a/src/nox/apps/spanning_tree/__init__.py b/src/nox/apps/spanning_tree/__init__.py new file mode 100644 index 000..e69de29 diff --git a/src/nox/apps/spanning_tree/meta.xml b/src/nox/apps/spanning_tree/meta.xml new file mode 100644 index 000..2c6fd15 --- /dev/null +++ b/src/nox/apps/spanning_tree/meta.xml @@ -0,0 +1,13 @@ +?xml version=1.0 encoding=UTF-8? +components:components xmlns:components=http://www.noxrepo.org/components.xsd; + component +namespanning_tree/name +dependency + namepython/name +/dependency +dependency + namediscovery/name +/dependency +pythonnox.apps.spanning_tree.spanning_tree/python + /component +/components:components diff --git a/src/nox/apps/spanning_tree/spanning_tree.py b/src/nox/apps/spanning_tree/spanning_tree.py new file mode 100644 index 000..4cdf03b --- /dev/null +++ b/src/nox/apps/spanning_tree/spanning_tree.py @@ -0,0 +1,307 @@ +# -- +# Spanning tree -- software based +# Authors: Glen Gibb [EMAIL PROTECTED] +# Date: 08/08/08 +# +# Changes: +# +# Notes: This won't work correctly if there are more than 2 switches
Re: [nox-dev] buffer_id in flow_mod messages
My mistake here. UINT32_MAX is the same as -1 for signed numbers. :-) Thanks for pointing that out Brandon. Glen Gibb wrote: Hi all, In install_datapath_flow in core.py we have: def install_datapath_flow(self, dp_id, attrs, max_idle, actions, buffer_id=None, priority=openflow.OFP_DEFAULT_PRIORITY, inport=None, packet=None): if buffer_id == None: buffer_id = UINT32_MAX Here the buffer_id is set to UINT32_MAX if there is no buffer to apply the flow to. This disagrees with the 0.8.1 spec where it states that the buffer_id should be -1 if the flow isn't to be applied to a buffer. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Port mod python example?
I'm looking to set the flood flag so that when I have loops in my
topology I don't end up looping packets forever.
I've actually written most of the code -- I'm just having trouble right
now copying the name into the name field from Python. Actually, do I
need to send the name back to the OF switch or will it work without
setting a name?
Here's the one snippet of code I haven't yet gotten working. In
openflow.i I have:
%extend ofp_phy_port {
void set_hw_addr(uint8_t *addr) {
memcpy($self-hw_addr, addr, ethernetaddr::LEN);
}
void set_name(uint8_t *name) {
memcpy($self-name, name, OFP_MAX_PORT_NAME_LEN);
}
};
(I'm basically trying to copy what you had in that file for ofp_match.)
The set_hw_addr works perfectly, the set_name fails because I haven't
yet managed to convert my string to a uint8_t array. Is there an easy
way to pass in a python string to set_name and copy from the Python
string to the name field?
Glen
Justin Pettit wrote:
Glen, what are you looking to modify? Currently, you are only able to
set the port flags over OpenFlow and the only flag is one to indicate
whether the port should be included in flood actions. We're looking
to include actions such as disabling ports, but that's not in there yet.
--Justin
On Aug 9, 2008, at 12:36 PM, Martin Casado wrote:
I'm not sure port mod is supported in the OF reference
implementation. Justin/Ben?
On Aug 8, 2008, at 4:42 PM, Glen Gibb wrote:
Hi all,
Is there an example available that sends port mod messages to a
switch?
I'm currently looking for examples but can't find one.
Thanks,
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Port mod from python -- patch
I just realized that I was doing a double htonl on attrs['speed'] in my
set_port method in utils.py. There's some funning looking logic there as
my htonl was generating a -ve value when the speed was 1000 and SWIG was
generating an error as it wasn't of type unit32 :-(
Corrected patch attached.
Glen
Glen Gibb wrote:
Hi all,
Attached are the diffs to enable me to send port mods from python.
Feel free to integrate the diff and let me know if you have any
comments/questions.
Oh, and to actually send a port mod I just do this from my app:
self.ctxt.send_port_mod(dp, set_port(port))
where port is a dictionary identical to that returned in the stats in
a dp_join event.
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
diff --git a/src/nox/apps/pyrt/context.i b/src/nox/apps/pyrt/context.i
index b02a3b8..54d0f4e 100644
--- a/src/nox/apps/pyrt/context.i
+++ b/src/nox/apps/pyrt/context.i
@@ -80,6 +80,9 @@ public:
void send_port_stats_request(uint64_t datapath_id);
void send_aggregate_stats_request(uint64_t datapath_ids, const
struct ofp_match match, uint8_t table_id);
+
+void send_port_mod(uint64_t datapath_id,
+ const ofp_phy_port port);
private:
PyContext();
diff --git a/src/nox/apps/pyrt/pycontext.cc b/src/nox/apps/pyrt/pycontext.cc
index 87d8111..7c5dc2f 100644
--- a/src/nox/apps/pyrt/pycontext.cc
+++ b/src/nox/apps/pyrt/pycontext.cc
@@ -234,6 +234,30 @@ PyContext::send_stats_request(uint64_t datapath_id, ofp_stats_types type, const
}
}
+void
+PyContext::send_port_mod(uint64_t datapath_id,
+ const ofp_phy_port port) {
+ofp_port_mod* opm = NULL;
+size_t size = sizeof *opm;
+boost::shared_arrayuint8_t raw_of(new uint8_t[size]);
+opm = (ofp_port_mod*) raw_of.get();
+
+opm-header.version = OFP_VERSION;
+opm-header.type = OFPT_PORT_MOD;
+opm-header.length = htons(size);
+opm-header.xid = htonl(0);
+
+::memcpy(opm-desc, port, sizeof port);
+
+int error = c-send_openflow_command(datapathid::from_host(datapath_id),
+ opm-header, false);
+if (error == EAGAIN) {
+vlog().log(vlog().get_module_val(pyrt), Vlog::LEVEL_ERR,
+ should queue port_mod);
+}
+}
+
+
bool
PyContext::unregister_handler(uint32_t rule_id) {
return c-unregister_handler(rule_id);
diff --git a/src/nox/apps/pyrt/pycontext.hh b/src/nox/apps/pyrt/pycontext.hh
index a18158d..186b16e 100644
--- a/src/nox/apps/pyrt/pycontext.hh
+++ b/src/nox/apps/pyrt/pycontext.hh
@@ -113,6 +113,9 @@ public:
void send_aggregate_stats_request(uint64_t datapath_ids, const
struct ofp_match match, uint8_t table_id);
+void send_port_mod(uint64_t datapath_id,
+ const ofp_phy_port port);
+
/* C++ context */
const container::Context* ctxt;
diff --git a/src/nox/lib/openflow.i b/src/nox/lib/openflow.i
index 3dd2286..3b47d82 100644
--- a/src/nox/lib/openflow.i
+++ b/src/nox/lib/openflow.i
@@ -24,9 +24,19 @@
using namespace vigil;
%}
+%include cstring.i
%include common-defs.i
%include openflow.h
+%extend ofp_phy_port {
+void set_hw_addr(uint8_t *addr) {
+memcpy($self-hw_addr, addr, ethernetaddr::LEN);
+}
+void set_name(const char *name) {
+memcpy($self-name, name, OFP_MAX_PORT_NAME_LEN);
+}
+};
+
%extend ofp_match {
void set_dl_src(uint8_t *addr) {
memcpy($self-dl_src, addr, ethernetaddr::LEN);
diff --git a/src/nox/lib/util.py b/src/nox/lib/util.py
index 25f49c5..ed42960 100644
--- a/src/nox/lib/util.py
+++ b/src/nox/lib/util.py
@@ -17,7 +17,7 @@
import core
import array
-from socket import htons
+from socket import htons, htonl
import nox.lib.openflow as openflow
@@ -285,6 +285,53 @@ def set_match(attrs):
m.wildcards = htons(wildcards)
return m
+def set_port(attrs):
+p = openflow.ofp_phy_port()
+
+print attrs
+if attrs.has_key('port_no'):
+p.port_no = htons(attrs['port_no'])
+else:
+print 'undefined port_no attribute type in attrs', attrs
+return None
+
+if attrs.has_key('hw_addr'):
+v = convert_to_eaddr(attrs['hw_addr'])
+if v == None:
+print 'invalid ethernet addr'
+return None
+p.set_hw_addr(v.octet)
+else:
+print 'undefined hw_addr attribute type in attrs', attrs
+return None
+
+if attrs.has_key('name'):
+p.set_name(attrs['name'])
+else:
+print 'undefined name attribute type in attrs', attrs
+return None
+
+if attrs.has_key('flags'):
+p.flags = htonl(attrs['flags'])
+else:
+p.flags = 0
+
+if attrs.has_key('speed'):
+speed = htonl(attrs['speed'])
+if speed 0
Re: [nox-dev] LLDP packet generated by HP ProCurve crashes discovery
Sure, I'll grab one and send it across later this afternoon. Also, this isn't high priority -- I'm just going to disable LLDP on the ProCurve. Glen Martin Casado wrote: Looks like there is a bug in the LLDP protocol handling. I can take a look at this. Glen, would it be possible for you to send a pcap file of the offending packet? thanks! .martin Hi Glen, On the HP switches, I usually run the following commands: lldp admin-status [dataports] disable no spanning-tree [dataports] refers to a1-a24 on the current HP setup. These ensure that the switch send no traffic out the OF interfaces; maybe this will help in the meantime. -Brandon On Wed, Jul 30, 2008 at 11:42 AM, Glen Gibb [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all, We plugged an HP ProCurve switch into an OpenFlow switch today and it caused crashes in discovery: 2|pyrt|ERR:unable to invoke a Python event handler: Traceback (most recent call last): File ./nox/lib/util.py, line 115, in f event.total_len, buffer_id, packet) File ./nox/apps/discovery/discovery.py, line 148, in lambda discovery.lldp_input_handler(self,dp,inport,reason,len,bid,packet), File ./nox/apps/discovery/discovery.py, line 235, in lldp_input_handler (portid,) = struct.unpack(!H, lldph.tlvs[1].id) File /usr/lib/python2.5/struct.py, line 87, in unpack return o.unpack(s) error: unpack requires a string argument of length 2 Attached is the Packet In message containing the LLDP packet. Let me know if there's any other info you need, Glen ___ nox-dev mailing list nox-dev@noxrepo.org mailto:nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] LLDP packet generated by HP ProCurve crashes discovery
Here's the full LLDP packet. Glen Martin Casado wrote: That would be very helpful. Thanks. On Jul 30, 2008, at 3:32 PM, Glen Gibb wrote: I think the LLDP inside the Packet In is truncated. Let me know if you need the whole packet. Glen Martin Casado wrote: Thats what I get for reading e-mail backwards. Thanks Glen, I'll take a look at this right away. Should be an easy fix. Hi all, We plugged an HP ProCurve switch into an OpenFlow switch today and it caused crashes in discovery: 2|pyrt|ERR:unable to invoke a Python event handler: Traceback (most recent call last): File ./nox/lib/util.py, line 115, in f event.total_len, buffer_id, packet) File ./nox/apps/discovery/discovery.py, line 148, in lambda discovery.lldp_input_handler(self,dp,inport,reason,len,bid,packet), File ./nox/apps/discovery/discovery.py, line 235, in lldp_input_handler (portid,) = struct.unpack(!H, lldph.tlvs[1].id) File /usr/lib/python2.5/struct.py, line 87, in unpack return o.unpack(s) error: unpack requires a string argument of length 2 Attached is the Packet In message containing the LLDP packet. Let me know if there's any other info you need, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org procurve_lldp_full.pcap Description: application/cap ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Different format for flows in events in Flow_in and Flow_expiry
Hi all,
I notice that the format of fields in the flow dictionary/object appears
different in Flow_in versus Flow_expiry in Python.
In Flow_in, if I do a print event.flow I get:
{'dl_type': 2054, 'nw_dst': 2873313822L, 'dl_src': 345045179815L,
'nw_proto': 0, 'tp_dst': 0, 'tp_src': 0, 'dl_dst': 219902323L,
'dl_vlan': 65535, 'nw_src': 2873313811L, 'in_port': 1}
In this case, fields such as nw_dst are longs.
Whereas, if I do the print event.flow in Flow_expiry I get:
{'dl_type': 2048, 'nw_dst': '\xabCJ\x1c', 'dl_src':
'\x00\xd0\x05\x8e\xa4\x00', 'nw_proto': 1, 'tp_dst': 0, 'tp_src': 0,
'dl_dst': '\x00\xca\xfe\x00\x00\x01', 'dl_vlan': 65535, 'nw_src':
'\xabCJ\x11', 'in_port': 0}
In this case, fields such as nw_dst are strings.
Glen
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Documentation request -- events and ordering
Hi Nicira, I've got a documentation feature request for you. Can you add a section to the manual outlining events and event ordering. As an application it would be useful to have a list the order of events that NOX generates if a new host is connected to the network and sends in a packet. Feel free to make this a low priority -- writing test code and seeing what happens has worked well so far ;-) Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Flow establishment problem? NOX and/or OpenFlow
Ben Pfaff wrote: Glen Gibb [EMAIL PROTECTED] writes: Ben Pfaff wrote: Glen Gibb [EMAIL PROTECTED] writes: I've got another issue here, this time to do with flow establishment. I'm trying to ping from one host to another through a bunch of OF switches -- this succeeds if the OF switches are brought up before NOX but fails if the OF switches are brought up after NOX. Are the switches using in-band or out-of-band control? I am aware of a bug in the in-band control code that might cause these symptoms. I now have a fix that is under review. I've pushed it to the arp branch on nicira.dyndns.org and on yuba.stanford.edu:/usr/local/git/openflow. The commit messages should make it clear what it fixes. Let me know if it makes a different for you. Nope, this is out-of-band control. Is the fix likely to do anything in this scenario? That particular fix will not have any effect with out-of-band control. However, the following commit could have fixed the problem. Please make sure that it is included in the copy of NOX that you are running. commit d8226dd2e8305cd59417fa004c70ac20e2169720 Author: Ben Pfaff [EMAIL PROTECTED] Date: Tue Jul 15 15:48:31 2008 -0700 Keep time from standing still. do_gettimeofday(true) needs to be called on a reasonably frequent basis, or the time as returned by do_gettimeofday(false) will never be updated. In this case, the symptoms were that if NOX was running for over 5 seconds without anything to do, then switches that attempted to connect would instantly be timed out, because Handshake_fsm has a 5-second timeout and time wasn't getting updated. Hi Ben, I'm afraid the above commit didn't fix the problem. We still need to kill and restart NOX if a switch comes up after NOX. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] get_route event in PyRouting
Hi Natasha, After some more debugging I discovered the error message was caused by a minor typo in our code. Instead of assigning to the attribute outport of a FullRoute instance, we were inadvertently assigning to output (this is in Python code). Could you add generating an error message when users do this as a low-priority feature request please :-) Also, while I understand the logic of wanting to prevent the inport and outport from being the same at either end of the link, what happens when someone uses NOX on a wireless AP in which case it may be the case that the input and output should be the same? Thanks again, Glen Natasha Gude wrote: The message means that if the found route were to be installed, the flow would be sent out the same port that it came in on at either the source or destination access point switch. NOX state-wise, it means we have a link connected to the same port as a switch, which is incorrect. In the test code, the inport/outport fields of the FullRoute object describe where the endhosts are connected, not where the links are connected (which is on port 0). Natasha On Jul 18, 2008, at 8:16 PM, Glen Gibb wrote: Hi all, Perhaps I'm misunderstanding the get_route event but I'm getting error messages like the following at times: 8|routing|ERR:Invalid route between aps 1731efa639:3 and 1731ed8d28:0 (inport == outport) Can someone clarify what this error means? As far as I can tell this error doesn't make sense for the scenario in which I'm trying to use it. I have three OF switches connected effectively in a line -- the two aps listed above are on opposite ends of this line. Also, looking through the examples for sample code I saw the following in pyunittests/routing_test.py: def post_events(self): e = Link_event(netinet.datapathid.from_host(2), netinet.datapathid.from_host(3), 0, 0, Link_event.ADD) self.post(e) e = Link_event(netinet.datapathid.from_host(1), netinet.datapathid.from_host(2), 0, 1, Link_event.ADD) self.post(e) self.d = defer.Deferred() return self.d def handle_link_event(self, event): if self.n_received == 0: self.n_received = 1 return CONTINUE route = pyrouting.PyFullRoute() route.id.src = src = netinet.datapathid.from_host(1) route.id.dst = dst = netinet.datapathid.from_host(3) route.inport = route.outport = 1 if not self.routing.get_route(route): Reading the above I would have thought that 1 and 3 would have been connected on port 0, but in the get_route it looks like you're querying from port 1? Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] get_route event in PyRouting
Hi all, Perhaps I'm misunderstanding the get_route event but I'm getting error messages like the following at times: 8|routing|ERR:Invalid route between aps 1731efa639:3 and 1731ed8d28:0 (inport == outport) Can someone clarify what this error means? As far as I can tell this error doesn't make sense for the scenario in which I'm trying to use it. I have three OF switches connected effectively in a line -- the two aps listed above are on opposite ends of this line. Also, looking through the examples for sample code I saw the following in pyunittests/routing_test.py: def post_events(self): e = Link_event(netinet.datapathid.from_host(2), netinet.datapathid.from_host(3), 0, 0, Link_event.ADD) self.post(e) e = Link_event(netinet.datapathid.from_host(1), netinet.datapathid.from_host(2), 0, 1, Link_event.ADD) self.post(e) self.d = defer.Deferred() return self.d def handle_link_event(self, event): if self.n_received == 0: self.n_received = 1 return CONTINUE route = pyrouting.PyFullRoute() route.id.src = src = netinet.datapathid.from_host(1) route.id.dst = dst = netinet.datapathid.from_host(3) route.inport = route.outport = 1 if not self.routing.get_route(route): Reading the above I would have thought that 1 and 3 would have been connected on port 0, but in the get_route it looks like you're querying from port 1? Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Buffer_id xxx at internal ap
Hi all, What would trigger a Buffer_id xxx at internal ap message? Thanks, Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Flow establishment problem? NOX and/or OpenFlow
Hi all, I've got another issue here, this time to do with flow establishment. I'm trying to ping from one host to another through a bunch of OF switches -- this succeeds if the OF switches are brought up before NOX but fails if the OF switches are brought up after NOX. The details are as follows: Network setup: Three OF switches (mvm-ofroot, mvm-of1, mvm-of2), two hosts (mvm-17, mvm-18), connected linearly as follows: mvm-17 mvm-ofroot mvm-of1 mvm-ap1 mvm-18 Note: mvm-18 is actually the of0 interface on a noxbox install on mvm-ap1 I'm trying to ping from mvm-18 to mvm-17. If I start the NOX controller before bringing up the OF switches the ping fails. The ICMP echo requests fail to reach the destination (mvm-17) although ARP packets seem to get through. If I start the OF switches and then bring up the NOX controller the ping succeeds. To aid in debugging I turned on NOX logging, ran a packet capture on the NOX controller, and ran dpctl on each of the OF switches. The file http://yuba.stanford.edu/~grg/ping_issue.tgz contains the results of these processes. The ping_nox_first.* files are when running NOX before starting OF flow, the ping_nox_last.* files are the opposite. In ping_nox_first.dump, you can see the ARP requests/replies in packets 278 to 299 (including packet in/packet out messages). Packet 301 is the echo request from mvm-ap1, 302 is a flow mod, and 304 is the corresponding packet out. Then in 306 we have a echo request packet in from mvm-of1, followed by a flow mod to of1, but there is no corresponding packet out. Contrasting with ping_nox_last.dump, we see the ARP request/replies in packets 215 to 235. Packet 237 is the echo request packet in from ap1, 238, 240 and 242 are flow mods to the three OFs, and 244 is a packet out. We don't see a packet in from of1. We then see a packet in for the echo request from ofroot at 246, with flow mods at 247, 248 and 250, followed by the packet out at 253. Hopefully this has given you plenty of information to help track down the problem. Let me know if there's other things I can do to help. Glen ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Flow establishment problem? NOX and/or OpenFlow
Ben Pfaff wrote: Glen Gibb [EMAIL PROTECTED] writes: I've got another issue here, this time to do with flow establishment. I'm trying to ping from one host to another through a bunch of OF switches -- this succeeds if the OF switches are brought up before NOX but fails if the OF switches are brought up after NOX. Are the switches using in-band or out-of-band control? I am aware of a bug in the in-band control code that might cause these symptoms. I now have a fix that is under review. I've pushed it to the arp branch on nicira.dyndns.org and on yuba.stanford.edu:/usr/local/git/openflow. The commit messages should make it clear what it fixes. Let me know if it makes a different for you. Nope, this is out-of-band control. Is the fix likely to do anything in this scenario? ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
