I don't have time to get into this much until next Thursday. You can ping me again then if you still want my input.
Besides what Peter suggested, you also may find that just increasing the link timeout helps (e.g., --link-timeout=20) helps. If that doesn't, you could adjust the way send_cycle_time is computed. Divide by a larger number (on the intuition that more cycles per timeout interval means greater chance than one will get through). I'll also point out that Andrew Ferguson and I discussed some related stuff (particularly related to your final question) in the pox-dev thread "question about openflow.discovery development" on March 31st, which you might want to read. -- Murphy On Apr 12, 2013, at 5:04 PM, Weiyang Mo wrote: > Hi, > > I always use the openflow.discovery as my topology module, however I met some > strange behaviors recently and raise some questions. > > The strange behaviors are that link time_out appear unexpectedly, which > causes flow entry deleted ( I'm using l2_multi). But actually the link is > good. > > The unexpected link time_out may happen in following cases, and more frequent > if several cases at the same time: > > (1) If I keep requesting info from switches ( e.g. portstatus request). I'm > wondering why the request causes this. Is that because the request flushes > the LLDP packets? > > (2) If a new traffic is introduced. Is that because of the traffic to > controller blocks LLDP during learning before flow installed? > > (3) If do flow entry modification. I guess the modification takes some time > and during this time, many data packets are forwarded to controller and > occupy control channel. > > Unfortuanately, My program is doing all the above for some intelligent > routing. However the unexpected link time_out will fresh everything... It is > still need to have the time_out because sometimes it is really a link > disconnection. I'm requesting port_status every 2 seconds, and use the feed > back to intelligent route. > > Is that because of LLDPs are blaocked by other packets in control channel > and links cannot be updated? Is it possible to set highest priority for LLDP > in control channel rather than others? If the data channel is almost fully > occupied, will the LLDPs be blocked in that channel and be treated as link > time_out? > > And another question is that: Why not only using port_status as link_event > rather than link update? The most concern I can think probably is that some > cables are really bad, but they are stilltreated connected for switches? > > Thanks very much. > > Weiyang
