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 20
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:
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 wrote:
> I am not exactly sure what you mean about L3 flows, I am guessing yo
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 th
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
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, un
