[ovs-discuss] [OVN] Routed provider networks

Ankur Sharma ankur.sharma at nutanix.com
Fri May 8 18:09:27 UTC 2020


Hi Ihar,

Got it, makes sense.
I believe generic filter would be to look for "inport=INACTIVE_LOCALNET_PORT".

Regards,
Ankur
________________________________
From: Ihar Hrachyshka <ihrachys at redhat.com>
Sent: Thursday, May 7, 2020 9:51 PM
To: Ankur Sharma <ankur.sharma at nutanix.com>; Numan Siddique <numans at ovn.org>
Cc: ovs-discuss <ovs-discuss at openvswitch.org>
Subject: Re: [ovs-discuss] [OVN] Routed provider networks

On 4/30/20 9:35 PM, Ankur Sharma wrote:
Hi Ihar, Numan

Thanks for further closure on this.
When we have 2 localnet ports per logical switch, then there will an extra flow anyways for packets coming from localnet port to integration.
I would not consider such flows as "extra".

Or probably i am missing on something in the usecase.


The use case implies that only a single localnet port of these switch ports is actually wired to fabric, that's why flows that belong to unwired ports are redundant and could be in theory cleaned up to reduce the size of tables.


Regards,
Ankur

________________________________
From: Numan Siddique <numans at ovn.org><mailto:numans at ovn.org>
Sent: Tuesday, April 28, 2020 11:27 PM
To: Ihar Hrachyshka <ihrachys at redhat.com><mailto:ihrachys at redhat.com>
Cc: Ankur Sharma <ankur.sharma at nutanix.com><mailto:ankur.sharma at nutanix.com>; ovs-discuss <ovs-discuss at openvswitch.org><mailto:ovs-discuss at openvswitch.org>
Subject: Re: [ovs-discuss] [OVN] Routed provider networks



On Tue, Apr 28, 2020 at 11:58 PM Ihar Hrachyshka <ihrachys at redhat.com<mailto:ihrachys at redhat.com>> wrote:
To close the loop: I don't see a particular problem with mac mapping
for E-W tagged routing: the implementation doesn't assume a single
port and configures a conj_id per in_port. So each localport will get
a flow configured to handle the scenario, even if only one of these
flows will actually be utilized per chassis. (Do we consider the
presence of flows that are not utilized a problem serious enough to
optimize it by determining which localnet port is in use right now and
skipping conjunction actions for the rest?)

If the unneeded flows can't be filtered out easily, then having them is not that serious
in my opinion.

Thanks
Numan


Ihar

