On Thu, Aug 14, 2014 at 11:31:07AM -0700, Ben Pfaff wrote:
> On Thu, Aug 14, 2014 at 03:14:05PM -0300, Flavio Leitner wrote:
> > Speaking on how ports works and limits, I've heard about an interesting
> > problem when using containers. If you add more than 1k containers to
> > an OVS bridge, the n
On Thu, Aug 14, 2014 at 03:14:05PM -0300, Flavio Leitner wrote:
> Speaking on how ports works and limits, I've heard about an interesting
> problem when using containers. If you add more than 1k containers to
> an OVS bridge, the network starts to fail. The reason is that when
> flooding packets
On Thu, Aug 14, 2014 at 10:36:49AM -0700, Ben Pfaff wrote:
> On Thu, Aug 14, 2014 at 02:29:49PM -0300, Flavio Leitner wrote:
> > On Thu, Aug 14, 2014 at 10:01:56AM -0700, Ben Pfaff wrote:
> > > On Wed, Aug 13, 2014 at 6:57 PM, Flavio Leitner wrote:
> > > > If it's kernel DP, then patch ports are i
Thanks! I will try out and see which is the best solution for me. will
update here if it works for me :)
On Thu, Aug 14, 2014 at 1:45 PM, Ben Pfaff wrote:
> You're doing something that no one really wants to do (as far as I
> know). I see this as not a real problem, therefore it doesn't need a
You're doing something that no one really wants to do (as far as I
know). I see this as not a real problem, therefore it doesn't need a
real solution.
You can use veths, I think.
On Thu, Aug 14, 2014 at 01:42:20PM -0400, Krishna Pratap wrote:
> Yea I saw that but my question is ...should I be ch
Yea I saw that but my question is ...should I be changing that? I am sort
of new to ovs. is there any other way to connect switches?
Since the same packet is being forwarded by all switches it reaches that
recursion limit. so apart from increasing this limit ..do we have another
solution?
Thanks
You can increase MAX_RESUBMIT_RECURSION in ofproto-dpif-xlate.c.
On Thu, Aug 14, 2014 at 01:22:55PM -0400, Krishna Pratap wrote:
> yes Ben, you maybe right. I saw it in log file when i enabled debugging .
>
> *2014-08-12T10:55:26.658Z|00070|ofproto_dpif_xlate(handler_1)|ERR|resubmit
> actions rec
On Thu, Aug 14, 2014 at 02:29:49PM -0300, Flavio Leitner wrote:
> On Thu, Aug 14, 2014 at 10:01:56AM -0700, Ben Pfaff wrote:
> > On Wed, Aug 13, 2014 at 6:57 PM, Flavio Leitner wrote:
> > > If it's kernel DP, then patch ports are internal ports which during TX
> > > inserts the packet (skb) into t
On Thu, Aug 14, 2014 at 10:01:56AM -0700, Ben Pfaff wrote:
> On Wed, Aug 13, 2014 at 6:57 PM, Flavio Leitner wrote:
> > If it's kernel DP, then patch ports are internal ports which during TX
> > inserts the packet (skb) into the CPU backlog queue (enqueue_to_backlog())
> > for later processing. L
On Thu, Aug 14, 2014 at 10:01:56AM -0700, Ben Pfaff wrote:
> On Wed, Aug 13, 2014 at 6:57 PM, Flavio Leitner wrote:
> > If it's kernel DP, then patch ports are internal ports which during TX
> > inserts the packet (skb) into the CPU backlog queue (enqueue_to_backlog())
> > for later processing. L
yes Ben, you maybe right. I saw it in log file when i enabled debugging .
*2014-08-12T10:55:26.658Z|00070|ofproto_dpif_xlate(handler_1)|ERR|resubmit
actions recursed over 64 times*
Is there a way to work around this? how can i remove this limit to see if
it crashes or not. are there any other way
On Wed, Aug 13, 2014 at 6:57 PM, Flavio Leitner wrote:
> If it's kernel DP, then patch ports are internal ports which during TX
> inserts the packet (skb) into the CPU backlog queue (enqueue_to_backlog())
> for later processing. Later on, the backlog queue is processed
> (process_backlog()) and t
Hi,
The kernel version is 3.8.0-38 ( Linux ccpu1 3.8.0-38-generic
#56~precise1-Ubuntu)
I think you are right. it is the kernel datapath which is used by the
patch ports. I am not too familiar with working you explained about
the backlog queue.
i will have to explore the suggestions that you have m
Are you using datapath in kernel or in userspace?
What's the kernel version?
If it's kernel DP, then patch ports are internal ports which during TX
inserts the packet (skb) into the CPU backlog queue (enqueue_to_backlog())
for later processing. Later on, the backlog queue is processed
(process_
There's no drop. The packets should have wondered somewhere. Find it :D
You set this up by a py script or manually? If not entirely by a script
which you surely have check, than I'm skeptical of a mistake. But
anyway, another suggestion is: manually delete 66th and link 65 with 67.
See if it's
i dont know how i didnt recevie the first email from Duy.
this is the original query
http://openvswitch.org/pipermail/discuss/2014-August/014741.html
On Wed, Aug 13, 2014 at 1:15 PM, Ben Pfaff wrote:
> Please don't drop the list.
>
> Open vSwitch does not have such a check.
>
> On Wed, Aug 13,
Please don't drop the list.
Open vSwitch does not have such a check.
On Wed, Aug 13, 2014 at 01:06:46PM -0400, Krishna Pratap wrote:
> exactly, i have been wondering the same. do you know where this check
> is done the code? it doesnt forward anything after 65 hops
>
> On Wed, Aug 13, 2014 at 1:
On Wed, Aug 13, 2014 at 10:02 AM, Krishna Pratap
wrote:
> TTL doesnt seems to be the problem. i have considered that. anyhow if
> you check the traffic in the output that i posted the TTL is set as
> 255. Also i dont think TTL should matter if we are forwarding packets
> at layer 2.
>
> I am gues
TTL doesnt seems to be the problem. i have considered that. anyhow if
you check the traffic in the output that i posted the TTL is set as
255. Also i dont think TTL should matter if we are forwarding packets
at layer 2.
I am guessing there is a check somewhere in OVS code which limits it.
if anyo
Dear,
Time to live behavior? Just my sense. I'm not very into this to be sure.
You can see from wireshark if it's really because of TTL.
Regards,
Duy
On 08/13/2014 06:18 PM, Krishna Pratap wrote:
Hi,
I am trying to create a linear topology of 70 switches and linking all
these switches with p
Hi,
I am trying to create a linear topology of 70 switches and linking all
these switches with patch ports. After this, I am injecting traffic
packets in the first switch(S0) and I have added flows on all of the
switches to forward the packets in one direction towards the last
switch (S69). I am u
21 matches
Mail list logo