Re: [ovs-discuss] OVN Dynamic Routing
Hi Frode, Glad to see your message. Yes, while we started with EVPN as our main use case, we agree that it is more of a generic dynamic routing capability in OVN. Sure, we will kickstart the discussions around this on mailing list as well. Thanks Regards, Ankur From: Frode Nordahl Sent: Thursday, December 10, 2020 1:10 AM To: Ankur Sharma Cc: Greg Smith ; ovs-discuss Subject: OVN Dynamic Routing Hello, Ankur, Greg, All, Thank you for sharing your view on dynamic routing support for OVN during OVSCON 2020 [0]. I believe this is a topic that interests multiple parties in the community, and it applies to multiple topologies/use cases, not just EVPN. Would you be interested in presenting and discussing the proposed design on the mailing list? 0: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openvswitch.org_support_ovscon2020_&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=3HUT7aQXAsSImmITSraoqdZ6mWcRxUtwVRKAfH3ygQA&s=Xzze2S3f7Rstp66gRz7MSuTGvGltr3t8uxyx5M3R8og&e= -- Frode Nordahl ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovn] TCP/UDP traffic dropped between IP addresses defined in allowed address pairs when remote security group is used
Hi Numan,
https://signal.klimonda.com/ovnnb.db-broken.txt - this is the "initial" state
where TCP is not being established (but ping works)
https://signal.klimonda.com/ovnnb.db-working.txt - this is after I create a
separate IP-based rule to allow TCP traffic
In both examples, security group in question is
ed081ef3-754a-492f-80b2-fb73cd2dceed which is mapped to
pg_ed081ef3_754a_492f_80b2_fb73cd2dceed port group.
In the second ovnnb.db (ovnnb.db-working.txt), there is an extra ACL
fb464efc-f63b-494b-b59b-6c2860dcecba added from CLI via:
`openstack security group rule create --ingress --protocol tcp --remote-ip
172.16.0.0/24 default`
--
Krzysztof Klimonda
kklimo...@syntaxhighlighted.com
On Mon, Dec 14, 2020, at 14:14, Numan Siddique wrote:
> On Mon, Dec 14, 2020 at 4:01 PM Krzysztof Klimonda
> wrote:
> >
> > Hi,
> >
> > After upgrading to OVN 20.12.0 snapshot d8bc0377c I've noticed a problem in
> > communication between VMs that use allowed address pairs and remote group
> > id in security groups. I believe it has worked properly with OVN 20.06.2
> > release (although I have no way of verifying it right now).
> >
>
> Thanks for reporting the issue.
>
> Is it possible for you to share the OVN NB DB somewhere ?
>
> It would be easier to reproduce the issue with the DB.
>
> Thanks
> Numan
>
> > Given the following scenario:
> >
> > - 2 VMs with IP addresses: vm-a with IP addresses 10.0.0.10 and 172.16.0.10
> > and vm-b with IP addresses 10.0.0.11 and 172.16.0.11 where 10.0.0.0/8
> > addresses are set on ports, and 172.16.0.0/16 addresses are set in
> > allowed-address for on ports
> > - There is single security group attached to both ports allowing for
> > ingress tcp traffic coming from the same security group (remote-group)
> > - There is a TCP service listening on 10.0.0.10 on port 8000
> >
> > When I try accessing service from vm-b using 10.0.0.10 address, ovn
> > forwards traffic properly. However, when I try accessing same service via
> > 172.16.0.10 traffic is dropped.
> >
> > When I trace packets between VMs using ovn-trace, for first scenario the
> > last step is:
> >
> > 8<8<
> > ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> > ---
> > 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> > ct_label.blocked == 0, priority 4, uuid ab5a233e
> > reg0[8] = 1;
> > reg0[10] = 1;
> > next;
> > 5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
> > @pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src ==
> > $pg_ed081ef3_754a_492f_80b2_fb73cd2dceed_ip4 && tcp), priority 2002, uuid
> > d92706d4
> > next;
> > 9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst
> > == fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4,
> > 10.0.0.10, 172.16.0.0/16}, priority 90, uuid ff3390b1
> > next;
> > 10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst
> > == {fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
> > output;
> > /* output to "864929", type "" */
> > 8<8<
> >
> > However, when I use 172.16.0.0/24 addresses, the last step changes to:
> >
> > 8<8<
> > ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> > ---
> > 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> > ct_label.blocked == 0, priority 4, uuid ab5a233e
> > reg0[8] = 1;
> > reg0[10] = 1;
> > next;
> > 5. ls_out_acl (ovn-northd.c:5553): reg0[10] == 1 && (outport ==
> > @neutron_pg_drop && ip), priority 2001, uuid e36c0840
> > ct_commit { ct_label.blocked = 1; };
> > 8<8<
> >
> > Further notes:
> >
> > - ICMP traffic between 172.16.0.0/24 addresses is forwarded correctly, with
> > last step of ovn-trace being:
> >
> > 8<8<
> > ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> > ---
> > 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> > ct_label.blocked == 0, priority 4, uuid ab5a233e
> > reg0[8] = 1;
> > reg0[10] = 1;
> > next;
> > 5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
> > @pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src == 0.0.0.0/0 &&
> > icmp4), priority 2002, uuid cd1705d8
> > next;
> > 9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst
> > == fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4,
> > 10.0.0.10, 172.16.0.0/16}, priority 90, uuid ff3390b1
> > next;
> > 10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst
> > == {fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
> > output;
> > /* output to "864929", type "" */
> > 8<8<
> >
> > - If I replace security group rule, changing remote group to remote ip,
Re: [ovs-discuss] [ovn] TCP/UDP traffic dropped between IP addresses defined in allowed address pairs when remote security group is used
On Mon, Dec 14, 2020 at 4:01 PM Krzysztof Klimonda
wrote:
>
> Hi,
>
> After upgrading to OVN 20.12.0 snapshot d8bc0377c I've noticed a problem in
> communication between VMs that use allowed address pairs and remote group id
> in security groups. I believe it has worked properly with OVN 20.06.2 release
> (although I have no way of verifying it right now).
>
Thanks for reporting the issue.
Is it possible for you to share the OVN NB DB somewhere ?
It would be easier to reproduce the issue with the DB.
Thanks
Numan
> Given the following scenario:
>
> - 2 VMs with IP addresses: vm-a with IP addresses 10.0.0.10 and 172.16.0.10
> and vm-b with IP addresses 10.0.0.11 and 172.16.0.11 where 10.0.0.0/8
> addresses are set on ports, and 172.16.0.0/16 addresses are set in
> allowed-address for on ports
> - There is single security group attached to both ports allowing for ingress
> tcp traffic coming from the same security group (remote-group)
> - There is a TCP service listening on 10.0.0.10 on port 8000
>
> When I try accessing service from vm-b using 10.0.0.10 address, ovn forwards
> traffic properly. However, when I try accessing same service via 172.16.0.10
> traffic is dropped.
>
> When I trace packets between VMs using ovn-trace, for first scenario the last
> step is:
>
> 8<8<
> ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> ---
> 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> ct_label.blocked == 0, priority 4, uuid ab5a233e
> reg0[8] = 1;
> reg0[10] = 1;
> next;
> 5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
> @pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src ==
> $pg_ed081ef3_754a_492f_80b2_fb73cd2dceed_ip4 && tcp), priority 2002, uuid
> d92706d4
> next;
> 9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst ==
> fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4, 10.0.0.10,
> 172.16.0.0/16}, priority 90, uuid ff3390b1
> next;
> 10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst ==
> {fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
> output;
> /* output to "864929", type "" */
> 8<8<
>
> However, when I use 172.16.0.0/24 addresses, the last step changes to:
>
> 8<8<
> ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> ---
> 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> ct_label.blocked == 0, priority 4, uuid ab5a233e
> reg0[8] = 1;
> reg0[10] = 1;
> next;
> 5. ls_out_acl (ovn-northd.c:5553): reg0[10] == 1 && (outport ==
> @neutron_pg_drop && ip), priority 2001, uuid e36c0840
> ct_commit { ct_label.blocked = 1; };
> 8<8<
>
> Further notes:
>
> - ICMP traffic between 172.16.0.0/24 addresses is forwarded correctly, with
> last step of ovn-trace being:
>
> 8<8<
> ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> ---
> 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> ct_label.blocked == 0, priority 4, uuid ab5a233e
> reg0[8] = 1;
> reg0[10] = 1;
> next;
> 5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
> @pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src == 0.0.0.0/0 &&
> icmp4), priority 2002, uuid cd1705d8
> next;
> 9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst ==
> fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4, 10.0.0.10,
> 172.16.0.0/16}, priority 90, uuid ff3390b1
> next;
> 10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst ==
> {fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
> output;
> /* output to "864929", type "" */
> 8<8<
>
> - If I replace security group rule, changing remote group to remote ip,
> traffic is forwarded correctly and last step in ovn-trace is:
>
> 8<8<
> ct_next(ct_state=est|trk /* default (use --ct to customize) */)
> ---
> 4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
> ct_label.blocked == 0, priority 4, uuid ab5a233e
> reg0[8] = 1;
> reg0[10] = 1;
> next;
> 5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
> @pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src == 172.16.0.0/24
> && tcp), priority 2002, uuid a0871ca2
> next;
> 9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst ==
> fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4, 10.0.0.10,
> 172.16.0.0/16}, priority 90, uuid ff3390b1
> next;
> 10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst ==
> {fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
> output;
> /* output
[ovs-discuss] [ovn] TCP/UDP traffic dropped between IP addresses defined in allowed address pairs when remote security group is used
Hi,
After upgrading to OVN 20.12.0 snapshot d8bc0377c I've noticed a problem in
communication between VMs that use allowed address pairs and remote group id in
security groups. I believe it has worked properly with OVN 20.06.2 release
(although I have no way of verifying it right now).
Given the following scenario:
- 2 VMs with IP addresses: vm-a with IP addresses 10.0.0.10 and 172.16.0.10 and
vm-b with IP addresses 10.0.0.11 and 172.16.0.11 where 10.0.0.0/8 addresses are
set on ports, and 172.16.0.0/16 addresses are set in allowed-address for on
ports
- There is single security group attached to both ports allowing for ingress
tcp traffic coming from the same security group (remote-group)
- There is a TCP service listening on 10.0.0.10 on port 8000
When I try accessing service from vm-b using 10.0.0.10 address, ovn forwards
traffic properly. However, when I try accessing same service via 172.16.0.10
traffic is dropped.
When I trace packets between VMs using ovn-trace, for first scenario the last
step is:
8<8<
ct_next(ct_state=est|trk /* default (use --ct to customize) */)
---
4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
ct_label.blocked == 0, priority 4, uuid ab5a233e
reg0[8] = 1;
reg0[10] = 1;
next;
5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
@pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src ==
$pg_ed081ef3_754a_492f_80b2_fb73cd2dceed_ip4 && tcp), priority 2002, uuid
d92706d4
next;
9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst ==
fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4, 10.0.0.10,
172.16.0.0/16}, priority 90, uuid ff3390b1
next;
10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst ==
{fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
output;
/* output to "864929", type "" */
8<8<
However, when I use 172.16.0.0/24 addresses, the last step changes to:
8<8<
ct_next(ct_state=est|trk /* default (use --ct to customize) */)
---
4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
ct_label.blocked == 0, priority 4, uuid ab5a233e
reg0[8] = 1;
reg0[10] = 1;
next;
5. ls_out_acl (ovn-northd.c:5553): reg0[10] == 1 && (outport ==
@neutron_pg_drop && ip), priority 2001, uuid e36c0840
ct_commit { ct_label.blocked = 1; };
8<8<
Further notes:
- ICMP traffic between 172.16.0.0/24 addresses is forwarded correctly, with
last step of ovn-trace being:
8<8<
ct_next(ct_state=est|trk /* default (use --ct to customize) */)
---
4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
ct_label.blocked == 0, priority 4, uuid ab5a233e
reg0[8] = 1;
reg0[10] = 1;
next;
5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
@pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src == 0.0.0.0/0 &&
icmp4), priority 2002, uuid cd1705d8
next;
9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst ==
fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4, 10.0.0.10,
172.16.0.0/16}, priority 90, uuid ff3390b1
next;
10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst ==
{fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
output;
/* output to "864929", type "" */
8<8<
- If I replace security group rule, changing remote group to remote ip, traffic
is forwarded correctly and last step in ovn-trace is:
8<8<
ct_next(ct_state=est|trk /* default (use --ct to customize) */)
---
4. ls_out_acl_hint (ovn-northd.c:5292): !ct.new && ct.est && !ct.rpl &&
ct_label.blocked == 0, priority 4, uuid ab5a233e
reg0[8] = 1;
reg0[10] = 1;
next;
5. ls_out_acl (ovn-northd.c:5498): reg0[8] == 1 && (outport ==
@pg_ed081ef3_754a_492f_80b2_fb73cd2dceed && ip4 && ip4.src == 172.16.0.0/24 &&
tcp), priority 2002, uuid a0871ca2
next;
9. ls_out_port_sec_ip (ovn-northd.c:4525): outport == "864929" && eth.dst ==
fa:16:3e:bc:20:10 && ip4.dst == {255.255.255.255, 224.0.0.0/4, 10.0.0.10,
172.16.0.0/16}, priority 90, uuid ff3390b1
next;
10. ls_out_port_sec_l2 (ovn-northd.c:4929): outport == "864929" && eth.dst ==
{fa:16:3e:bc:20:10}, priority 50, uuid af91c05c
output;
/* output to "864929", type "" */
8<8<
--
Krzysztof Klimonda
kklimo...@syntaxhighlighted.com
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
