Hi Ihar, Got it, makes sense. I believe generic filter would be to look for "inport=INACTIVE_LOCALNET_PORT".
Regards, Ankur ________________________________ From: Ihar Hrachyshka <ihrac...@redhat.com> Sent: Thursday, May 7, 2020 9:51 PM To: Ankur Sharma <ankur.sha...@nutanix.com>; Numan Siddique <num...@ovn.org> Cc: ovs-discuss <ovs-discuss@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 <num...@ovn.org><mailto:num...@ovn.org> Sent: Tuesday, April 28, 2020 11:27 PM To: Ihar Hrachyshka <ihrac...@redhat.com><mailto:ihrac...@redhat.com> Cc: Ankur Sharma <ankur.sha...@nutanix.com><mailto:ankur.sha...@nutanix.com>; ovs-discuss <ovs-discuss@openvswitch.org><mailto:ovs-discuss@openvswitch.org> Subject: Re: [ovs-discuss] [OVN] Routed provider networks On Tue, Apr 28, 2020 at 11:58 PM Ihar Hrachyshka <ihrac...@redhat.com<mailto:ihrac...@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.sha...@nutanix.com<mailto:ankur.sha...@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 <dce...@redhat.com<mailto:dce...@redhat.com>> > Sent: Wednesday, April 1, 2020 6:54 AM > To: Maciej Jozefczyk <mjoze...@redhat.com<mailto:mjoze...@redhat.com>>; > ovs-discuss <ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>> > Cc: Ankur Sharma <ankur.sha...@nutanix.com<mailto:ankur.sha...@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 > disc...@openvswitch.org<mailto:disc...@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 disc...@openvswitch.org<mailto:disc...@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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss