<div dir="ltr">Hello,<div><br></div><div>Have the same issue as Krzysztof, did some more digging and it seems that:</div><div>- Magnum adds a CIDR network to allowed_address_pairs (<a href="http://10.100.0.0/16" target="_blank">10.100.0.0/16</a> by default)</div><div>- OVN does not support adding CIDR to OVN NB LSP addresses field (so it makes it at least harder to reach feature parity with ML2/OVS in that sense)</div><div><br></div><div>I've been able to work this around by changing Magnum code to add additional SG rules to pass traffic with remote_ip: <a href="http://10.100.0.0/16" target="_blank">10.100.0.0/16</a> (<a href="https://review.opendev.org/c/openstack/magnum/+/773923/1/magnum/drivers/k8s_fedora_coreos_v1/templates/kubecluster.yaml">https://review.opendev.org/c/openstack/magnum/+/773923/1/magnum/drivers/k8s_fedora_coreos_v1/templates/kubecluster.yaml</a>).</div><div><br></div><div>Unfortunately disabling allowed_address_pairs (which I wanted to propose in the same change) effects in <a href="http://10.100.0.0/16">10.100.0.0/16</a> not being added to OVN NB LSP port_security field - and then it stops working.</div><div><br></div><div>Are there some additional SG entries needed that might allow that traffic (to facilitate the disablement of allowed_address_pairs and improve scalability)?</div><div><br></div><div><br></div><div>I'll post another thread on ovs-discuss to discuss if adding CIDRs to addresses field as a feature is technically feasible.</div><div><br></div><div>Michal</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 16 gru 2020 o 13:00 Slawek Kaplonski <<a href="mailto:skaplons@redhat.com" target="_blank">skaplons@redhat.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Wed, Dec 16, 2020 at 12:23:02PM +0100, Daniel Alvarez Sanchez wrote:<br>
> On Tue, Dec 15, 2020 at 10:57 PM Daniel Alvarez <<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>> wrote:<br>
> <br>
> ><br>
> ><br>
> ><br>
> > > On 15 Dec 2020, at 22:18, Slawek Kaplonski <<a href="mailto:skaplons@redhat.com" target="_blank">skaplons@redhat.com</a>> wrote:<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > >> On Tue, Dec 15, 2020 at 05:14:29PM +0100, Krzysztof Klimonda wrote:<br>
> > >>> On Tue, Dec 15, 2020, at 16:59, Daniel Alvarez Sanchez wrote:<br>
> > >>> Hi Chris, thanks for moving this here.<br>
> > >>><br>
> > >>> On Tue, Dec 15, 2020 at 4:22 PM Krzysztof Klimonda <<br>
> > <a href="mailto:kklimonda@syntaxhighlighted.com" target="_blank">kklimonda@syntaxhighlighted.com</a>> wrote:<br>
> > >>>> Hi,<br>
> > >>>><br>
> > >>>> This email is a follow-up to a discussion I've openened on<br>
> > ovs-discuss ML[1] regarding lack of TCP/UDP connectivity between pods<br>
> > deployed on magnum-managed k8s cluster with calico CNI and IPIP tunneling<br>
> > disabled (calico_ipv4pool_ipip label set to a default value of Off).<br>
> > >>>><br>
> > >>>> As a short introduction, during magnum testing in ussuri deployment<br>
> > with ml2/ovn neutron driver I've noticed lack of communication between pods<br>
> > deployed on different nodes as part of magnum deployment with calico<br>
> > configured to *not* encapsulate traffic in IPIP tunnel, but route it<br>
> > directly between nodes. In theory, magnum configures adds defined pod<br>
> > network to k8s nodes ports' allowed_address_pairs[2] and then security<br>
> > group is created allowing for ICMP and TCP/UDP traffic between ports<br>
> > belonging to that security group[3]. This doesn't work with ml2/ovn as<br>
> > TCP/UDP traffic between IP addresses in pod network is not matching ACLs<br>
> > defined in OVN.<br>
> > >>>><br>
> > >>>> I can't verify this behaviour under ml2/ovs for the next couple of<br>
> > weeks, as I'm taking them off for holidays, but perhaps someone knows if<br>
> > that specific usecase (security group rules with remote groups used with<br>
> > allowed address pairs) is supposed to be working, or should magnum use pod<br>
> > network cidr to allow traffic between nodes instead.<br>
> > >>><br>
> > >>> In ML2/OVN we're adding the allowed address pairs to the 'addresses'<br>
> > field only when the MAC address of the pair is the same as the port MAC [0].<br>
> > >>> I think that we can change the code to accomplish what you want (if it<br>
> > matches ML2/OVS which I think it does) by adding all IP-MAC pairs of the<br>
> > allowed-address pairs to the 'addresses' column. E.g:<br>
> > >>><br>
> > >>> addresses = [ MAC1 IP1, AP_MAC1 AP_IP1, AP_MAC2 AP_IP2 ]    (right now<br>
> > it's just  addresses = [ MAC1 IP1 ])<br>
> > >>> port_security column will be kept as it is today.<br>
> > >><br>
> > >> How does [AP_MAC1 AP_IP1 AP_MAC2 AP_IP2] scale with a number of IP<br>
> > addresses set in allowed_address_pairs? Given how default pod network is<br>
> > <a href="http://10.100.0.0/16" rel="noreferrer" target="_blank">10.100.0.0/16</a> will that generate 65k flows in ovs, or is it not a 1:1<br>
> > mapping?<br>
> ><br>
> > It will use conjunctive flows but yes it will be huge no matter what. If<br>
> > we follow the approach of adding match conditions to the ACLs for each<br>
> > address pair it is going to be even worse when expanded by ovn-controller.<br>
> > >><br>
> > >> If ml2/ovs is also having scaling issues when remote groups are used,<br>
> > perhaps magnum should switch to defining remote-ip in its security groups<br>
> > instead, even if the underlying issue on ml2/ovn is fixed?<br>
> > ><br>
> > > IIRC Kuryr moved already to such solution as they had problems with<br>
> > scaling on<br>
> > > ML2/OVS when remote_group ids where used.<br>
> ><br>
> <br>
> @Slaweq, ML2/OVS accounts for allowed address pairs for remote security<br>
> groups but not for FIPs right? I wonder why the distinction.<br>
> Documentation is not clear but I'm certain that FIPs are not accounted for<br>
> by remote groups.<br>
<br>
Right. FIPs aren't added to the list of allowed IPs in the ipset.<br>
<br>
> <br>
> If we decide to go ahead and implement this in ML2/OVN, the same thing can<br>
> be applied for FIPs adding the FIP to the 'addresses' field but there might<br>
> be scaling issues.<br>
> <br>
> <br>
> > That’s right. Remote groups are expensive in any case.<br>
> ><br>
> > Mind opening a launchpad bug for OVN though?<br>
> ><br>
> > Thanks!<br>
> > ><br>
> > >><br>
> > >>><br>
> > >>> This way, when ovn-northd generates the Address_Set in the SB database<br>
> > for the corresponding remote group, the allowed-address pairs IP addresses<br>
> > will be added to it and honored by the security groups.<br>
> > >>><br>
> > >>> +Numan Siddique <mailto:<a href="mailto:nusiddiq@redhat.com" target="_blank">nusiddiq@redhat.com</a>> to confirm that this<br>
> > doesn't have any unwanted side effects.<br>
> > >>><br>
> > >>> [0]<br>
> > <a href="https://opendev.org/openstack/neutron/src/commit/6a8fa65302b45f32958e7fc2b73614715780b997/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L122-L125" rel="noreferrer" target="_blank">https://opendev.org/openstack/neutron/src/commit/6a8fa65302b45f32958e7fc2b73614715780b997/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py#L122-L125</a><br>
> > >>>><br>
> > >>>> [1]<br>
> > <a href="https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050836.html" rel="noreferrer" target="_blank">https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050836.html</a><br>
> > >>>> [2]<br>
> > <a href="https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb001df4/magnum/drivers/k8s_fedora_coreos_v1/templates/kubeminion.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb001df4/magnum/drivers/k8s_fedora_coreos_v1/templates/kubeminion.yaml</a><br>
> > >>>> [3]<br>
> > <a href="https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb001df4/magnum/drivers/k8s_fedora_coreos_v1/templates/kubecluster.yaml#L1038" rel="noreferrer" target="_blank">https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb001df4/magnum/drivers/k8s_fedora_coreos_v1/templates/kubecluster.yaml#L1038</a><br>
> > >>>><br>
> > >>>> --<br>
> > >>>> Best Regards,<br>
> > >>>>  - Chris<br>
> > >>>><br>
> > ><br>
> > > --<br>
> > > Slawek Kaplonski<br>
> > > Principal Software Engineer<br>
> > > Red Hat<br>
> > ><br>
> ><br>
<br>
-- <br>
Slawek Kaplonski<br>
Principal Software Engineer<br>
Red Hat<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Michał Nasiadka<br><a href="mailto:mnasiadka@gmail.com" target="_blank">mnasiadka@gmail.com</a></div>