| Message ID | 1564703707-21545-4-git-send-email-ankur.sharma@nutanix.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | OVN: Vlan backed DVR, enable N-S packet flow | expand |
On Fri, Aug 2, 2019 at 5:24 AM Ankur Sharma <ankur.sharma@nutanix.com> wrote: > Background: > With c0974331b7a19a87ab8f1f2cec8fbe366af92fa2, we have added > support for E-W workflow for vlan backed DVRs. > > This series enables N-S workflow for vlan backed DVRs. > > Key difference between E-W and N-S traffic flow is that > N-S flow requires a gateway chassis. A gateway chassis > will be respondible for following: > a. Doing Network Address Translation (NAT). > b. Becoming entry and exit point for North->South > and South->North traffic respectively. > > OVN by default always uses overlay encapsulation to redirect > the packet to gateway chassis. This series will enable > the redirection to gateway chassis in the absence of encapsulation. > > This patch: > a. Make sure that ARP request for endpoint behind the gateway > router port is sent from gateway chassis only and not from > host(compute) chassis. > What do you mean by behind the gateway router port ? Suppose if 2 logical switches - s1 and s2 are connected to the logical router r1 and s3 which provides gateway connectivity is also connected to r1. If a logical port s1-p1 on s1 wants to reach to logical port s2-p1 on s2 , then the logical router pipeline on the compute node where s1-p1 is residing generates an arp request for s2-p1. With this patch the generated arp packet is sent to the gateway chassis where s3-r1 is residing and it replies with the arp response ? > b. This is achieved by adding a new logical flow in > lr_in_arp_resolve at priority=50. > > c. This flow run on non gateway chassis and sets the destination > mac to router port mac, if outport is a gateway chassis attached > router port and redirect-type is set as "vlan". > Example logical flow: > table=9 (lr_in_arp_resolve ), priority=50 , match=(outport == > "router-to-underlay" && !is_chassis_resident("cr-router-to-underlay")), > action=(eth.dst = 00:00:01:01:02:04; next;) > > d. This change is needed because other wise for non resolved ARPs, > we will end up doing get_arp in host chassis. Doing so will > have following issues: > i. We want all the interation with North bound endpoints via > gateway chassis only, doing so on host chassis will violate > that. > > ii. With get_arp, ovn-controller will generate the ARP using router > port's mac as source mac, which will lead us to the same issue, > where router port mac will be going through continous mac moves > in physical network. Worst, it would affect the redirection, > since it uses router port mac as destination mac. > > Signed-off-by: Ankur Sharma <ankur.sharma@nutanix.com> > --- > northd/ovn-northd.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c > index 7c0fd6c..ba38ef6 100644 > --- a/northd/ovn-northd.c > +++ b/northd/ovn-northd.c > @@ -7565,6 +7565,28 @@ build_lrouter_flows(struct hmap *datapaths, struct > hmap *ports, > 100, ds_cstr(&match), > ds_cstr(&actions)); > } > } > + > + if (op->nbrp->n_gateway_chassis && !op->derived) { > Right now we support 3 ways for gateway chassis 1. option "reside-on-chassis" should be set in the logical router port 2. The logical router port has gateway chassis set (which this patch takes into account) 3. The logical router port has ha_chassis_group set. I think we can ignore (1) as it is old and CMS should start using (2) or (3). The first priority is given to (3) if both are gateway_chassis and ha_chassis_group are set. So can you handle this scenario ? May be we can have a generic function which checks if the logical router port provides gateway functionality or not. Also can you update the ovn-northd.8.xml for the new flow you are adding ? Note that this series needs a rebase as its not applying on the current master. Thanks Numan + const char *redirect_type = smap_get(&op->nbrp->options, > + "redirect-type"); > + if (redirect_type && !strcasecmp(redirect_type, "vlan")) { > + /* Packet is on a non gateway chassis and > + * has an unresolved ARP on a network behind gateway > + * chassis attached router port. Since, redirect type > + * is set to vlan, hence instead of calling "get_arp" > + * on this node, we will redirect the packet to > gateway > + * chassis, by setting destination mac router port > mac.*/ > + ds_clear(&match); > + ds_put_format(&match, "outport == %s && " > + "!is_chassis_resident(%s)", > op->json_key, > + op->od->l3redirect_port->json_key); > + ds_clear(&actions); > + ds_put_format(&actions, "eth.dst = %s; next;", > + op->lrp_networks.ea_s); > + ovn_lflow_add(lflows, op->od, S_ROUTER_IN_ARP_RESOLVE, > + 50, ds_cstr(&match), ds_cstr(&actions)); > + } > + } > } else if (op->od->n_router_ports && strcmp(op->nbsp->type, > "router") > && strcmp(op->nbsp->type, "virtual")) { > /* This is a logical switch port that backs a VM or a > container. > -- > 1.8.3.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
Hi Numan, Thanks a lot for the review. Please find my comments inline. V4 will accommodate changes for review comments. Regards, Ankur From: Numan Siddique <nusiddiq@redhat.com> Sent: Thursday, August 8, 2019 12:13 AM To: Ankur Sharma <ankur.sharma@nutanix.com> Cc: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v3 3/4 ovn] OVN: Vlan backed DVR N-S, avoid get_arp on non redirect chassis. On Fri, Aug 2, 2019 at 5:24 AM Ankur Sharma <ankur.sharma@nutanix.com<mailto:ankur.sharma@nutanix.com>> wrote: Background: With c0974331b7a19a87ab8f1f2cec8fbe366af92fa2, we have added support for E-W workflow for vlan backed DVRs. This series enables N-S workflow for vlan backed DVRs. Key difference between E-W and N-S traffic flow is that N-S flow requires a gateway chassis. A gateway chassis will be respondible for following: a. Doing Network Address Translation (NAT). b. Becoming entry and exit point for North->South and South->North traffic respectively. OVN by default always uses overlay encapsulation to redirect the packet to gateway chassis. This series will enable the redirection to gateway chassis in the absence of encapsulation. This patch: a. Make sure that ARP request for endpoint behind the gateway router port is sent from gateway chassis only and not from host(compute) chassis. What do you mean by behind the gateway router port ? Suppose if 2 logical switches - s1 and s2 are connected to the logical router r1 and s3 which provides gateway connectivity is also connected to r1. If a logical port s1-p1 on s1 wants to reach to logical port s2-p1 on s2 , then the logical router pipeline on the compute node where s1-p1 is residing generates an arp request for s2-p1. With this patch the generated arp packet is sent to the gateway chassis where s3-r1 is residing and it replies with the arp response ? [ANKUR]: Endpoint behind the gateway router port mean endpoint on s3 (in your example). For s1-p1 to s2-p1 packet flow there is no change, Arp requests will be generated from compute chassis. b. This is achieved by adding a new logical flow in lr_in_arp_resolve at priority=50. c. This flow run on non gateway chassis and sets the destination mac to router port mac, if outport is a gateway chassis attached router port and redirect-type is set as "vlan". Example logical flow: table=9 (lr_in_arp_resolve ), priority=50 , match=(outport == "router-to-underlay" && !is_chassis_resident("cr-router-to-underlay")), action=(eth.dst = 00:00:01:01:02:04; next;) d. This change is needed because other wise for non resolved ARPs, we will end up doing get_arp in host chassis. Doing so will have following issues: i. We want all the interation with North bound endpoints via gateway chassis only, doing so on host chassis will violate that. ii. With get_arp, ovn-controller will generate the ARP using router port's mac as source mac, which will lead us to the same issue, where router port mac will be going through continous mac moves in physical network. Worst, it would affect the redirection, since it uses router port mac as destination mac. Signed-off-by: Ankur Sharma <ankur.sharma@nutanix.com<mailto:ankur.sharma@nutanix.com>> --- northd/ovn-northd.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c index 7c0fd6c..ba38ef6 100644 --- a/northd/ovn-northd.c +++ b/northd/ovn-northd.c @@ -7565,6 +7565,28 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap *ports, 100, ds_cstr(&match), ds_cstr(&actions)); } } + + if (op->nbrp->n_gateway_chassis && !op->derived) { Right now we support 3 ways for gateway chassis 1. option "reside-on-chassis" should be set in the logical router port 2. The logical router port has gateway chassis set (which this patch takes into account) 3. The logical router port has ha_chassis_group set. I think we can ignore (1) as it is old and CMS should start using (2) or (3). The first priority is given to (3) if both are gateway_chassis and ha_chassis_group are set. So can you handle this scenario ? May be we can have a generic function which checks if the logical router port provides gateway functionality or not. [ANKUR]: Agreed, will add a generic function. Also can you update the ovn-northd.8.xml for the new flow you are adding ? [ANKUR]: Sure. Note that this series needs a rebase as its not applying on the current master. [ANKUR]: Sure, will address merge conflicts in v4. Thanks Numan + const char *redirect_type = smap_get(&op->nbrp->options, + "redirect-type"); + if (redirect_type && !strcasecmp(redirect_type, "vlan")) { + /* Packet is on a non gateway chassis and + * has an unresolved ARP on a network behind gateway + * chassis attached router port. Since, redirect type + * is set to vlan, hence instead of calling "get_arp" + * on this node, we will redirect the packet to gateway + * chassis, by setting destination mac router port mac.*/ + ds_clear(&match); + ds_put_format(&match, "outport == %s && " + "!is_chassis_resident(%s)", op->json_key, + op->od->l3redirect_port->json_key); + ds_clear(&actions); + ds_put_format(&actions, "eth.dst = %s; next;", + op->lrp_networks.ea_s); + ovn_lflow_add(lflows, op->od, S_ROUTER_IN_ARP_RESOLVE, + 50, ds_cstr(&match), ds_cstr(&actions)); + } + } } else if (op->od->n_router_ports && strcmp(op->nbsp->type, "router") && strcmp(op->nbsp->type, "virtual")) { /* This is a logical switch port that backs a VM or a container. -- 1.8.3.1
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c index 7c0fd6c..ba38ef6 100644 --- a/northd/ovn-northd.c +++ b/northd/ovn-northd.c @@ -7565,6 +7565,28 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap *ports, 100, ds_cstr(&match), ds_cstr(&actions)); } } + + if (op->nbrp->n_gateway_chassis && !op->derived) { + const char *redirect_type = smap_get(&op->nbrp->options, + "redirect-type"); + if (redirect_type && !strcasecmp(redirect_type, "vlan")) { + /* Packet is on a non gateway chassis and + * has an unresolved ARP on a network behind gateway + * chassis attached router port. Since, redirect type + * is set to vlan, hence instead of calling "get_arp" + * on this node, we will redirect the packet to gateway + * chassis, by setting destination mac router port mac.*/ + ds_clear(&match); + ds_put_format(&match, "outport == %s && " + "!is_chassis_resident(%s)", op->json_key, + op->od->l3redirect_port->json_key); + ds_clear(&actions); + ds_put_format(&actions, "eth.dst = %s; next;", + op->lrp_networks.ea_s); + ovn_lflow_add(lflows, op->od, S_ROUTER_IN_ARP_RESOLVE, + 50, ds_cstr(&match), ds_cstr(&actions)); + } + } } else if (op->od->n_router_ports && strcmp(op->nbsp->type, "router") && strcmp(op->nbsp->type, "virtual")) { /* This is a logical switch port that backs a VM or a container.
Background: With c0974331b7a19a87ab8f1f2cec8fbe366af92fa2, we have added support for E-W workflow for vlan backed DVRs. This series enables N-S workflow for vlan backed DVRs. Key difference between E-W and N-S traffic flow is that N-S flow requires a gateway chassis. A gateway chassis will be respondible for following: a. Doing Network Address Translation (NAT). b. Becoming entry and exit point for North->South and South->North traffic respectively. OVN by default always uses overlay encapsulation to redirect the packet to gateway chassis. This series will enable the redirection to gateway chassis in the absence of encapsulation. This patch: a. Make sure that ARP request for endpoint behind the gateway router port is sent from gateway chassis only and not from host(compute) chassis. b. This is achieved by adding a new logical flow in lr_in_arp_resolve at priority=50. c. This flow run on non gateway chassis and sets the destination mac to router port mac, if outport is a gateway chassis attached router port and redirect-type is set as "vlan". Example logical flow: table=9 (lr_in_arp_resolve ), priority=50 , match=(outport == "router-to-underlay" && !is_chassis_resident("cr-router-to-underlay")), action=(eth.dst = 00:00:01:01:02:04; next;) d. This change is needed because other wise for non resolved ARPs, we will end up doing get_arp in host chassis. Doing so will have following issues: i. We want all the interation with North bound endpoints via gateway chassis only, doing so on host chassis will violate that. ii. With get_arp, ovn-controller will generate the ARP using router port's mac as source mac, which will lead us to the same issue, where router port mac will be going through continous mac moves in physical network. Worst, it would affect the redirection, since it uses router port mac as destination mac. Signed-off-by: Ankur Sharma <ankur.sharma@nutanix.com> --- northd/ovn-northd.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)