[ovs-dev] [PATCH ovn v2] Fix the routing for external logical ports of bridged logical switches.

Dumitru Ceara dceara at redhat.com
Thu Aug 13 10:49:54 UTC 2020


On 8/6/20 9:57 AM, Numan Siddique wrote:
> Thanks Ankur for the lengthy reply.
> 
> Please see below for some comments.
> 
> Thanks
> Numan
> 
> 
> On Thu, Jul 30, 2020 at 9:23 AM Ankur Sharma <ankur.sharma at nutanix.com>
> wrote:
> 
>> Hi Numan, Daniel, Lucas,
>>
>> Thank  you so much for the feedback and providing your inputs.
>> I went the through the bug that was being referenced and Numan's inputs
>> and following is my take on it.
>> Its a lengthy email, if you just want to look at the suggestions for fix
>> then please scroll to the second section :).
>>
>> Just taking a summary of the input/feedback points and the ones that are
>> most pertinent to the discussion.
>>
>> a. "Hard to colocate the the gateway ports of External port and Router
>> port"
>> [ANKUR]:  Looking at https://bugzilla.redhat.com/show_bug.cgi?id=1829762.
>> I do not see a reference to an attempt for using "HA Chassis group" (or
>> may be i missed it).
>> OVN has a primitive which allows a HA chassis cluster to be shared across
>> multiple entities. I like this primitive, i think it can be easily used
>> here.
>> And the whole purpose of having a separate table for HA chassis group is
>> so that it can be shared.
>> Other than openstack implementation, if there are other hindrances in
>> adopting it then we should try to address the same in OVN.
>>
>> b. " if you see the logical swithes ls_vlan4 and ls_vlan5 in this example
>> don't provide any N/S connectivity and hence it may not be accurate
>> to consider them as having gateway ports."
>> [ANKUR]: Its just the terminology and its interpretation, i.e what is our
>> interpretation of NS traffic and gateway ports.
>> From the router's perspective, all we are trying to say is that for a
>> distributed router port, if we receive traffic from non OVN endpoint
>> (i.e entry point to chassis is localnet port), then we need to have a
>> specific designated chassis which is the entry point for ARP and Unicast
>> traffic.
>>
>> Now, the existing gateway port primitive does exactly what i have
>> described above. However, if we want to use some other
>> term for discussion/documentation, i am totally fine with it.
>>
>>
>> c. "ideally there should be no external entity sharing the IP address from
>> these subnets and using the same VLAN. Although practically it's possible
>> to do so"
>> [ANKUR]: Even in an ideal world its a valid requirement. Especially for
>> vlan backed subnets, it is a valid and practical use case where OVN does
>> not own
>> the whole ip space of a CIDR. For example, there could be baremetal
>> endpoints or there is a transition phase of migrating virtual non ovn
>> endpoints
>> to ovn, or to avoid the pain of migration there are both ovn and non ovn
>> virtual endpoints in same subnet, similarly there could be
>> stretched subnet across sites (hybrid cloud use case), where both sites
>> (and both of them need not be OVN run)
>> manage non overlapping ip pools for their respective endpoints.
>>
>>
>> d.  " If there is such a requirement, I think CMS should consider using
>> 'external' port for this"
>> [ANKUR]: Use of external port is that we leverage on DHCP service by OVN
>> for non ovn endpoints.
>> Which is definitely good to have, but not mandatory (infact it MUST not be
>> mandatory).
>> A deployment could have its own external DHCP server even for ovn
>> endpoints or
>> external dhcp server for non ovn endpoints or non ovn endpoints have
>> static IPs.
>> Neither of which mandates that non ovn endpoint has to be marked as
>> external.
>> Infact, for hybrid connectivity cases like (like stretched subnets across
>> sites/AZs as mentioned in c. above),
>> mandating DHCP service for whole CIDR by OVN would be non desirable.
>> TOR gateway is also a non ovn endpoint :).
>>
>>
>> ======================================
>>
>> ALTERNATIVE PROPOSALS:
>> There are multiple ways the scenario called out in this thread can be
>> addressed.
>>
>> a. Remove the "ls_in_external_port" stage in pipeline. For example, in the
>> topology mentioned here:
>>
>> https://docs.google.com/document/d/117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls/edit?usp=sharing
>>
>> I see following flows in "ls_in_external_port":
>>   table=18(ls_in_external_port), priority=100  , match=(inport ==
>> "ls-underlay-physnet1" && eth.src == 50:6b:8d:cc:17:7d &&
>> !is_chassis_resident("lsp-external") && arp.tpa == 10.15.24.135 && arp.op
>> == 1), action=(drop;)
>>   table=18(ls_in_external_port), priority=100  , match=(inport ==
>> "ls-underlay-physnet1" && eth.src == 50:6b:8d:cc:17:7d &&
>> !is_chassis_resident("lsp-external") && nd_ns && ip6.dst ==
>> {fe80::200:1ff:fe01:204, ff02::1:ff01:204} && nd.target ==
>> fe80::200:1ff:fe01:204), action=(drop;)
>>   table=18(ls_in_external_port), priority=0    , match=(1), action=(next;)
>>
>> My opinion/understanding is that it is on router to decide where it wants
>> router port ARP to be resolved. A logical switch port cannot/should not
>> decide, where it want the attached router port ip to be resolved.
>> If we do not have above flow, then it implies that significance of
>> HA_Chassis group for external port is to call out which chassis will behave
>> like a DHCP server for a given external endpoint.
>> For regular datapath operations, packet flow stays consistent with any
>> external/non ovn endpoint.
>>
> 
> If we don't have this, then the broadcast ARP packet from the external
> port  will be handled by all the ovn-controllers and you will see 'n' ARP
> replies for 1 ARP request from the external port (or any other external
> entity) where
> 'n' is the number of ovn-controllers which can receive this ARP request.
> 
> We still have this issue for ARP requests from external entities (without
> having an external port in the OVN NB DB).  So I don't think removing
> "ls_in_external_port" will solve the issue.
> 
> Since the router pipeline is distributed in OVN, one solution is to
>    - Centralize the routing for VLAN based provider networks in OVN. And
> that's why we added the support of "option - reside-on-redirect-chassis".
> 
> But I think you added the chassis specific MACs to have distributed routing
> for provider VLAN networks. And Openstack neutron wants to leverage this.
> 
> Lets say we remove "ls_in_external_port" and instead handle this in the
> router pipeline, we can't really differentiate if the ARP request came from
> a localnet port
> or from an internal logical port (for E-W traffic). If we pin the router ip
> to a specific chassis, then we can't have distributed routing.
> 
> In the case of distributed gateway router ports, it is expected to be
> centralized anyway. But we can't have the same assumption for internal VLAN
> provider logical switches.
> 
> To summarize, I think
>    - The traffic from external entities to the router IP is broken anyway
>    - And this patch tries to solve only for external ports and not for
> other external entities.
> 
> To be clear, I want to give an example of an external entity and how it is
> broken now. If we have VLAN logical switch ls_vlan4 (with cidr - 10.0.0.0/24
> and the router IP - 10.0.0.1 and router mac V4_ROUTER_MAC)
> and another logical switch ls_vlan5 (with cidr - 20.0.0.0/24 and router IP
> - 20.0.0.1). And there is an external entity with IP - 10.0.0.100 (for
> which there is no logical port in OVN) which I will refer below as
> 10.0.0.100 machine.
> 
> When 10.0.0.100  machine wants to ping to 20.0.0.4 (which could be an OVN
> logical port or another external entity) and when it sends an ARP packet
> for 10.0.0.1, there will be 'n' ARP replies
> as I mentioned above. All these ARP replies will give the same arp.sha  -
> V4_ROUTER_MAC in the ARP reply but each reply will have chassis MAC as
> source MAC.
> So 10.0.0.100 machine will send the ICMP packet with eth.dst set to the
> V4_ROUTER_MAC and this packet will get dropped because the ToR don't know
> who has V4_ROUTER_MAC.
> 
> With this patch applied, 10.0.0.4 machine will again see 'n' ARP replies
> but with arp.sha as - CHASSIS_MAC<n>. This would also result in the failure.
> 
> But it will work for external ports as only one chassis will reply (thanks
> to HA_Chassis_group) with the arp.sha as CHASSIS_MAC ( instead of
> V4_ROUTER_MAC).
> 
> I think this patch should be Ok now. And once we support proper routing of
> external entities, the behaviour added by this patch will go away as we
> will address the issue properly.
> At this point I don't have any approach to solve this issue.
> 
> Let me know your thoughts.
> 
> Thanks
> Numan
> 
> 
>> If at all the stage was meant to have additional work, then atleast the
>> flows at priority=100 should not be there.
>>
>> P.N: I have not tried removing the above flow and testing end to end. It
>> is possible, some additional changes could be needed.
>> Will be identify the same, once i give it a try.
>>
>> b. If we still want to keep the pipeline stage and priority=100 flows,
>> then change the is_chassis_resident check to the attached router port,
>> rather than external logical switch port.
>>
>> c. I am assuming that HA_Chassis_group was not used by openstack. If that
>> is correct, then openstack can/should use Ha_Chassis_group and attach the
>> same group to both external LSP and Logical Router.
>>
>> ========================================
>>
>> IMO, the patch discussed in this thread and b. and c. above are all
>> workarounds.
>> a. above seems to be a no workaround and clean solution (will give it a
>> try and validate that it is working fine).
>> However, i will leave it open for further discussion.
>>
>> ========================================
>>
>> I do not intend to block/delay the patch/fix.
>> However, i am strongly opinionated against having a solution that breaks
>> the fundamental of having a consistent ARP cache.
>> I would definitely recommend that we avoid taking this path.
>>
>> Please let me know your thoughts.
>> Please feel free to call out, if i missed something, i will be happy to
>> discuss further.
>>
>>
>> Appreciate the discussions and inputs.
>>
>>
> 
> 
> 
>> Regards,
>> Ankur
>>
>>
>> From: dev <ovs-dev-bounces at openvswitch.org> on behalf of Ankur Sharma <
>> ankur.sharma at nutanix.com>
>> Sent: Saturday, July 25, 2020 10:09 PM
>> To: Numan Siddique <numans at ovn.org>; Daniel Alvarez Sanchez <
>> dalvarez at redhat.com>; Lucas Alvares Gomes Martins <lmartins at redhat.com>
>> Cc: dev at openvswitch.org <dev at openvswitch.org>
>> Subject: Re: [ovs-dev] [PATCH ovn v2] Fix the routing for external logical
>> ports of bridged logical switches.
>>
>> Hi Numan,
>>
>> Sorry, was a little out of sync with mailing list this week.
>> I will get back to you sometime early next week.
>> But yes, using chassis mac for router port ip is not correct ?.
>>
>> Let me check the scenario you have called out and will try to propose
>> alternatives.
>>
>> Regards,
>> Ankur
>> ________________________________
>> From: Numan Siddique <numans at ovn.org>
>> Sent: Wednesday, July 22, 2020 12:24 PM
>> To: Ankur Sharma <ankur.sharma at nutanix.com>; Daniel Alvarez Sanchez <
>> dalvarez at redhat.com>; Lucas Alvares Gomes Martins <lmartins at redhat.com>
>> Cc: dev at openvswitch.org <dev at openvswitch.org>
>> Subject: Re: [ovs-dev] [PATCH ovn v2] Fix the routing for external logical
>> ports of bridged logical switches.
>>
>>
>>
>> On Mon, Jul 13, 2020 at 11:56 AM Numan Siddique <numans at ovn.org<mailto:
>> numans at ovn.org>> wrote:
>> +Daniel Alvarez Sanchez<mailto:dalvarez at redhat.com>
>> +Lucas Alvares Gomes Martins<mailto:lmartins at redhat.com>
>>
>>
>> On Mon, Jul 13, 2020 at 11:29 AM Ankur Sharma <ankur.sharma at nutanix.com
>> <mailto:ankur.sharma at nutanix.com>> wrote:
>> Hi Numan,
>>
>> Thank you so much for the details.
>>
>>
>> Hi Ankur,
>>
>> Thanks for the detailed email. Your analysis is correct. I have few
>> comments.
>> Please see below.
>>
>>
>>
>> Hi Ankur,
>>
>> Did you get any chance to look into my comments ? Just checking.
>>
>> Thanks
>> Numan
>>
>> Following is my analysis on the feature:
>> a. Port of type EXTERNAL means that we create a logical switch port in OVN
>> without a VIF backing.
>> b. i.e the physical port corresponding to external port is NOT behind OVN
>> managed vswitch (for SRIOV specific case it is not behind any vswitch,
>> since PNIC sends the packet directly yo guest driver).
>>     Just for the sake of further discussion we will refer the PHYSICAL
>> PORT/VM corresponding to external port as SRIOV PORT/VM.
>> c. Now from OVN perspective, packets from SRIOV VM will enter the OVN flow
>> pipeline via localnet port (on the Active HA Chassis).
>> d. For DHCP requests, the logical switch pipeline responds.
>> e. Now, we were trying to get the routing working.
>>
>> Based on the understanding mentioned above, i tried following scenario and
>> observed following:
>> a. SRIOV VM could talk to endpoints on other LS attached to LR via Active
>> gateway/HA chassis.
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls_edit-3Fusp-3Dsharing&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=d13SMOucZAjzR7ArHHuztyRleXuYULUleLUW2KOFOq4&s=ESEBFx9KvUt06OhY-MYsFx3b262zXG-qneCnHc-UsH8&e=
>> [docs.google.com]<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=q9WWbrPUDgiU93U-DOJVxeEpK79REZSrErU_ee0qu9Y&e=
>>>
>> [
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lh5.googleusercontent.com_vhEZ3Ws4BXXkqoxc7naEXKPFC9qMqhJxKhumRzSyXsw9L1jbDc4B4r8cHBZZfOl9J6vYwgtyVA-3Dw1200-2Dh630-2Dp&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=d13SMOucZAjzR7ArHHuztyRleXuYULUleLUW2KOFOq4&s=pMXdAlIutqtFfXl2-TKHUaRnT3iUuz1WV_mUDT4aNWQ&e=
>> [lh5.googleusercontent.com]<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lh5.googleusercontent.com_vhEZ3Ws4BXXkqoxc7naEXKPFC9qMqhJxKhumRzSyXsw9L1jbDc4B4r8cHBZZfOl9J6vYwgtyVA-3Dw1200-2Dh630-2Dp&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=zWkviN5FVfZhl1x3GjkIGBx_wv0RtwbpS6TdnKbhnrw&e=
>>> ]<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls_edit-3Fusp-3Dsharing&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=d13SMOucZAjzR7ArHHuztyRleXuYULUleLUW2KOFOq4&s=ESEBFx9KvUt06OhY-MYsFx3b262zXG-qneCnHc-UsH8&e=
>> [docs.google.com]<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=q9WWbrPUDgiU93U-DOJVxeEpK79REZSrErU_ee0qu9Y&e=
>>>>
>> OVN EXTERNAL PORT ROUTING<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls_edit-3Fusp-3Dsharing&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=d13SMOucZAjzR7ArHHuztyRleXuYULUleLUW2KOFOq4&s=ESEBFx9KvUt06OhY-MYsFx3b262zXG-qneCnHc-UsH8&e=
>> [docs.google.com]<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_117yskeP1S3qHmkNrBrZ0PxXCvMJCCVJhcPG4phw1Qls_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=q9WWbrPUDgiU93U-DOJVxeEpK79REZSrErU_ee0qu9Y&e=
>>>>
>> OVN EXTERNAL PORT EW ROUTING LOGICAL TOPOLOGY CONFIGURATION LOGICAL ROUTER
>> router 2bd894b1-81a0-4095-9c58-0472aa5de19d (router) port router-to-gvlan1
>> mac: "00:00:01:01:02:03" networks: ["20.0.0.1/24 [20.0.0.1]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__20.0.0.1_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=o1WHBD0yoZB2GnoKY2cWk4q_C14mkgDQubaYD79mkLQ&e=>"]
>> port router-to-underlay mac: "00:00:01:01:02:...
>> docs.google.com [docs.google.com]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.google.com&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=Ydg_oGnKmSxu8Rlf_mAuGxENj4UChWZZJQ5Ezxa463U&e=
>>>
>>
>> Explanation:
>> a. Since packets are coming through localnet port, hence from Router
>> perspective, it is an external endpoint, i.e NS.
>> b. Now for such cases, Router is designed to respond to ARP requests ONLY
>> on gateway chassis and since we have centralized a chassis for NS now,
>> hence from the Gateway chassis there is no MAC replacement.
>> c. Based on a. and b. above, i attached the same gateway chassis to LRP
>> (Logical Router Port) connecting to SRIOV PORT's LS.
>> d. And routing across LR connected Switches worked fine.
>> e. Mac table on TOR and ARP table on SRIOV VM was also fine, i.e ARP cache
>> had <router_port_ip, router_port_mac> and Mac table had an entry for router
>> port mac.
>>
>>
>> Inference:
>> a. For Routing, traffic from localnet ports has to enter via gateway node.
>> b. Hence, the Router port which connects to SR IOV VM Logical Switch has
>> to be on same gateway node as corresponding external port (Which can be
>> achieved easily by attaching same HA chassis group to both).
>>
>> If you see the BZ here -
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1829762&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=d13SMOucZAjzR7ArHHuztyRleXuYULUleLUW2KOFOq4&s=kvkYAQLskHW7IrwhfOGkFofv3Tc_j4-2BGCWlYIonOA&e=
>> [bugzilla.redhat.com]<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1829762&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=0ZBIcnulyCrwKbstGcM2psoQCIR6F0YDVsXvP-YF7iw&e=>,
>> Openstack networking ovn folks want this to be decoupled. According to
>> them, it will be hard to maintain the logic to collocate the
>> ha chassis group of external ports with the gateway chassis ports. I have
>> CC'd them to get more comments from them.
>>
>> There is another problem:
>> Let's say we have 3 logical switches - ls_vlan4 (10.0.0.0/24 [10.0.0.0]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=2K0vGKF-mjJV80OtEXORywOzBS6KeQMuLAs1q5zQcOI&e=>)
>> , ls_vlan5 (20.0.0.0/24 [20.0.0.0]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__20.0.0.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=J7YUlV90oAkrtEjxJRUp48CU_CCaJH3xbTw6ogMTCrM&e=>)
>> and ls_public (172.168.0.0/24 [172.168.0.0]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__172.168.0.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=R1Qt7cK-4GsM3taBChEjienzfbVMD25YtgGxQKSTv70&e=>)
>> connected to a logical router lr0. And all are VLAN bridge networks
>> but only ls_public provides N/S traffic. ls_vlan4 and ls_vlan5 are tenant
>> bridged networks. I think this is a very common use case.
>>
>> In this scenario, you will have one l3gateway port - lr0-public
>> connecting to logical switch ls_public. So there will be a set of
>> gateway_chassis created for this.
>>
>> To solve this issue, we can also make the router ports - lr0-vlan4 and
>> lr0-vlan5 (connecting to logical switches ls_vlan4 and ls_vlan5) as gateway
>> ports by (once we enhance OVN
>> to support multiple gateway ports), but if you see the logical swithes
>> ls_vlan4 and ls_vlan5 in this example don't provide any N/S connectivity
>> and hence it may not be accurate
>> to consider them as having gateway ports.
>>
>> And the subnets (here 10.0.0.0/24 [10.0.0.0]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=2K0vGKF-mjJV80OtEXORywOzBS6KeQMuLAs1q5zQcOI&e=>
>> and 20.0.0.0/24 [20.0.0.0]<
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__20.0.0.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=r_sUw9ByTfcTEhmuWQtqLg4QqGyztY08TjYbxFEYg_8&s=J7YUlV90oAkrtEjxJRUp48CU_CCaJH3xbTw6ogMTCrM&e=>)
>> of ls_vlan4 and ls_vlan5 are internal to OVN and ideally there should be no
>> external entity sharing the IP address from these subnets and using the same
>> VLAN. Although practically it's possible to do so. If there is such a
>> requirement, I think CMS should consider using 'external' port for this. I
>> had noticed the issue you mentioned below in (c) long time back,
>> I didn't think to bother much because of the reason I mentioned now. (i.e
>> these subnets are internal to OVN)
>>
>> That's why I think it may be OK to take the approach of this patch. i.e
>> replace the chassis mac with the actual router mac in the ARP replies for
>> the router IPs.
>>
>> In the case of ls_public (which provides N/S connectivity) I would expect
>> an external router to handle routing for this. Please correct me if I'm
>> wrong.
>>
>> Let me know your thoughts.
>>
>> Thanks
>> Numan
>>

