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
