| Message ID | 4d35f64a-b98b-44a2-820f-cc72170c0f69@DESKTOP-LBPO59B.local |
|---|---|
| State | Deferred |
| Headers | show |
I don't understand this yet. The OVN logical router already has logic to reply to ICMP requests. Can you add some more explanation to the commit message?
IMO, following that discuss mail chain, it ends up here: https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331200.html I did not see any update to the test case to reproduce the problem. On 1 June 2017 at 04:28, 钢锁0918 <liw@dtdream.com> wrote: > that is for this problem[ovs-dev] [ovs-discuss] ovn: unsnat handling error > for Distributed Gatewayhttps://mail.openvswitch.org/pipermail/ovs- > dev/2017-April/330536.html > *****RTFSC***** > ------------------------------------------------------------------发件人：Ben > Pfaff <blp@ovn.org>发送时间：2017年6月1日(星期四) 07:32收件人：钢锁0918 <liw@dtdream.com>抄 > 送：dev <dev@openvswitch.org>主 题：Re: [ovs-dev] [PATCH] ovn-northd: Add > logical flows to reply ICMP echo requests for all the other router ports > connected to one switch > I don't understand this yet. The OVN logical router already has logic > to reply to ICMP requests. Can you add some more explanation to the > commit message? > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
On Thu, Jun 1, 2017 at 4:28 AM, 钢锁0918 <liw@dtdream.com> wrote: > that is for this problem[ovs-dev] [ovs-discuss] ovn: unsnat handling error > for Distributed Gatewayhttps://mail.openvswitch.org/pipermail/ovs- > dev/2017-April/330536.html I don't understand why this workaround is a good thing. In theory, all pings should succeed. The point of the ping is to test the datapath with an actual packet, to make sure that things work. Replying to the ping when you have gone less than half way to the endpoint seems to me to defeat the purpose. Mickey > > *****RTFSC***** > ------------------------------------------------------------------发件人：Ben > Pfaff <blp@ovn.org>发送时间：2017年6月1日(星期四) 07:32收件人：钢锁0918 <liw@dtdream.com>抄 > 送：dev <dev@openvswitch.org>主 题：Re: [ovs-dev] [PATCH] ovn-northd: Add > logical flows to reply ICMP echo requests for all the other router ports > connected to one switch > I don't understand this yet. The OVN logical router already has logic > to reply to ICMP requests. Can you add some more explanation to the > commit message? > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >
I read the code and find this
datapath/conntrack.c : 982
if (info->nat && !(key->ct_state & OVS_CS_F_NAT_MASK) &&
(nf_ct_is_confirmed(ct) || info->commit) &&
ovs_ct_nat(net, key, info, skb, ct, ctinfo) != NF_ACCEPT) {
return -EINVAL;
}
I think this may be the reason of that problem
the pipiline is nat-->imcp reply-->nat
the first nat set the ct_state, so the second nat do not execute
am i right?
在 2017/6/2 1:14, Mickey Spiegel 写道:
>
> On Thu, Jun 1, 2017 at 4:28 AM, 钢锁0918 <liw@dtdream.com
> <mailto:liw@dtdream.com>> wrote:
>
> that is for this problem[ovs-dev] [ovs-discuss] ovn: unsnat
> handling error for Distributed
> Gatewayhttps://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330536.html
> <http://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330536.html>
>
>
> I don't understand why this workaround is a good thing. In theory, all
> pings should succeed. The point of the ping is to test the datapath
> with an actual packet, to make sure that things work. Replying to the
> ping when you have gone less than half way to the endpoint seems to me
> to defeat the purpose.
>
> Mickey
>
>
> *****RTFSC*****
> ------------------------------------------------------------------发件人：Ben
> Pfaff <blp@ovn.org <mailto:blp@ovn.org>>发送时间：2017年6月1日(星期四)
> 07:32收件人：钢锁0918 <liw@dtdream.com
> <mailto:liw@dtdream.com>>抄 送：dev <dev@openvswitch.org
> <mailto:dev@openvswitch.org>>主 题：Re: [ovs-dev] [PATCH] ovn-northd:
> Add logical flows to reply ICMP echo requests for all the other
> router ports connected to one switch
> I don't understand this yet. The OVN logical router already has logic
> to reply to ICMP requests. Can you add some more explanation to the
> commit message?
> _______________________________________________
> dev mailing list
> dev@openvswitch.org <mailto:dev@openvswitch.org>
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>
>
>
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c index 83db75338..74e714d30 100644 --- a/ovn/northd/ovn-northd.c +++ b/ovn/northd/ovn-northd.c @@ -4192,6 +4192,63 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap *ports, /* Logical router ingress table 1: IP Input for IPv4. */ HMAP_FOR_EACH (op, key_node, ports) { if (!op->nbrp) { + if (!strcmp(op->nbsp->type, "router")) { + + /* This is a logical switch port that connects to a router. */ + + /* The peer of this switch port is the router port for which + * we need to add logical flows such that it can reply + * ICMP echo requests received for all the other router ports + * connected to the switch in question. + * This is similar to ARP Resolution in table 6. */ + + const char *peer_name = smap_get(&op->nbsp->options, + "router-port"); + if (!peer_name) { + continue; + } + + struct ovn_port *peer = ovn_port_find(ports, peer_name); + if (!peer || !peer->nbrp) { + continue; + } + + for (size_t i = 0; i < op->od->n_router_ports; i++) { + const char *router_port_name = smap_get( + &op->od->router_ports[i]->nbsp->options, + "router-port"); + struct ovn_port *router_port = ovn_port_find(ports, + router_port_name); + if (!router_port || !router_port->nbrp) { + continue; + } + + /* Skip the router port under consideration. */ + if (router_port == peer) { + continue; + } + + /* ICMP echo reply. These flows reply to ICMP echo requests + * received for the router's IP address. Since packets only + * get here as part of the logical router datapath, the inport + * (i.e. the incoming locally attached net) does not matter. + * The ip.ttl also does not matter (RFC1812 section 4.2.2.9) */ + ds_clear(&match); + ds_put_cstr(&match, "ip4.dst == "); + op_put_v4_networks(&match, router_port, false); + ds_put_cstr(&match, " && icmp4.type == 8 && icmp4.code == 0"); + + ds_clear(&actions); + ds_put_format(&actions, + "ip4.dst <-> ip4.src; " + "ip.ttl = 255; " + "icmp4.type = 0; " + "flags.loopback = 1; " + "next; "); + ovn_lflow_add(lflows, peer->od, S_ROUTER_IN_IP_INPUT, 90, + ds_cstr(&match), ds_cstr(&actions)); + } + } continue; }