[nox-dev] What is the possible cause of error: type=3, code=3 and type=3, code=1
Hi When setting up a flow entry (I am using mininet and NOX from HOTI tutorial), it says: 00065|openflow-event|ERR:received Openflow error packet from dpid=000c: type=3, code=1, 80 bytes of data 00324|openflow-event|ERR:received Openflow error packet from dpid=0013: type=3, code=3, 80 bytes of data 00325|openflow-event|ERR:received Openflow error packet from dpid=000c: type=3, code=3, 80 bytes of data 00326|openflow-event|ERR:received Openflow error packet from dpid=000e: type=3, code=3, 88 bytes of data I am very confused. I never set CHECK_OVERLAP flag. Also, when will a flow entry become emergency? I didnt set it. Will it be set when a previous flow_mod fail? Is there any general/common reason for these two errors? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] How can I resolve: make[9]: *** No rule to make target `meta.json', needed by `all-am'. Stop.
The problem is solved. I named the file as meta.jason. That was the problem. Thank you Kyriakos. On Sun, Sep 19, 2010 at 11:26 PM, Guanyao Huang wrote: > Hello > > Sorry to bother others. I am using the latest NOX module from: > > http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/ProductionSetup/NOXDestinyTransition > > I met a problem when compiling spanning_tree module. I guess it is a common > problem. I changed configure.ac.in and nox.json. I also changed the > meta.json file in the spanning_tree directory. I run ./boot.sh and > ./configure. However, make is not successful. It shows: > > Making all in spanning_tree > make[8]: Entering directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make all-am > make[9]: Entering directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make[9]: *** No rule to make target `meta.json', needed by `all-am'. Stop. > make[9]: Leaving directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make[8]: *** [all] Error 2 > make[8]: Leaving directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make[7]: *** [all-recursive] Error 1 > make[7]: Leaving directory `/home/mininet/nox/src/nox/netapps' > make[6]: *** [all] Error 2 > make[6]: Leaving directory `/home/mininet/nox/src/nox/netapps' > make[5]: *** [all-recursive] Error 1 > make[5]: Leaving directory `/home/mininet/nox/src/nox' > make[4]: *** [all] Error 2 > make[4]: Leaving directory `/home/mininet/nox/src/nox' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/mininet/nox/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/mininet/nox/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mininet/nox' > make: *** [all] Error 2 > > Did I miss something? Thank you. > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] How can I resolve: make[9]: *** No rule to make target `meta.json', needed by `all-am'. Stop.
The link for spanning_tree module: http://www.mail-archive.com/nox-dev@noxrepo.org/msg00167.html http://www.openflowswitch.org/wk/index.php/Basic_Spanning_Tree I plan to use spanning_tree so that routing module can be used for a network of loops. Thanks. On Sun, Sep 19, 2010 at 11:26 PM, Guanyao Huang wrote: > Hello > > Sorry to bother others. I am using the latest NOX module from: > > http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/ProductionSetup/NOXDestinyTransition > > I met a problem when compiling spanning_tree module. I guess it is a common > problem. I changed configure.ac.in and nox.json. I also changed the > meta.json file in the spanning_tree directory. I run ./boot.sh and > ./configure. However, make is not successful. It shows: > > Making all in spanning_tree > make[8]: Entering directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make all-am > make[9]: Entering directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make[9]: *** No rule to make target `meta.json', needed by `all-am'. Stop. > make[9]: Leaving directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make[8]: *** [all] Error 2 > make[8]: Leaving directory > `/home/mininet/nox/src/nox/netapps/spanning_tree' > make[7]: *** [all-recursive] Error 1 > make[7]: Leaving directory `/home/mininet/nox/src/nox/netapps' > make[6]: *** [all] Error 2 > make[6]: Leaving directory `/home/mininet/nox/src/nox/netapps' > make[5]: *** [all-recursive] Error 1 > make[5]: Leaving directory `/home/mininet/nox/src/nox' > make[4]: *** [all] Error 2 > make[4]: Leaving directory `/home/mininet/nox/src/nox' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/mininet/nox/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/mininet/nox/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mininet/nox' > make: *** [all] Error 2 > > Did I miss something? Thank you. > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] How can I resolve: make[9]: *** No rule to make target `meta.json', needed by `all-am'. Stop.
Hello Sorry to bother others. I am using the latest NOX module from: http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/ProductionSetup/NOXDestinyTransition I met a problem when compiling spanning_tree module. I guess it is a common problem. I changed configure.ac.in and nox.json. I also changed the meta.json file in the spanning_tree directory. I run ./boot.sh and ./configure. However, make is not successful. It shows: Making all in spanning_tree make[8]: Entering directory `/home/mininet/nox/src/nox/netapps/spanning_tree' make all-am make[9]: Entering directory `/home/mininet/nox/src/nox/netapps/spanning_tree' make[9]: *** No rule to make target `meta.json', needed by `all-am'. Stop. make[9]: Leaving directory `/home/mininet/nox/src/nox/netapps/spanning_tree' make[8]: *** [all] Error 2 make[8]: Leaving directory `/home/mininet/nox/src/nox/netapps/spanning_tree' make[7]: *** [all-recursive] Error 1 make[7]: Leaving directory `/home/mininet/nox/src/nox/netapps' make[6]: *** [all] Error 2 make[6]: Leaving directory `/home/mininet/nox/src/nox/netapps' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/mininet/nox/src/nox' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/mininet/nox/src/nox' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/mininet/nox/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/mininet/nox/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mininet/nox' make: *** [all] Error 2 Did I miss something? Thank you. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] How can I introduce new NOX module
Right xxx is abbreviation. It is not there in src directory. I am using the NOX module from http://openflow.org/wk/index.php/GEC8Tutorial, to test and run on virtual machine. If I recover by "git clone git://noxrepo.org/nox", will there be any version conflict? Thanks. On Wed, Sep 15, 2010 at 11:33 AM, kk yap wrote: > Hi Guanyao, > > You are suppose to have Make.vars in the src directory. Is it there? > I am curious how xxx/Make.vars got there. > > Regards > KK > > On 15 September 2010 11:24, Guanyao Huang wrote: > > You are right. I forgot to rerun boot.sh and configure. > > But it is not successful. It says: > > automake: can not open < /Make.vars: no such file or directory > > autoreconf: automake failed with exit status: 1 > > > > On Wed, Sep 15, 2010 at 11:10 AM, Martin Casado > wrote: > >> > >> Did you rerun boot.sh? > >> > >> Hello > >> Sorry to bother others. > >> http://noxrepo.org/wp/ seems outdated. > >> > >> I have a new module and I want to compile it. I remember the only files > I > >> need to change are: configure.ac.in, nox.xml and meta.xml inside my > module > >> folder. However, it is not working. When make, it ignores my module. It > >> never gets compiled. > >> > >> Did I miss anything? > >> > >> Thank you. > >> > >> ___ > >> nox-dev mailing list > >> nox-dev@noxrepo.org > >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > >> > > > > > > ___ > > nox-dev mailing list > > nox-dev@noxrepo.org > > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > > > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] How can I introduce new NOX module
You are right. I forgot to rerun boot.sh and configure. But it is not successful. It says: automake: can not open < /Make.vars: no such file or directory autoreconf: automake failed with exit status: 1 On Wed, Sep 15, 2010 at 11:10 AM, Martin Casado wrote: > Did you rerun boot.sh? > > Hello > Sorry to bother others. > http://noxrepo.org/wp/ seems outdated. > > I have a new module and I want to compile it. I remember the only files I > need to change are: configure.ac.in, nox.xml and meta.xml inside my module > folder. However, it is not working. When make, it ignores my module. It > never gets compiled. > > Did I miss anything? > > Thank you. > > > ___ > nox-dev mailing > listnox-...@noxrepo.orghttp://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] How can I introduce new NOX module
Hello Sorry to bother others. http://noxrepo.org/wp/ seems outdated. I have a new module and I want to compile it. I remember the only files I need to change are: configure.ac.in, nox.xml and meta.xml inside my module folder. However, it is not working. When make, it ignores my module. It never gets compiled. Did I miss anything? Thank you. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] I met a basic problem when testing virtual environment
Hello Sorry to bother others. I am testing my software openflow according to http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/Virtual I also run ./nox_core -i ptcp:6633 routing After run vms-start.py -u 2hosts-2ofsw.vms.xml, 4 windows pop up for 2 hosts and 2 switches. Everything seems OK. However, on the controller window, it keeps saying: |nox|WARN:stream: closing connection due to timeout after 5 seconds in receiving features reply state The virtual hosts fail to ping each other. Do you have any idea what does that message mean? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Cant run virtual machine for the simple example in the tutorial
It works. Thank you. On Tue, Jun 8, 2010 at 1:09 PM, kk yap wrote: > As mentioned, the list is ordered. So, I swapped ip and xterm in the > host definition, and it works now. Attached is the updated file. > > Regards > KK > > On 8 June 2010 13:02, Guanyao Huang wrote: >> Here is my script. Thank you. >> >> On Tue, Jun 8, 2010 at 12:32 PM, kk yap wrote: >>> Hi, >>> >>> The actual declaration is ordered in xml. xterm should work. Do send >>> me your " 2hosts-2ofsw.vms.xml". >>> >>> Regards >>> KK >>> >>> On 8 June 2010 12:10, Guanyao Huang wrote: >>>> Hi, this is the error: >>>> >>>> gyhu...@leo:~/OpenFlowExample$ xmlstarlet val -e -s >>>> ../openflowvms/xsd/vms.xsd 2hosts-2ofsw.vms.xml >>>> 2hosts-2ofsw.vms.xml:14: element xterm: Schemas validity error : >>>> Element 'xterm': This element is not expected. Expected is ( screenrc >>>> ). >>>> 2hosts-2ofsw.vms.xml:18: element xterm: Schemas validity error : >>>> Element 'xterm': This element is not expected. Expected is ( screenrc >>>> ). >>>> 2hosts-2ofsw.vms.xml - invalid >>>> >>>> So, I changed to screenrc. Sorry I am not familiar with this. >>>> >>>> On Tue, Jun 8, 2010 at 12:00 PM, Kyriakos Zarifis >>>> wrote: >>>>> Hi, >>>>> >>>>>> >>>>>> My script for the 2-host-2-switch case is the same as in the link >>>>>> above, but I changed the tag to tag as suggested by >>>>>> the xmlstarlet command. >>>>> >>>>> I'm not sure about this, maybe it's a recent change, but last time I tried >>>>> it worked for me. Did you try that? >>>> >>>> ___ >>>> 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] Cant run virtual machine for the simple example in the tutorial
Here is my script. Thank you. On Tue, Jun 8, 2010 at 12:32 PM, kk yap wrote: > Hi, > > The actual declaration is ordered in xml. xterm should work. Do send > me your " 2hosts-2ofsw.vms.xml". > > Regards > KK > > On 8 June 2010 12:10, Guanyao Huang wrote: >> Hi, this is the error: >> >> gyhu...@leo:~/OpenFlowExample$ xmlstarlet val -e -s >> ../openflowvms/xsd/vms.xsd 2hosts-2ofsw.vms.xml >> 2hosts-2ofsw.vms.xml:14: element xterm: Schemas validity error : >> Element 'xterm': This element is not expected. Expected is ( screenrc >> ). >> 2hosts-2ofsw.vms.xml:18: element xterm: Schemas validity error : >> Element 'xterm': This element is not expected. Expected is ( screenrc >> ). >> 2hosts-2ofsw.vms.xml - invalid >> >> So, I changed to screenrc. Sorry I am not familiar with this. >> >> On Tue, Jun 8, 2010 at 12:00 PM, Kyriakos Zarifis >> wrote: >>> Hi, >>> >>>> >>>> My script for the 2-host-2-switch case is the same as in the link >>>> above, but I changed the tag to tag as suggested by >>>> the xmlstarlet command. >>> >>> I'm not sure about this, maybe it's a recent change, but last time I tried >>> it worked for me. Did you try that? >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> > 48 true true 192.168.100.1 true 192.168.100.2 true ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Cant run virtual machine for the simple example in the tutorial
Hi, this is the error: gyhu...@leo:~/OpenFlowExample$ xmlstarlet val -e -s ../openflowvms/xsd/vms.xsd 2hosts-2ofsw.vms.xml 2hosts-2ofsw.vms.xml:14: element xterm: Schemas validity error : Element 'xterm': This element is not expected. Expected is ( screenrc ). 2hosts-2ofsw.vms.xml:18: element xterm: Schemas validity error : Element 'xterm': This element is not expected. Expected is ( screenrc ). 2hosts-2ofsw.vms.xml - invalid So, I changed to screenrc. Sorry I am not familiar with this. On Tue, Jun 8, 2010 at 12:00 PM, Kyriakos Zarifis wrote: > Hi, > >> >> My script for the 2-host-2-switch case is the same as in the link >> above, but I changed the tag to tag as suggested by >> the xmlstarlet command. > > I'm not sure about this, maybe it's a recent change, but last time I tried > it worked for me. Did you try that? ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Cant run virtual machine for the simple example in the tutorial
Hi Sorry to bother others. I am playing with software openflow following tutorial: http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/Virtual I assume that I will see five virtual screen for the example of 2-host-2-switch. But, screen -ls shows there is only one called ofswslirp. Others are not successful. If I directly vms-start the script for 2-host-1-switch, then: gyhu...@leo:~/OpenFlowExample$ screen -ls There are screens on: 23903.host2 (06/08/2010 10:58:53 AM)(Detached) 23899.host1 (06/08/2010 10:58:53 AM)(Detached) 23892.of1 (06/08/2010 10:58:52 AM)(Detached) 23888.ofswslirp (06/08/2010 10:58:52 AM)(Detached) 4 Sockets in /var/run/screen/S-gyhuang. This is correct. My script for the 2-host-2-switch case is the same as in the link above, but I changed the tag to tag as suggested by the xmlstarlet command. Any comments on why I can not get virtual screen for the 2-host-2-switch case? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Some problem with nox compiling, err or: forward declaration of ‘struct vigil: :Kernel’
Sorry. I dont quite understand. I am already compiling under ./nox/build. build is a new directory. It is not source tree, right? I am following instructions from the webpage. First I mkdir build, then I go into it, ../configure, and then I make in it. On Mon, May 24, 2010 at 8:16 AM, Martin Casado wrote: > Yeah, this seems to happen when you compile in the source tree. Try using a > remote build tree from a clean source tree and see if that works. > >> Hi, >> Sorry to bother others. I am compiling OpenFlow v1.0. compatible NOX, >> following steps on: >> >> http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/LabSetup#4_Controller_Setup >> I never met following errors before but now they pop up. It seems >> everything is clean. I just download, configure, and make it. I didnt >> modify anything. >> >> ../../../../../src/nox/netapps/authenticator/authenticator_event.cc: >> In member function ‘vigil::Disposition >> vigil::applications::Authenticator::handle_bootstrap(const >> vigil::Event&)’: >> ../../../../../src/nox/netapps/authenticator/authenticator_event.cc:40: >> error: invalid use of incomplete type ‘struct vigil::Kernel’ >> ../../../../../src/nox/component.hh:49: error: forward declaration of >> ‘struct vigil::Kernel’ >> ../../../../../src/nox/netapps/authenticator/authenticator_event.cc:40: >> error: ‘INSTALLED’ was not declared in this scope >> ../../../../../src/nox/netapps/authenticator/authenticator_event.cc:41: >> error: invalid use of incomplete type ‘struct vigil::Kernel’ >> ../../../../../src/nox/component.hh:49: error: forward declaration of >> ‘struct vigil::Kernel’ >> make[9]: *** [authenticator_la-authenticator_event.lo] Error 1 >> >> I saw someone else encountered this error in this email list, but he >> got no reply. >> >> Thanks. >> >> ___ >> 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] Some problem with nox compiling, err or: forward declaration of ‘struct vigil: :Kernel’
Hi, Sorry to bother others. I am compiling OpenFlow v1.0. compatible NOX, following steps on: http://www.openflowswitch.org/foswiki/bin/view/OpenFlow/Deployment/HOWTO/LabSetup#4_Controller_Setup I never met following errors before but now they pop up. It seems everything is clean. I just download, configure, and make it. I didnt modify anything. ../../../../../src/nox/netapps/authenticator/authenticator_event.cc: In member function ‘vigil::Disposition vigil::applications::Authenticator::handle_bootstrap(const vigil::Event&)’: ../../../../../src/nox/netapps/authenticator/authenticator_event.cc:40: error: invalid use of incomplete type ‘struct vigil::Kernel’ ../../../../../src/nox/component.hh:49: error: forward declaration of ‘struct vigil::Kernel’ ../../../../../src/nox/netapps/authenticator/authenticator_event.cc:40: error: ‘INSTALLED’ was not declared in this scope ../../../../../src/nox/netapps/authenticator/authenticator_event.cc:41: error: invalid use of incomplete type ‘struct vigil::Kernel’ ../../../../../src/nox/component.hh:49: error: forward declaration of ‘struct vigil::Kernel’ make[9]: *** [authenticator_la-authenticator_event.lo] Error 1 I saw someone else encountered this error in this email list, but he got no reply. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] is this a known bug in storage module
Hi Sorry to bother others. My program has serious problem. Here is the dump under gdb. I am wondering has anyone seen something similar before. Maybe this is known bug? Any suggestion would be helpful. *** glibc detected *** /home/sraza/noxcore/build/src/.libs/lt-nox_core: malloc(): memory corruption: 0x7f3010a27a00 *** === Backtrace: = /lib64/libc.so.6[0x36f947b5df] /lib64/libc.so.6(__libc_malloc+0x98)[0x36f947ce18] /usr/lib64/libstdc++.so.6(_Znwm+0x1d)[0x37078c41bd] nox/netapps/storage/storage-common.so(_ZNSt3tr110_HashtableISsSt4pairIKSsN5boost7variantIlSsdN5vigil12applications7storage4GUIDENS3_6detail7variant5void_ESB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_EEESaISD_ESt10_Select1stISD_ESt8equal_toISsENS_4hashISsEENS_8__detail18_Mod_range_hashingENSL_20_Default_ranged_hashENSL_20_Prime_rehash_policyELb0ELb0ELb1EE19_M_allocate_bucketsEm+0x33)[0x7f3007a050f3] nox/netapps/storage/storage-common.so(_ZNSt3tr110_HashtableISsSt4pairIKSsN5boost7variantIlSsdN5vigil12applications7storage4GUIDENS3_6detail7variant5void_ESB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_EEESaISD_ESt10_Select1stISD_ESt8equal_toISsENS_4hashISsEENS_8__detail18_Mod_range_hashingENSL_20_Default_ranged_hashENSL_20_Prime_rehash_policyELb0ELb0ELb1EEC2ERKSP_+0x40)[0x7f3007a055a0] nox/netapps/storage/storage-backend.so(_ZN5boost4bindINS_8functionIFvRKN5vigil12applications7storage6ResultERKNS4_7ContextERKNS2_8hash_mapISsNS_7variantIlSsdNS4_4GUIDENS_6detail7variant5void_ESG_SG_SG_SG_SG_SG_SG_SG_SG_SG_SG_SG_SG_SG_SG_EENSt3tr14hashISsEESt8equal_toISsESaISt4pairIKSsSH_EEENS_3argILi1EEES8_SR_EENS_3_bi6bind_tINSY_11unspecifiedET_NSY_9list_av_3IT0_T1_T2_E4typeEEES11_S13_S14_S15_+0x13d)[0x7f30073d0c8d] nox/netapps/storage/storage-backend.so(_ZN5vigil12applications7storage17Async_DHT_storage3getERKSsRKNS_8hash_mapISsN5boost7variantIlSsdNS1_4GUIDENS6_6detail7variant5void_ESB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_EENSt3tr14hashISsEESt8equal_toISsESaISt4pairIS3_SC_RKNS6_8functionIFvRKNS1_6ResultERKNS1_7ContextESN_EEE+0x194)[0x7f30073c2ff4] nox/netapps/bindings_storage/.libs/bindings_storage.so(_ZN5vigil12applications16Bindings_Storage17run_get_links_fsmERKN5boost10shared_ptrINS0_12Get_Links_OpEEENS0_13GetLinksStateE+0xf7)[0x7f3006ac2b57] nox/netapps/bindings_storage/.libs/bindings_storage.so(_ZN5vigil12applications16Bindings_Storage13get_all_linksERKN5boost8functionIFvRNSt7__debug4listINS0_4LinkESaIS6_EE+0xc8)[0x7f3006ac3b08] ./nox/netapps/bindings_storage/_pybindings_storage.so(_ZN5vigil12applications22Bindings_Storage_Proxy18get_links_dispatchEN5boost8functionIFvRNS3_IFvRNSt7__debug4listINS0_4LinkESaIS6_EP7_object+0x393)[0x7f3006854263] ./nox/netapps/bindings_storage/_pybindings_storage.so(_ZN5vigil12applications22Bindings_Storage_Proxy13get_all_linksEP7_object+0x44)[0x7f30068547b4] ./nox/netapps/bindings_storage/_pybindings_storage.so[0x7f3006863e14] /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13)[0x371143d173] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x4117)[0x37114bcca7] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x70d)[0x37114bfa7d] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x58cc)[0x37114be45c] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x6356)[0x37114beee6] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x70d)[0x37114bfa7d] /usr/lib64/libpython2.5.so.1.0[0x371145b9c7] /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13)[0x371143d173] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x4117)[0x37114bcca7] /usr/lib64/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x70d)[0x37114bfa7d] /usr/lib64/libpython2.5.so.1.0[0x371145ba32] /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13)[0x371143d173] /usr/lib64/libpython2.5.so.1.0[0x37114443b0] /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13)[0x371143d173] /usr/lib64/libpython2.5.so.1.0[0x3711444ffb] /usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13)[0x371143d173] /usr/lib64/libpython2.5.so.1.0(PyEval_CallObjectWithKeywords+0x71)[0x37114b7fc1] nox/coreapps/pyrt/pyrt.so(_ZN5vigil20call_python_functionIN5boost13intrusive_ptrI7_objectvS4_T_+0x2b)[0x7f301508517b] ./nox/coreapps/pyrt/_oxidereactor.so(_ZN5boost6detail8function26void_function_obj_invoker0INS_3_bi6bind_tIvPFvNS_13intrusive_ptrI7_objectEES7_ENS3_5list2INS3_5valueIS7_EESC_vE6invokeERNS1_15function_bufferE+0x49)[0x7f300928cd99] /home/sraza/noxcore/build/src/builtin/.libs/libbuiltin.so.0(_ZNK5boost9function0IvEclEv+0x2e)[0x7f3015df921e] /home/sraza/noxcore/build/src/lib/.libs/libnoxcore.so.0(_ZN5vigil16Timer_dispatcher4pollEv+0x4fa)[0x7f3015b5573a] /home/sraza/noxcore/build/src/lib/.libs/libnoxcore.so.0[0x7f3015b3501f] /home/sraza/noxcore/build/src/lib/.libs/libnoxcore.so.0[0x7f3015b356d4] /home/sraza/noxcore/build/src/lib/.libs/libnoxcore.so.0(_ZN5vigil14Poll_loop_impl3runEv+0xc8)[0x7f3015b35f48] /home/sraza/noxcore/build/src/.libs/lt-nox_core(main+0x1f73)[0x4111f3] /lib64/libc.so.6(__libc_start_main+0xfa)[0x36f941e32a] /home/sraza/noxcore/build/src/.libs/lt-nox_core(_ZNSt8ios_base
[nox-dev] Fail to receive flow-expire message occasionally.
Hi Sorry to bother others. I have a general question about flow-expire message. I want to know if there is any situation that a switch doesnt send flow-expire message even a flow expires, or, is there any chance the controller receives flow-expire message but drops it because it is out of buffer? Also I have questions about the first packet of a flow. My NOX controller fails to receive flow expire message from some flows of some switch. I havent checked the tcpdump files yet, because the traffic volume is not small. The module maintains every new flow and delete it once it expire. But it turns out that some flows continue being remained after there is no traffic. My NOX periodically queries flow size of all the flows maintained. I find out that all the left flows in the NOX have size 1, this shows that their sizes are not updated since they have arrived. *I want to know whether the first packet will update the counter in the first switch after this packet is sent back from controller? From document this packet is sent to the outport directly, but it turns out that it will still update the counter, at least I see this is the case for many flows. But, if the packet is received (from controller) by the first switch before the rule is established, what will happen? I guess in this case the counter is still 0. * *If a counter is 0, will the flow-expire message be sent back to the controller? * Any suggestions will be helpful. Thank you. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Need to the error type of send_openflow_command()
Hi
Thank you for your reply.
I actually avoided the problem by using some other codes, but I still
donot understand what was going on behind it. I checked the code but
feel stuck at some points. I mean, since send_openflow_command is
commonly used, maybe it is better to specifically document possible
errors.
Do you mean to check the datapath_leave_event between switch and
controller, which possibly contains reasons why the switch leaves? I
am sure the leaving datapath (f7:ca:e4:00:00:64) is a valid datapath.
Why will it leave if we send some commands to any invalid datapathid?
Thanks.
On Mon, Apr 5, 2010 at 4:12 AM, kk yap wrote:
> Hi Guanyao,,
>
> Did you check for datapath_leave_event and make sure that you do not
> send commands to invalid datapathid? Seems like that is the problem.
>
> Regards
> KK
>
> On 4 April 2010 21:41, Guanyao Huang wrote:
>> Hi
>> Sorry to bother others. My program breaks with datapath leaves the
>> network (HP switch). There are some errors returned by the
>> send_openflow_command, which I dont understand. Is there any document
>> on the meaning of the error?
>>
>>
>> 00079|openflow|WARN:stream: send error: Broken pipe
>> 00080|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
>> f7cae464 : error 32
>> 00081|openflow|WARN:stream: send error: Bad file descriptor
>> 00082|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
>> f7cae464 : error 9
>> 00083|openflow|WARN:stream: send error: Bad file descriptor
>> not successfully opf command: routingMR::send_stats_request()
>> 00084|openflow|WARN:stream: send error: Bad file descriptor
>> not successfully opf command: routingMR::send_stats_request()
>> 00085|openflow|WARN:stream: send error: Bad file descriptor
>> 00086|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
>> f7cae464 : error 9
>> 00087|openflow|WARN:stream: send error: Bad file descriptor
>> 00088|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
>> f7cae464 : error 9
>> 00089|openflow|WARN:stream: send error: Bad file descriptor
>> 00090|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
>> f7cae464 : error 9
>> 00091|openflow|WARN:stream: receive error: Bad file descriptor
>> 00092|nox|WARN:stream: disconnected (Bad file descriptor)
>> Datapath leave, f7:ca:e4:00:00:64
>>
>>
>> In the output above, what are the meaning of error 9 and 32. The
>> source code is simply as:
>>
>> int ofc_ret = send_openflow_command(curr_dpid, &ofm->header, true);
>> if(ofc_ret) {
>> VLOG_ERR(lg, "OpenFlowMR::install_flow: flow-mod command to dpid
>> %s : error %d", curr_dpid.string().c_str(), ofc_ret);
>> }
>>
>> Many thanks.
>>
>> ___
>> 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] Need to the error type of send_openflow_command()
Hi
Sorry to bother others. My program breaks with datapath leaves the
network (HP switch). There are some errors returned by the
send_openflow_command, which I dont understand. Is there any document
on the meaning of the error?
00079|openflow|WARN:stream: send error: Broken pipe
00080|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
f7cae464 : error 32
00081|openflow|WARN:stream: send error: Bad file descriptor
00082|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
f7cae464 : error 9
00083|openflow|WARN:stream: send error: Bad file descriptor
not successfully opf command: routingMR::send_stats_request()
00084|openflow|WARN:stream: send error: Bad file descriptor
not successfully opf command: routingMR::send_stats_request()
00085|openflow|WARN:stream: send error: Bad file descriptor
00086|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
f7cae464 : error 9
00087|openflow|WARN:stream: send error: Bad file descriptor
00088|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
f7cae464 : error 9
00089|openflow|WARN:stream: send error: Bad file descriptor
00090|routingMR|ERR:OpenFlowMR::install_flow: flow-mod command to dpid
f7cae464 : error 9
00091|openflow|WARN:stream: receive error: Bad file descriptor
00092|nox|WARN:stream: disconnected (Bad file descriptor)
Datapath leave, f7:ca:e4:00:00:64
In the output above, what are the meaning of error 9 and 32. The
source code is simply as:
int ofc_ret = send_openflow_command(curr_dpid, &ofm->header, true);
if(ofc_ret) {
VLOG_ERR(lg, "OpenFlowMR::install_flow: flow-mod command to dpid
%s : error %d", curr_dpid.string().c_str(), ofc_ret);
}
Many thanks.
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] What will happen when OFPBAC_BAD_OUT_PORT occurs
Sorry about the misunderstanding. I have solved my problem. I was trying to understand how to use OFPP_IN_PORT. In my program I need to to set one host as DPI box, but this host itself will send packets to the network. So, his packets need to copied and send back through the same port. I wanted to know whether OFPP_IN_PORT can be used as flow modification command to setup a rule such that packets can be sent back. Now I find that it is very simple, just setting ofp_action_output::port to OFPP_IN_PORT is enough. Thank you for your kindly help. On Fri, Mar 26, 2010 at 12:54 PM, Rob Sherwood wrote: > I think you're confusing OFPP_INPORT which is a constant used to send > packets out the port they came in on with ofp_match->in_port which is > the way you would match which port an incoming packet came from. You > would use openflow_send_command() to send a flow_mod message that had > the ofp_match structure set to specify the in_port to match on. > > Does that help? > > > Also, including the list helps archive some of these answers, so is > there a reason you did not include the list? > > - Rob > . > > > > On Fri, Mar 26, 2010 at 9:21 AM, Guanyao Huang wrote: >> Hi, sorry to bother you again. >> When using OFPP_INPORT, can I use it to setup a flow-table rule via >> openflow_send_command, or, I can only use it by openflow_send_packet. >> >> My question is, can one rule in switch use OFPP_INPORT to match >> certain packets to OUTPUT to the inport? >> >> Thanks. >> >> On Thu, Mar 4, 2010 at 3:50 PM, Rob Sherwood >> wrote: >>> The more likely explanation is that you tried to sent to output:$port >>> with where $port == $inport. To prevent loops, OpenFlow makes you >>> explicitly use the action output:OFPP_INPORT if you want to send back >>> out the port a packet came in on. >>> >>> Does that help? >>> >>> - Rob >>> . >>> >>> >>> >>> On Thu, Mar 4, 2010 at 11:24 AM, Guanyao Huang wrote: >>>> Hello >>>> My program shows error of type2 code4. From specification it means >>>> OFPBAC_BAD_OUT_PORT error. >>>> I want to know if one simple case is the possible reason. >>>> Suppose the switch already has one entry for the flow, but now I >>>> OFPFC_ADD a new entry with different port. Will this lead to the error >>>> above? Or, the switch will simply delete the existing entry and insert >>>> the new one. It seems my calculated path will not have a bad port >>>> which leads to nowhere. >>>> Thanks. >>>> >>>> ___ >>>> 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] A question regarding Authenticator module
Sorry. I dont quite follow your reply below. Do you mean I just enable AUTH_WITH_ROUTING then the existing routing module will work? I canot find this AUTH_WITH_ROUTING What do you mean by "which depends on the routing_module library, NOT the sprouting.hh/sprouting.cc component"?? > Finally, in regard to the presence of multiple locations for a given mac > address. We found the need for this in certain topologies where a host was > effectively connected to two distinct openflow ports in the network, > sending/receiving packets on both using the same mac address. If this > doesn't happen in your topologies, and the AUTH_WITH_ROUTING ifdef is > enabled in authenticator.hh (which depends on the routing_module library, > NOT the sprouting.hh/sprouting.cc component) then you should not be seeing > multiple locations, or they should be timing out. > Feel free to resend any questions I missed. > Natasha >> >> On Fri, Mar 12, 2010 at 1:40 PM, Srini Seetharaman >> wrote: >> > Just to add to Guanyao's observations: I wanted to mention that the >> > host having two bindings is something we run across often in our >> > Stanford setup. However, we notice it only when the topology is >> > changed during runtime. >> > >> > Srini. >> > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A question regarding Authenticator module
I think some document of authenticator module is very necessary. The newest version of authenticator module seems changed a lot, but the code for routing module remains the same. For example, why there are many events defined in host_event.hh, why there are many entries, bindings defined in authenticator.hh. Normally, given a mac address, or, IP address, what is the API used to get its datapath? Without such things, I feel easily get lost in the code. I guess many people are developing their own module based on flow_in event. It would be nice if they know how this flow_in event was generated. On Fri, Mar 12, 2010 at 1:40 PM, Srini Seetharaman wrote: > Just to add to Guanyao's observations: I wanted to mention that the > host having two bindings is something we run across often in our > Stanford setup. However, we notice it only when the topology is > changed during runtime. > > Srini. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A question regarding Authenticator module
c. > In the case you describe, both inports get recorded, and based on > information from link discovery, authenticator can tell which inport is most > "accurate" (takes the one most upstream). But again, not sure which version > of nox you're using. > 2. That is not expected behavior and likely just depends on what > information that authenticator/routing modules have discovered so far. > Natasha > On Wed, Mar 3, 2010 at 2:51 PM, Guanyao Huang wrote: >> >> Sorry to bother you again. >> I have two issues regarding both authenticator module and routing >> module. Please look at the code in sprouting.cc, set_route() function. >> >> 1, The inport is from fi.src_location.location->dpport. Can you >> explain the structure of the location variable? How it maintains both >> datapathid and port number? >> >> My actual concern is: >> Sometimes, packets will get broadcasted before a route is calculated. >> When a broadcasted packet hit another switch, the inport also changed. >> I understand route.id.src is the real ingress switch, so, the whole >> procedure is to find a route from the src datapath, not current >> datapath. But sometimes, because of this, it consistently show "Packet >> not on route" and freezes there. I guess this is because the >> controller is always processing at this "Packet not on route" but not >> continue. >> >> 2, Sometimes the egress datapath read from the authenticator module is >> not the closest one to the dst mac. This makes the flow sent to >> different datapath other than the correct one. Is this a known bug or >> is this not important? Our experiment shows this sometimes matters. >> >> Thanks. > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] What will nox do with [Malformed packet]
I think malformed tcp packets are dropped by authenticator module, but udp packets will still generate flow_in event. I run routing and spanning_tree module. I did a simple test to tcpreplay the truncated packets. All of them generated packet_in event, which are captured by the control channel. I added a simple line to sprouting.cc, function set_route(): if(fi.flow.nw_proto==ip_::proto::TCP) VLOG_DBG(lg, "Broadcasting %"PRIx64" %s", fi.datapath_id.as_host(), os.str().c_str()); This let TCP packets be printed out if they are broadcasted (which is true since there is no path for them in my case). Then, I find that no TCP truncated packets printed out. If I delete the if() judgement, this line is printed out. This shows that malformed tcp packets will not generate flow_in event. But truncated ICMP and UDP packets donot have such problem. Thanks. On Thu, Mar 11, 2010 at 1:37 PM, Martin Casado wrote: > I'm not exactly sure what you're doing. If the openflow headers have become > corrupted, then the openflow stack will drop the packets without generating > events. > >> Hi >> Sorry to bother others. >> My program needs to tcpreplay some packets between switches. Since the >> trace is from raw IP, I converted them to ethernet packets. However, >> some of the original packets are truncated, and I found these packets >> are forwarded but missed. >> If I tcpreplay them and tcpdump the interface, I saw these packets >> become [Malformed packet]. My module even didnt capture a flow_in >> event for these packets. >> So, I am wondering, where are these packets actually dropped? Are they >> dropped by IP stack or are they dropped by authenticator module? Our >> control in nox is above or below IP stack?? >> Thanks. >> >> ___ >> 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] What will nox do with [Malformed packet]
Hi Sorry to bother others. My program needs to tcpreplay some packets between switches. Since the trace is from raw IP, I converted them to ethernet packets. However, some of the original packets are truncated, and I found these packets are forwarded but missed. If I tcpreplay them and tcpdump the interface, I saw these packets become [Malformed packet]. My module even didnt capture a flow_in event for these packets. So, I am wondering, where are these packets actually dropped? Are they dropped by IP stack or are they dropped by authenticator module? Our control in nox is above or below IP stack?? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] aggregate flow statistics always return 0
dump-aggregate command means you want to aggregate some field, right? For example suppose there are 4 flows, two of them have the same dst IP. Then, dump-aggregate dst_IP will return 2 flows. Instead, dump-flows is to show all the flows. So, my question was, does dump-aggregate work properly for all the fields? On Tue, Mar 9, 2010 at 5:58 PM, Yu-Chieh Chou wrote: > Sorry, I did not explain very clearly. I use the command "dpctl > dump-aggregate" on OpenFlow switch works correctly. > > But the aggregate value on NOX component monitor always get zero. > > > > 2010/3/10 Guanyao Huang >> >> What do you mean by "dpctl dump-aggregate works correctly". My >> experience is that for some fields it works correctly, for some fields >> not. >> >> On Tue, Mar 9, 2010 at 12:35 AM, Yu-Chieh Chou wrote: >> > Hi all, I also use NOX Virtual Test Environment. >> > >> > And the aggregate value returns from switch is always zero. >> > >> > The dpctl dump-aggregate works correctly. >> > >> > Have someone solve this problem? >> > >> > Thanks. >> > >> > 2010/2/4 Rodrigo Braga >> >> >> >> Hi Guanyao, I have tested dpctl on switch openflow and it show me the >> >> stats about aggregating flows perfectly. >> >> >> >> I used the secchan, dpctl e openflow_mod.ko available in NOX Virtual >> >> Test >> >> Environment setup. >> >> >> >> But the monitor component continue showing all values with zero :( >> >> >> >> >> >> On Tue, Feb 2, 2010 at 11:32 PM, Guanyao Huang >> >> wrote: >> >>> >> >>> I guess it depends on whether dpctl dump-aggregate works correctly. >> >>> My problem with it is that sometimes it can not aggregate flows >> >>> according to the specified wildcard. I guess this depends on >> >>> configuration of switches. >> >>> >> >>> On Tue, Feb 2, 2010 at 5:57 PM, Rodrigo Braga >> >>> wrote: >> >>> > I have the same problem, did someone solve this problem ?? >> >>> > >> >>> > My nox version is 0.8 >> >>> > >> >>> > compiled to openflow 0x97 >> >>> > >> >>> > thanks >> >>> > >> >>> > >> >>> > On Fri, Jan 15, 2010 at 3:36 AM, MinChi Tseng >> >>> > wrote: >> >>> >> >> >>> >> I am using monitor component in NOX. >> >>> >> >> >>> >> >> >>> >> >> >>> >> nox-0.6.0/src/noxcoreapps/examples/monitor.py = >> >>> >> >> >>> >> def aggregate_timer(self, dpid): >> >>> >> >> >>> >> flow = ofp_match() >> >>> >> >> >>> >> flow.wildcards = 0x >> >>> >> >> >>> >> self.ctxt.send_aggregate_stats_request(dpid, flow, 0xff) >> >>> >> >> >>> >> self.post_callback(MONITOR_TABLE_PERIOD, lambda : >> >>> >> self.aggregate_timer(dpid)) >> >>> >> >> >>> >> >> >>> >> >> >>> >> Thanks, >> >>> >> >> >>> >> MinChi >> >>> >> >> >>> >> >> >>> >> >> >>> >> Can you paste the code which is doing the query? >> >>> >> >> >>> >> >> >>> >> >> >>> >> > No, the OF is get via NOX Virtual Test Environment setup >> >>> >> > instruction. >> >>> >> >> >>> >> > http://noxrepo.org/manual/vm_environment.html >> >>> >> >> >>> >> > >> >>> >> >> >>> >> > wget http://noxrepo.org/openflow_mod.ko >> >>> >> >> >>> >> > wget http://noxrepo.org/dpctl >> >>> >> >> >>> >> > wget http://noxrepo.org/secchan >> >>> >> >> >>> >> > >> >>> >> >> >>> >> > >> >>> >> >> >>> >> > MinChi >> >>> >> >> >>> >> > >> >>> &g
Re: [nox-dev] aggregate flow statistics always return 0
What do you mean by "dpctl dump-aggregate works correctly". My experience is that for some fields it works correctly, for some fields not. On Tue, Mar 9, 2010 at 12:35 AM, Yu-Chieh Chou wrote: > Hi all, I also use NOX Virtual Test Environment. > > And the aggregate value returns from switch is always zero. > > The dpctl dump-aggregate works correctly. > > Have someone solve this problem? > > Thanks. > > 2010/2/4 Rodrigo Braga >> >> Hi Guanyao, I have tested dpctl on switch openflow and it show me the >> stats about aggregating flows perfectly. >> >> I used the secchan, dpctl e openflow_mod.ko available in NOX Virtual Test >> Environment setup. >> >> But the monitor component continue showing all values with zero :( >> >> >> On Tue, Feb 2, 2010 at 11:32 PM, Guanyao Huang >> wrote: >>> >>> I guess it depends on whether dpctl dump-aggregate works correctly. >>> My problem with it is that sometimes it can not aggregate flows >>> according to the specified wildcard. I guess this depends on >>> configuration of switches. >>> >>> On Tue, Feb 2, 2010 at 5:57 PM, Rodrigo Braga >>> wrote: >>> > I have the same problem, did someone solve this problem ?? >>> > >>> > My nox version is 0.8 >>> > >>> > compiled to openflow 0x97 >>> > >>> > thanks >>> > >>> > >>> > On Fri, Jan 15, 2010 at 3:36 AM, MinChi Tseng >>> > wrote: >>> >> >>> >> I am using monitor component in NOX. >>> >> >>> >> >>> >> >>> >> nox-0.6.0/src/noxcoreapps/examples/monitor.py = >>> >> >>> >> def aggregate_timer(self, dpid): >>> >> >>> >> flow = ofp_match() >>> >> >>> >> flow.wildcards = 0x >>> >> >>> >> self.ctxt.send_aggregate_stats_request(dpid, flow, 0xff) >>> >> >>> >> self.post_callback(MONITOR_TABLE_PERIOD, lambda : >>> >> self.aggregate_timer(dpid)) >>> >> >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> MinChi >>> >> >>> >> >>> >> >>> >> Can you paste the code which is doing the query? >>> >> >>> >> >>> >> >>> >> > No, the OF is get via NOX Virtual Test Environment setup >>> >> > instruction. >>> >> >>> >> > http://noxrepo.org/manual/vm_environment.html >>> >> >>> >> > >>> >> >>> >> > wget http://noxrepo.org/openflow_mod.ko >>> >> >>> >> > wget http://noxrepo.org/dpctl >>> >> >>> >> > wget http://noxrepo.org/secchan >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > MinChi >>> >> >>> >> > >>> >> >>> >> > -Original Message- >>> >> >>> >> > From: Martin Casado [mailto:cas...@nicira.com] >>> >> >>> >> > Sent: Friday, January 15, 2010 2:34 PM >>> >> >>> >> > To: MinChi Tseng >>> >> >>> >> > Cc: nox-dev@noxrepo.org >>> >> >>> >> > Subject: Re: [nox-dev] aggregate flow statistics always return 0 >>> >> >>> >> > >>> >> >>> >> > Are you using the OF reference code from Stanford? >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> >> Hi all, >>> >> >>> >> >> >>> >> >>> >> >> I am using NOX Virtual Test Environment >>> >> >>> >> >> >>> >> >>> >> >> The topology is one OpenFlow switch and two hosts. >>> >> >>> >> >> >>> >> >>> >> >> Host 1 and host2 continually ping each other. >>> >> >>> >> >> >>> >> >>> >> >> In monitor component, the aggregate statistics always show 0. >>> >> >>> >> >> >>> >> >>> >> &
Re: [nox-dev] What will happen when OFPBAC_BAD_OUT_PORT occurs
Thanks for your help. This is the most possible reason, but I still need to figure out when this occurs.. On Fri, Mar 5, 2010 at 3:50 AM, Rob Sherwood wrote: > The more likely explanation is that you tried to sent to output:$port > with where $port == $inport. To prevent loops, OpenFlow makes you > explicitly use the action output:OFPP_INPORT if you want to send back > out the port a packet came in on. > > Does that help? > > - Rob > . > > > > On Thu, Mar 4, 2010 at 11:24 AM, Guanyao Huang wrote: >> Hello >> My program shows error of type2 code4. From specification it means >> OFPBAC_BAD_OUT_PORT error. >> I want to know if one simple case is the possible reason. >> Suppose the switch already has one entry for the flow, but now I >> OFPFC_ADD a new entry with different port. Will this lead to the error >> above? Or, the switch will simply delete the existing entry and insert >> the new one. It seems my calculated path will not have a bad port >> which leads to nowhere. >> Thanks. >> >> ___ >> 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] What will happen when OFPBAC_BAD_OUT_PORT occurs
Seems the only explanation is "when you add a flow which forwards packets to a non-existing port" I find it from: http://www.openflowswitch.org/wk/index.php/OpenFlow_v1.0. The flow_mod below seems will not lead to my error. On Fri, Mar 5, 2010 at 3:24 AM, Guanyao Huang wrote: > Hello > My program shows error of type2 code4. From specification it means > OFPBAC_BAD_OUT_PORT error. > I want to know if one simple case is the possible reason. > Suppose the switch already has one entry for the flow, but now I > OFPFC_ADD a new entry with different port. Will this lead to the error > above? Or, the switch will simply delete the existing entry and insert > the new one. It seems my calculated path will not have a bad port > which leads to nowhere. > Thanks. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] What will happen when OFPBAC_BAD_OUT_PORT occurs
Hello My program shows error of type2 code4. From specification it means OFPBAC_BAD_OUT_PORT error. I want to know if one simple case is the possible reason. Suppose the switch already has one entry for the flow, but now I OFPFC_ADD a new entry with different port. Will this lead to the error above? Or, the switch will simply delete the existing entry and insert the new one. It seems my calculated path will not have a bad port which leads to nowhere. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A question regarding Authenticator module
Sorry to bother you again. I have two issues regarding both authenticator module and routing module. Please look at the code in sprouting.cc, set_route() function. 1, The inport is from fi.src_location.location->dpport. Can you explain the structure of the location variable? How it maintains both datapathid and port number? My actual concern is: Sometimes, packets will get broadcasted before a route is calculated. When a broadcasted packet hit another switch, the inport also changed. I understand route.id.src is the real ingress switch, so, the whole procedure is to find a route from the src datapath, not current datapath. But sometimes, because of this, it consistently show "Packet not on route" and freezes there. I guess this is because the controller is always processing at this "Packet not on route" but not continue. 2, Sometimes the egress datapath read from the authenticator module is not the closest one to the dst mac. This makes the flow sent to different datapath other than the correct one. Is this a known bug or is this not important? Our experiment shows this sometimes matters. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] My datapath leaves again (HP network)
I now use smaller traces and no such problem again. I think it is because of heavy load. ... Thanks. On Mon, Mar 1, 2010 at 10:12 PM, Martin Casado wrote: > Actually nevermind, I don't think the HP switch support inband control so > you must be using out of band. > > Another option is to turn off the echo timer in Nox ... > > >> Sorry, my English is poor, what do you mean by "out of band control"? :) >> >> On Mon, Mar 1, 2010 at 10:07 PM, Martin Casado wrote: >> >>> >>> I wonder if this is a problem with lost echo requests under load ... >>> >>> Can you set up your environment to use out of band control? >>> >>> >>>> >>>> My program runs about 15 mins, it processes some traces. Datapath >>>> leaves at around 12 mins. >>>> Current CPU load is around 30%, and hit 35% occasionally. >>>> >>>> On Mon, Mar 1, 2010 at 9:59 PM, kk yap wrote: >>>> >>>> >>>>> >>>>> Just to be blunt. What is the CPU load of your HP? >>>>> >>>>> Regards >>>>> KK >>>>> >>>>> On 1 March 2010 21:42, Guanyao Huang wrote: >>>>> >>>>> >>>>>> >>>>>> Which part defines the time interval for this echo request? I guess >>>>>> enlarger it will temporarily handle my problem. >>>>>> >>>>>> On Mon, Mar 1, 2010 at 9:38 PM, kk yap wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Hi Guanyao, >>>>>>> >>>>>>> NOX periodic checks if the switch is still alive by sending an echo >>>>>>> request. Basically, your switch did not reply. You should look at >>>>>>> the tcpdump to see if you can find the echo reply. If yes, bug >>>>>>> people >>>>>>> in this list. If no, debug your switch. >>>>>>> >>>>>>> Regards >>>>>>> KK >>>>>>> >>>>>>> On 1 March 2010 21:34, Guanyao Huang wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Hi >>>>>>>> Sorry to bother others. >>>>>>>> In my program the datapath leaves network again. This time it seems >>>>>>>> a >>>>>>>> little different: >>>>>>>> >>>>>>>> 00341|openflow|WARN:stream: no response to inactivity probe after 15 >>>>>>>> seconds, disconnecting >>>>>>>> 00342|nox|WARN:stream: disconnected (Protocol error) >>>>>>>> Datapath leave, f7:ca:e4:00:01:90 >>>>>>>> 00343|bindings_storage|ERR:NDB error on get_locnames_cb (ok if >>>>>>>> transient): Can't find specified row >>>>>>>> 00344|openflow|WARN:stream: no response to inactivity probe after 15 >>>>>>>> seconds, disconnecting >>>>>>>> 00345|nox|WARN:stream: disconnected (Protocol error) >>>>>>>> Datapath leave, f7:ca:e4:00:01:2c >>>>>>>> 00346|openflow|WARN:stream: no response to inactivity probe after 15 >>>>>>>> seconds, disconnecting >>>>>>>> 00347|nox|WARN:stream: disconnected (Protocol error) >>>>>>>> Datapath leave, f7:ca:e4:00:00:c8 >>>>>>>> >>>>>>>> >>>>>>>> I am wondering what is this 15 second probe. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> ___ >>>>>>>> nox-dev mailing list >>>>>>>> nox-dev@noxrepo.org >>>>>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>> ___ >>>> nox-dev mailing list >>>> nox-dev@noxrepo.org >>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>>> >>>> >>> >>> > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] My datapath leaves again (HP network)
My program runs about 15 mins, it processes some traces. Datapath leaves at around 12 mins. Current CPU load is around 30%, and hit 35% occasionally. On Mon, Mar 1, 2010 at 9:59 PM, kk yap wrote: > Just to be blunt. What is the CPU load of your HP? > > Regards > KK > > On 1 March 2010 21:42, Guanyao Huang wrote: >> Which part defines the time interval for this echo request? I guess >> enlarger it will temporarily handle my problem. >> >> On Mon, Mar 1, 2010 at 9:38 PM, kk yap wrote: >>> Hi Guanyao, >>> >>> NOX periodic checks if the switch is still alive by sending an echo >>> request. Basically, your switch did not reply. You should look at >>> the tcpdump to see if you can find the echo reply. If yes, bug people >>> in this list. If no, debug your switch. >>> >>> Regards >>> KK >>> >>> On 1 March 2010 21:34, Guanyao Huang wrote: >>>> Hi >>>> Sorry to bother others. >>>> In my program the datapath leaves network again. This time it seems a >>>> little different: >>>> >>>> 00341|openflow|WARN:stream: no response to inactivity probe after 15 >>>> seconds, disconnecting >>>> 00342|nox|WARN:stream: disconnected (Protocol error) >>>> Datapath leave, f7:ca:e4:00:01:90 >>>> 00343|bindings_storage|ERR:NDB error on get_locnames_cb (ok if >>>> transient): Can't find specified row >>>> 00344|openflow|WARN:stream: no response to inactivity probe after 15 >>>> seconds, disconnecting >>>> 00345|nox|WARN:stream: disconnected (Protocol error) >>>> Datapath leave, f7:ca:e4:00:01:2c >>>> 00346|openflow|WARN:stream: no response to inactivity probe after 15 >>>> seconds, disconnecting >>>> 00347|nox|WARN:stream: disconnected (Protocol error) >>>> Datapath leave, f7:ca:e4:00:00:c8 >>>> >>>> >>>> I am wondering what is this 15 second probe. >>>> >>>> Thanks. >>>> >>>> ___ >>>> 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] My datapath leaves again (HP network)
Which part defines the time interval for this echo request? I guess enlarger it will temporarily handle my problem. On Mon, Mar 1, 2010 at 9:38 PM, kk yap wrote: > Hi Guanyao, > > NOX periodic checks if the switch is still alive by sending an echo > request. Basically, your switch did not reply. You should look at > the tcpdump to see if you can find the echo reply. If yes, bug people > in this list. If no, debug your switch. > > Regards > KK > > On 1 March 2010 21:34, Guanyao Huang wrote: >> Hi >> Sorry to bother others. >> In my program the datapath leaves network again. This time it seems a >> little different: >> >> 00341|openflow|WARN:stream: no response to inactivity probe after 15 >> seconds, disconnecting >> 00342|nox|WARN:stream: disconnected (Protocol error) >> Datapath leave, f7:ca:e4:00:01:90 >> 00343|bindings_storage|ERR:NDB error on get_locnames_cb (ok if >> transient): Can't find specified row >> 00344|openflow|WARN:stream: no response to inactivity probe after 15 >> seconds, disconnecting >> 00345|nox|WARN:stream: disconnected (Protocol error) >> Datapath leave, f7:ca:e4:00:01:2c >> 00346|openflow|WARN:stream: no response to inactivity probe after 15 >> seconds, disconnecting >> 00347|nox|WARN:stream: disconnected (Protocol error) >> Datapath leave, f7:ca:e4:00:00:c8 >> >> >> I am wondering what is this 15 second probe. >> >> Thanks. >> >> ___ >> 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] My datapath leaves again (HP network)
Hi Sorry to bother others. In my program the datapath leaves network again. This time it seems a little different: 00341|openflow|WARN:stream: no response to inactivity probe after 15 seconds, disconnecting 00342|nox|WARN:stream: disconnected (Protocol error) Datapath leave, f7:ca:e4:00:01:90 00343|bindings_storage|ERR:NDB error on get_locnames_cb (ok if transient): Can't find specified row 00344|openflow|WARN:stream: no response to inactivity probe after 15 seconds, disconnecting 00345|nox|WARN:stream: disconnected (Protocol error) Datapath leave, f7:ca:e4:00:01:2c 00346|openflow|WARN:stream: no response to inactivity probe after 15 seconds, disconnecting 00347|nox|WARN:stream: disconnected (Protocol error) Datapath leave, f7:ca:e4:00:00:c8 I am wondering what is this 15 second probe. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A quick question about topology module
My bad. My code was wrong. Everything is maintained. Thanks. On Fri, Feb 26, 2010 at 12:34 PM, kk yap wrote: > Hi Guanyao, > > Can you elaborate? struct DpInfo is paired with a datapathid using a > hash_map and contained the destination datapathid using another > hash_map. Finally that points to LinkSet that is a lis to src and dst > ports. That information is preserved from what I can see. > > Regards > KK > > > On 26 February 2010 12:13, Guanyao Huang wrote: >> Hi >> I find that the topology module doesnt support the case where there >> are two links between two switches. But Discovery module support this >> situation. Is there a particular reason for this? >> Thanks. >> >> ___ >> 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] A quick question about topology module
Hi I find that the topology module doesnt support the case where there are two links between two switches. But Discovery module support this situation. Is there a particular reason for this? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] When will datapath leave network?
The error messsages below are for the HP virtual switches. The NEC switch does leave the network, but shows flow table is full. On Fri, Feb 19, 2010 at 5:17 PM, Guanyao Huang wrote: > Hello > I am running on a topology of 9 switches. It uses both HP switch and > NEC switch. What is the meaning of the following error? Is it the > controller connection breaking out? > > When this occurs, I remember the number of entries is less than 1500, > actually around 800 for HP. What are the possible reasons forcing HP > switches to leave? The CPU of controller? Is there any limit on the > number of entries per virtual switch (per vlan)? > > 00265|openflow|WARN:stream: send error: Broken pipe > 00266|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with > 32:Broken pipe. > 00267|openflow|WARN:stream: send error: Bad file descriptor > 00268|routingMR|ERR:Send packet to dp:f7cae400012c failed with 9:Bad > file descriptor. > 00269|openflow|WARN:stream: receive error: Bad file descriptor > 00270|nox|WARN:stream: disconnected (Bad file descriptor) > Datapath leave, f7:ca:e4:00:01:2c > 00271|nox|ERR:no datapath with id f7cae400012c registered at nox > 00272|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 3:No > such process. > 00273|nox|ERR:no datapath with id f7cae400012c registered at nox > 00274|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 3:No > such process. > > = > On the NEC switch, it also occasionally shows error type 3 code 0, > meaning the flow table is full, but it seems to me not full, around > 1000 or less. Is there a limit on the number of entries per virtual > switch (not physical switch)? > > Thanks. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] When will datapath leave network?
Hello I am running on a topology of 9 switches. It uses both HP switch and NEC switch. What is the meaning of the following error? Is it the controller connection breaking out? When this occurs, I remember the number of entries is less than 1500, actually around 800 for HP. What are the possible reasons forcing HP switches to leave? The CPU of controller? Is there any limit on the number of entries per virtual switch (per vlan)? 00265|openflow|WARN:stream: send error: Broken pipe 00266|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 32:Broken pipe. 00267|openflow|WARN:stream: send error: Bad file descriptor 00268|routingMR|ERR:Send packet to dp:f7cae400012c failed with 9:Bad file descriptor. 00269|openflow|WARN:stream: receive error: Bad file descriptor 00270|nox|WARN:stream: disconnected (Bad file descriptor) Datapath leave, f7:ca:e4:00:01:2c 00271|nox|ERR:no datapath with id f7cae400012c registered at nox 00272|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 3:No such process. 00273|nox|ERR:no datapath with id f7cae400012c registered at nox 00274|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 3:No such process. = On the NEC switch, it also occasionally shows error type 3 code 0, meaning the flow table is full, but it seems to me not full, around 1000 or less. Is there a limit on the number of entries per virtual switch (not physical switch)? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Inquiry a race condition of openflow switches
Right. I understand. We want to flow_cmd B and C before sending back first packet. Thanks. On Mon, Feb 8, 2010 at 8:19 PM, kk yap wrote: > Hi Guanyao, > > I do not understand > > "I think to guarantee flow_mod be set up for every switch, it is better > to install in the initial order, that means, the first switch" > > In that case, the second packet-in will still occur. Wouldn't it? > Imagine route A-B-C, and we send the flow_mod to A first. Then B > will/might see the packet-in. > > My suggestion for the guarantee is to send to B and C with a barrier > function it. Once both barrier function returns, we install A. That > way, we are sure B and C has the entries before sending the flow_mod > to A. > > Hope I am clear. > > Regards > KK > > On 8 February 2010 19:39, Guanyao Huang wrote: >> I heard this from my supervisor. I also think this is not resolved, >> because it seems hard to resolve this. >> I think to guarantee flow_mod be set up for every switch, it is better >> to install in the initial order, that means, the first switch >> installed first, because the packet will hit in this order. >> I think this is unresolved, because I occasionally saw this happens. I >> guess the only thing we can do is to handle new flow_in event. >> >> On Mon, Feb 8, 2010 at 7:10 PM, kk yap wrote: >>> Hi Guanyao, >>> >>> From what I know this is not resolved. Do you recall where you heard >>> that this is resolved in NOX 0.5? >>> >>> I put in a component in NOX 0.6 (not available publicly) to install >>> the route/tree in reverse order, i.e., destination first. This is not >>> foolproof either, since there is no guarantees on the flow_mod will >>> reach the switch in that order. Just does better than the current >>> order of installation. >>> >>> There exists a solution that totally removes the problem, but it adds >>> an RTT delay. Basically you can (in theory) do a barrier function for >>> each flow_mod and wait for all the replies before putting the flow_mod >>> to the source switch. >>> >>> Regards >>> KK >>> >>> On 8 February 2010 14:33, Guanyao Huang wrote: >>>> Hi >>>> Sorry to bother others. >>>> In order to establish packet forwarding between switches, the rule >>>> should be sent to switch before the first packet is sent back. The >>>> race condition is the packet is sent back and even forwarded by the >>>> first switch, but it doesnt find a rule in the second switch although >>>> openflow command is already sent. I was told that conditions like this >>>> were resolved after nox 0.5. My version is 0.5.0-full-beta, but I >>>> still find this happens occasionally. Is there any other requirement >>>> on the version? Also, how did you gaurrantee these conditions are >>>> resolved. Did you try to control the delay of the packets on wire? >>>> Thanks. >>>> >>>> ___ >>>> 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] Inquiry a race condition of openflow switches
I heard this from my supervisor. I also think this is not resolved, because it seems hard to resolve this. I think to guarantee flow_mod be set up for every switch, it is better to install in the initial order, that means, the first switch installed first, because the packet will hit in this order. I think this is unresolved, because I occasionally saw this happens. I guess the only thing we can do is to handle new flow_in event. On Mon, Feb 8, 2010 at 7:10 PM, kk yap wrote: > Hi Guanyao, > > From what I know this is not resolved. Do you recall where you heard > that this is resolved in NOX 0.5? > > I put in a component in NOX 0.6 (not available publicly) to install > the route/tree in reverse order, i.e., destination first. This is not > foolproof either, since there is no guarantees on the flow_mod will > reach the switch in that order. Just does better than the current > order of installation. > > There exists a solution that totally removes the problem, but it adds > an RTT delay. Basically you can (in theory) do a barrier function for > each flow_mod and wait for all the replies before putting the flow_mod > to the source switch. > > Regards > KK > > On 8 February 2010 14:33, Guanyao Huang wrote: >> Hi >> Sorry to bother others. >> In order to establish packet forwarding between switches, the rule >> should be sent to switch before the first packet is sent back. The >> race condition is the packet is sent back and even forwarded by the >> first switch, but it doesnt find a rule in the second switch although >> openflow command is already sent. I was told that conditions like this >> were resolved after nox 0.5. My version is 0.5.0-full-beta, but I >> still find this happens occasionally. Is there any other requirement >> on the version? Also, how did you gaurrantee these conditions are >> resolved. Did you try to control the delay of the packets on wire? >> Thanks. >> >> ___ >> 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] Inquiry a race condition of openflow switches
Hi Sorry to bother others. In order to establish packet forwarding between switches, the rule should be sent to switch before the first packet is sent back. The race condition is the packet is sent back and even forwarded by the first switch, but it doesnt find a rule in the second switch although openflow command is already sent. I was told that conditions like this were resolved after nox 0.5. My version is 0.5.0-full-beta, but I still find this happens occasionally. Is there any other requirement on the version? Also, how did you gaurrantee these conditions are resolved. Did you try to control the delay of the packets on wire? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] A question regarding Authenticator module
Hello Sorry to bother others. I can't understand the code of authenticator module, but I need a small favor. I understand that if one mac is dst address, this mac address should first be authenticated. After a while, this mac will timeout and expire. My current program wants to extend this timeout session. In this program it first sends ping packets to authenticate dst mac (by ICMP reply), and then tcpreplay some traces. If it expires quickly later traces can not be redirected but only broadcasted to dst mac. So, I only want to know which variable defines this interval. I tried a few and it works. But I still need to know which variable is the key factor. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] What can I do with datapath leave
I am using HP switch with openflow 0.8.9 On Wed, Feb 3, 2010 at 1:02 PM, Ben Pfaff wrote: > Normally the OpenFlow reference implementation and Open vSwitch log > a message when a connection closes. > > On Wed, Feb 03, 2010 at 12:59:16PM -0800, Guanyao Huang wrote: >> Hi >> What are the logs you were talking about? >> I saw the following messages. The CPU is only around 30%. >> >> 00038|openflow|WARN:stream: send error: Broken pipe >> 00039|routingMR|ERR:Add flow entry to dp:f7cae464 failed with >> 32:Broken pipe. >> 00040|openflow|WARN:stream: send error: Bad file descriptor >> 00041|routingMR|ERR:Send packet to dp:f7cae464 failed with 9:Bad >> file descriptor. >> 00042|openflow|WARN:stream: send error: Broken pipe >> 00043|routingMR|ERR:Add flow entry to dp:f7cae40001f4 failed with >> 32:Broken pipe. >> 00044|openflow|WARN:stream: send error: Bad file descriptor >> 00045|routingMR|ERR:Send packet to dp:f7cae40001f4 failed with 9:Bad >> file descriptor. >> 00046|openflow|WARN:stream: send error: Broken pipe >> 00047|routingMR|ERR:Add flow entry to dp:f7cae4c8 failed with >> 32:Broken pipe. >> 00048|openflow|WARN:stream: send error: Bad file descriptor >> 00049|routingMR|ERR:Send packet to dp:f7cae4c8 failed with 9:Bad >> file descriptor. >> 00050|openflow|WARN:stream: send error: Broken pipe >> 00051|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with >> 32:Broken pipe. >> 00052|openflow|WARN:stream: send error: Bad file descriptor >> 00053|routingMR|ERR:Send packet to dp:f7cae400012c failed with 9:Bad >> file descriptor. >> 00054|openflow|WARN:stream: send error: Broken pipe >> 00055|routingMR|ERR:Add flow entry to dp:f7cae4000190 failed with >> 32:Broken pipe. >> 00056|openflow|WARN:stream: send error: Bad file descriptor >> 00057|routingMR|ERR:Send packet to dp:f7cae4000190 failed with 9:Bad >> file descriptor. >> 00058|openflow|WARN:stream: receive error: Bad file descriptor >> 00059|nox|WARN:stream: disconnected (Bad file descriptor) >> 00060|openflow|WARN:stream: receive error: Bad file descriptor >> 00061|nox|WARN:stream: disconnected (Bad file descriptor) >> 00062|openflow|WARN:stream: receive error: Bad file descriptor >> 00063|nox|WARN:stream: disconnected (Bad file descriptor) >> 00064|openflow|WARN:stream: receive error: Bad file descriptor >> 00065|nox|WARN:stream: disconnected (Bad file descriptor) >> 00066|openflow|WARN:stream: receive error: Bad file descriptor >> 00067|nox|WARN:stream: disconnected (Bad file descriptor) >> Datapath leave, f7:ca:e4:00:00:64 >> Datapath leave, f7:ca:e4:00:01:f4 >> Datapath leave, f7:ca:e4:00:00:c8 >> Datapath leave, f7:ca:e4:00:01:2c >> Datapath leave, f7:ca:e4:00:01:90 >> >> >> On Tue, Feb 2, 2010 at 9:33 PM, Ben Pfaff wrote: >> > On Tue, Feb 02, 2010 at 09:23:52PM -0800, Guanyao Huang wrote: >> >> I am wondering what is the usual cause for a datapath to proactively >> >> leaves the network. Is it because it is overburdened or some probe >> >> messages time-out? >> > >> > The easiest way to find out is to look at the logs on the switches. >> > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] What can I do with datapath leave
Hi What are the logs you were talking about? I saw the following messages. The CPU is only around 30%. 00038|openflow|WARN:stream: send error: Broken pipe 00039|routingMR|ERR:Add flow entry to dp:f7cae464 failed with 32:Broken pipe. 00040|openflow|WARN:stream: send error: Bad file descriptor 00041|routingMR|ERR:Send packet to dp:f7cae464 failed with 9:Bad file descriptor. 00042|openflow|WARN:stream: send error: Broken pipe 00043|routingMR|ERR:Add flow entry to dp:f7cae40001f4 failed with 32:Broken pipe. 00044|openflow|WARN:stream: send error: Bad file descriptor 00045|routingMR|ERR:Send packet to dp:f7cae40001f4 failed with 9:Bad file descriptor. 00046|openflow|WARN:stream: send error: Broken pipe 00047|routingMR|ERR:Add flow entry to dp:f7cae4c8 failed with 32:Broken pipe. 00048|openflow|WARN:stream: send error: Bad file descriptor 00049|routingMR|ERR:Send packet to dp:f7cae4c8 failed with 9:Bad file descriptor. 00050|openflow|WARN:stream: send error: Broken pipe 00051|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 32:Broken pipe. 00052|openflow|WARN:stream: send error: Bad file descriptor 00053|routingMR|ERR:Send packet to dp:f7cae400012c failed with 9:Bad file descriptor. 00054|openflow|WARN:stream: send error: Broken pipe 00055|routingMR|ERR:Add flow entry to dp:f7cae4000190 failed with 32:Broken pipe. 00056|openflow|WARN:stream: send error: Bad file descriptor 00057|routingMR|ERR:Send packet to dp:f7cae4000190 failed with 9:Bad file descriptor. 00058|openflow|WARN:stream: receive error: Bad file descriptor 00059|nox|WARN:stream: disconnected (Bad file descriptor) 00060|openflow|WARN:stream: receive error: Bad file descriptor 00061|nox|WARN:stream: disconnected (Bad file descriptor) 00062|openflow|WARN:stream: receive error: Bad file descriptor 00063|nox|WARN:stream: disconnected (Bad file descriptor) 00064|openflow|WARN:stream: receive error: Bad file descriptor 00065|nox|WARN:stream: disconnected (Bad file descriptor) 00066|openflow|WARN:stream: receive error: Bad file descriptor 00067|nox|WARN:stream: disconnected (Bad file descriptor) Datapath leave, f7:ca:e4:00:00:64 Datapath leave, f7:ca:e4:00:01:f4 Datapath leave, f7:ca:e4:00:00:c8 Datapath leave, f7:ca:e4:00:01:2c Datapath leave, f7:ca:e4:00:01:90 On Tue, Feb 2, 2010 at 9:33 PM, Ben Pfaff wrote: > On Tue, Feb 02, 2010 at 09:23:52PM -0800, Guanyao Huang wrote: >> I am wondering what is the usual cause for a datapath to proactively >> leaves the network. Is it because it is overburdened or some probe >> messages time-out? > > The easiest way to find out is to look at the logs on the switches. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] What can I do with datapath leave
Hello Sorry to bother others. My program is redirecting traffic of 5 switches. Each switch tcpreplay a trace with speed=0.01mbps. There are at maximum 400 flow entries per switch. This is very small. However, the program shows some datapath leaves: 00016|openflow|WARN:stream: connection closed by peer 00017|nox|WARN:stream: connection closed by peer Datapath leave, f7:ca:e4:00:00:64 00018|nox|ERR:no datapath with id f7cae464 registered at nox not successfully opf command: routingMR::send_stats_request() 00019|nox|ERR:no datapath with id f7cae464 registered at nox not successfully opf command: routingMR::send_stats_request() 00020|bindings_storage|ERR:NDB error on get_locnames_cb (ok if transient): Can't find specified row I am wondering what is the usual cause for a datapath to proactively leaves the network. Is it because it is overburdened or some probe messages time-out? Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Inquiry about counters of openflow switches
Hello Sorry to bother others. My program is to redirect flows according to some metric in a topology of loops, 5 switches. I need to accurately query flow sizes from counters. For one flow, I will query its size from the egress switch. I find that: 1, Querying sizes from the ingress switch has many problems, because you have no idea whether the first packet will update the counter. Although the first packet is sent to the outport directly, sometimes it still update the counter, sometimes it will not. I am wondering how can it update the counter if it is sent to the outport directly from the controller. 2, Querying egress switch sometimes has the same problem, but it is more stable. Occasionally (with small probability), a packet gets through the switch without updating the counter (Because I saw no flow_in event is generated). I am wondering what are the possible reasions for this. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] aggregate flow statistics always return 0
I guess it depends on whether dpctl dump-aggregate works correctly.
My problem with it is that sometimes it can not aggregate flows
according to the specified wildcard. I guess this depends on
configuration of switches.
On Tue, Feb 2, 2010 at 5:57 PM, Rodrigo Braga wrote:
> I have the same problem, did someone solve this problem ??
>
> My nox version is 0.8
>
> compiled to openflow 0x97
>
> thanks
>
>
> On Fri, Jan 15, 2010 at 3:36 AM, MinChi Tseng wrote:
>>
>> I am using monitor component in NOX.
>>
>>
>>
>> nox-0.6.0/src/noxcoreapps/examples/monitor.py =
>>
>> def aggregate_timer(self, dpid):
>>
>> flow = ofp_match()
>>
>> flow.wildcards = 0x
>>
>> self.ctxt.send_aggregate_stats_request(dpid, flow, 0xff)
>>
>> self.post_callback(MONITOR_TABLE_PERIOD, lambda :
>> self.aggregate_timer(dpid))
>>
>>
>>
>> Thanks,
>>
>> MinChi
>>
>>
>>
>> Can you paste the code which is doing the query?
>>
>>
>>
>> > No, the OF is get via NOX Virtual Test Environment setup instruction.
>>
>> > http://noxrepo.org/manual/vm_environment.html
>>
>> >
>>
>> > wget http://noxrepo.org/openflow_mod.ko
>>
>> > wget http://noxrepo.org/dpctl
>>
>> > wget http://noxrepo.org/secchan
>>
>> >
>>
>> >
>>
>> > MinChi
>>
>> >
>>
>> > -Original Message-
>>
>> > From: Martin Casado [mailto:cas...@nicira.com]
>>
>> > Sent: Friday, January 15, 2010 2:34 PM
>>
>> > To: MinChi Tseng
>>
>> > Cc: nox-dev@noxrepo.org
>>
>> > Subject: Re: [nox-dev] aggregate flow statistics always return 0
>>
>> >
>>
>> > Are you using the OF reference code from Stanford?
>>
>> >
>>
>> >
>>
>> >> Hi all,
>>
>> >>
>>
>> >> I am using NOX Virtual Test Environment
>>
>> >>
>>
>> >> The topology is one OpenFlow switch and two hosts.
>>
>> >>
>>
>> >> Host 1 and host2 continually ping each other.
>>
>> >>
>>
>> >> In monitor component, the aggregate statistics always show 0.
>>
>> >>
>>
>> >> But, if I dump the aggregate statistics on OpenFlow switch, OpenFlow
>>
>> >> switch did print aggregate statistics which is non-zero.
>>
>> >>
>>
>> >> My question is why OpenFlow switch always returned 0 for aggregate
>>
>> >> stats to NOX.
>>
>> >>
>>
>> >> OpenFlow version is 0.8.9~1
>>
>> >>
>>
>> >> NOX version is 0.6.0
>>
>> >>
>>
>> >> On NOX, I issued: *./nox_core -v -i ptcp:2525 pyswitch monitor*
>>
>> >>
>>
>> >> On OpenFlow, I issued: *./secchan nl:0 tcp:10.0.2.2:2525 &*
>>
>> >>
>>
>> >> = some NOX log message
>>
>> >>
>>
>> >> 00140|openflow-event|DBG:received stats reply from 002320c72f83
>>
>> >>
>>
>> >> Table stats in from datapath 00:23:20:c7:2f:83
>>
>> >>
>>
>> >> hash2 : 4
>>
>> >>
>>
>> >> linear : 0
>>
>> >>
>>
>> >> 00141|openflow-event|DBG:received stats reply from 002320c72f83
>>
>> >>
>>
>> >> Port stats in from datapath 00:23:20:c7:2f:83
>>
>> >>
>>
>> >> 0 : 167
>>
>> >>
>>
>> >> 1 : 165
>>
>> >>
>>
>> >> 00142|openflow-event|DBG:received stats reply from 002320c72f83
>>
>> >>
>>
>> >> *Aggregate stats in from datapath 00:23:20:c7:2f:83*
>>
>> >>
>>
>> >> * {'packet_count': 0L, 'byte_count': 0L, 'flow_count': 0L}*
>>
>> >>
>>
>> >> 00143|openflow-event|DBG:received stats reply from 002320c72f83
>>
>> >>
>>
>> >> Table stats in from datapath 00:23:20:c7:2f:83
>>
>> >>
>>
>> >> hash2 : 4
>>
>> >>
>>
>> >> linear : 0
>>
>> >>
>>
>> >> 00144|openflow-event|DBG:received stats reply from 002320c72f83
>>
>> >>
>>
>> >> Port stats in from datapath 00:23:20:c7:2f:83
>>
>> >>
>>
>> >> 0 : 173
>>
>> >>
>>
>> >> 1 : 171
>>
>> >>
>>
>> >> 00145|openflow-event|DBG:received stats reply from 002320c72f83
>>
>> >>
>>
>> >> *Aggregate stats in from datapath 00:23:20:c7:2f:83*
>>
>> >>
>>
>> >> * {'packet_count': 0L, 'byte_count': 0L, 'flow_count': 0L}*
>>
>> >>
>>
>> >> * *
>>
>> >>
>>
>> >> dump aggregate statistics from Openflow ==
>>
>> >>
>>
>> >> hda:/cdrom# *./dpctl dump-aggregate nl:0*
>>
>> >>
>>
>> >> stats_reply (xid=0xbf8b2f94): flags=none type=2(aggregate)
>>
>> >>
>>
>> >> *packet_count=310 byte_count=30380 flow_count=4*
>>
>> >>
>>
>> >> hda:/cdrom# *./dpctl dump-aggregate nl:0*
>>
>> >>
>>
>> >> stats_reply (xid=0xe7b9f769): flags=none type=2(aggregate)
>>
>> >>
>>
>> >> *packet_count=318 byte_count=31164 flow_count=4*
>>
>> >>
>>
>> >> * *
>>
>> >>
>>
>> >> * *
>>
>> >>
>>
>> >> Thanks,
>>
>> >>
>>
>> >> MinChi
>>
>> >>
>>
>> >>
>> >>
>>
>> >>
>>
>> >> ___
>>
>> >> nox-dev mailing list
>>
>> >> nox-dev@noxrepo.org
>>
>> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>>
>> >>
>>
>> >>
>>
>> >
>>
>> >
>>
>>
>>
>> -Original Message-
>> From: Martin Casado [mailto:cas...@nicira.com]
>> Sent: Friday, January 15, 2010 3:16 PM
>> To: MinChi Tseng
>> Cc: nox-dev@noxrepo.org
>> Subject: Re: [nox-dev] aggregate flow statistics always return 0
>> ___
>> nox-dev mailing list
>> nox-dev@noxrepo.org
>> http://noxre
Re: [nox-dev] [openflow-discuss] One question regarding byte number, another one regarding ./dpctl dump-flows entries
You are right. I double check the traces. 1, 4 byte is checksum. 2, The pcap traces are actually broadcasted to another end, so, there is no flow table. But if I ping first, the end host can authenticate the dst mac, therefore a route can be set up for later coming pcap traces. These are not big issues. Thanks for your reply. On Wed, Jan 27, 2010 at 1:54 PM, Dan Talayco wrote: > Hi Guanyao-- > > For (1), I expect that the CRC is counted in the stats on the > switch, but not by pcap. It is a 4 byte "checksum" (actually, > cyclical redundancy check) attached at the L2 layer. This is > a frequent problem with counting bytes on Ethernet switches. > > I'm not sure about (2). Flows expire and it can sometimes be > hard to know what's there when a packet hits the switch. It > could also be something particular about your hardware setup. > What hardware are you using? > > -Dan > > On 1/26/10 1:09 PM, Guanyao Huang wrote: >> >> Hi >> I am running on my own nox module on a topology of 5 switches. I find >> two phenomena: >> >> 1, The byte number of every packet read from statistics is always 4 >> bytes larger than the real size. >> If pcap shows the packet is of size N, ./dpctl dump-flows will show a >> size of N+4. So, if we query statistics, it is also N+4. I want to >> know why there is a difference of 4? >> >> 2, I found that sometimes packets can also get redirected without an >> entry in flow table, or, the switch has a bug to show the correct flow >> table. >> When I tcpreplay from one host to another one, packets get redirected >> (tcpdump shows so), but ./dpctl dump-flows shows no entry. Even if >> the flow is so short to get counted as 0 size (first packet get lost), >> an entry should still exist. >> However, if I ping between these two hosts and then tcpreplay, the >> entries will show correctly. >> Is there any possible reason why flows get redirected but an entry is >> not there? >> >> Many thanks. >> ___ >> openflow-discuss mailing list >> openflow-disc...@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] One question regarding byte number, another one regarding ./dpctl dump-flows entries
Hi I am running on my own nox module on a topology of 5 switches. I find two phenomena: 1, The byte number of every packet read from statistics is always 4 bytes larger than the real size. If pcap shows the packet is of size N, ./dpctl dump-flows will show a size of N+4. So, if we query statistics, it is also N+4. I want to know why there is a difference of 4? 2, I found that sometimes packets can also get redirected without an entry in flow table, or, the switch has a bug to show the correct flow table. When I tcpreplay from one host to another one, packets get redirected (tcpdump shows so), but ./dpctl dump-flows shows no entry. Even if the flow is so short to get counted as 0 size (first packet get lost), an entry should still exist. However, if I ping between these two hosts and then tcpreplay, the entries will show correctly. Is there any possible reason why flows get redirected but an entry is not there? Many thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] aggregated flow statistics doesnt support nw_src and nw_dst option.
Sorry, I was saying toroki switch and NEC switch, not sure about HP switch. On Fri, Jan 22, 2010 at 3:04 PM, Guanyao Huang wrote: > Hi > I have two questions. > 1, why have people developed both individual flow statistics query and > aggregated flow statistics query, since both of them have wildcard to > aggregate flows. > My supervisor suggested that for individual flow statistics query, if > one flow in flow table is matched, then the count value will be > returned, regardless of other possible matches. Is this true? > > 2, For the aggregated flow statistics query, there seems to have bugs > on both Toroki and HP switches. > When I specify nw_src and nw_dst to be some values, the switch will > ignore this and return all flow statistics based on other fields. > Later I find that dpctl dump-aggregate will have the same result. > Basically, suppose there are 4 flows in the flow table with only 2 of > them have desired IP address. If "dpctl dump-aggregate switchname > nw_src=xx.xx.xx.xx", all the 4 flows will be matched. For other fields > such as dl_dst, dl_src, in_port, etc, it matches correctly. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] aggregated flow statistics doesnt support nw_src and nw_dst option.
Hi I have two questions. 1, why have people developed both individual flow statistics query and aggregated flow statistics query, since both of them have wildcard to aggregate flows. My supervisor suggested that for individual flow statistics query, if one flow in flow table is matched, then the count value will be returned, regardless of other possible matches. Is this true? 2, For the aggregated flow statistics query, there seems to have bugs on both Toroki and HP switches. When I specify nw_src and nw_dst to be some values, the switch will ignore this and return all flow statistics based on other fields. Later I find that dpctl dump-aggregate will have the same result. Basically, suppose there are 4 flows in the flow table with only 2 of them have desired IP address. If "dpctl dump-aggregate switchname nw_src=xx.xx.xx.xx", all the 4 flows will be matched. For other fields such as dl_dst, dl_src, in_port, etc, it matches correctly. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Fwd: A general question regarding discovery module
-- Forwarded message -- From: Guanyao Huang Date: Wed, Dec 23, 2009 at 3:17 PM Subject: Re: [nox-dev] A general question regarding discovery module To: Martin Casado In verbose model: 00015|openflow|WARN:stream: send error: Broken pipe 00016|routingMR|ERR:Add flow entry to dp:f7cae400012c failed with 32:Broken pipe. 00017|openflow|WARN:stream: receive error: Bad file descriptor 00018|nox|WARN:stream: disconnected (Bad file descriptor) Datapath leave, f7:ca:e4:00:01:2c 00019|bindings_storage|ERR:NDB error on get_locnames_cb (ok if transient): Can't find specified row 00020|nox|ERR:no datapath with id f7cae400012c registered at nox not successfully opf command: routingMR::send_stats_request() 00021|nox|ERR:no datapath with id f7cae400012c registered at nox not successfully opf command: routingMR::send_stats_request() 00022|openflow|WARN:stream: send error: Broken pipe 00023|routingMR|ERR:Add flow entry to dp:f7cae4c8 failed with 32:Broken pipe. 00024|openflow|WARN:stream: send error: Bad file descriptor Before these warnings, some other warnings show there are Unidirectional links: WARNING: Unidirectional link detected between f7:ca:e4:00:01:2c -- 21 <--> f7:ca:e4:00:00:64 -- 15 WARNING: Unidirectional link detected between f7:ca:e4:00:01:90 -- 26 <--> f7:ca:e4:00:01:2c -- 24 WARNING: Unidirectional link detected between f7:ca:e4:00:01:2c -- 21 <--> f7:ca:e4:00:00:64 -- 15 WARNING: Unidirectional link detected between f7:ca:e4:00:01:90 -- 26 <--> f7:ca:e4:00:01:2c -- 24 On Wed, Dec 23, 2009 at 3:08 PM, Guanyao Huang wrote: > I forgot to mention: > > Those warnings are the first warnings in my program. After them, it > shows failure to send flow command to the switch that left. If the > discovery module times out first, I guess some warnings will print > out. > > On Wed, Dec 23, 2009 at 2:55 PM, Martin Casado wrote: >> What is likely happening is that discovery times out the link, therefore now >> flows are set up to use it forcing all packets to the controller. This >> causes major packet loss (including the uptime echo request) forcing a reset >> of the connection. >> >>> Right, it only times out links if no LLDP is received. I was asking >>> what was the reason for the warning messages above. Seems they are not >>> related with discovery module. >>> >>> On Wed, Dec 23, 2009 at 2:37 PM, kk yap wrote: >>> >>>> >>>> Hi Guanyao, >>>> >>>> I am not sure what you are asking but discovery will not disconnected >>>> switches. That can be said with certainty. >>>> >>>> Regards >>>> KK >>>> >>>> 2009/12/23 Guanyao Huang : >>>> >>>>> >>>>> Some general questions: >>>>> >>>>> Will the datapath actively leave the network if it is burdened? Or >>>>> only link_timeouts at discovery module will make them leave. >>>>> >>>>> My program has following messages: >>>>> 00016|openflow|WARN:stream: send error: Broken pipe >>>>> 00017|routingMR|ERR:Add flow entry to dp:f7cae464 failed with >>>>> 32:Broken pipe. >>>>> 00018|openflow|WARN:stream: receive error: Bad file descriptor >>>>> 00019|nox|WARN:stream: disconnected (Bad file descriptor) >>>>> Datapath leave, f7:ca:e4:00:00:64 >>>>> >>>>> What does "Broken pipe" usually imply? I cant find where it is from. >>>>> >>>>> On Tue, Dec 22, 2009 at 10:41 AM, Guanyao Huang >>>>> wrote: >>>>> >>>>>> >>>>>> But I am now in UCdavis. I will start my intern next quarter >>>>>> >>>>>> On Tue, Dec 22, 2009 at 5:18 AM, Rob Sherwood >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Hi Guanyao, >>>>>>> >>>>>>> I'm going to be in the lab today ... let's try to find some time to >>>>>>> talk about this. >>>>>>> >>>>>>> - Rob >>>>>>> . >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 22, 2009 at 5:17 AM, Rob Sherwood >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Mon, Dec 21, 2009 at 12:47 PM, Martin Casado >>>>>>>> wrote: >>>>&
Re: [nox-dev] A general question regarding discovery module
I forgot to mention: Those warnings are the first warnings in my program. After them, it shows failure to send flow command to the switch that left. If the discovery module times out first, I guess some warnings will print out. On Wed, Dec 23, 2009 at 2:55 PM, Martin Casado wrote: > What is likely happening is that discovery times out the link, therefore now > flows are set up to use it forcing all packets to the controller. This > causes major packet loss (including the uptime echo request) forcing a reset > of the connection. > >> Right, it only times out links if no LLDP is received. I was asking >> what was the reason for the warning messages above. Seems they are not >> related with discovery module. >> >> On Wed, Dec 23, 2009 at 2:37 PM, kk yap wrote: >> >>> >>> Hi Guanyao, >>> >>> I am not sure what you are asking but discovery will not disconnected >>> switches. That can be said with certainty. >>> >>> Regards >>> KK >>> >>> 2009/12/23 Guanyao Huang : >>> >>>> >>>> Some general questions: >>>> >>>> Will the datapath actively leave the network if it is burdened? Or >>>> only link_timeouts at discovery module will make them leave. >>>> >>>> My program has following messages: >>>> 00016|openflow|WARN:stream: send error: Broken pipe >>>> 00017|routingMR|ERR:Add flow entry to dp:f7cae464 failed with >>>> 32:Broken pipe. >>>> 00018|openflow|WARN:stream: receive error: Bad file descriptor >>>> 00019|nox|WARN:stream: disconnected (Bad file descriptor) >>>> Datapath leave, f7:ca:e4:00:00:64 >>>> >>>> What does "Broken pipe" usually imply? I cant find where it is from. >>>> >>>> On Tue, Dec 22, 2009 at 10:41 AM, Guanyao Huang >>>> wrote: >>>> >>>>> >>>>> But I am now in UCdavis. I will start my intern next quarter >>>>> >>>>> On Tue, Dec 22, 2009 at 5:18 AM, Rob Sherwood >>>>> wrote: >>>>> >>>>>> >>>>>> Hi Guanyao, >>>>>> >>>>>> I'm going to be in the lab today ... let's try to find some time to >>>>>> talk about this. >>>>>> >>>>>> - Rob >>>>>> . >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 22, 2009 at 5:17 AM, Rob Sherwood >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> On Mon, Dec 21, 2009 at 12:47 PM, Martin Casado >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> I agree that if the problem is timeout due to loss from overload, >>>>>>>> then the >>>>>>>> only solution is prioritization. >>>>>>>> >>>>>>> >>>>>>> In general yes, but the current discovery algorithm is fairly >>>>>>> brittle. >>>>>>> With a large number of ports (48) on a hardware switch, even a small >>>>>>> amount of packet loss it can falsely report down links. Part of the >>>>>>> goal of the rewrite is to address this issue. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Question for the slicing folks, does slicing extend to the control >>>>>>>> channel >>>>>>>> (packets set to the controller?) >>>>>>>> >>>>>>> >>>>>>> In addition to what Yiannis said (short story == "not yet"), Jean >>>>>>> from >>>>>>> HP developed a "rate limiter" openflow action as a vendor extension >>>>>>> that can affect control and data traffic, so that could be used here. >>>>>>> I think this is a useful primitive and something I'm hoping will >>>>>>> making it into a future release of openflow (1.1?). >>>>>>> >>>>>>> - Rob >>>>>>> . >>>>>>> >>>>>>> >>>> >>>> ___ >>>> nox-dev mailing list >>>> nox-dev@noxrepo.org >>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>>> >>>> >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A general question regarding discovery module
Right, it only times out links if no LLDP is received. I was asking what was the reason for the warning messages above. Seems they are not related with discovery module. On Wed, Dec 23, 2009 at 2:37 PM, kk yap wrote: > Hi Guanyao, > > I am not sure what you are asking but discovery will not disconnected > switches. That can be said with certainty. > > Regards > KK > > 2009/12/23 Guanyao Huang : >> Some general questions: >> >> Will the datapath actively leave the network if it is burdened? Or >> only link_timeouts at discovery module will make them leave. >> >> My program has following messages: >> 00016|openflow|WARN:stream: send error: Broken pipe >> 00017|routingMR|ERR:Add flow entry to dp:f7cae464 failed with >> 32:Broken pipe. >> 00018|openflow|WARN:stream: receive error: Bad file descriptor >> 00019|nox|WARN:stream: disconnected (Bad file descriptor) >> Datapath leave, f7:ca:e4:00:00:64 >> >> What does "Broken pipe" usually imply? I cant find where it is from. >> >> On Tue, Dec 22, 2009 at 10:41 AM, Guanyao Huang wrote: >>> But I am now in UCdavis. I will start my intern next quarter >>> >>> On Tue, Dec 22, 2009 at 5:18 AM, Rob Sherwood >>> wrote: >>>> Hi Guanyao, >>>> >>>> I'm going to be in the lab today ... let's try to find some time to >>>> talk about this. >>>> >>>> - Rob >>>> . >>>> >>>> >>>> >>>> On Tue, Dec 22, 2009 at 5:17 AM, Rob Sherwood >>>> wrote: >>>>> On Mon, Dec 21, 2009 at 12:47 PM, Martin Casado wrote: >>>>>> I agree that if the problem is timeout due to loss from overload, then >>>>>> the >>>>>> only solution is prioritization. >>>>> >>>>> In general yes, but the current discovery algorithm is fairly brittle. >>>>> With a large number of ports (48) on a hardware switch, even a small >>>>> amount of packet loss it can falsely report down links. Part of the >>>>> goal of the rewrite is to address this issue. >>>>> >>>>>> Question for the slicing folks, does slicing extend to the control >>>>>> channel >>>>>> (packets set to the controller?) >>>>> >>>>> In addition to what Yiannis said (short story == "not yet"), Jean from >>>>> HP developed a "rate limiter" openflow action as a vendor extension >>>>> that can affect control and data traffic, so that could be used here. >>>>> I think this is a useful primitive and something I'm hoping will >>>>> making it into a future release of openflow (1.1?). >>>>> >>>>> - Rob >>>>> . >>>>> >>>> >>> >> >> ___ >> 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] A general question regarding discovery module
Some general questions: Will the datapath actively leave the network if it is burdened? Or only link_timeouts at discovery module will make them leave. My program has following messages: 00016|openflow|WARN:stream: send error: Broken pipe 00017|routingMR|ERR:Add flow entry to dp:f7cae464 failed with 32:Broken pipe. 00018|openflow|WARN:stream: receive error: Bad file descriptor 00019|nox|WARN:stream: disconnected (Bad file descriptor) Datapath leave, f7:ca:e4:00:00:64 What does "Broken pipe" usually imply? I cant find where it is from. On Tue, Dec 22, 2009 at 10:41 AM, Guanyao Huang wrote: > But I am now in UCdavis. I will start my intern next quarter > > On Tue, Dec 22, 2009 at 5:18 AM, Rob Sherwood > wrote: >> Hi Guanyao, >> >> I'm going to be in the lab today ... let's try to find some time to >> talk about this. >> >> - Rob >> . >> >> >> >> On Tue, Dec 22, 2009 at 5:17 AM, Rob Sherwood >> wrote: >>> On Mon, Dec 21, 2009 at 12:47 PM, Martin Casado wrote: >>>> I agree that if the problem is timeout due to loss from overload, then the >>>> only solution is prioritization. >>> >>> In general yes, but the current discovery algorithm is fairly brittle. >>> With a large number of ports (48) on a hardware switch, even a small >>> amount of packet loss it can falsely report down links. Part of the >>> goal of the rewrite is to address this issue. >>> >>>> Question for the slicing folks, does slicing extend to the control channel >>>> (packets set to the controller?) >>> >>> In addition to what Yiannis said (short story == "not yet"), Jean from >>> HP developed a "rate limiter" openflow action as a vendor extension >>> that can affect control and data traffic, so that could be used here. >>> I think this is a useful primitive and something I'm hoping will >>> making it into a future release of openflow (1.1?). >>> >>> - Rob >>> . >>> >> > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] ofp_match
My code is simply to query statistics of flows with the same (also in_port is specified). However, I find that by some reason the srcip and dstip are also wildcarded. No matter tmpmatch.nw_src=1 or 2 or anything, all the flows will be returned. srcip and dstip are indeed wildcarded although I dont want to. === size_t size = sizeof(ofp_stats_request) + sizeof(ofp_aggregate_stats_request); boost::shared_array raw_of(new char[size]); ofp_stats_request *ost = (ofp_stats_request*)raw_of.get(); ost->header.version = OFP_VERSION; ost->header.type = OFPT_STATS_REQUEST; ost->header.length = htons(size); uint32_t id=rand(); ost->header.xid = htonl(id); ost->type = htons(OFPST_AGGREGATE); ost->flags = htons(0); ofp_aggregate_stats_request* ofsr = (ofp_aggregate_stats_request*)(((uint8_t*)ost->body)+0); ofsr->table_id = 0xff; //request for all flows ofsr->out_port = OFPP_NONE; ofp_match tmpmatch; tmpmatch.nw_src=1;//(flow.nw_src); tmpmatch.nw_dst=1;//(flow.nw_dst); tmpmatch.in_port=5; tmpmatch.wildcards=htonl( OFPFW_NW_PROTO | OFPFW_DL_VLAN | OFPFW_DL_SRC | OFPFW_DL_DST | OFPFW_DL_TYPE | OFPFW_TP_SRC | OFPFW_TP_DST ); memcpy(&ofsr->match, &tmpmatch, sizeof(ofp_match)); send_openflow_command(thisdp, &ost->header, false) ; On Wed, Dec 23, 2009 at 1:01 AM, Guanyao Huang wrote: > This question might be too naive. If I want to specify nw_src and > nw_dst, and make other fields wildcards, shouldn't the code be as > follows: > tmpmatch.wildcards=htonl( OFPFW_NW_PROTO | OFPFW_DL_VLAN | > OFPFW_DL_SRC | OFPFW_DL_DST | OFPFW_DL_TYPE | OFPFW_TP_SRC | > OFPFW_TP_DST ); > Is there anything wrong? 0 means not to wildcarded it. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] ofp_match
This question might be too naive. If I want to specify nw_src and nw_dst, and make other fields wildcards, shouldn't the code be as follows: tmpmatch.wildcards=htonl( OFPFW_NW_PROTO | OFPFW_DL_VLAN | OFPFW_DL_SRC | OFPFW_DL_DST | OFPFW_DL_TYPE | OFPFW_TP_SRC | OFPFW_TP_DST ); Is there anything wrong? 0 means not to wildcarded it. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A general question regarding discovery module
I can have a try, but I dont expect the new algorithm will solve my problem. :) On Mon, Dec 21, 2009 at 12:36 AM, Rob Sherwood wrote: > Hello Guanyao, > > I don't work for Nicira, but there are some well known scaling issues > with the algorithm used by the discovery protocol. I'm hoping that > this week I should be able to get around to an improved algorithm > that, if you're interested in previewing, I can send you a copy. > > - Rob > . > > > > On Fri, Dec 18, 2009 at 2:44 PM, Martin Casado wrote: >> Yeah, it could be due to high-loss from load (unfortunately). >> >> You could try increasing the timeout value in discovery.py. If you don't >> have dynamic link events, this should be able to survive temporary timeouts. >> >> What switches are you using? >> >>> In my program the discovery module times out links sometimes, causing >>> my program not working well. I will debug to find out details why the >>> link fails. Actually they are not supposed to fail. Maybe it's because >>> of huge data. >>> >>> On Fri, Dec 18, 2009 at 8:41 AM, Martin Casado wrote: >>> The goal is to detect link failures, so one would hope that would be the most common failure mode. > > I assume LLDP packets are sent periodically. If there is no LLDP, what > will be the most possible reason? The controller or the switch is too > busy? > > On Thu, Dec 17, 2009 at 3:07 PM, Martin Casado > wrote: > > >> >> Discovery times out links when no LLDP packets have been received over >> some >> timeout period. Timer values are documented within discovery.py. >> >> >> >>> >>> It seems this module will periodically construct the topology. I dont >>> know why it will periodically time_out the links. I want to know in >>> what situations the links will time_out. >>> Thanks. >>> >>> ___ >>> nox-dev mailing list >>> nox-dev@noxrepo.org >>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >>> >>> >> >> >> >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] A general question regarding discovery module
In my program the discovery module times out links sometimes, causing my program not working well. I will debug to find out details why the link fails. Actually they are not supposed to fail. Maybe it's because of huge data. On Fri, Dec 18, 2009 at 8:41 AM, Martin Casado wrote: > The goal is to detect link failures, so one would hope that would be the > most common failure mode. > >> I assume LLDP packets are sent periodically. If there is no LLDP, what >> will be the most possible reason? The controller or the switch is too >> busy? >> >> On Thu, Dec 17, 2009 at 3:07 PM, Martin Casado wrote: >> >>> >>> Discovery times out links when no LLDP packets have been received over >>> some >>> timeout period. Timer values are documented within discovery.py. >>> >>> It seems this module will periodically construct the topology. I dont know why it will periodically time_out the links. I want to know in what situations the links will time_out. Thanks. ___ 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] A general question regarding discovery module
I assume LLDP packets are sent periodically. If there is no LLDP, what will be the most possible reason? The controller or the switch is too busy? On Thu, Dec 17, 2009 at 3:07 PM, Martin Casado wrote: > Discovery times out links when no LLDP packets have been received over some > timeout period. Timer values are documented within discovery.py. > >> It seems this module will periodically construct the topology. I dont >> know why it will periodically time_out the links. I want to know in >> what situations the links will time_out. >> Thanks. >> >> ___ >> 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] Need help regarding querying statistics from switches
We are recently confirmed the switch itself has some bug, it cant collect byte statistics. Thanks all. On Thu, Dec 10, 2009 at 6:02 PM, Guanyao Huang wrote: > Hello > Sorry to bother others. I one question regarding querying flow > statistics from switches through struct ofp_stats_request. I am using > nox 5.0 > > In my topology I periodically ping between hosts. However, I find the > packet_count and byte_count from the switch are always 0. I am > confirmed that I successfully received ofp_flow_stats from the desired > switch. The central controller maintains flow information and I query > flows with desired nw_proto, nw_src, nw_dst, tp_src, tp_dst, and > in_port. Other fields I use wildcard. > > When I use tcpreplay to replay some big packets, I find that the > returned size are not always 0. However, flows in pcap file expire > quickly and it is not easy to debug. > > Is it true that the returned size will always be 0 if the packet is small? > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] A general question regarding discovery module
It seems this module will periodically construct the topology. I dont know why it will periodically time_out the links. I want to know in what situations the links will time_out. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Need help regarding querying statistics from switches
I find that I can not query port statistics either when pinging. The returned value is also 0. But if I tcpreplay, the returned value is obviously larger than 0 (for port load). Is it that ping is too small? But obviously it can not be 0. On Sun, Dec 13, 2009 at 3:55 PM, Keith Amidon wrote: > I apologize if you stated this already and I missed it, but what > versions NOX and switch software are you using? > > Thanks, Keith > > > On Sun, 13 Dec 2009 11:17:01 -0800, Guanyao Huang wrote: >> I dont think the flow table entries expire quickly, because I find out >> only initially the new packet is sent to the controller. Later packets >> already have entries. >> >> It seems I dont have priority to use dpctl dump-flows command. I can >> telnet to the switches and run showflow command, which shows the flows >> are correct, with increasing size. >> >> Even if I use wildcards=0x to get all flow entries and use a >> short interval to query flow statistics (500 ms), the returned sizes >> are still always 0. >> >> Now, even reading port statistics doesnt work. Returned value is 0. >> >> The code is already posted to this email. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Need help regarding querying statistics from switches
There are only two flow entries on the switch (ping and ICMP reply). I can clearly see the byte_no is none 0 through showflow command. I periodically query and get statistics. I am sure the ofp_match fields of the query and reply are the same for the 10 fields. But the returned byte_no is always 0. On Fri, Dec 11, 2009 at 2:25 PM, Keith Amidon wrote: > On Thu, 10 Dec 2009 18:02:57 -0800, Guanyao Huang wrote: >> In my topology I periodically ping between hosts. However, I find the >> packet_count and byte_count from the switch are always 0. I am >> confirmed that I successfully received ofp_flow_stats from the desired >> switch. The central controller maintains flow information and I query >> flows with desired nw_proto, nw_src, nw_dst, tp_src, tp_dst, and >> in_port. Other fields I use wildcard. > > How frequent are the pings and how are the flows being installed. One > possibility here is that the flows are being installed with a timeout > shorter than the interval between pings. If that is the scenario, the > behavior could be: > > 1. ping arrives at switch > 2. switch does not find a matching flow, forwards to controller for > decision. > 3. controller installs flow in switch to match future pings with a > soft timeout. The controller may not count the stats from the > initial ping packet received in step 2 as being part of this new > flow. > 4. nothing matches flow for the soft timeout. flow is removed from > switch. > 5. goto step 1 > > Might this be what is happening? > > --- Keith > > > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Need help regarding querying statistics from switches
Nox version is 5.0. It works for the version of OpenFlow on the switch (0.8.9). I used the same function to print ofp_match field and compare the ofp_match value in the flow statistics request and flow statistics reply. They are exactly the same for the 10 fields (wildcards=0). But the returned value is still always 0. If I use wildcards=0x, then two flows returns (one is for ICMP reply), still with byte_no 0. On Sun, Dec 13, 2009 at 3:55 PM, Keith Amidon wrote: > I apologize if you stated this already and I missed it, but what > versions NOX and switch software are you using? > > Thanks, Keith > > > On Sun, 13 Dec 2009 11:17:01 -0800, Guanyao Huang wrote: >> I dont think the flow table entries expire quickly, because I find out >> only initially the new packet is sent to the controller. Later packets >> already have entries. >> >> It seems I dont have priority to use dpctl dump-flows command. I can >> telnet to the switches and run showflow command, which shows the flows >> are correct, with increasing size. >> >> Even if I use wildcards=0x to get all flow entries and use a >> short interval to query flow statistics (500 ms), the returned sizes >> are still always 0. >> >> Now, even reading port statistics doesnt work. Returned value is 0. >> >> The code is already posted to this email. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] A general question regarding getting statistics from switches.
Hi When querying individual flow statistics, the returned value is a vector of Flow_stats, in which every flow ofp_match is clearly contained. That means when querying flow statistics with some wildcards, we might get more than one flows with their statistics. But when using aggregate_flow_statistics, the returned value is ofp_aggregate_stats_reply, which does not contain flow match information. So, it seems that we can only use the id of the reply to match the request id. I just want to confirm this. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Need help regarding querying statistics from switches
I dont think the flow table entries expire quickly, because I find out only initially the new packet is sent to the controller. Later packets already have entries. It seems I dont have priority to use dpctl dump-flows command. I can telnet to the switches and run showflow command, which shows the flows are correct, with increasing size. Even if I use wildcards=0x to get all flow entries and use a short interval to query flow statistics (500 ms), the returned sizes are still always 0. Now, even reading port statistics doesnt work. Returned value is 0. The code is already posted to this email. > How frequent are the pings and how are the flows being installed. One > possibility here is that the flows are being installed with a timeout > shorter than the interval between pings. If that is the scenario, the > behavior could be: > > 1. ping arrives at switch > 2. switch does not find a matching flow, forwards to controller for > decision. > 3. controller installs flow in switch to match future pings with a > soft timeout. The controller may not count the stats from the > initial ping packet received in step 2 as being part of this new > flow. > 4. nothing matches flow for the soft timeout. flow is removed from > switch. > 5. goto step 1 > > Might this be what is happening? > > --- Keith > > > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Need help regarding querying statistics from switches
Sorry, I was wrong in saying my program can query flow statistics of
large flows. It cant query statistics of flows, no matter large or
small.
But I can query statistics of port. That is successful.
Below is my code to query flow statistics:
size_t size = sizeof(ofp_stats_request) + sizeof(ofp_flow_stats_request);
boost::shared_array raw_of(new char[size]);
ofp_stats_request *ost = (ofp_stats_request*)raw_of.get();
ost->header.version = OFP_VERSION;
ost->header.type = OFPT_STATS_REQUEST;
ost->header.length = htons(size);
ost->header.xid = htonl(STATS_DETAIL_ID);
ost->type = htons(OFPST_FLOW);
ost->flags = htons(0);
ofp_flow_stats_request* ofsr =
(ofp_flow_stats_request*)(((uint8_t*)ost->body)+0);
ofsr->table_id = 0xff; //request for all flow table
ofsr->out_port = OFPP_NONE;
for(.){//some loop code
ofp_match tmpmatch;
tmpmatch.nw_src=itflow->first.nw_src;
tmpmatch.nw_dst=itflow->first.nw_dst;
tmpmatch.tp_src=itflow->first.tp_src;
tmpmatch.tp_dst=itflow->first.tp_dst;
tmpmatch.nw_proto=itflow->first.nw_proto;
tmpmatch.in_port=itflow->first.in_port;
tmpmatch.wildcards=htonl(OFPFW_DL_VLAN | OFPFW_DL_SRC |
OFPFW_DL_DST | OFPFW_DL_TYPE | OFPFW_TP_SRC | OFPFW_TP_DST );
memcpy(&ofsr->match, &tmpmatch, sizeof(ofp_match));
if( 0 != send_openflow_command((it->first), &ost->header, false) ){
;
}
}
When parsing struct ofp_flow_stats, I find it is exactly the flow I
want to query. But the packet_count and byte_count are always 0.
Is this some setting problem?
On Thu, Dec 10, 2009 at 6:02 PM, Guanyao Huang wrote:
> Hello
> Sorry to bother others. I one question regarding querying flow
> statistics from switches through struct ofp_stats_request. I am using
> nox 5.0
>
> In my topology I periodically ping between hosts. However, I find the
> packet_count and byte_count from the switch are always 0. I am
> confirmed that I successfully received ofp_flow_stats from the desired
> switch. The central controller maintains flow information and I query
> flows with desired nw_proto, nw_src, nw_dst, tp_src, tp_dst, and
> in_port. Other fields I use wildcard.
>
> When I use tcpreplay to replay some big packets, I find that the
> returned size are not always 0. However, flows in pcap file expire
> quickly and it is not easy to debug.
>
> Is it true that the returned size will always be 0 if the packet is small?
>
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Need help regarding querying statistics from switches
Hello Sorry to bother others. I one question regarding querying flow statistics from switches through struct ofp_stats_request. I am using nox 5.0 In my topology I periodically ping between hosts. However, I find the packet_count and byte_count from the switch are always 0. I am confirmed that I successfully received ofp_flow_stats from the desired switch. The central controller maintains flow information and I query flows with desired nw_proto, nw_src, nw_dst, tp_src, tp_dst, and in_port. Other fields I use wildcard. When I use tcpreplay to replay some big packets, I find that the returned size are not always 0. However, flows in pcap file expire quickly and it is not easy to debug. Is it true that the returned size will always be 0 if the packet is small? ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Questions regarding routing module
Sorry, routing module doesnt handle lldp. I was refering some other module. Forget about this. On Mon, Nov 30, 2009 at 3:48 PM, Guanyao Huang wrote: > Hi > Sorry to bother others. > I find that there is one routing module under netapps directory. It > can route the flows between openflow switches. > My work now is to write my own routing module which uses dijstra > protocol to find the shortest path (not all-pairs shortest path > algorithm). I have a topology of some connected switches. Each switch > connects to one end host. The topology contains loops for these > switches. My module wants to achieve routing from any end host to > another host. > I guess it is a good choice to modify codes of routing module for my module. > > There are a couple of questions I dont understand regarding existing > routing module. > 1, Is it developed for layer 2 routing or layer 3 routing? I find > that the routing module works well (for my case) when the topology is > loopless. But it can not work when there are loops for my case. > 2, Is there any document on how it works? Forget about the All-pairs > shortest path algorithm (I am using dijstra), I dont understand some > codes in sprouting.cc, which uses some flooding and broadcasting. > Specifically, I dont understand some related structures such as > dst_locations. Basically, given the mac of end host, how to find the > datapathid that the flow should be routed to. > 3, I dont quite understand why it also handles lldp. I guess the > topology is captured by topology module. > > Thanks. > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Questions regarding routing module
Hi Sorry to bother others. I find that there is one routing module under netapps directory. It can route the flows between openflow switches. My work now is to write my own routing module which uses dijstra protocol to find the shortest path (not all-pairs shortest path algorithm). I have a topology of some connected switches. Each switch connects to one end host. The topology contains loops for these switches. My module wants to achieve routing from any end host to another host. I guess it is a good choice to modify codes of routing module for my module. There are a couple of questions I dont understand regarding existing routing module. 1, Is it developed for layer 2 routing or layer 3 routing? I find that the routing module works well (for my case) when the topology is loopless. But it can not work when there are loops for my case. 2, Is there any document on how it works? Forget about the All-pairs shortest path algorithm (I am using dijstra), I dont understand some codes in sprouting.cc, which uses some flooding and broadcasting. Specifically, I dont understand some related structures such as dst_locations. Basically, given the mac of end host, how to find the datapathid that the flow should be routed to. 3, I dont quite understand why it also handles lldp. I guess the topology is captured by topology module. Thanks. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
