Re: [nox-dev] monitoring usage error
Move the inst.Monitoring... line to the bottom under inst = self or use
self.Monitoring = ...
inst is still of type None when you try to assign inst.Monitoring. It
says inst is of type NoneType and does not have an attribute Monitoring.
So either you assign self to inst first or you assing your monitoring
component to self.Monitoring and then assign inst.
Best regards
Bernd
On 28.02.2012 15:51, Baraki Halefom wrote:
The following is what I did and is same as what is in pyswitch. but
still gives the same error
def __init__(self, ctxt):
global inst
Component.__init__(self, ctxt)
self.ctxt = ctxt
inst.Monitoring =
ctxt.resolve("nox.netapps.monitoring.monitoring.Monit$
self.st <http://self.st> = {}
inst = self
On Tue, Feb 28, 2012 at 9:25 AM, Bernd Wittefeld
mailto:s9bew...@stud.uni-saarland.de>>
wrote:
Hi,
it complains about "inst" not being declared (it is of type None).
You missed the
"inst = self"
in the __init__ method of your component. Maybe you should take a
look at the pyswitch.py from coreapps/examples.
Best regards
Bernd
On 28.02.2012 14:59, Baraki Halefom wrote:
Thank you for your reply. but I got same same error "
AttributeError: 'NoneType' object has no attribute 'Monitoring' "
after making the changes you told me.
inst.Monitoring =
ctxt.resolve("nox.netapps.monitoring.monitoring.Monitoring")
and run monitoring in the commandline
Sincerely,
On Tue, Feb 28, 2012 at 7:28 AM, Bernd Wittefeld
mailto:s9bew...@stud.uni-saarland.de>> wrote:
Hi,
the resolve() function expects a string. You don't even need
to import the monitoring stuff.
inst.Monitoring =
ctxt.resolve("nox.netapps.monitoring.monitoring.Monitoring")
Of course you should ensure that the Monitoring module is
resolvable, that means, it must be loaded by NOX either by
issueing it on the commandline or (which is the cleaner way)
it must be declared in the meta.json file of your component
as a dependency.
Hope that helps.
Best regards,
Bernd
On 27.02.2012 17 :53, Baraki Halefom wrote:
Hello everyone,
I want use the methods in the Monitoring component to send
flow stats request from my own component.
I did the following two variations to user the monitoring
component
1. include monitoring component in the dependency list
of my components meta.json file
import the monitoring component as: from
nox.netapps.monitoring.monitoring import Monitoring
then inside my component :
def __init_(self, ctxt):
global inst
Component.__init__(self,ctxt)
inst.Monitoring = ctxt.resolve(Monitoring)
and then use it like, inst.Monitoring.send_flow_
stats_request()
this gives me Monitoring description not found error.
2. when I tried to use the monitoring component in the
command line after the proper import as follows
> ./nox_core -i ptcp:6633 monitoring mycomponent
it gives me again the following error.
inst.Monitoring = ctxt.resolve(Monitoring)
AttributeError: 'NoneType' object has not
attribute 'Monitoring'
please tell me where my mistake is.
thanks
--
Baraki H. Abay
Department of Math and Computer science
North Carolina Central University
Durham, 27707 NC
___
nox-dev mailing list
nox-dev@noxrepo.org <mailto:nox-dev@noxrepo.org>
http://noxrepo.org/mailman/listinfo/nox-dev
--
Baraki H. Abay
Department of Math and Computer science
North Carolina Central University
Durham, 27707 NC
--
Baraki H. Abay
Department of Math and Computer science
North Carolina Central University
Durham, 27707 NC
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] monitoring usage error
Hi,
it complains about "inst" not being declared (it is of type None). You
missed the
"inst = self"
in the __init__ method of your component. Maybe you should take a look
at the pyswitch.py from coreapps/examples.
Best regards
Bernd
On 28.02.2012 14:59, Baraki Halefom wrote:
Thank you for your reply. but I got same same error "
AttributeError: 'NoneType' object has no attribute 'Monitoring' "
after making the changes you told me.
inst.Monitoring =
ctxt.resolve("nox.netapps.monitoring.monitoring.Monitoring")
and run monitoring in the commandline
Sincerely,
On Tue, Feb 28, 2012 at 7:28 AM, Bernd Wittefeld
mailto:s9bew...@stud.uni-saarland.de>>
wrote:
Hi,
the resolve() function expects a string. You don't even need to
import the monitoring stuff.
inst.Monitoring =
ctxt.resolve("nox.netapps.monitoring.monitoring.Monitoring")
Of course you should ensure that the Monitoring module is
resolvable, that means, it must be loaded by NOX either by
issueing it on the commandline or (which is the cleaner way) it
must be declared in the meta.json file of your component as a
dependency.
Hope that helps.
Best regards,
Bernd
On 27.02.2012 17 :53, Baraki Halefom wrote:
Hello everyone,
I want use the methods in the Monitoring component to send flow
stats request from my own component.
I did the following two variations to user the monitoring component
1. include monitoring component in the dependency list of
my components meta.json file
import the monitoring component as: from
nox.netapps.monitoring.monitoring import Monitoring
then inside my component :
def __init_(self, ctxt):
global inst
Component.__init__(self,ctxt)
inst.Monitoring = ctxt.resolve(Monitoring)
and then use it like, inst.Monitoring.send_flow_
stats_request()
this gives me Monitoring description not found error.
2. when I tried to use the monitoring component in the command
line after the proper import as follows
> ./nox_core -i ptcp:6633 monitoring mycomponent
it gives me again the following error.
inst.Monitoring = ctxt.resolve(Monitoring)
AttributeError: 'NoneType' object has not attribute
'Monitoring'
please tell me where my mistake is.
thanks
--
Baraki H. Abay
Department of Math and Computer science
North Carolina Central University
Durham, 27707 NC
___
nox-dev mailing list
nox-dev@noxrepo.org <mailto:nox-dev@noxrepo.org>
http://noxrepo.org/mailman/listinfo/nox-dev
--
Baraki H. Abay
Department of Math and Computer science
North Carolina Central University
Durham, 27707 NC
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] monitoring usage error
Hi,
the resolve() function expects a string. You don't even need to import
the monitoring stuff.
inst.Monitoring =
ctxt.resolve("nox.netapps.monitoring.monitoring.Monitoring")
Of course you should ensure that the Monitoring module is resolvable,
that means, it must be loaded by NOX either by issueing it on the
commandline or (which is the cleaner way) it must be declared in the
meta.json file of your component as a dependency.
Hope that helps.
Best regards,
Bernd
On 27.02.2012 17:53, Baraki Halefom wrote:
Hello everyone,
I want use the methods in the Monitoring component to send flow stats
request from my own component.
I did the following two variations to user the monitoring component
1. include monitoring component in the dependency list of my
components meta.json file
import the monitoring component as: from
nox.netapps.monitoring.monitoring import Monitoring
then inside my component :
def __init_(self, ctxt):
global inst
Component.__init__(self,ctxt)
inst.Monitoring = ctxt.resolve(Monitoring)
and then use it like, inst.Monitoring.send_flow_
stats_request()
this gives me Monitoring description not found error.
2. when I tried to use the monitoring component in the command line
after the proper import as follows
> ./nox_core -i ptcp:6633 monitoring mycomponent
it gives me again the following error.
inst.Monitoring = ctxt.resolve(Monitoring)
AttributeError: 'NoneType' object has not attribute
'Monitoring'
please tell me where my mistake is.
thanks
--
Baraki H. Abay
Department of Math and Computer science
North Carolina Central University
Durham, 27707 NC
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Creating and sending udp packet from controller through switch
Hi,
thank you very much. Works like a charm now.
I had to set udp_packet.len as well in order to get the correct length
everywhere. I also set the ipv4_packet.protocol and ethernet_packet.type
to the corresponding values.
As already pointed out: Try to use a string as payload for the packet
and you will most probably get an exception that array.array could not
be found.
Thank you very much for your help!
Best regards
Bernd
On 26.01.2012 22:09, Sabnis, Saurabh S wrote:
Thanks. Let me try your code and let me also try using a different branch. But I think you are not
getting this error because you are sending a packet as an argument to the set_payload method and
hence the code "elif type(payload) == array.array:" never gets called because "if
isinstance(payload, packet_base):" will always be true for such cases. (Please see below)
from packet_base.py
===
def set_payload(self, payload):
'''Set the packet payload. Expects a string, array to packet of type
packet_base'''
if isinstance(payload, packet_base):
self.next= payload
payload.prev = self
elif type(payload) == type(''):
self.next = payload
elif type(payload) == array.array:
self.next = payload.tostring()
else:
self.msg('warning, payload must be string, array or type
packet_base')
--Saurabh
- Original Message -----
From: Aaron Rosen
To: Saurabh S Sabnis
Cc: nox-dev, Bernd Wittefeld
Sent: Thu, 26 Jan 2012 15:33:45 -0500 (EST)
Subject: Re: [nox-dev] Creating and sending udp packet from controller through
switch
Here's an example of sending a UDP packet. If you want to send an ICMP
packet just change l4=icmp() (and fill in the icmp fields) and the
l3.protocol type to icmp.
Aaron
P.S: I'm using the latest nox destiny and I didn't need to change any
internal nox code.
def send_udp(mac, dstip, srcip, srcport, dstport, payload):
l4 = udp()
l4.srcport = srcport
l4.dstport = dstport
l4.len = udp.MIN_LEN + len(payload)
l4.set_payload(payload)
l4.arr = l4.tostring()
l3 = ipv4()
l3.iplen = ipv4.MIN_LEN + l4.len
l3.protocol = ipv4.UDP_PROTOCOL
l3.dstip = dstip
l3.srcip = srcip
l3.set_payload(l4)
l2 = ethernet()
l2.set_payload(l3)
l2.dst = mac
l2.src = octstr_to_array(CONTROLLER_MAC)
l2.type = ethernet.IP_TYPE
l4.csum = l4.checksum()
return l2
then:
send_openflow_packet(dpid, send_udp(mac, dstip, srcip, srcport,
dstport, payload).tostring(), inport)
On Thu, Jan 26, 2012 at 2:43 PM, Sabnis, Saurabh S wrote:
Hi,
I have similar doubt. I was trying to send ICMP unreachable packets back to host but when
I tried to set the payload of unreach() packet to "packet.next.arr[0:packet.next.hl
* 4 + 8]", I got an error due to missing 'import array' statement. After inserting
it in the packet_base.py file I got the following error.
00074|pyrt|ERR:unable to invoke a Python event handler:
Traceback (most recent call last):
File "./nox/lib/util.py", line 116, in f
event.total_len, buffer_id, packet)
File "./nox/coreapps/examples/printpacket.py", line 185, in packet_in_callback
route_packet(self,dpid, inport, packet, packet.arr, bufid)
File "./nox/coreapps/examples/printpacket.py", line 173, in route_packet
learn_and_forward(self,dpid,inport,packet,buf,bufid)
File "./nox/coreapps/examples/printpacket.py", line 132, in learn_and_forward
send_dest_unreach(self,dpid,packet,inport)
File "./nox/coreapps/examples/printpacket.py", line 89, in send_dest_unreach
unreach_packet.set_payload(packet.next.arr[0:packet.next.hl * 4 + 8])
File "./nox/lib/packet/packet_base.py", line 96, in set_payload
elif type(payload) == array.array:
AttributeError: type object 'array.array' has no attribute 'array'
Then to work around, I did not set the payload of unreach() and created other
wrapper packets and sent them to the host using sed_openflow_packet method.
This method requires eth.tostring() method which calls hdr and checksum methods
of ipv4.py. But then it again gets stuck there by giving following error:
File "./nox/coreapps/examples/printpacket.py", line 185, in packet_in_callback
route_packet(self,dpid, inport, packet, packet.arr, bufid)
File "./nox/coreapps/examples/printpacket.py", line 173, in route_packet
learn_and_forward(self,dpid,inport,packet,buf,bufid)
File "./nox/coreapps/examples/printpacket.py", line 132, in learn_and_forward
send_dest_unreach(self,dpid,packet,inport)
File "./nox/coreapps/examples/printpacket.py", line 119, in send_dest_unreach
self.send_openflow_packet(dpid, unreach_eth.tostring(),
inport,openflow.OFPP_NONE)
File &quo
[nox-dev] Creating and sending udp packet from controller through switch
Hi, I have a python component and want to create an udp packet in the controller and send it out via "self.send_openflow_packet(dpid, packet.tostring(), outport)" First of all: a small bugfix is needed: nox/src/nox/lib/packet/packet_base.py needs an "import array". Without that, the set_payload function raises an exception as it does not find array.array. Now I create my packet the following way: from nox.lib.packet.udpimport udp from nox.lib.packet.ipv4 import ipv4 from nox.lib.packet.ethernetimport ethernet udp_packet = udp() udp_packet.srcport = 12345 udp_packet.dstport = 4711 rand = random.random() udp_packet.set_payload(str(rand)) udp_packet.csum = udp_packet.checksum() ipv4_packet = ipv4() ipv4_packet.set_payload(udp_packet) ipv4_packet.srcip = ipstr_to_int(CONTROLLER_IP) ipv4_packet.dstip = ipstr_to_int(CONTROLLER_IP) ipv4_packet.csum = ipv4_packet.checksum() eth_packet = ethernet() eth_packet.src = CONTROLLER_MAC eth_packet.dst = CONTROLLER_MAC eth_packet.set_payload(ipv4_packet) eth_packet.type = ethernet.IP_TYPE and send this then via self.send_openflow_packet The packet goes out the link and is forwarded (via a flow on another switch) back to the controller where I can see it in my packet_in handler. The only problem is: the packet only consists of the link layer (ethernet type) header and the ipv4 type header. The payload of the ipv4 packet (which should be my udp header and the payload) is completely missing. From the ipv4 class, the ipv4.next is None and I can also verify with wireshark that the packet that is transmitted from the controller to the switch encapsuled in an OpenFlow packet, consists only of the ethernet header and the ipv4 header. Am I missing something? Where is this going wrong? I tried to look at the send_openflow_packet function. It seems to somehow call self.ctxt.send_openflow_packet_port in nox/src/nox/lib/core.py which I could not find?! I am not into Swig and all that stuff, so I am stuck here :( Any help is greatly appreciated! Best regards Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Measuring delay of links between switches
Hi, so I decided to go with a statsmanager component that measures delay and packet loss for every link found by the discovery component. To measure delay, I will send ICMP echo requests and measure the RTT for the links to the switches and then send a packet from the controller to switchA to switchB back to the controller. As a first approach this should be fine. The first problem I have is: How do I get the IPs of the switches to send the ICMP echo requests to? NOX talks to these switches via the control channel and I want to simply send an ICMP echo request to this IP. Is there any way to get this piece of information? The stats reply that I get from a datapath_join event doesn't contain it and I could not find anything else that might give me the needed information. Your help is very much appreciated. Best regards Bernd Wittefeld On 12.01.2012 15:34, Bernd Wittefeld wrote: Hi Kyriakos, yes I know of the propagation delays of the control channels. I thought of measuring these by simple ICMP Echo Requests and extracting the RTT from that. Assuming that we have symmetric channels, I can get an estimate of these delays and use them in the delay calculation. The processing time on the switches should be a part of the overall delay in my opinion, as the packets travelling through the network must also take this time to be processed. The question now is: which way is the best to implement this: patching the discovery module, as the infrastructure for periodical packets on every link is already there, or writing an own component which can be rather complex as there are some details that cannot be solved easily in my opinion. The LLDP packets are filtered out and processed. A similar concept would be needed in this component. Then is the question: what type of packets would be used and how would they be sent through the network? Maybe creating a simple packet with the dst IP of the controller and an action on the dst switch to forward the whole packet to the controller would work as long as the flows being installed do not interfere with the "normal" switch processing. Best regards Bernd On 11.01.2012 23:42, Kyriakos Zarifis wrote: Hi Bernd, this sounds like an interesting idea to me, and something that could be proven useful. One concern is that in the trip from the controller to switch A, switch B and back to the controller, you have the propagation delay of the control channels, the propagation delay between A<->B, but also the processing delay on the switches. So some caution should be taken there in order to make sure that the processing delay on the switches is minimized, in order to get the best possible estimate of the delay of the link A<->B. Also I would imagine that, say, if there was no other traffic, buffers were all empty etc, even then different switches would perform a bit differently, so that's another factor that would influence the estimation, though it's probably negligible. On Wed, Jan 11, 2012 at 7:33 AM, Bernd Wittefeld <mailto:s9bew...@stud.uni-saarland.de>> wrote: Hi, I am currently working on a component that needs a lot of statistical information about the current network state. In fact, I need the packet lLoss rate and the delay of single links between OpenFlow-switches. The PLR can be computed quite easily from the statistics that the switch gives me (tx_packets and rx_packets of switches that are connected via a link), but the delay turns out to be a problem. I have the following idea: I might use the discovery module and install an organizationally specific TLV that simply carries a timestamp and with every received LLDP packet, I can measure the time it takes for a packet to travel from controller to switchA to switchB and back to the controller. The links from the controller to the switches can be measured easily, so I can get a rough estimate of the Delay on the link (we don't talk about accuracy in the first place here :)) The discovery module can then deliver the delay for a specific link via an API function. What do you think? Is this feasible? Is this way ok or do I abuse the LLDP protocol? If it's ok, the implementation might be relatively straight forward, adding a class to nox.lib.packet.lldp for my tlv and add a parser, then modify the discovery module and I should be fine?! If yes, do you have any other suggestions on how to implement this? I also thought about a custom component that builds a packet containing a timestamp and sends it out every switch port that is connected to another switch and install an Action on the target switch to forward that packet back to the controller. I don't know if this is feasible and would work in the first place (addressing and type of the packet carrying the timestamp for example woul
Re: [nox-dev] Measuring delay of links between switches
Hi Kyriakos, yes I know of the propagation delays of the control channels. I thought of measuring these by simple ICMP Echo Requests and extracting the RTT from that. Assuming that we have symmetric channels, I can get an estimate of these delays and use them in the delay calculation. The processing time on the switches should be a part of the overall delay in my opinion, as the packets travelling through the network must also take this time to be processed. The question now is: which way is the best to implement this: patching the discovery module, as the infrastructure for periodical packets on every link is already there, or writing an own component which can be rather complex as there are some details that cannot be solved easily in my opinion. The LLDP packets are filtered out and processed. A similar concept would be needed in this component. Then is the question: what type of packets would be used and how would they be sent through the network? Maybe creating a simple packet with the dst IP of the controller and an action on the dst switch to forward the whole packet to the controller would work as long as the flows being installed do not interfere with the "normal" switch processing. Best regards Bernd On 11.01.2012 23:42, Kyriakos Zarifis wrote: Hi Bernd, this sounds like an interesting idea to me, and something that could be proven useful. One concern is that in the trip from the controller to switch A, switch B and back to the controller, you have the propagation delay of the control channels, the propagation delay between A<->B, but also the processing delay on the switches. So some caution should be taken there in order to make sure that the processing delay on the switches is minimized, in order to get the best possible estimate of the delay of the link A<->B. Also I would imagine that, say, if there was no other traffic, buffers were all empty etc, even then different switches would perform a bit differently, so that's another factor that would influence the estimation, though it's probably negligible. On Wed, Jan 11, 2012 at 7:33 AM, Bernd Wittefeld mailto:s9bew...@stud.uni-saarland.de>> wrote: Hi, I am currently working on a component that needs a lot of statistical information about the current network state. In fact, I need the packet lLoss rate and the delay of single links between OpenFlow-switches. The PLR can be computed quite easily from the statistics that the switch gives me (tx_packets and rx_packets of switches that are connected via a link), but the delay turns out to be a problem. I have the following idea: I might use the discovery module and install an organizationally specific TLV that simply carries a timestamp and with every received LLDP packet, I can measure the time it takes for a packet to travel from controller to switchA to switchB and back to the controller. The links from the controller to the switches can be measured easily, so I can get a rough estimate of the Delay on the link (we don't talk about accuracy in the first place here :)) The discovery module can then deliver the delay for a specific link via an API function. What do you think? Is this feasible? Is this way ok or do I abuse the LLDP protocol? If it's ok, the implementation might be relatively straight forward, adding a class to nox.lib.packet.lldp for my tlv and add a parser, then modify the discovery module and I should be fine?! If yes, do you have any other suggestions on how to implement this? I also thought about a custom component that builds a packet containing a timestamp and sends it out every switch port that is connected to another switch and install an Action on the target switch to forward that packet back to the controller. I don't know if this is feasible and would work in the first place (addressing and type of the packet carrying the timestamp for example would be a problem). Or am I completely wrong here? Is there anything that gives me this information? What do you think? I'm open for suggestions :) Thanks in advance! Bernd ___ nox-dev mailing list nox-dev@noxrepo.org <mailto:nox-dev@noxrepo.org> http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] Measuring delay of links between switches
Hi, I am currently working on a component that needs a lot of statistical information about the current network state. In fact, I need the packet lLoss rate and the delay of single links between OpenFlow-switches. The PLR can be computed quite easily from the statistics that the switch gives me (tx_packets and rx_packets of switches that are connected via a link), but the delay turns out to be a problem. I have the following idea: I might use the discovery module and install an organizationally specific TLV that simply carries a timestamp and with every received LLDP packet, I can measure the time it takes for a packet to travel from controller to switchA to switchB and back to the controller. The links from the controller to the switches can be measured easily, so I can get a rough estimate of the Delay on the link (we don't talk about accuracy in the first place here :)) The discovery module can then deliver the delay for a specific link via an API function. What do you think? Is this feasible? Is this way ok or do I abuse the LLDP protocol? If it's ok, the implementation might be relatively straight forward, adding a class to nox.lib.packet.lldp for my tlv and add a parser, then modify the discovery module and I should be fine?! If yes, do you have any other suggestions on how to implement this? I also thought about a custom component that builds a packet containing a timestamp and sends it out every switch port that is connected to another switch and install an Action on the target switch to forward that packet back to the controller. I don't know if this is feasible and would work in the first place (addressing and type of the packet carrying the timestamp for example would be a problem). Or am I completely wrong here? Is there anything that gives me this information? What do you think? I'm open for suggestions :) Thanks in advance! Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] NOX UnicodeDecodeError in nox/coreapps/pyrt/pyoxidereactor.py
Hi, I'm currently not in the office. Thanks for the logging hint. I will look further into that and keep you posted as soon as I'm back. My module is written in Python and does some minimal logging. Maybe there is the error. I will try to execute the same module in the old and working environment. Thank you very much! Bernd -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. Murphy McCauley schrieb: It looks like some Python component is trying to log something unprintable. Is your prrt module in Python? Does it do any logging? Is that the full stack trace that you pasted? It'd be nice to see where emit() was being called from. If you just want a quick fix, you could try just commenting out lines 337-339 in pyrt. But if this is happening because of something in monitoring or spanning_tree, I'd like to understand the problem better so that we could fix it. -- Murphy On Dec 20, 2011, at 4:50 AM, Bernd Wittefeld wrote: > Hi, > I have another problem with my NOX installation. When I start it using > > ./nox_core -i ptcp:6633 spanning_tree switch prrt monitoring > > it worked flawlessly all the time with the standard openflow switch from > openflow.org in my old environment. Now I have moved to a new environment > using an exact copy of the previous setup only with vmware installations, I > have the following problem appearing in the NOX logs: > > Traceback (most recent call last): > File "./nox/coreapps/pyrt/pyoxidereactor.py", line 339, in emit > msg = unicode(msg, 'utf-8') > UnicodeDecodeError: 'utf8' codec can't decode bytes in position 127-129: > invalid data > > prrt is a module that I am currently working on. It does nothing with pyrt > and stuff. Currently only gathering information from discovery and filling > some datastructures. > Does anyone know where this can come from? Do I miss some dependencies upon > installation? It seems like NOX cannot understand the data it gets from a > switch?! > I have checked the configure scripts for dependencies and searched the web > but could not find anything useful on this. > > Thanks in advance! > Bernd >_ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] NOX UnicodeDecodeError in nox/coreapps/pyrt/pyoxidereactor.py
Hi, I have another problem with my NOX installation. When I start it using ./nox_core -i ptcp:6633 spanning_tree switch prrt monitoring it worked flawlessly all the time with the standard openflow switch from openflow.org in my old environment. Now I have moved to a new environment using an exact copy of the previous setup only with vmware installations, I have the following problem appearing in the NOX logs: Traceback (most recent call last): File "./nox/coreapps/pyrt/pyoxidereactor.py", line 339, in emit msg = unicode(msg, 'utf-8') UnicodeDecodeError: 'utf8' codec can't decode bytes in position 127-129: invalid data prrt is a module that I am currently working on. It does nothing with pyrt and stuff. Currently only gathering information from discovery and filling some datastructures. Does anyone know where this can come from? Do I miss some dependencies upon installation? It seems like NOX cannot understand the data it gets from a switch?! I have checked the configure scripts for dependencies and searched the web but could not find anything useful on this. Thanks in advance! Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] meta.json syntax and importing files in Python
Hi, it's me again :) I was able to import my python files. They needed to be added to the NOX_RUNTIMEFILES and EXTRA_DIST in my Makefile.am, so that the links from the build directory were established. So that problem is solved, but I would love to have some docs about those meta.json files. Greetings Bernd On 16.12.2011 16:03, Bernd Wittefeld wrote: Hi, I'm am wondering about the syntax and sematic of the meta.json files. I cannot find anything about it in the wiki and the mailinglists. The problem is a fairly easy one: I have written a python component and splitted it up in several files, but I cannot import those files. I tried various permutations of the import statement and nothing worked. Can you give me a hint where I can find valuable information about the NOX build system? Do I have to add my *.py files (which I only want to use in my component) to Makefile.am and meta.json? Thanks in advance Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] meta.json syntax and importing files in Python
Hi, I'm am wondering about the syntax and sematic of the meta.json files. I cannot find anything about it in the wiki and the mailinglists. The problem is a fairly easy one: I have written a python component and splitted it up in several files, but I cannot import those files. I tried various permutations of the import statement and nothing worked. Can you give me a hint where I can find valuable information about the NOX build system? Do I have to add my *.py files (which I only want to use in my component) to Makefile.am and meta.json? Thanks in advance Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Spanning Tree Module
Hi, ok, I got it to work now. It was a problem on our side. In fact, the switches in the lab are connected by an HP ProCurve switch, which i have configured to use VLANs for every "link" between the OpenFlow switches. After configuring the HP switch in the correct way, everything worked :) So, I read in the wiki, that the Spanning Tree module was only tested with three switches. I can confirm it works flawlessly with six switches. Thanks for your quick answer. Best regards Bernd Zitat von Murphy McCauley : AFAIK, this should work. Have you actually inspected the switches? Are the relevant ports actually getting NOFLOOD set? -- Murphy On Nov 29, 2011, at 7:54 AM, Bernd Wittefeld wrote: Hi, first of all: thanks for your great work and the really good support here. I have a small problem and I hope someone knows what to do :) The situation is the following: I have a network with 6 OpenFlow switches in a mesh here. The software (switches and NOX) is working fine. I use the spanning_tree module in order to prevent loops in the network when flooding ARP-Requests and stuff. I got everything to work fine and even the NOX Gui (I'm on destiny) shows me a correct Spanning-Tree without loops. I have two hosts which are connected to two different switches. If I send an ICMP ping from one host to the other, I get the ARP requests in the Openflow network. They travel along the spanning tree which I checked by using wireshark and tcpdump. The other links don't show ARP requests. Now the problem: The ARP requests are not forwarded out of the OpenFlow network. That means, they reach the switch that is connected to the destination host, but the host does not get the ARP request. How can I solve this? Do I have to "manually" unset the NOFLOOD switch on that port in my controller or is there any other way, maybe to make the spanning_tree module more intelligent or am I doing something wrong? Thanks in advance Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] Spanning Tree Module
Hi, first of all: thanks for your great work and the really good support here. I have a small problem and I hope someone knows what to do :) The situation is the following: I have a network with 6 OpenFlow switches in a mesh here. The software (switches and NOX) is working fine. I use the spanning_tree module in order to prevent loops in the network when flooding ARP-Requests and stuff. I got everything to work fine and even the NOX Gui (I'm on destiny) shows me a correct Spanning-Tree without loops. I have two hosts which are connected to two different switches. If I send an ICMP ping from one host to the other, I get the ARP requests in the Openflow network. They travel along the spanning tree which I checked by using wireshark and tcpdump. The other links don't show ARP requests. Now the problem: The ARP requests are not forwarded out of the OpenFlow network. That means, they reach the switch that is connected to the destination host, but the host does not get the ARP request. How can I solve this? Do I have to "manually" unset the NOFLOOD switch on that port in my controller or is there any other way, maybe to make the spanning_tree module more intelligent or am I doing something wrong? Thanks in advance Bernd ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