On Thu, Apr 2, 2020 at 12:40 AM Ankur Sharma <ankur.sharma at nutanix.com<mailto:ankur.sharma at nutanix.com>> wrote:
>
> Hi Dumitru, Maciej,
>
> Routing for vlan backed networks can be enhanced to support multiple localnet ports per logical switch.
>
> Regards,
> Ankur
>
> ________________________________
> From: Dumitru Ceara <dceara at redhat.com<mailto:dceara at redhat.com>>
> Sent: Wednesday, April 1, 2020 6:54 AM
> To: Maciej Jozefczyk <mjozefcz at redhat.com<mailto:mjozefcz at redhat.com>>; ovs-discuss <ovs-discuss at openvswitch.org<mailto:ovs-discuss at openvswitch.org>>
> Cc: Ankur Sharma <ankur.sharma at nutanix.com<mailto:ankur.sharma at nutanix.com>>
> Subject: Re: [ovs-discuss] [OVN] Routed provider networks
>
> On 3/30/20 4:53 PM, Maciej Jozefczyk wrote:
> > Hello!
> >
> > I started to work on Routed Provider Networks feature for Openstack
> > Neutron, that is described [1].
> > Neutron community chosen second variant of this RFE, that would be
> > easier to implement for now.
> >
> > To achieve this we would need to have multiple provider network segments
> > configured within the same Logical Switch.
> > I prepared an example environment [2] and tested it.
>
> Hi Maciej,
>
> Thanks for trying this out!
>
> >
> > The worker hosts where VMs are placed are directly connected to provider
> > vlan network with segments:
> > external-segment-1: 172.24.4.0/24 [172.24.4.0]<https://urldefense.proofpoint.com/v2/url?u=http-3A__172.24.4.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=7GwWk3F3TZ7GuGAdNId2AdRvqihzNb3ut76zrZZvE98&s=hzzPvC73Q7zHn3hVlyYEMk2lKieDc8tTyTebx_dRpl8&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__172.24.4.0_24&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=maGCQOQrlsCYiPu14xbFVk72L2fMRpMxlxBECXgb488&e= > vlan 4
> > external-segment-2: 172.24.6.0/24 [172.24.6.0]<https://urldefense.proofpoint.com/v2/url?u=http-3A__172.24.6.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=7GwWk3F3TZ7GuGAdNId2AdRvqihzNb3ut76zrZZvE98&s=U8C8MBD9x0AAOcWCCixdvHbYQrw6JefG-dB_8zKweZ8&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__172.24.6.0_24&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=Po-XxK57K60hQ5JfzJs09UrF8oUghaRAx-OEN31z5cA&e= > vlan 6
> >
> > Worker host have following-bridge mappings configured:
> > worker-1: ovn-bridge-mappings="external-segment-1:br-ex"
> > worker-2: ovn-bridge-mappings="external-segment-2:br-ex"
> > and fabric physical interfaces connected to br-ex.
> >
> > In OVN both segments are connected to the same Logical_Switch 'public':
> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > ovn-nbctl list logical_switch_port
> > _uuid               : e80bbfef-e966-4973-bec2-2dad6c18b09c
> > addresses           : [unknown]
> > dhcpv4_options      : []
> > dhcpv6_options      : []
> > dynamic_addresses   : []
> > enabled             : []
> > external_ids        : {}
> > ha_chassis_group    : []
> > name                : public-segment-1-localnet
> > options             : {network_name=external-segment-1}
> > parent_name         : []
> > port_security       : []
> > tag                 : []
> > tag_request         : []
> > type                : localnet
> > up                  : false
> >
> > _uuid               : efdcbbed-dd97-4b09-9b96-0dd25a4d6f03
> > addresses           : [unknown]
> > dhcpv4_options      : []
> > dhcpv6_options      : []
> > dynamic_addresses   : []
> > enabled             : []
> > external_ids        : {}
> > ha_chassis_group    : []
> > name                : public-segment-2-localnet
> > options             : {network_name=external-segment-2}
> > parent_name         : []
> > port_security       : []
> > tag                 : []
> > tag_request         : []
> > type                : localnet
> > up                  : false
> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > I also spawned 2 VMS: vm1 - in external-segment-1 and vm2 - in
> > external-segment-2.
> >
> > *Conclusion*:
> > I *can* ping VMs from hosts connected to fabric [2], from host-1 I can
> > ping vm1 and from host-2 I can ping vm2.
> > I *do not see* any traffic from external-segment-1 on external-segment-2
> > and vice-versa.
> >
> > *However I spotted some issues*:
> > Unfortunately the ovn-controller on worker-1 and worker-2 are
> > continuously logging:
> > From worker-1:
> > patch|ERR|bridge not found for localnet port 'public-segment-2-localnet'
> > with network name 'external-segment-2'
> > From worker-2:
> > patch|ERR|bridge not found for localnet port 'public-segment-1-localnet'
> > with network name 'external-segment-1'
> >
> > *Questions*:
> > Can we try to log this kind of error only once in this situation?
> > So when there is a Logical_Switch, in which there are more than one
> > localnet ports added and chassis is placed in only one segment, can we
> > print this log only once and skip patch port plug-in until there would
> > be update of ovn-bridge-mappings for that chassis?
> > Do you find this architecture (multiple localnet ports in one
> > Logical_Switch) could lead us to some issues?
> >
>
>
> While this might seem to work out of the box, I'm afraid it's not a
> supported configuration. The implementation in ovn-northd expects at
> most one localnet port per logical switch:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_blob_v20.03.0_northd_ovn-2Dnorthd.c-23L542&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=dnm5Xllc9MgaZ6WtclTJSeQsYoeSaJ4mQqhoRSmN3YQ&e=
>
> If there would be multiple localnet ports per logical switch, only the
> last one would be saved:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_blob_v20.03.0_northd_ovn-2Dnorthd.c-23L2051&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=fMPrM75DH2sT35FGnxAyBsn-jbrIsM0vPN2ROyrbBIE&e=
>
> ovn-northd creates logical flows that use the localnet port json_key so
> having multiple localnet ports per LS would lead to having these flows
> properly installed *only* for the "last" localnet port in the logical
> switch.
>
> Some examples of flows that would need to explicitly consider multiple
> localnet ports:
> - Logical flows for DHCP responders for external ports:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_blob_v20.03.0_northd_ovn-2Dnorthd.c-23L6313&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=AmOuw5c9wqUqmoguoFgf81XP9aCJCVCsJuvrvNnstXo&e=
>
> - Logical flows that drop ARP requests for non-chassis-local ports
> received from localnet ports :
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_blob_v20.03.0_northd_ovn-2Dnorthd.c-23L6503&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=27u3zfu-1PCNp_iZ_ZKrDxEoRK0lF8n0PMcqrJ9OEpM&e=
>
> - Logical flows that flood of ARP requests on localnet ports:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_blob_master_northd_ovn-2Dnorthd.c-23L5922&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=1TSfvJLBJeZjt5W9HUE8nYHfxIJadxRiEOAwlP8bvdU&e=
>
> All scenarios above can be enhanced to take into account multiple
> localnet ports.
>
> However, there's also the case of East-West routing of traffic between
> localnet VLAN tagged logical switches for which ovn-chassis-mac-mappings
> should be configured in order to avoid running the routing pipeline
> multiple times:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_blob_v20.03.0_ovn-2Darchitecture.7.xml-23L1451&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=XlqGos8ICieMfQhUgb0ZRKF0x-QVQYDQO0HgRfSTubI&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ovn-2Dorg_ovn_commit_522911269f1422e1274cbfbe53035a3bb8f573eb&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=c5lYehct-A0eUTLL2CtFvXHsBT-7b7viKlDW5q7JIYs&e=
>
> As far as I remember this assumes too that there's only one localnet
> port per logical switch. CC-ing Ankur to confirm.
>
> Regards,
> Dumitru
>
> >
> > Thanks,
> > Maciej
> >
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_neutron_-2Bbug_1865889&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=lueaBh7WI0WgIuUNQSFl7vUvl6asNfFl-0rO6v2IkkQ&e=
> > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__imgur.com_a_hEI8Nin&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=gFxJriNYFd9r4jq-QhH4iS3xjG_GvLire3eQpWCAYj8&s=gSw3QLm3fO34Nnaa-spSJ-qhj2XU2CbCVq3ze4ZJrQc&e=
> >
> > --
> > Best regards,
> > Maciej Józefczyk
> >
> > _______________________________________________
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org<mailto:discuss at openvswitch.org>
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss [mail.openvswitch.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=7GwWk3F3TZ7GuGAdNId2AdRvqihzNb3ut76zrZZvE98&s=ckV0V7relupwHXuUIOhx0D5his2wMBLTdoTZz8UJ0r0&e=>

_______________________________________________
discuss mailing list
discuss at openvswitch.org<mailto:discuss at openvswitch.org>
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss [mail.openvswitch.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=7GwWk3F3TZ7GuGAdNId2AdRvqihzNb3ut76zrZZvE98&s=ckV0V7relupwHXuUIOhx0D5his2wMBLTdoTZz8UJ0r0&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200508/8067dddd/attachment-0001.html>


More information about the discuss mailing list