We're finding that sometimes reused floating IP addresses
won't be reachable, for some reason. And I remembered that,
we found the same issue once for the reference
solution once, it was fixed here: [1]
Basically because the linux kernel, under some conditions will
ignore the gARP requests, and re
See inline email, I wasn't subscribed to ovs-discuss, sorry :)
On Nov 15, 2017 2:32 PM, "Miguel Angel Ajo Pelayo"
wrote:
We're finding that sometimes reused floating IP addresses
won't be reachable, for some reason. And I remembered that,
we found the same issue once f
u can confirm that our understanding is correct, that'd be
great, I also
see that your upstream kernel patch is really modifying the behaviour to
also
catch ANSWER packets with sha == tha, which should be equivalent as per RFC.
On Wed, Nov 15, 2017 at 8:10 PM, Miguel Angel Ajo Pelayo <
majop.
ESTs till very recently, there may be other,
> more niche networking stacks also exposing inconsistent behavior.
>
> Ihar
>
> On Thu, Nov 16, 2017 at 6:22 AM, Miguel Angel Ajo Pelayo
> wrote:
> > Sorry, it's the other way around.
> >
> > REQUEST is what neutr
Today during coffee I was discussing with Jakub the idea of having
some sort of "rally" [1] [2] like project to measure the native reponse
of OVN at scale, measuring things like:
* NB object creation to SB update
* Tap creation to SB port binding, and to connectivity.
* dnat NAT association
01:33PM +0100, Miguel Angel Ajo Pelayo wrote:
> > Today during coffee I was discussing with Jakub the idea of having
> > some sort of "rally" [1] [2] like project to measure the native reponse
> > of OVN at scale, measuring things like:
> >
> > * NB object
Hey, which version are you using?, There are a couple of patches that
Russell submitted recently to avoid flows not necessary on specific
chassis, and I know Ben was looking at improving the bundle logic on
ovn-controller to also reduce the number of flows generated for address
sets.
On Tue, Dec 1
Wow, amazing, big +1 for such patch. :D
On Tue, Feb 27, 2018 at 3:57 PM Daniel Alvarez Sanchez
wrote:
> Hi all,
>
> When working on the performance of the OVN OpenStack integration and
> following up this thread [0].
>
> I went a bit deeper trying to find out the root cause of the linear
> growt
As OVN started implementing L3HA with the use of BFD monitoring, after
discussing with the people who is doing QA and thinking about future
troubleshooting of the feature, they proposed something the thing on
$subject.
What do you think?
For example, in this case:
[heat-admin@overcloud-novacompu
I will submit it tomorrow, I wanted to share the idea first to make sure it
made sense.
Thank you,
Miguel Ángel.
On Wed, Mar 7, 2018 at 8:41 PM Ben Pfaff wrote:
> On Wed, Mar 07, 2018 at 12:56:49PM +0000, Miguel Angel Ajo Pelayo wrote:
> > As OVN started implementing L3HA with the u
false" or not set ?
Thanks in advance,
Miguel Ángel.
On Wed, Mar 7, 2018 at 10:04 PM Anil Venkata wrote:
> This is nice option to have.
>
> On 07-Mar-2018 6:27 PM, "Miguel Angel Ajo Pelayo"
> wrote:
>
>>
>> As OVN started implementing L3HA with the use
a real
deployment and get back here with the results.
On Thu, Mar 8, 2018 at 7:12 PM Ben Pfaff wrote:
> On Thu, Mar 08, 2018 at 04:43:50PM +, Miguel Angel Ajo Pelayo wrote:
> > Ok, looking at the code, it seems like we may only need to do this?
> >
> > diff --git a/utilit
face
"patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
type: patch
options:
{peer="patch-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4-to-br-int"}
Port "ovn-9f2335-0"
Interface "ovn-9f2335-0"
aff wrote:
> Seems reasonable to me, feel free to submit a patch.
>
> On Fri, Mar 09, 2018 at 05:43:00PM +0000, Miguel Angel Ajo Pelayo wrote:
> > Ok, I have modified it to just show bfd_status, for rexample, in a 3
> > controller + 1 compute
> > environment,
Thank you for bringing this topic to the ovs list. We also may want to find
a way of implementing this on OVN.
On Thu, Apr 12, 2018, 1:32 PM Sławek Kapłoński wrote:
> Hi,
>
> I’m trying to implement somehow guaranteed minimum bandwidth for egress
> traffic from VM in OpenStack Neutron.
> Problem
I believe we need to emit ICMP / need to frag messages to have proper
support
on different MTUs (on router sides), I wonder how does it work the other way
around (when external net is 1500, and internal net is 1500-geneve
overhead).
Is there any way to match packet_size > X on a flow?
How could w
On 24 July 2018 at 17:20:59, Han Zhou (zhou...@gmail.com) wrote:
On Thu, Jul 12, 2018 at 7:03 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:
> I believe we need to emit ICMP / need to frag messages to have proper
> support
> on different MTUs (on router sides), I won
On 24 July 2018 at 17:43:51, Han Zhou (zhou...@gmail.com) wrote:
On Tue, Jul 24, 2018 at 8:26 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:
>
>
>
> On 24 July 2018 at 17:20:59, Han Zhou (zhou...@gmail.com) wrote:
>
>
>
> On Thu, Jul 12, 2018 at 7:
to the source.
But I guess, that we still need the kernel changes to match on
those “big packets”.
On 27 July 2018 at 23:35:58, Ben Pfaff (b...@ovn.org) wrote:
On Thu, Jul 12, 2018 at 04:03:33PM +0200, Miguel Angel Ajo Pelayo wrote:
> Is there any way to match packet_size > X on a flow?
&
we had this path MTU discovery
mechanism in play for IPv4 .
On 2 August 2018 at 22:21:28, Ben Pfaff (b...@ovn.org) wrote:
On Thu, Aug 02, 2018 at 01:19:57PM -0700, Ben Pfaff wrote:
> On Wed, Aug 01, 2018 at 10:46:07AM -0400, Miguel Angel Ajo Pelayo wrote:
> > Hi Ben, ICMP is used as a si
priority, but I’d like
to hear
opinions.
Best regards,
Miguel Ángel.
On 3 August 2018 at 08:11:01, Miguel Angel Ajo Pelayo (majop...@redhat.com)
wrote:
I’m going to capture some example traffic and try to figure out which RFCs
talk about that behaviour so we can come up with a consistent solution
size of the packets? I wonder...
Thanks!
Daniel
On Fri, Aug 3, 2018 at 5:20 PM Miguel Angel Ajo Pelayo
wrote:
>
> We didn’t understand why a MTU missmatch in one direction worked (N/S),
> but in other direction (S/N) didn’t work… and we found that that it’s
> actually
> working (at le
Yeah, I was talking to daniel this morning, and I didn't know you already
had content for something like that, and it looks pretty good.
You can keep building the website in the ovn tree if you wanted... but
it's pretty packed with information already, and very
similar design, it just uses sphinx
23 matches
Mail list logo
