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 <cas...@nicira.com> 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 <yap...@gmail.com> 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 <gyhu...@ucdavis.edu>: >>> >>>> >>>> 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:f7cae4000064 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 <gyhu...@ucdavis.edu> >>>> 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 >>>>> <rob.sherw...@stanford.edu> 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 >>>>>> <rob.sherw...@stanford.edu> wrote: >>>>>> >>>>>>> >>>>>>> On Mon, Dec 21, 2009 at 12:47 PM, Martin Casado <cas...@nicira.com> >>>>>>> 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
