netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trev Larock <trev@larock.ca>
To: David Ahern <dsahern@gmail.com>
Cc: Ben Greear <greearb@candelatech.com>, netdev@vger.kernel.org
Subject: Re: VRF + ip xfrm, egress ESP packet looping when qdisc configured
Date: Sun, 2 Feb 2020 22:13:30 -0500	[thread overview]
Message-ID: <CAHgT=KePvNSg9uU7SdG-9LwmwZZJkH7_FSXW+Yd5Y8G-Bd3gtA@mail.gmail.com> (raw)
In-Reply-To: <fe7ec5d0-73ed-aa8b-3246-39894252fec7@gmail.com>

On Mon, Jan 13, 2020 at 11:51 AM David Ahern <dsahern@gmail.com> wrote:
> Trev's problem is looping due to the presence of the qdisc. The vrf
> driver needs to detect that it has seen the packet and not redirect it
> again.
Yes note it was when specifying no dev on the xfrm policy/state.
For the non-qdisc case the policy triggered from the __ip4_datagram_connect->
xfrm_lookup and the vrf "direct" route sent it out without any xfrm_lookup call.
It appears to work but it's not really a "xfrm vrf specific " policy.

For qdisc the policy matched again on the vrf->xfrm_lookup call.

When specifying "dev vrf0" I don't see the policy get matched at all.
Should that be triggered in the vrf.c -> xfrm_lookup  call from
vrf_process_v4_outbound or elsewhere?

(The qdisc case seems more like the older / pre dcdd43c41e commit flow.)

From ftrace stack trace with qdisc and sending UDP packet with netcat
   nc-4391  [001] .... 11663.551103: xfrm_lookup <-xfrm_lookup_route
   nc-4391  [001] .... 11663.551104: <stack trace>
 => xfrm_lookup
 => xfrm_lookup_route
 => vrf_xmit
 => dev_hard_start_xmit
 => sch_direct_xmit
 => __qdisc_run
 => __dev_queue_xmit
 => vrf_finish_output
 => vrf_output
 => ip_send_skb
 => udp_send_skb
 => udp_sendmsg
 => sock_sendmsg
 => SYSC_sendto
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe

Full flow from vrf_xmit:
vrf_xmit
 -->is_ip_tx_frame
   -->vrf_process_v4_outbound
     -->ip_route_output_flow
       -->xfrm_lookup_route
         --> xfrm_lookup

In vrf_process_v4_outbound the flow sets ".flowi4_oif = vrf_dev->ifindex",
should that match the vrf ifindex or the network interface enslaved to the vrf?
I observe it's = network interface so matching a policy with dev vrf0
won't trigger, but not sure if it's missing config or some other issue.
Is there any reference/test sample configs for vrf+xfrm use case where
that matched policy as expected? (even on older kernel).

Thanks,
Trev


  reply	other threads:[~2020-02-03  4:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02 23:11 VRF + ip xfrm, egress ESP packet looping when qdisc configured Trev Larock
2020-01-03  4:44 ` David Ahern
2020-01-04  5:56   ` Trev Larock
2020-01-06  4:27     ` David Ahern
2020-01-06  5:58       ` Trev Larock
2020-01-07 22:59         ` Ben Greear
2020-01-13 16:48           ` David Ahern
2020-02-03  3:13             ` Trev Larock [this message]
2020-02-03  4:04               ` David Ahern
2020-02-21  4:52                 ` Trev Larock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHgT=KePvNSg9uU7SdG-9LwmwZZJkH7_FSXW+Yd5Y8G-Bd3gtA@mail.gmail.com' \
    --to=trev@larock.ca \
    --cc=dsahern@gmail.com \
    --cc=greearb@candelatech.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).