Re: [nox-dev] Topology component and FlowVisor.
Hi Sergio, Could you try to run your application without flowvisor. I find it strange that flowvisor would be causing a problem here, even though it treats lldp packets rather awkwardly. That said, if your setup works without flowvisor then we can definitely say that flowvisor is at fault and we can investigate further. -- Ali Al-Shabibi On 12 janv. 2012, at 04:24, Sergio Jiménez Feijóo jjji...@gmail.com wrote: Hi guys, I've developed a NOX aplication which needs to use the topology component to discover the network topology. I've tested my application in a testbed of 6 Linksys WRT54GL running the OpenWRT Pantou firmware (without flowvisor) and it worked like a charm. Now I'm testing my aplication in a testbed of 5 NEC IP8800/S3640-24T2XW (with flowvisor) and the topology detection isn't working at all (the data struct is empty). Since OpenFlow allows an application to run in different devices I've discarded the fact of using new switches as the cause of the error. Therefore I think flowvisor is causing the topology component not to run properly. Is this possible? Have you experienced any problems with flowvisor and NOX? Thank you. http://homestore.cisco.eu/store/ciscoeu/en_IE/pd/productID.241269400 http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Deployment/Vendor/NEC ___ 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] packet_in_event
Hi! *My first question is that when a packet_in_event is received by the controller, the 'inport' parameter designs the port of controller that received the packet from the switch or the port of the switch that received the packet. The inport parameter designates the port on which the packet arrived on the switch. why do we compare the prt[0] to the inport and why do we do a inst.send_openflow(dpid, bufid, buf, openflow.OFPP_FLOOD, inport) when they are equal but we do inst.install_datapath_flow(dpid, flow, CACHE_TIMEOUT, actions, bufid, openflow.OFP_DEFAULT_PRIORITY, inport, buf) when they are different. Because prt[0] is the first element of the tuple stored in inst.st[dpid][dstaddr], namely the output port for that destination address. So, if the previously learned output port is the same as the inport then either we have a or are creating loop on the network or something has changed that the switch did not notice (which would be very odd) and therefore we flood the packet onto all ports except the inport in an attempt to have it delivered. If the previously learned port and the destination port are different then we are in good shape and we should forward the packet to that destination port. This is done by the install_datapath_flow method. Thanks a lot and sorry for bothering with those basic questions. There are no stupid questions, feel free to ask questions when you have some ;) Cheers, Ali Regards, Karim ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev Ali Al-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch Tel : +41 22 767 86 46 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] send_openflow to different dpid question
Hi Aaron, self.dpid_of_duplication is not the dpid the packet arrived on, therefore therefore bufid is meaningless to self.dpid_of_duplication. You should send self.dpid_of_duplication the actual packet you want to packet_out. Hope this helps, -- Ali Al-Shabibi On 10 déc. 2010, at 18:57, Aaron Rosen aro...@clemson.edu wrote: Hello, When I get a specific kind of packet I want to send that packet to a specific dpid and port and also send it to the dpid and port that the packet was intended for. If I do: # send packet to end host # note self.PortMaping[dpid, mac_to_str(packet.dst)] returns the port number the packet.dst is on actions = [[openflow.OFPAT_OUTPUT, [0, self.PortMaping[dpid, mac_to_str(packet.dst) self.send_openflow(dpid, bufid, buf, actions, inport) # send packet to specific dpid and port 11 actions = [[openflow.OFPAT_OUTPUT, [0, 11]]] self.send_openflow(self.dpid_of_duplication, bufid, buf, actions, inport) The packet never gets to the self.dpid_of_duplication port 11. Anyone see where I'm going wrong here? Thanks, Aaron -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel 843.425.9777 ___ 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] send_openflow to different dpid question
James is right, you should check with tcpdump. By looking at the send_openflow code, you can see, if buffer_id != None: self.send_openflow_buffer(dp_id, buffer_id, actions, inport) Switch the buffer_id for None and it should work, the comment is incorrect. On Dec 10, 2010, at 8:22 PM, James Murphy McCauley wrote: Have you installed a rule to send the entire packet (the type that you want to duplicate) to the controller? If not, it may well be truncated. So you may only be sending the truncated version out on the second dpid. Depending on how you're checking to see if this is working, this may just look like it's failing (e.g., because if it's a TCP packet, the receiver will just throw it away because its checksum will be wrong among other things). -- Murphy On Fri, 2010-12-10 at 14:08 -0500, Aaron Rosen wrote: Hi Ali, Looking at the comments for send_openflow, if buffer_id is -1 then, it should send the packet. Though, maybe I'm still doing this incorrectly? actions = [[openflow.OFPAT_OUTPUT, [0, 11]]] self.send_openflow(self.dpid_of_duplication, -1, buf, actions, inport) also actions = [[openflow.OFPAT_PACKET_OUTPUT, [0, 11]]] self.send_openflow(self.dpid_of_duplication, -1, buf or packet, actions, inport) doesn't seem to work. Could you point out where I'm going wrong? Thanks, Aaron On Fri, Dec 10, 2010 at 1:41 PM, Ali Al-Shabibi ali.al-shab...@cern.ch wrote: Hi Aaron, self.dpid_of_duplication is not the dpid the packet arrived on, therefore therefore bufid is meaningless to self.dpid_of_duplication. You should send self.dpid_of_duplication the actual packet you want to packet_out. Hope this helps, -- Ali Al-Shabibi On 10 déc. 2010, at 18:57, Aaron Rosen aro...@clemson.edu wrote: Hello, When I get a specific kind of packet I want to send that packet to a specific dpid and port and also send it to the dpid and port that the packet was intended for. If I do: # send packet to end host # note self.PortMaping[dpid, mac_to_str(packet.dst)] returns the port number the packet.dst is on actions = [[openflow.OFPAT_OUTPUT, [0, self.PortMaping[dpid, mac_to_str(packet.dst) self.send_openflow(dpid, bufid, buf, actions, inport) # send packet to specific dpid and port 11 actions = [[openflow.OFPAT_OUTPUT, [0, 11]]] self.send_openflow(self.dpid_of_duplication, bufid, buf, actions, inport) The packet never gets to the self.dpid_of_duplication port 11. Anyone see where I'm going wrong here? Thanks, Aaron -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel 843.425.9777 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel 843.425.9777 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org -- Ali Al-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch Tel : +41 22 767 86 46 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] discovery
1. Creates a lldp packet with the 6 least significant bytes of the dpid as a tlv (see line 65 and 66 of discovery.py). 2. The received lldp packet's tlv field is then used to compute a chassis id (line 276), this chassis id is only 6 bytes long You are right. The problem is that you are unable to associate multiple Openflow instances on the same HP switch with the same controller because the TLV contains only the least significant 48 bits. I thought this was solved with NOX-destiny branch which has support for 64 bit dpid. I'll let the NOX team put in the patch. I actually believe it doesn't work even if the connections are on the distinct HP switches. Because the keys in self.dps are 8 bytes long and the chassisid is 6 bytes long (and ignores the first 2 bytes of the dpid). So unless the first 2 bytes of the dpid is all zero, this will never work. Moreover, the first 2 bytes cannot be zero as they represent the openflow instance vlan id which cannot be 0 (at least on HP switches). Please correct me, if I am wrong. Also, I noticed that the switchstats.py in the switchstats component has the following call: self.ctxt.send_port_stats_request(dp) Shouldn't this call be: self.ctxt.send_port_stats_request(dp, openflow.OFPP_NONE) I believe the default value of OFPP_NONE for the second argument is set elsewhere. When I run the switchstats module, I get this error: 12:30:48 a...@pcepatr39[src]$ ./nox_core -i ptcp:2525 switchstats NOX 0.8.0~full~beta (nox_core), compiled Sep 2 2010 16:32:28 Compiled with OpenFlow 0x01 1|reactor|ERR:Unhandled Error Traceback (most recent call last): --- exception caught here --- File ./nox/coreapps/pyrt/pyoxidereactor.py, line 86, in __call__ self.func(*self.args, **self.kw); File ./nox/netapps/switchstats/switchstats.py, line 123, in lambda lambda : self.port_timer(dp)) File ./nox/netapps/switchstats/switchstats.py, line 88, in port_timer self.ctxt.send_port_stats_request(dp) File ./nox/coreapps/pyrt/pycomponent.py, line 476, in send_port_stats_request def send_port_stats_request(*args): return _pycomponent.PyContext_send_port_stats_request(*args) exceptions.TypeError: PyContext_send_port_stats_request() takes exactly 3 arguments (2 given) It is fixed by adding the OFPP_NONE Thanks! -- Ali Al-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch Tel : +41 22 767 86 46 Mob : +41 78 609 04 84 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] discovery
Hi all, I noticed that the discovery module in the destiny branch does not work with HP switches (at least). So attached is a patch that resolves this situation. I am not entirely sure this is the appropriate way to solve the problem but it works for me.Hope it helps, Ali Al-ShabibiDoctoral StudentPH-ATDCERN - European Organization for Nuclear ResearchOffice: 513 R-018ali.al-shab...@cern.chTel : +41 22 767 86 46 discovery.patch Description: Binary data ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Routing module
2e988cc00065 (len:60) 00290|openflow-event|DBG:received packet-in event from 2e9aea65 (len:60) 00291|openflow-event|DBG:received packet-in event from 2e988cc00065 (len:60) 00292|openflow-event|DBG:received packet-in event from 2e9aea65 (len:60) 00293|openflow-event|DBG:received packet-in event from 2e988cc00065 (len:60) Martin Casado wrote: What I don't understand is why I don't see packets sent to Nox in the debugging output you sent out. I would expect some output from authenticator or routing. My suspicion is that the switch is not forwarding packets to Nox under the VLAN configuration you're testing. Does the switch application work under your VLAN configuration? Hi Martin, If I put the two end hosts in the same vlan and ping them it works fine. But when they are in different vlans the arp requests are not resolved, the only flow which is added is the one I quoted in my original email. So I am positive that the packets are making it to nox. What is the scenario in which the routing module works best? Could you give me some pointers as to how the routing module works? Thanks for your help, On Oct 13, 2009, at 9:30 PM, Martin Casado wrote: All I see are the LLDP packets being received. Are you sure that packets from the end hosts are making it to Nox? If not, perhaps there is a switch mis-configuration. What happens if you run switch instead of routing? If this doesn't work as well, then it is almost certainly a switch issue. .martin -- Ali Al-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch Tel : +41 22 767 86 46 Mob : +41 78 609 04 84 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Routing module
Should it not also advertise that routing assumes that either spanning tree is running or that the physical topology contains no loops to function correctly. Martin Casado wrote: Ah, I'm starting to understand what is going on. Routing has no notion of subnets, vlans etc. It doesn't operate like a standard ipv4 router (perhaps the name should be changed to avoid confusion). Routing operates as follows: - It pulls in the authenticator component which tracks MAC addresses and the switch ports they are bound to - For each packet in which the destination MAC address has been discovered, a point to point route is calculated and a flow entry is added to each switch along path. - If the destination MAC has not been discovered, the packet is flooded It doesn't, however, have an ARP stack. So if you're host is configered with the first switch as the next hop, the ARP packet will be flooded, to no effect. This is a roundabout way of saying that, yes in order to operate correctly, all hosts must be on the same subnet. hope this all makes sense, .martin The switch application does not work under my vlan configuration, and it should not as each the two end hosts reside in different subnets. It seems that the routing module expects all datapaths to be within the same openflow vlan instance. Basically this means that if H1 is in one vlan instance and H2 is in the other, then these hosts will never be able to communicate. I do not know if this issue is specific to hardware openflow implementations, but I believe so. The solution that I have found so far is to put all datapaths in the same vlan. This seems to solve the problem, and the routing module picks up routes. Let me know if I have missed something. Cheers. Martin Casado wrote: What I don't understand is why I don't see packets sent to Nox in the debugging output you sent out. I would expect some output from authenticator or routing. My suspicion is that the switch is not forwarding packets to Nox under the VLAN configuration you're testing. Does the switch application work under your VLAN configuration? Hi Martin, If I put the two end hosts in the same vlan and ping them it works fine. But when they are in different vlans the arp requests are not resolved, the only flow which is added is the one I quoted in my original email. So I am positive that the packets are making it to nox. What is the scenario in which the routing module works best? Could you give me some pointers as to how the routing module works? Thanks for your help, On Oct 13, 2009, at 9:30 PM, Martin Casado wrote: All I see are the LLDP packets being received. Are you sure that packets from the end hosts are making it to Nox? If not, perhaps there is a switch mis-configuration. What happens if you run switch instead of routing? If this doesn't work as well, then it is almost certainly a switch issue. .martin -- Ali Al-Shabibi Doctoral Student PH-ATD CERN - European Organization for Nuclear Research Office: 513 R-018 ali.al-shab...@cern.ch Tel : +41 22 767 86 46 Mob : +41 78 609 04 84 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
