[ovs-discuss] [OVN] Routed provider networks
Numan Siddique
numans at ovn.org
Wed Apr 29 06:27:11 UTC 2020
On Tue, Apr 28, 2020 at 11:58 PM Ihar Hrachyshka <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>
> 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>
> > Sent: Wednesday, April 1, 2020 6:54 AM
> > To: Maciej Jozefczyk <mjozefcz at redhat.com>; ovs-discuss <
> ovs-discuss at openvswitch.org>
> > Cc: Ankur Sharma <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 <
> 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 <
> 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
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200429/4415709d/attachment-0001.html>
More information about the discuss
mailing list