This really depends on where the packet is lost in the switch. Might just be a bug if the CPU is at 30+%. Without more information, there is very little to comment about here.
Regards KK On 1 March 2010 22:39, Martin Casado <[email protected]> wrote: > OOB control doesn't help unfortunately (I forget that HP doesn't support > inband control). We need to be able to slice the control channel so that > control packets are prioritized I think. > >> btw this is starting to look like a common issue as it's been reported a >> few times in the past. I guess out-of-band control or control packet >> priority would alleviate this >> >> On Mon, Mar 1, 2010 at 10:20 PM, Guanyao Huang <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >>>> >> >>>> >> >>>>> >> >>>>> Just to be blunt. What is the CPU load of your HP? >> >>>>> >> >>>>> Regards >> >>>>> KK >> >>>>> >> >>>>> On 1 March 2010 21:42, Guanyao Huang <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> >>>>>>>> [email protected] <mailto:[email protected]> >> >>>>>>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> nox-dev mailing list >> >>>> [email protected] <mailto:[email protected]> >> >>>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >>>> >> >>>> >> >>> >> >>> >> > >> > >> >> _______________________________________________ >> nox-dev mailing list >> [email protected] <mailto:[email protected]> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> > > > _______________________________________________ > nox-dev mailing list > [email protected] > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