Hi Numan,

I agree with Ankur that we shouldn't be using the chassis mac when
replying to ARP requests. The chassis mac should be OVN internal and
shouldn't leak to the external network.

However, I've been trying some things out and I think that if the CMS
can ensure that external ports connected to the same logical switch are
always resident on the same chassis, i.e.,
is_chassis_resident(ext-port1) and is_chassis_resident(ext-portx) return
true for the same chassis, then we could use the same approach we use
now for restricting which chassis to reply to ARP requests:

# This flow exists in OVN right now and restricts ARP requests only on
chassis where the external port is resident.
  table=18(ls_in_external_port), priority=100  , match=(inport ==
"ln-sw0" && eth.src == 50:54:00:00:00:10 &&
!is_chassis_resident("sw0-ext1") && arp.tpa == 10.0.0.1 && arp.op == 1),
action=(drop;)

# This flow could be added to OVN to restrict all IP traffic that needs
to be routed, that is with dmac == router-port-mac to the chassis where
the external port is resident.
  table=18(ls_in_external_port), priority=100  , match=(inport ==
"ln-sw0" && eth.src == 50:54:00:00:00:10 &&
!is_chassis_resident("sw0-ext1") && eth.dst == 00:00:00:00:ff:01 &&
ip4), action=(drop;)

This way we ensure that we always reply to IP packets destined to the
router only on the chassis where we also reply to ARP requests. As
mentioned above, if the CMS makes sure that external ports are always
resident on the same chassis then this shouldn't create an issue for E-W
traffic either.

What do you think?

Thanks,
Dumitru



More information about the dev mailing list