got it. thanks!
Hemanth Aramadaka <hemant...@acldigital.com> 于2022年4月8日周五 00:36写道: > Hi, > > > > Here we are not fragmenting VXLAN packets in the outer IP header.The > packets originating from VM with the larger size than the configured MTU > > will get fragmented and these inner packets are encapsulated with vxlan > header in which we have the different source ports for UDP. > > > > Thanks, > > Hemanth. > > > > *From:* Peng He <xnhp0...@gmail.com> > *Sent:* 16 March 2022 11:30 > *To:* Hemanth Aramadaka <hemant...@acldigital.com> > *Cc:* Sriharsha Basavapatna via dev <ovs-dev@openvswitch.org>; Ilya > Maximets <i.maxim...@ovn.org> > *Subject:* Re: [ovs-dev] [PATCH] flow: Consistent VXLAN UDP src ports for > fragmented packets > > > > Normally, VXLAN packets will be set to DF( don't frag) in the outter IP > header. > > I am trying to understand why fragmentation happens in the first place. > > > > Hemanth Aramadaka via dev <ovs-dev@openvswitch.org> 于2022年3月15日周二 22:38写道: > > Issue: > > The src-port for UDP is based on RSS hash in the packet metadata. > In case of packets coming from VM it will be 5-tuple, if available, > otherwise just IP addresses.If the VM fragments a large IP packet > and sends the fragments to ovs, only the first fragment will contain > the L4 header. Therefore, the first fragment and subsequent fragments > get different UDP src ports in the outgoing VXLAN header.This can > lead to fragment re-ordering in the fabric as packet will take > different paths. > > Fix: > > Intention of this is to avoid fragment packets taking different paths. > For example, due to presence of firewalls, fragment packets will take > different paths and will get dropped.To avoid this we ignore the L4 > header during hash calculation only in the case of fragmented packets. > > P.S: There is already a review request raised for the same. > https://mail.openvswitch.org/pipermail/ovs-dev/2021-January/379395.html. > Re-iterating the same patch request on the latest master code. > > Signed-off-by: Hemanth Aramadaka <hemant...@acldigital.com> > --- > lib/flow.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/lib/flow.c b/lib/flow.c > index dd523c889..17bd47724 100644 > --- a/lib/flow.c > +++ b/lib/flow.c > @@ -2238,7 +2238,7 @@ miniflow_hash_5tuple(const struct miniflow *flow, > uint32_t basis) > > if (flow) { > ovs_be16 dl_type = MINIFLOW_GET_BE16(flow, dl_type); > - uint8_t nw_proto; > + uint8_t nw_proto,nw_frag; > > if (dl_type == htons(ETH_TYPE_IPV6)) { > struct flowmap map = FLOWMAP_EMPTY_INITIALIZER; > @@ -2260,6 +2260,14 @@ miniflow_hash_5tuple(const struct miniflow *flow, > uint32_t basis) > > nw_proto = MINIFLOW_GET_U8(flow, nw_proto); > hash = hash_add(hash, nw_proto); > + /* Skip l4 header fields if IP packet is fragmented since > + * only first fragment will carry l4 header. > + */ > + nw_frag = MINIFLOW_GET_U8(flow, nw_frag); > + if ((nw_frag)) { > + goto out; > + } > + > if (nw_proto != IPPROTO_TCP && nw_proto != IPPROTO_UDP > && nw_proto != IPPROTO_SCTP && nw_proto != IPPROTO_ICMP > && nw_proto != IPPROTO_ICMPV6) { > -- > 2.25.1 > > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > > > -- > > hepeng > -- hepeng _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev