From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Alexandre Derumier <aderumier@odiso.com>
Subject: [pve-devel] applied: [PATCH pve-docs] sdn: add rp_filter sysctl tuning when mulitple evpn nodes are used
Date: Tue, 21 Mar 2023 09:20:02 +0100 [thread overview]
Message-ID: <e5cffa00-3038-df86-3ee1-a07f9f6f08dc@proxmox.com> (raw)
In-Reply-To: <20230321065307.2218261-1-aderumier@odiso.com>
Am 21/03/2023 um 07:53 schrieb Alexandre Derumier:
> Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
> ---
> pvesdn.adoc | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
applied, with touching up format and language slightly in a follow up, thanks!
> diff --git a/pvesdn.adoc b/pvesdn.adoc
> index be62769..d1ff036 100644
> --- a/pvesdn.adoc
> +++ b/pvesdn.adoc
> @@ -928,6 +928,19 @@ and 10.0.2.0/24 in this example), will be announced dynamically.
> Notes
> -----
>
> +Multiple EVPN Exit Nodes
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If you have multiple gateway nodes, disable rp_filter as packet could incoming in a 1 node, and outgoing
> +to another node.
> +
> +
> +sysctl.conf
> +-----
> +net.ipv4.conf.default.rp_filter=0
> +net.ipv4.conf.all.rp_filter=0
> +-----
I'm wondering, shouldn't setting this to 2 for the loose-mode (from RFC3704) be
enough here for such asymmetric routing? The sysctl docs say the following
> rp_filter - INTEGER
> 0 - No source validation.
> 1 - Strict mode as defined in RFC3704 Strict Reverse Path
> Each incoming packet is tested against the FIB and if the interface
> is not the best reverse path the packet check will fail.
> By default failed packets are discarded.
> 2 - Loose mode as defined in RFC3704 Loose Reverse Path
> Each incoming packet's source address is also tested against the FIB
> and if the source address is not reachable via any interface
> the packet check will fail.
>
> Current recommended practice in RFC3704 is to enable strict mode
> to prevent IP spoofing from DDos attacks. If using asymmetric routing
> or other complicated routing, then loose mode is recommended.
Wouldn't the (exit) address from the other node be in the FIB? I mean `0` obviously
works here and setups doing that are normally secured/firewalled/configured such
that it probably won't matter much, so asking mostly for my understanding.
The sysctl knob docs continue with:
> The max value from conf/{all,interface}/rp_filter is used
> when doing source validation on the {interface}.
>
> Default value is 0. Note that some distributions enable it
> in startup scripts.
So as the max value is used, this can still be overridden by interface specific
settings, or? The loose `2` option would have that problem, fwiw.
prev parent reply other threads:[~2023-03-21 8:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 6:53 [pve-devel] " Alexandre Derumier
2023-03-21 8:20 ` Thomas Lamprecht [this message]
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=e5cffa00-3038-df86-3ee1-a07f9f6f08dc@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=aderumier@odiso.com \
--cc=pve-devel@lists.proxmox.com \
/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