On Tue, Apr 4, 2023 at 10:03 AM Eric Dumazet wrote:
> On Tue, Apr 4, 2023 at 9:33 AM Felix Huettner
> wrote:
> >
> > assume the following setup on a single machine:
> > 1. An openvswitch instance with one bridge and default flows
> > 2. two network namespaces "server" and "client"
> > 3. two ovs
On Mon, 3 Apr 2023 20:50:00 + Jakub Kicinski wrote:
> On Mon, 3 Apr 2023 11:18:46 + Felix Hüttner wrote:
> > On Sat, 1 Apr 2023 6:25:00 + Jakub Kicinski wrote:
> > > On Fri, 31 Mar 2023 06:25:13 + Felix Hüttner wrote:
> > > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > >
Thanks for the review
On Sat, 1 Apr 2023 6:25:00 + Jakub Kicinski wrote:
> On Fri, 31 Mar 2023 06:25:13 + Felix Hüttner wrote:
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 253584777101..6628323b7bea 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -3199,6
assume the following setup on a single machine:
1. An openvswitch instance with one bridge and default flows
2. two network namespaces "server" and "client"
3. two ovs interfaces "server" and "client" on the bridge
4. for each ovs interface a veth pair with a matching name and 32 rx and
tx
Assume the following setup:
++
| Logical Router |
| lr001 +-+
++ |
|
++ |
| Logical Router | | ++ +--+
| lr002 +-+-+ Logical Switch +-+ Phyiscal Network |
++ | |
Hello everyone,
We had a discussion on ovs-discuss that we wanted to bring here [1]:
Assume a physical network connected to a OVN Logical_Switch and then multiple
Logical_Routers like so:
++
| Logical Router |
| lr001 +-+
++ |
|
Assume the following setup:
++
| Logical Router |
| lr001 +-+
++ |
|
++ |
| Logical Router | | ++ +--+
| lr002 +-+-+ Logical Switch +-+ Phyiscal Network |
++ | |
the comments did refer to tables 1 below the actual table number.
Signed-off-by: Felix Huettner
---
northd/northd.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 770a5b50e..c366b545e 100644
---
previously garps/rarps were only sent for NAT IPs if these had an
ipv4 address attached. For lsp's on gateway routers that do not have
an ipv4 address assigned (e.g. if they are ipv6 only) no rarps where
send out.
This causes traffic outages when changing the priority of a gateway
chassis as the
Previously graceful rarps sent from ovn-controller were handled as
normal packets and flooded to other routers. As the other routers should
already have that information, we can skip flooding (just like it is done
for GARPs already) and thereby mitigate ovs refusing to send the packet
because of
in order to easily add future ipv6 test cases the common `ovn_attach`
function should also support ipv6 addresses.
Acked-by: Numan Siddique
Signed-off-by: Felix Huettner
---
tests/ovn-macros.at | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tests/ovn-macros.at
We need to be able to handle rarp fields in order to ensure we can
handle rarp messages we send ourselves.
This will be used by the next patch in the series.
Acked-by: Numan Siddique
Signed-off-by: Felix Huettner
---
lib/logical-fields.c | 8
lib/ovn-util.c | 2 +-
ovn-sb.xml
previously garps/rarps where only sent for "external" lsp's if these
had an ipv4 address attached. For lsp's on gateway routers that do
not have an ipv4 address assigned (e.g. if they are ipv6 only) no
rarps were send out.
This causes traffic outages when changing the priority of a gateway
Previously graceful rarps sent from ovn-controller were handled as
normal packets and flooded to other routers. As the other routers should
already have that information, we can skip flooding (just like it is done
for GARPs already) and thereby mitigate ovs refusing to send the packet
because of
previously garps/rarps were only sent for NAT IPs if these had an
ipv4 address attached. For lsp's on gateway routers that do not have
an ipv4 address assigned (e.g. if they are ipv6 only) no rarps where
send out.
This causes traffic outages when changing the priority of a gateway
chassis as the
in order to easily add future ipv6 test cases the common `ovn_attach`
function should also support ipv6 addresses.
Acked-by: Numan Siddique
Signed-off-by: Felix Huettner
---
tests/ovn-macros.at | 9 +
tests/ovn.at| 22 +++---
2 files changed, 16 insertions(+),
previously garps/rarps where only sent for "external" lsp's if these
had an ipv4 address attached. For lsp's on gateway routers that do
not have an ipv4 address assigned (e.g. if they are ipv6 only) no
rarps were send out.
This causes traffic outages when changing the priority of a gateway
We need to be able to handle rarp fields in order to ensure we can
handle rarp messages we send ourselves.
This will be used by the next patch in the series.
Acked-by: Numan Siddique
Signed-off-by: Felix Huettner
---
lib/logical-fields.c | 8
lib/ovn-util.c | 2 +-
ovn-sb.xml
previously garps/rarps were only sent for NAT IPs if these had an
ipv4 address attached. For lsp's on gateway routers that do not have
an ipv4 address assigned (e.g. if they are ipv6 only) no rarps where
send out.
This causes traffic outages when changing the priority of a gateway
chassis as the
in order to easily add future ipv6 test cases the common `ovn_attach`
function should also support ipv6 addresses.
Signed-off-by: Felix Huettner
---
tests/ovn-macros.at | 9 +
tests/ovn.at| 22 +++---
2 files changed, 16 insertions(+), 15 deletions(-)
diff
Previously graceful rarps sent from ovn-controller were handled as
normal packets and flooded to other routers. As the other routers should
already have that information, we can skip flooding (just like it is done
for GARPs already) and thereby mitigate ovs refusing to send the packet
because of
We need to be able to handle rarp fields in order to ensure we can
handle rarp messages we send ourselves.
This will be used by the next patch in the series.
Signed-off-by: Felix Huettner
---
lib/logical-fields.c | 8
lib/ovn-util.c | 2 +-
ovn-sb.xml | 2 ++
3 files
previously garps/rarps where only sent for "external" lsp's if these
had an ipv4 address attached. For lsp's on gateway routers that do
not have an ipv4 address assigned (e.g. if they are ipv6 only) no
rarps were send out.
This causes traffic outages when changing the priority of a gateway
23 matches
Mail list logo
