Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR
Hi Numan, Sorry, was a little tied up last week. Thanks a lot for trying out the N-S patch and providing feedback as well. Please find the replies inline. V9 has code changes handling the review comments. Appreciate your inputs. Regards, Ankur From: Numan Siddique Sent: Monday, May 20, 2019 4:31 AM To: Ankur Sharma Cc: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR On Mon, May 20, 2019 at 4:32 PM Numan Siddique mailto:nusid...@redhat.com>> wrote: Hi Ankur Please see below for my comments. On Sat, May 11, 2019 at 6:31 AM Ankur Sharma mailto:ankur.sha...@nutanix.com>> wrote: Hi Numan, Thanks for trying out the patch. Please find my comments inline. Regards, Ankur From: Numan Siddique mailto:nusid...@redhat.com>> Sent: Friday, May 10, 2019 5:44 AM To: Ankur Sharma mailto:ankur.sha...@nutanix.com>> Cc: ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org> Subject: Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR On Thu, May 9, 2019 at 4:29 AM Ankur Sharma mailto:ankur.sha...@nutanix.com>> wrote: Background: [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html [mail.openvswitch.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2018-2DOctober_353066.html&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=Xe3Tslf9dH-ojv6rVTjtfGBIkiWgIc0BQk9oKGZWVSA&e=> [2] https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=VkYkJsl7ZarJYttljqeT3mm4fxQB_wSWl05mmoSoGh8&e=> This Series: Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan backed distributed logical router. This patch: For North-South traffic, we need a chassis which will respond to ARP requests for router port coming from outside. For this purpose, we will reply upon gateway-chassis construct in OVN, on a logical router port, we will associate one or more chassis as gateway chassis. One of these chassis would be active at a point and will become entry point to traffic, bound for end points behind logical router coming from outside network (North to South). This patch make some enhancements to gateway chassis implementation to manage above used case. A. Do not replace router port mac with chassis mac on gateway chassis. This is done, because: i. Chassisredirect port is NOT a distributed port, hence we need not replace its mac address (which same as router port mac). ii. ARP cache will be consistent everywhere, i.e just like endpoints on OVN chassis will see configured router port mac as resolved mac for router port ip, outside endpoints will see that as well. iii. For implementing Network Address Translation. Although not a part of this series. But, follow up series would be having this feature and approach would rely upon sending packets to redirect chassis using chassis redirect router port mac as dest mac. B. Advertise router port GARP on gateway chassis. This is needed, especially if a failover happens and chassisredirect port moves to a new gateway chassis. Otherwise, there would be packet drops till outside router ARPs for router port ip again. Intention of this GARP is to update top of the rack (TOR) to direct router port mac to new hypervisor. Hence, we could have done the same using RARP as well, but because ovn-controller has implementation for GARP already, hence it did not look like worthy to add a RARP implementation just for this. C. For South to North traffic, we need not pass through gateway chassis, if there is no address transalation needed. For overlay networks, NATing is a must to talk to outside networks. However, for vlan backed networks, NATing is not a must, and hence in the absence of NATing configuration we need redirect the packet to gateway chassis. Signed-off-by: Ankur Sharma mailto:ankur.sha...@nutanix.com>> --- Hi Ankur, I am little confused with the approach taken here. I ran the tests added in this patch. I see below logical flows in the router pipeline *** table=1 (lr_in_ip_input ), priority=90 , match=(inport == "router-to-ls1" && arp.spa == 192.168.1.0/24 [192.168.1.0]<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.1.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=ybcxareUnxxe99NpytghpFAsZQVzSRxWNIjQG2F
Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR
On Mon, May 20, 2019 at 4:32 PM Numan Siddique wrote: > Hi Ankur > > Please see below for my comments. > > > > On Sat, May 11, 2019 at 6:31 AM Ankur Sharma > wrote: > >> Hi Numan, >> >> Thanks for trying out the patch. >> Please find my comments inline. >> >> Regards, >> Ankur >> >> >> >> *From:* Numan Siddique >> *Sent:* Friday, May 10, 2019 5:44 AM >> *To:* Ankur Sharma >> *Cc:* ovs-dev@openvswitch.org >> *Subject:* Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan >> backed DVR >> >> >> >> >> >> >> >> On Thu, May 9, 2019 at 4:29 AM Ankur Sharma >> wrote: >> >> Background: >> [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html >> [mail.openvswitch.org] >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2018-2DOctober_353066.html&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=Xe3Tslf9dH-ojv6rVTjtfGBIkiWgIc0BQk9oKGZWVSA&e=> >> [2] >> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing >> [docs.google.com] >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=VkYkJsl7ZarJYttljqeT3mm4fxQB_wSWl05mmoSoGh8&e=> >> >> This Series: >> Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan >> backed distributed logical router. >> >> This patch: >> For North-South traffic, we need a chassis which will respond to >> ARP requests for router port coming from outside. For this purpose, >> we will reply upon gateway-chassis construct in OVN, on a logical >> router port, we will associate one or more chassis as gateway chassis. >> >> One of these chassis would be active at a point and will become >> entry point to traffic, bound for end points behind logical router >> coming from outside network (North to South). >> >> This patch make some enhancements to gateway chassis implementation >> to manage above used case. >> >> A. >> Do not replace router port mac with chassis mac on gateway >> chassis. >> This is done, because: >> i. Chassisredirect port is NOT a distributed port, hence >>we need not replace its mac address >> (which same as router port mac). >> >>ii. ARP cache will be consistent everywhere, i.e just like >>endpoints on OVN chassis will see configured router port >>mac as resolved mac for router port ip, outside endpoints >>will see that as well. >> >> iii. For implementing Network Address Translation. Although >>not a part of this series. But, follow up series would >>be having this feature and approach would rely upon >>sending packets to redirect chassis using chassis redirect >>router port mac as dest mac. >> >> B. >> Advertise router port GARP on gateway chassis. >> This is needed, especially if a failover happens and >> chassisredirect port moves to a new gateway chassis. >> Otherwise, there would be packet drops till outside >> router ARPs for router port ip again. >> >> Intention of this GARP is to update top of the rack (TOR) >> to direct router port mac to new hypervisor. >> >> Hence, we could have done the same using RARP as well, but >> because ovn-controller has implementation for GARP already, >> hence it did not look like worthy to add a RARP implementation >> just for this. >> >> C. >> For South to North traffic, we need not pass through gateway >> chassis, if there is no address transalation needed. >> >> For overlay networks, NATing is a must to talk to outside networks. >> However, for vlan backed networks, NATing is not a must, and hence >> in the absence of NATing configuration we need redirect the packet >> to gateway chassis. >> >> Signed-off-by: Ankur Sharma >> --- >> >> >> >> >> >> Hi Ankur, >> >> >> >> I am little confused with the approach taken here. I ran the tests added >> in this patch. >> >> I see below logical flows in the router pipeline >> >> >> >> *** >> >> table=1 (lr_in_ip_input ), p
Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR
Hi Ankur Please see below for my comments. On Sat, May 11, 2019 at 6:31 AM Ankur Sharma wrote: > Hi Numan, > > Thanks for trying out the patch. > Please find my comments inline. > > Regards, > Ankur > > > > *From:* Numan Siddique > *Sent:* Friday, May 10, 2019 5:44 AM > *To:* Ankur Sharma > *Cc:* ovs-dev@openvswitch.org > *Subject:* Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan > backed DVR > > > > > > > > On Thu, May 9, 2019 at 4:29 AM Ankur Sharma > wrote: > > Background: > [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html > [mail.openvswitch.org] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2018-2DOctober_353066.html&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=Xe3Tslf9dH-ojv6rVTjtfGBIkiWgIc0BQk9oKGZWVSA&e=> > [2] > https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing > [docs.google.com] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=VkYkJsl7ZarJYttljqeT3mm4fxQB_wSWl05mmoSoGh8&e=> > > This Series: > Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan > backed distributed logical router. > > This patch: > For North-South traffic, we need a chassis which will respond to > ARP requests for router port coming from outside. For this purpose, > we will reply upon gateway-chassis construct in OVN, on a logical > router port, we will associate one or more chassis as gateway chassis. > > One of these chassis would be active at a point and will become > entry point to traffic, bound for end points behind logical router > coming from outside network (North to South). > > This patch make some enhancements to gateway chassis implementation > to manage above used case. > > A. > Do not replace router port mac with chassis mac on gateway > chassis. > This is done, because: > i. Chassisredirect port is NOT a distributed port, hence >we need not replace its mac address > (which same as router port mac). > >ii. ARP cache will be consistent everywhere, i.e just like >endpoints on OVN chassis will see configured router port >mac as resolved mac for router port ip, outside endpoints >will see that as well. > > iii. For implementing Network Address Translation. Although >not a part of this series. But, follow up series would >be having this feature and approach would rely upon >sending packets to redirect chassis using chassis redirect >router port mac as dest mac. > > B. > Advertise router port GARP on gateway chassis. > This is needed, especially if a failover happens and > chassisredirect port moves to a new gateway chassis. > Otherwise, there would be packet drops till outside > router ARPs for router port ip again. > > Intention of this GARP is to update top of the rack (TOR) > to direct router port mac to new hypervisor. > > Hence, we could have done the same using RARP as well, but > because ovn-controller has implementation for GARP already, > hence it did not look like worthy to add a RARP implementation > just for this. > > C. > For South to North traffic, we need not pass through gateway > chassis, if there is no address transalation needed. > > For overlay networks, NATing is a must to talk to outside networks. > However, for vlan backed networks, NATing is not a must, and hence > in the absence of NATing configuration we need redirect the packet > to gateway chassis. > > Signed-off-by: Ankur Sharma > --- > > > > > > Hi Ankur, > > > > I am little confused with the approach taken here. I ran the tests added > in this patch. > > I see below logical flows in the router pipeline > > > > *** > > table=1 (lr_in_ip_input ), priority=90 , match=(inport == > "router-to-ls1" && arp.spa == 192.168.1.0/24 [192.168.1.0] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.1.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=ybcxareUnxxe99NpytghpFAsZQVzSRxWNIjQG2F2K_A&e=> > && arp.tpa == 192.168.1.3 && arp.op == 1), action=(put_arp(inport, arp.spa, > arp.sha); eth.dst = eth.src; eth.src = 00:00:01:01:02:03; arp.op =
Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR
Hi Numan,
Thanks for trying out the patch.
Please find my comments inline.
Regards,
Ankur
From: Numan Siddique
Sent: Friday, May 10, 2019 5:44 AM
To: Ankur Sharma
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR
On Thu, May 9, 2019 at 4:29 AM Ankur Sharma
mailto:ankur.sha...@nutanix.com>> wrote:
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[mail.openvswitch.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2018-2DOctober_353066.html&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=Xe3Tslf9dH-ojv6rVTjtfGBIkiWgIc0BQk9oKGZWVSA&e=>
[2]
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
[docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU_edit-3Fusp-3Dsharing&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=VkYkJsl7ZarJYttljqeT3mm4fxQB_wSWl05mmoSoGh8&e=>
This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.
This patch:
For North-South traffic, we need a chassis which will respond to
ARP requests for router port coming from outside. For this purpose,
we will reply upon gateway-chassis construct in OVN, on a logical
router port, we will associate one or more chassis as gateway chassis.
One of these chassis would be active at a point and will become
entry point to traffic, bound for end points behind logical router
coming from outside network (North to South).
This patch make some enhancements to gateway chassis implementation
to manage above used case.
A.
Do not replace router port mac with chassis mac on gateway
chassis.
This is done, because:
i. Chassisredirect port is NOT a distributed port, hence
we need not replace its mac address
(which same as router port mac).
ii. ARP cache will be consistent everywhere, i.e just like
endpoints on OVN chassis will see configured router port
mac as resolved mac for router port ip, outside endpoints
will see that as well.
iii. For implementing Network Address Translation. Although
not a part of this series. But, follow up series would
be having this feature and approach would rely upon
sending packets to redirect chassis using chassis redirect
router port mac as dest mac.
B.
Advertise router port GARP on gateway chassis.
This is needed, especially if a failover happens and
chassisredirect port moves to a new gateway chassis.
Otherwise, there would be packet drops till outside
router ARPs for router port ip again.
Intention of this GARP is to update top of the rack (TOR)
to direct router port mac to new hypervisor.
Hence, we could have done the same using RARP as well, but
because ovn-controller has implementation for GARP already,
hence it did not look like worthy to add a RARP implementation
just for this.
C.
For South to North traffic, we need not pass through gateway
chassis, if there is no address transalation needed.
For overlay networks, NATing is a must to talk to outside networks.
However, for vlan backed networks, NATing is not a must, and hence
in the absence of NATing configuration we need redirect the packet
to gateway chassis.
Signed-off-by: Ankur Sharma
mailto:ankur.sha...@nutanix.com>>
---
Hi Ankur,
I am little confused with the approach taken here. I ran the tests added in
this patch.
I see below logical flows in the router pipeline
***
table=1 (lr_in_ip_input ), priority=90 , match=(inport ==
"router-to-ls1" && arp.spa == 192.168.1.0/24
[192.168.1.0]<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.1.0_24&d=DwMFaQ&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=fcURf-DmIv_hk0JTs77pyJpD2g1VjmREfKT2Ht3N7Fs&s=ybcxareUnxxe99NpytghpFAsZQVzSRxWNIjQG2F2K_A&e=>
&& arp.tpa == 192.168.1.3 && arp.op == 1), action=(put_arp(inport, arp.spa,
arp.sha); eth.dst = eth.src; eth.src = 00:00:01:01:02:03; arp.op = 2; /* ARP
reply */ arp.tha = arp.sha; arp.sha = 00:00:01:01:02:03; arp.tpa = arp.spa;
arp.spa = 192.168.1.3; outport = "router-to-ls1"; flags.loopback = 1; output;)
table=1 (lr_in_ip_input ), priority=90 , match=(inport ==
"router-to-ls1" && nd_ns && ip6.dst == {fe80::200:1ff:fe01:203,
ff02::1:ff01:203} && nd.target == fe80::200:1ff:fe01:203 &&
is_chassis_resident("cr-router-to-ls1")), action=(put_nd(inport, ip6.src,
nd.sll); nd_na_router { eth.src = 00:00:01:01:02:03; ip6.src =
fe80::200:1ff:fe01:203; nd.target
Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR
On Thu, May 9, 2019 at 4:29 AM Ankur Sharma
wrote:
> Background:
> [1]
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
> [2]
> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
>
> This Series:
> Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
> backed distributed logical router.
>
> This patch:
> For North-South traffic, we need a chassis which will respond to
> ARP requests for router port coming from outside. For this purpose,
> we will reply upon gateway-chassis construct in OVN, on a logical
> router port, we will associate one or more chassis as gateway chassis.
>
> One of these chassis would be active at a point and will become
> entry point to traffic, bound for end points behind logical router
> coming from outside network (North to South).
>
> This patch make some enhancements to gateway chassis implementation
> to manage above used case.
>
> A.
> Do not replace router port mac with chassis mac on gateway
> chassis.
> This is done, because:
> i. Chassisredirect port is NOT a distributed port, hence
>we need not replace its mac address
> (which same as router port mac).
>
>ii. ARP cache will be consistent everywhere, i.e just like
>endpoints on OVN chassis will see configured router port
>mac as resolved mac for router port ip, outside endpoints
>will see that as well.
>
> iii. For implementing Network Address Translation. Although
>not a part of this series. But, follow up series would
>be having this feature and approach would rely upon
>sending packets to redirect chassis using chassis redirect
>router port mac as dest mac.
>
> B.
> Advertise router port GARP on gateway chassis.
> This is needed, especially if a failover happens and
> chassisredirect port moves to a new gateway chassis.
> Otherwise, there would be packet drops till outside
> router ARPs for router port ip again.
>
> Intention of this GARP is to update top of the rack (TOR)
> to direct router port mac to new hypervisor.
>
> Hence, we could have done the same using RARP as well, but
> because ovn-controller has implementation for GARP already,
> hence it did not look like worthy to add a RARP implementation
> just for this.
>
> C.
> For South to North traffic, we need not pass through gateway
> chassis, if there is no address transalation needed.
>
> For overlay networks, NATing is a must to talk to outside networks.
> However, for vlan backed networks, NATing is not a must, and hence
> in the absence of NATing configuration we need redirect the packet
> to gateway chassis.
>
> Signed-off-by: Ankur Sharma
> ---
>
Hi Ankur,
I am little confused with the approach taken here. I ran the tests added in
this patch.
I see below logical flows in the router pipeline
***
table=1 (lr_in_ip_input ), priority=90 , match=(inport ==
"router-to-ls1" && arp.spa == 192.168.1.0/24 && arp.tpa == 192.168.1.3 &&
arp.op == 1), action=(put_arp(inport, arp.spa, arp.sha); eth.dst = eth.src;
eth.src = 00:00:01:01:02:03; arp.op = 2; /* ARP reply */ arp.tha = arp.sha;
arp.sha = 00:00:01:01:02:03; arp.tpa = arp.spa; arp.spa = 192.168.1.3;
outport = "router-to-ls1"; flags.loopback = 1; output;)
table=1 (lr_in_ip_input ), priority=90 , match=(inport ==
"router-to-ls1" && nd_ns && ip6.dst == {fe80::200:1ff:fe01:203,
ff02::1:ff01:203} && nd.target == fe80::200:1ff:fe01:203 &&
is_chassis_resident("cr-router-to-ls1")), action=(put_nd(inport, ip6.src,
nd.sll); nd_na_router { eth.src = 00:00:01:01:02:03; ip6.src =
fe80::200:1ff:fe01:203; nd.target = fe80::200:1ff:fe01:203; nd.tll =
00:00:01:01:02:03; outport = inport; flags.loopback = 1; output; };)
table=1 (lr_in_ip_input ), priority=90 , match=(inport ==
"router-to-ls2" && arp.spa == 192.168.2.0/24 && arp.tpa == 192.168.2.3 &&
arp.op == 1), action=(put_arp(inport, arp.spa, arp.sha); eth.dst = eth.src;
eth.src = 00:00:01:01:02:05; arp.op = 2; /* ARP reply */ arp.tha = arp.sha;
arp.sha = 00:00:01:01:02:05; arp.tpa = arp.spa; arp.spa = 192.168.2.3;
outport = "router-to-ls2"; flags.loopback = 1; output;)
table=1 (lr_in_ip_input ), priority=90 , match=(inport ==
"router-to-ls2" && nd_ns && ip6.dst == {fe80::200:1ff:fe01:205,
ff02::1:ff01:205} && nd.target == fe80::200:1ff:fe01:205 &&
is_chassis_resident("cr-router-to-ls2")), action=(put_nd(inport, ip6.src,
nd.sll); nd_na_router { eth.src = 00:00:01:01:02:05; ip6.src =
fe80::200:1ff:fe01:205; nd.target = fe80::200:1ff:fe01:205; nd.tll =
00:00:01:01:02:05; outport = inport; flags.loopback = 1; output; };)
But if I inspect the port_binding rows in the Southbound DB I don't see
"cr-router-to-ls1" and "cr-router-to-ls2".
I don't understand what's the purpose of these logical flows.
>From the patch I understand that you are trying to reply for the ARP
requests to the logical router ports on the gateway-chassis (where chassis
redirect port of the distributed
router p
