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] 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 s9bew...@stud.uni-saarland.de 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 tel:27.02.2012%2017: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] Creating and sending udp packet from controller through switch
, in tostring buf = self.hdr() File ./nox/lib/packet/ipv4.py, line 167, in hdr self.csum = self.checksum() File ./nox/lib/packet/ipv4.py, line 162, in checksum self.dstip) error: 'H' format requires 0= number= 65535 I printed the values of the attributes used in these functions and found out that the self.id attribute of ipv4 packet has value more than 65535. It is generated using int(time.time()) function. So I changed the statement to int(time.time()) % 65535 and went ahead. Now I am able to send my packet to the host and I can see it in Wireshark but my host is not giving me destination unreachable error. There are several problems here. Can someone please help me regarding this. My code is as follows: def send_dest_unreach(self,dpid,packet,inport): unreach_packet = unreach() unreach_packet.unused = 0 unreach_packet.next_mtu = 0 # unreachable messages include the IP header and the first 8 bytes of the # packet that couldn't reach its destination #print packet.next.arr[0:packet.next.hl * 4 + 8] unreach_packet.set_payload(packet.next.arr[0:packet.next.hl * 4 + 8]) #unreach_packet.arr = packet.next.arr[0:packet.next.hl * 4 + 8] unreach_icmp = icmp() unreach_icmp.type = 3 # unreachable unreach_icmp.code = 0 # network unreachable unreach_icmp.set_payload(unreach_packet) # icmp (unlike ipv4) doesn't automatically calculate its checksum, so we # have to do it ourself unreach_icmp.csum = packet_utils.checksum(unreach_icmp.tostring(), 0) unreach_ip = ipv4() # length of the header plus the length of the payload unreach_ip.iplen = unreach_ip.hl * 4 + len(unreach_icmp.tostring()) unreach_ip.protocol = ipv4.ICMP_PROTOCOL unreach_ip.srcip = packet.next.dstip # Hmm... ? unreach_ip.dstip = packet.next.srcip unreach_ip.set_payload(unreach_icmp) print_packet(unreach_ip,ID) unreach_eth = ethernet() unreach_eth.src = packet.dst # I wonder what this should actually be... ? unreach_eth.dst = packet.src unreach_eth.type = packet.type unreach_eth.set_payload(unreach_ip) - Original Message - From: Aaron Rosenaro...@clemson.edu To: Bernd Wittefelds9bew...@stud.uni-saarland.de Cc: nox-devnox-dev@noxrepo.org Sent: Thu, 26 Jan 2012 14:03:38 -0500 (EST) Subject: Re: [nox-dev] Creating and sending udp packet from controller through switch Hi, You need to set the length field in the Ipv4 packet. ipv4_packet.iplen = ipv4.MIN_LEN + udp_packet.len() should do the trick. Aaron On Thu, Jan 26, 2012 at 1:42 PM, Bernd Wittefeld s9bew...@stud.uni-saarland.de wrote: 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 -- Aaron O. Rosen Masters Student - Network
[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 s9bew...@stud.uni-saarland.de 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
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 s9bew...@stud.uni-saarland.de 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 jam...@nau.edu 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] 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 jam...@nau.edu: 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
