Hi Niky, Yes, this is clearer now. I do think it is better to watch for both packet_in and flow_removed in this case. You are looking for hints on the host binding and both gives you the same information. The easiest fix is to just update the timestamp nonetheless.
Regards KK On 26 January 2011 15:13, Niky Riga <[email protected]> wrote: > On the pyswitch code there is a function do_l2_learning(). > > It's easier if I just paste the code here, hopefully it won't be > too clattered. > > def do_l2_learning(dpid, inport, packet): > global inst > # learn MAC on incoming port > srcaddr = packet.src.tostring() > if ord(srcaddr[0]) & 1: > return > if inst.st[dpid].has_key(srcaddr): > dst = inst.st[dpid][srcaddr] > if dst[0] != inport: > log.msg(...) > else: > return > else: > log.msg(...) > > # learn or update timestamp of entry > inst.st[dpid][srcaddr] = (inport, time(), packet) > > # Replace any old entry for (switch,mac). > mac = mac_to_int(packet.src) > > The update of the entries is happening in the end of the fxn, > but if you look at the third 'if', if the cached port is the same > as the inport (i.e. the host hasn't moved) the fxn returns without > updating the timestamp, causing the entry to timeout sooner. > > Also it seems more appropriate that the entry times out after the > hard time out, since while the flow is installed the controller is > not expected to see any packets (at least from that flow), while it should > see a packet after the hard timeout expires. If the hard timeout is set to > infinite, then this is a potential problem, but in this case > one can either not timeout the entry (like the switch module) or just > set a default timeout value. > > Hope this helps, > Niky > > On 1/26/11 5:56 PM, kk yap wrote: >> >> Hi, >> >> I am lost in this conversation. While I can go and read the code, can >> someone explain this to people on the list? I can figure out why >> entries will timeout quickly. >> >> Regards >> KK >> >> On 26 January 2011 14:49, Niky Riga<[email protected]> wrote: >>> >>> I am not exactly sure what you mean about L3 flows, I am guessing you >>> mean >>> that it installs exact matches on all the fields and not just using the >>> L2 >>> fields, which, I am guessing, is done for efficiency reasons. >>> >>> I was thinking along the same lines as you, and modifying the controller >>> to >>> use the hard flow timeout value for the timeout, since the way it's >>> implemented now the entry will timeout really soon and thus new flows >>> have >>> to start with flooding packets. >>> >>> Thanks, >>> Niky >>> >>> On 1/26/11 1:40 PM, Murphy McCauley wrote: >>>> >>>> I think you're right. This has bothered me (a tiny, tiny bit) for >>>> years, >>>> but I never took the time to 100% convince myself that having it update >>>> the >>>> timestamp was the right thing to do. Since pyswitch isn't exactly an L2 >>>> switch -- it installs L3 flows -- I was worried there might be something >>>> subtle. At one point I had a version of pyswitch that did update it, >>>> and >>>> actually had two timeout numbers -- one was longer and used as the >>>> timeout >>>> for the internal map and also as the hard flow timeout, the other >>>> (shorter) >>>> one was the idle flow timeout. >>>> >>>> -- Murphy >>>> >>>> On Jan 26, 2011, at 9:56 AM, Niky Riga wrote: >>>> >>>>> Hi, >>>>> >>>>> I was recently going over the code of pyswitch and I noticed that the >>>>> timestamp >>>>> of an entry is not being updated when a packet comes in on the same >>>>> port >>>>> as before >>>>> (if the port is the same the code will return before updating the >>>>> entry). >>>>> >>>>> I know that this is not terribly important since, unless you have a >>>>> high >>>>> arrival rate of new >>>>> flows the entry will timeout really soon, I was just wondering ... >>>>> >>>>> Cheers, >>>>> Niky >>>>> >>>>> _______________________________________________ >>>>> 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 >>> > _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
