public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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.




      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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal