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

Reply via email to