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 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] Sending arp packets
on I'm not seeing any. Though at my controller I'm definitely >>>> getting the packets. (I think this may because I'm using mininet? I've >>>> tried all the interfaces on my machine in wireshark). Though when I >>>> try this using the Openflow Tutorial provided VM i'm also not seeing >>>> any 'of' packets in wireshark there? (Any idea why)? >>>> >>>> Thanks, >>>> >>>> Aaron >>>> >>>> >>>> >>> >>> ___ >>> 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 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] 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 >> 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 >>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] 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 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] 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): --- --- 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 : 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
Re: [nox-dev] discovery
build_lldp_generator())
self.post_callback(TIMEOUT_CHECK_PERIOD, lambda : discovery.timeout_links(self))
def post_link_event(self, linktuple, action):
e = Link_event(create_datapathid_from_host(linktuple[0]),
create_datapathid_from_host(linktuple[2]),
linktuple[1], linktuple[3], action)
self.post(e)
#--
# Link addition/deletion
#--
def add_link(self, linktuple):
self.post_link_event(linktuple, Link_event.ADD)
src_dpid = create_datapathid_from_host(linktuple[0])
src_port = linktuple[1]
dst_dpid = create_datapathid_from_host(linktuple[2])
dst_port = linktuple[3]
self._bindings.add_link(src_dpid,src_port,dst_dpid,dst_port)
self._user_event_log.log("discovery",LogLevel.ALERT,
"Added network link between {sl} and {dl}",
set_src_loc = (src_dpid,src_port),
set_dst_loc = (dst_dpid,dst_port))
def delete_links(self, deleteme):
for linktuple in deleteme:
del self.adjacency_list[linktuple]
src_dpid = create_datapathid_from_host(linktuple[0])
src_port = linktuple[1]
dst_dpid = create_datapathid_from_host(linktuple[2])
dst_port = linktuple[3]
try:
self._bindings.remove_link(src_dpid,src_port,dst_dpid,dst_port)
self._user_event_log.log("discovery",LogLevel.ALERT,
"Removed network link between {sl} and {dl}",
set_src_loc = (src_dpid,src_port),
set_dst_loc = (dst_dpid,dst_port))
except Exception, e:
lg.error('Error removing links from binding storage')
self.post_link_event(linktuple, Link_event.REMOVE)
#--
# Public API
#--
def is_switch_only_port(self, dpid, port):
""" Returns True if (dpid, port) designates a port that has any
neighbor switches"""
for dp1, port1, dp2, port2 in self.adjacency_list:
if dp1 == dpid and port1 == port:
return True
if dp2 == dpid and port2 == port:
return True
return False
def getFactory():
class Factory:
def instance(self, ctxt):
return discovery(ctxt)
return Factory()
On Sep 4, 2010, at 12:15 AM, Srini Seetharaman wrote:Hi AliCould you please let us know what you meant by "does not work"?Is the HP switch dropping the LLDP packet that is being packet-out?The only problem we used to have with HP switches was that if the LLPDsrc MAC was a multicast address, then the switch would drop it. Thishas been fixed for the past few months in most of the branches. So,it'll help us to know what version of NOX you're running (If you sendus the original discovery.py file, that helps too).ThanksSrini.On Fri, Sep 3, 2010 at 10:31 AM, Ali Al-Shabibi <ali.al-shab...@cern.ch> wrote:Hi all,I noticed that the discovery module in the destiny branch does not work withHP 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 butit 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___nox-dev mailing listnox-dev@noxrepo.orghttp://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Ali Al-ShabibiDoctoral StudentPH-ATDCERN - European Organization for Nuclear ResearchOffice: 513 R-018ali.al-shab...@cern.chTel : +41 22 767 86 46
___
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
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
Re: [nox-dev] Routing module
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
Re: [nox-dev] Routing module
5 00270|name_manager|DBG:Cannot mangled unknown principal type 4294967295. 00271|authenticator|DBG:Added location discovered;authenticated 2e988cc00067:37. 00272|name_manager|DBG:Cannot mangled unknown principal type 4294967295. 00273|authenticator|DBG:Added location discovered;authenticated 2e988cc00067:39. 00274|name_manager|DBG:Cannot mangled unknown principal type 4294967295. 00275|authenticator|DBG:Added location discovered;authenticated 2e988cc00065:41. 00276|openflow-event|DBG:received packet-in event from 2e988cc00065 (len:60) 00277|discovery|WARN:new link detected (00:00:2e:98:8c:c0:00:65 p:41 -> 00:00:2e:9a:ea:00:00:65 p:41) 00278|openflow-event|DBG:received packet-in event from 2e9aea65 (len:60) 00279|discovery|WARN:new link detected (00:00:2e:9a:ea:00:00:65 p:41 -> 00:00:2e:98:8c:c0:00:65 p:41) 00280|openflow-event|DBG:received packet-in event from 2e9aea66 (len:60) 00281|authenticator|DBG:Automatically authing 00:50:da:6e:ac:7f 0.0.0.0. 00282|authenticator|DBG:Host auth event received. 00283|authenticator|DBG:discovered;authenticated added location 2e9aea66:48 to 00:50:da:6e:ac:7f. 00284|authenticator|DBG:Looking up destination name for flow. 00285|authenticator|DBG:Caching host discovered;unauthenticated. 00286|sp_routing|DBG:Broadcasting 2e9aea66 port0030:vlan mac00:50:da:6e:ac:7f->ff:ff:ff:ff:ff:ff proto0806 ip0.0.0.0->0.0.0.0 port0->0 00287|openflow-event|DBG:received packet-in event from 2e988cc00065 (len:60) 00288|openflow-event|DBG:received packet-in event from 2e9aea000065 (len:60) 00289|openflow-event|DBG:received packet-in event from 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
[nox-dev] Routing module
Hello, I am trying to implement a monitoring protocol. For this I am relying on the routing module. I have a simple setup involving three openflow-enabled hardware switches. Below is the topology: ++ Vl 1++Vl 2 ++ H1--| R1 |--| R2 |--| R3 |--H2 ++ ++ ++ R1 and R2 share vlan 1 (ip 192.168.1.0/24) and R2 and R3 share vlan 2 (ip address 192.168.2.0/24). H1 (192.168.1.1) and H2 (192.168.2.1) are end hosts. Each vlan instance connects to the controller and is correctly picked up by nox as it registers the correct number of datapaths and switches. When I run, nox_core -i ptcp:2525 routing, I obtain the following output: a...@pcepatr39[src]$ sudo ./nox_core -i ptcp:2525 switch routing [sudo] password for ash: NOX 0.5.0~full~beta (nox_core), compiled Oct 13 2009 14:43:43 Compiled with OpenFlow 0x97 (exp) 1|sqlite3-impl|WARN:Transactional storage file not given in the command line; defaulting to 'testing.sqlite' 2|discovery|WARN:new link detected (00:00:2e:98:ca:40:00:66 p:45 -> 00:00:2e:9a:ea:00:00:66 p:45) 4|discovery|WARN:new link detected (00:00:2e:9a:ea:00:00:65 p:41 -> 00:00:2e:98:8c:c0:00:65 p:41) 5|discovery|WARN:new link detected (00:00:2e:9a:ea:00:00:66 p:45 -> 00:00:2e:98:ca:40:00:66 p:45) 6|discovery|WARN:new link detected (00:00:2e:98:8c:c0:00:65 p:41 -> 00:00:2e:9a:ea:00:00:65 p:41) So the links are correctly detected by the discovery module. But when I attempt to ping H2 from H1. The only flow then I see setup is: duration=11s, table_id=0, priority=65535, n_packets=9, n_bytes=540, idle_timeout=60,hard_timeout=0,arp,in_port=48,dl_vlan=0x,dl_src=00:50:da:6e:ac:7f, dl_dst=ff:ff:ff:ff:ff:ff,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_proto=0,tp_src=0,tp_dst=0,actions=FLOOD And no other flows are setup and no messages are sent out by the routing module. Am I missing something about the routing module? From the manual it seems like it is supposed to setup flows on each router from source till the destination. I am running this on 3 hp 3500s, with nox 0.5.0 full. Thanks for your help, -- 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] openflow wire protocol 0x98
Even after these modification there will be some problems with some of
the apps, such as the Routing and Flow Fetcher. These problems are due
to the fact that the ofp_match structure has changed to include now two
pads and a field for vlan priority. Also the ofp_flow_stats_request has
changed as well.
So most probably some alignments are off. Is it worth for me to modify
the code to support these changes or simply revert to a previous version
of openflow. If it is worth adapting the current nox code, could someone
please point me to the areas which require attention?
Thanks for your help,
Ali Al-Shabibi wrote:
Hi,
Thanks for your quick answer, Martin. Turns out that was part of the
error, but I started investigating deeper and I found that in the
includes from openflow, the struct ofp_flow_expired had been renamed to
ofp_flow_removed. Below is t he diff between the two files.
114c114
< OFPT_FLOW_EXPIRED, /* Async message */
---
> OFPT_FLOW_REMOVED,/* Async message */
569c569
< enum ofp_flow_expired_reason {
---
> enum ofp_flow_removed_reason {
576c576
< struct ofp_flow_expired {
---
> struct ofp_flow_removed {
590c590
< OFP_ASSERT(sizeof(struct ofp_flow_expired) == 80);
---
> OFP_ASSERT(sizeof(struct ofp_flow_removed) == 80);
Hope this helps ever soo slightly :)
Martin Casado wrote:
This may be a bug with the build system, I don't see the
/opt/openflow/ include path being appended to the compile line.
Could you try adding the openflow include directory to the AM_CPPFLAGS
in src/Make.vars and see if that works?
thanks!
.martin
Hello,
I have been trying to compile nox against the latest release of
openflow (wire protocol 0x98), unfortunately this has failed (see
below for compilation trail). Is there a fix for this, or should I
just revert to the previous version of openflow.
Configure command: ./configure --with-python=yes
--with-openflow=/opt/openflow
a...@pcepatr39[nox-0.5.0~full~beta]$ make
make all-recursive
make[1]: Entering directory `/opt/nox-0.5.0~full~beta'
Making all in src
make[2]: Entering directory `/opt/nox-0.5.0~full~beta/src'
make all-recursive
make[3]: Entering directory `/opt/nox-0.5.0~full~beta/src'
Making all in include
make[4]: Entering directory `/opt/nox-0.5.0~full~beta/src/include'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/opt/nox-0.5.0~full~beta/src/include'
Making all in lib
make[4]: Entering directory `/opt/nox-0.5.0~full~beta/src/lib'
make all-am
make[5]: Entering directory `/opt/nox-0.5.0~full~beta/src/lib'
/bin/bash ../../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I../.. -DPKGDATADIR=\"/usr/local/share/nox\"
-DPKGLIBDIR=\"/usr/local/bin/lib\"c
g++ -DHAVE_CONFIG_H -I. -I../..
-DPKGDATADIR=\"/usr/local/share/nox\"
-DPKGLIBDIR=\"/usr/local/bin/lib\"
-DPKGLOCALSTATEDIR=\"/usr/local/var/nox\" -DPKGSYSo
In file included from openflow-event.cc:43:
../../src/include/flow-expired.hh:43: error: expected ‘,’ or ‘...’
before ‘*’ token
../../src/include/flow-expired.hh:44: error: ISO C++ forbids
declaration of ‘ofp_flow_expired’ with no type
../../src/include/flow-expired.hh:58: error: ISO C++ forbids
declaration of ‘ofp_flow_expired’ with no type
../../src/include/flow-expired.hh:58: error: expected ‘;’ before ‘*’
token
../../src/include/flow-expired.hh:62: error: expected `;' before
‘static’
../../src/include/flow-expired.hh: In member function ‘virtual const
ofp_match* vigil::Flow_expired_event::get_flow() const’:
../../src/include/flow-expired.hh:55: error: ‘get_flow_expired’ was
not declared in this scope
../../src/include/flow-expired.hh: At global scope:
../../src/include/flow-expired.hh:69: error: expected ‘,’ or ‘...’
before ‘*’ token
../../src/include/flow-expired.hh:70: error: ISO C++ forbids
declaration of ‘ofp_flow_expired’ with no type
../../src/include/flow-expired.hh: In constructor
‘vigil::Flow_expired_event::Flow_expired_event(vigil::datapathid, int)’:
../../src/include/flow-expired.hh:71: error: ‘ofe’ was not declared
in this scope
openflow-event.cc: At global scope:
openflow-event.cc:68: error: expected ‘,’ or ‘...’ before ‘*’ token
openflow-event.cc:68: error: ISO C++ forbids declaration of
‘ofp_flow_expired’ with no type
openflow-event.cc: In function
‘vigil::Event*::handle_flow_expired(vigil::datapathid, int)’:
openflow-event.cc:72: error: ‘ofe’ was not declared in this scope
openflow-event.cc:72: error: ‘buf’ was not declared in this scope
openflow-event.cc: In function ‘vigil::Event*
vigil::openflow_packet_to_event(vigil::datapathid,
std::auto_ptr)’:
openflow-event.cc:277: error: ‘OFPT_FLOW_EXPIRED’ was not declared in
this scope
openflow-event.cc:278: error: no matching function for call to
‘handle_packet(vigil::Event* (&)(vigil::datapathid, int),
vigil::datapathid&, const ofp_hea
Re: [nox-dev] openflow wire protocol 0x98
Hi,
Thanks for your quick answer, Martin. Turns out that was part of the
error, but I started investigating deeper and I found that in the
includes from openflow, the struct ofp_flow_expired had been renamed to
ofp_flow_removed. Below is t he diff between the two files.
114c114
< OFPT_FLOW_EXPIRED, /* Async message */
---
> OFPT_FLOW_REMOVED,/* Async message */
569c569
< enum ofp_flow_expired_reason {
---
> enum ofp_flow_removed_reason {
576c576
< struct ofp_flow_expired {
---
> struct ofp_flow_removed {
590c590
< OFP_ASSERT(sizeof(struct ofp_flow_expired) == 80);
---
> OFP_ASSERT(sizeof(struct ofp_flow_removed) == 80);
Hope this helps ever soo slightly :)
Martin Casado wrote:
This may be a bug with the build system, I don't see the /opt/openflow/
include path being appended to the compile line.Could you try adding
the openflow include directory to the AM_CPPFLAGS in src/Make.vars and
see if that works?
thanks!
.martin
Hello,
I have been trying to compile nox against the latest release of
openflow (wire protocol 0x98), unfortunately this has failed (see
below for compilation trail). Is there a fix for this, or should I
just revert to the previous version of openflow.
Configure command: ./configure --with-python=yes
--with-openflow=/opt/openflow
a...@pcepatr39[nox-0.5.0~full~beta]$ make
make all-recursive
make[1]: Entering directory `/opt/nox-0.5.0~full~beta'
Making all in src
make[2]: Entering directory `/opt/nox-0.5.0~full~beta/src'
make all-recursive
make[3]: Entering directory `/opt/nox-0.5.0~full~beta/src'
Making all in include
make[4]: Entering directory `/opt/nox-0.5.0~full~beta/src/include'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/opt/nox-0.5.0~full~beta/src/include'
Making all in lib
make[4]: Entering directory `/opt/nox-0.5.0~full~beta/src/lib'
make all-am
make[5]: Entering directory `/opt/nox-0.5.0~full~beta/src/lib'
/bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../.. -DPKGDATADIR=\"/usr/local/share/nox\"
-DPKGLIBDIR=\"/usr/local/bin/lib\"c
g++ -DHAVE_CONFIG_H -I. -I../.. -DPKGDATADIR=\"/usr/local/share/nox\"
-DPKGLIBDIR=\"/usr/local/bin/lib\"
-DPKGLOCALSTATEDIR=\"/usr/local/var/nox\" -DPKGSYSo
In file included from openflow-event.cc:43:
../../src/include/flow-expired.hh:43: error: expected ‘,’ or ‘...’
before ‘*’ token
../../src/include/flow-expired.hh:44: error: ISO C++ forbids
declaration of ‘ofp_flow_expired’ with no type
../../src/include/flow-expired.hh:58: error: ISO C++ forbids
declaration of ‘ofp_flow_expired’ with no type
../../src/include/flow-expired.hh:58: error: expected ‘;’ before ‘*’
token
../../src/include/flow-expired.hh:62: error: expected `;' before ‘static’
../../src/include/flow-expired.hh: In member function ‘virtual const
ofp_match* vigil::Flow_expired_event::get_flow() const’:
../../src/include/flow-expired.hh:55: error: ‘get_flow_expired’ was
not declared in this scope
../../src/include/flow-expired.hh: At global scope:
../../src/include/flow-expired.hh:69: error: expected ‘,’ or ‘...’
before ‘*’ token
../../src/include/flow-expired.hh:70: error: ISO C++ forbids
declaration of ‘ofp_flow_expired’ with no type
../../src/include/flow-expired.hh: In constructor
‘vigil::Flow_expired_event::Flow_expired_event(vigil::datapathid, int)’:
../../src/include/flow-expired.hh:71: error: ‘ofe’ was not declared in
this scope
openflow-event.cc: At global scope:
openflow-event.cc:68: error: expected ‘,’ or ‘...’ before ‘*’ token
openflow-event.cc:68: error: ISO C++ forbids declaration of
‘ofp_flow_expired’ with no type
openflow-event.cc: In function
‘vigil::Event*::handle_flow_expired(vigil::datapathid, int)’:
openflow-event.cc:72: error: ‘ofe’ was not declared in this scope
openflow-event.cc:72: error: ‘buf’ was not declared in this scope
openflow-event.cc: In function ‘vigil::Event*
vigil::openflow_packet_to_event(vigil::datapathid,
std::auto_ptr)’:
openflow-event.cc:277: error: ‘OFPT_FLOW_EXPIRED’ was not declared in
this scope
openflow-event.cc:278: error: no matching function for call to
‘handle_packet(vigil::Event* (&)(vigil::datapathid, int),
vigil::datapathid&, const ofp_heade’
make[5]: *** [openflow-event.lo] Error 1
make[5]: Leaving directory `/opt/nox-0.5.0~full~beta/src/lib'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/opt/nox-0.5.0~full~beta/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/opt/nox-0.5.0~full~beta/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/opt/nox-0.5.0~full~beta/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/nox-0.5.0~full~beta'
make: *** [all] Error 2
18:45:59 a...@pcepatr39[nox-0.5.0~full~beta]$ ls
Thanks for your help,
--
Ali Al-Shabibi
Doctora
[nox-dev] openflow wire protocol 0x98
Hello, I have been trying to compile nox against the latest release of openflow (wire protocol 0x98), unfortunately this has failed (see below for compilation trail). Is there a fix for this, or should I just revert to the previous version of openflow. Configure command: ./configure --with-python=yes --with-openflow=/opt/openflow a...@pcepatr39[nox-0.5.0~full~beta]$ make make all-recursive make[1]: Entering directory `/opt/nox-0.5.0~full~beta' Making all in src make[2]: Entering directory `/opt/nox-0.5.0~full~beta/src' make all-recursive make[3]: Entering directory `/opt/nox-0.5.0~full~beta/src' Making all in include make[4]: Entering directory `/opt/nox-0.5.0~full~beta/src/include' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/opt/nox-0.5.0~full~beta/src/include' Making all in lib make[4]: Entering directory `/opt/nox-0.5.0~full~beta/src/lib' make all-am make[5]: Entering directory `/opt/nox-0.5.0~full~beta/src/lib' /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -DPKGDATADIR=\"/usr/local/share/nox\" -DPKGLIBDIR=\"/usr/local/bin/lib\"c g++ -DHAVE_CONFIG_H -I. -I../.. -DPKGDATADIR=\"/usr/local/share/nox\" -DPKGLIBDIR=\"/usr/local/bin/lib\" -DPKGLOCALSTATEDIR=\"/usr/local/var/nox\" -DPKGSYSo In file included from openflow-event.cc:43: ../../src/include/flow-expired.hh:43: error: expected ‘,’ or ‘...’ before ‘*’ token ../../src/include/flow-expired.hh:44: error: ISO C++ forbids declaration of ‘ofp_flow_expired’ with no type ../../src/include/flow-expired.hh:58: error: ISO C++ forbids declaration of ‘ofp_flow_expired’ with no type ../../src/include/flow-expired.hh:58: error: expected ‘;’ before ‘*’ token ../../src/include/flow-expired.hh:62: error: expected `;' before ‘static’ ../../src/include/flow-expired.hh: In member function ‘virtual const ofp_match* vigil::Flow_expired_event::get_flow() const’: ../../src/include/flow-expired.hh:55: error: ‘get_flow_expired’ was not declared in this scope ../../src/include/flow-expired.hh: At global scope: ../../src/include/flow-expired.hh:69: error: expected ‘,’ or ‘...’ before ‘*’ token ../../src/include/flow-expired.hh:70: error: ISO C++ forbids declaration of ‘ofp_flow_expired’ with no type ../../src/include/flow-expired.hh: In constructor ‘vigil::Flow_expired_event::Flow_expired_event(vigil::datapathid, int)’: ../../src/include/flow-expired.hh:71: error: ‘ofe’ was not declared in this scope openflow-event.cc: At global scope: openflow-event.cc:68: error: expected ‘,’ or ‘...’ before ‘*’ token openflow-event.cc:68: error: ISO C++ forbids declaration of ‘ofp_flow_expired’ with no type openflow-event.cc: In function ‘vigil::Event*::handle_flow_expired(vigil::datapathid, int)’: openflow-event.cc:72: error: ‘ofe’ was not declared in this scope openflow-event.cc:72: error: ‘buf’ was not declared in this scope openflow-event.cc: In function ‘vigil::Event* vigil::openflow_packet_to_event(vigil::datapathid, std::auto_ptr)’: openflow-event.cc:277: error: ‘OFPT_FLOW_EXPIRED’ was not declared in this scope openflow-event.cc:278: error: no matching function for call to ‘handle_packet(vigil::Event* (&)(vigil::datapathid, int), vigil::datapathid&, const ofp_heade’ make[5]: *** [openflow-event.lo] Error 1 make[5]: Leaving directory `/opt/nox-0.5.0~full~beta/src/lib' make[4]: *** [all] Error 2 make[4]: Leaving directory `/opt/nox-0.5.0~full~beta/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/nox-0.5.0~full~beta/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/nox-0.5.0~full~beta/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/nox-0.5.0~full~beta' make: *** [all] Error 2 18:45:59 a...@pcepatr39[nox-0.5.0~full~beta]$ ls Thanks for your help, -- 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
