Jesse Gross wrote:
David Erickson wrote:
Jesse Gross wrote:
David Erickson wrote:
The crux is the netflow message is matching the flow expiration.
There was nothing in the ovs-vswitchd.log file other than messages
about connecting to NOX and exiting fail-open mode, which was well
before
David Erickson wrote:
Jesse Gross wrote:
David Erickson wrote:
The crux is the netflow message is matching the flow expiration.
There was nothing in the ovs-vswitchd.log file other than messages
about connecting to NOX and exiting fail-open mode, which was well
before this test was perfo
Jesse Gross wrote:
David Erickson wrote:
The crux is the netflow message is matching the flow expiration.
There was nothing in the ovs-vswitchd.log file other than messages
about connecting to NOX and exiting fail-open mode, which was well
before this test was performed.
Can you try turni
David Erickson wrote:
The crux is the netflow message is matching the flow expiration.
There was nothing in the ovs-vswitchd.log file other than messages
about connecting to NOX and exiting fail-open mode, which was well
before this test was performed.
Can you try turning off segmentation
Jesse Gross wrote:
Jesse Gross wrote:
David Erickson wrote:
I've attached the packet dump of the netflow message from the switch
causing the problems. Also as an aside, I was only able to get it to
send one netflow message because my machine returned an icmp error
back to ovs since I am n
Jesse Gross wrote:
David Erickson wrote:
I've attached the packet dump of the netflow message from the switch
causing the problems. Also as an aside, I was only able to get it to
send one netflow message because my machine returned an icmp error
back to ovs since I am not listening on that
Justin Pettit wrote:
On Nov 13, 2009, at 11:28 AM, David Erickson wrote:
I've attached the packet dump of the netflow message from the switch causing
the problems. Also as an aside, I was only able to get it to send one netflow
message because my machine returned an icmp error back to ovs sin
David Erickson wrote:
I've attached the packet dump of the netflow message from the switch
causing the problems. Also as an aside, I was only able to get it to
send one netflow message because my machine returned an icmp error
back to ovs since I am not listening on that port.. is there a way
On Nov 13, 2009, at 11:28 AM, David Erickson wrote:
> I've attached the packet dump of the netflow message from the switch causing
> the problems. Also as an aside, I was only able to get it to send one netflow
> message because my machine returned an icmp error back to ovs since I am not
> lis
Jesse Gross wrote:
David Erickson wrote:
1. If you query the flow stats before the expiration message, do you
get the right results? You mentioned that this was true before but
these flows are less than your 10 second polling interval.
The values still look wrong from the stats message,
Jesse Gross writes:
> The easiest thing to do is set the key
> netflow..host=: to some machine running
> Wireshark and then tell it to decode that destination port as
> cflow.
I've been wondering lately whether we should add a way to direct
netflow traffic directly to a log file (probably in pca
David Erickson wrote:
1. If you query the flow stats before the expiration message, do you
get the right results? You mentioned that this was true before but
these flows are less than your 10 second polling interval.
The values still look wrong from the stats message, I just did a test
w
Jesse Gross wrote:
David Erickson wrote:
This patch seemed to work but exposed another bizarre problem. So my
setup is the same, 2 Xen servers with OVS, 1 reference OF software
switch inbetween the two, a wget from .12 to .13 which is running
apache. When the flows expire, dpid 17 which is
David Erickson wrote:
This patch seemed to work but exposed another bizarre problem. So my
setup is the same, 2 Xen servers with OVS, 1 reference OF software
switch inbetween the two, a wget from .12 to .13 which is running
apache. When the flows expire, dpid 17 which is the OVS on the
phys
Jesse Gross wrote:
Hi Jesse,
Certainly the first, however I am seeing this bug on both short and
long (20+seconds) flows, both with an idle timeout of whatever the
default NOX 0.4 timeout is (I'm assuming 5s?). Does that qualify?
Yeah, a 5 second idle timeout will trigger this problem.
Hi Jesse,
Certainly the first, however I am seeing this bug on both short and
long (20+seconds) flows, both with an idle timeout of whatever the
default NOX 0.4 timeout is (I'm assuming 5s?). Does that qualify?
Yeah, a 5 second idle timeout will trigger this problem. My guess is
that th
Jesse Gross wrote:
David Erickson wrote:
However when the flow expires, the byte/packet counter are zero.
I sent off a patch for review that fixes a problem with the counters
in flow expiration messages, which is hopefully the same problem as
the one you are having. Does this match your
David Erickson wrote:
However when the flow expires, the byte/packet counter are zero.
I sent off a patch for review that fixes a problem with the counters in
flow expiration messages, which is hopefully the same problem as the one
you are having. Does this match your scenario:
* The fl
Hi all,
At Justin's request I am forwarding this bug report along to this email
address. I am seeing a problem where flow expirations are consistently
returning zeros for packet/byte counts on a specific flow I am
inserting. I am using OVS build 1497 that Justin gave me today. The
flow has
19 matches
Mail list logo
