2020-04-28 06:01:49 +08:00
|
|
|
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
|
|
|
=========
|
|
|
|
IP Sysctl
|
|
|
|
=========
|
|
|
|
|
|
|
|
/proc/sys/net/ipv4/* Variables
|
|
|
|
==============================
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
ip_forward - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 0 - disabled (default)
|
|
|
|
- not 0 - enabled
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
Forward Packets between interfaces.
|
|
|
|
|
|
|
|
This variable is special, its change resets all configuration
|
|
|
|
parameters to their default state (RFC1122 for hosts, RFC1812
|
|
|
|
for routers)
|
|
|
|
|
|
|
|
ip_default_ttl - INTEGER
|
2010-12-14 04:50:49 +08:00
|
|
|
Default value of TTL field (Time To Live) for outgoing (but not
|
|
|
|
forwarded) IP packets. Should be between 1 and 255 inclusive.
|
|
|
|
Default: 64 (as recommended by RFC1700)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-12-14 12:13:45 +08:00
|
|
|
ip_no_pmtu_disc - INTEGER
|
|
|
|
Disable Path MTU Discovery. If enabled in mode 1 and a
|
2013-12-14 11:42:13 +08:00
|
|
|
fragmentation-required ICMP is received, the PMTU to this
|
2021-12-30 11:28:56 +08:00
|
|
|
destination will be set to the smallest of the old MTU to
|
|
|
|
this destination and min_pmtu (see below). You will need
|
2013-12-14 11:42:13 +08:00
|
|
|
to raise min_pmtu to the smallest interface MTU on your system
|
|
|
|
manually if you want to avoid locally generated fragments.
|
2013-12-14 12:13:45 +08:00
|
|
|
|
|
|
|
In mode 2 incoming Path MTU Discovery messages will be
|
|
|
|
discarded. Outgoing frames are handled the same as in mode 1,
|
|
|
|
implicitly setting IP_PMTUDISC_DONT on every created socket.
|
|
|
|
|
2018-06-04 18:07:37 +08:00
|
|
|
Mode 3 is a hardened pmtu discover mode. The kernel will only
|
2014-01-09 17:01:17 +08:00
|
|
|
accept fragmentation-needed errors if the underlying protocol
|
|
|
|
can verify them besides a plain socket lookup. Current
|
|
|
|
protocols for which pmtu events will be honored are TCP, SCTP
|
|
|
|
and DCCP as they verify e.g. the sequence number or the
|
|
|
|
association. This mode should not be enabled globally but is
|
|
|
|
only intended to secure e.g. name servers in namespaces where
|
|
|
|
TCP path mtu must still work but path MTU information of other
|
|
|
|
protocols should be discarded. If enabled globally this mode
|
|
|
|
could break other protocols.
|
|
|
|
|
|
|
|
Possible values: 0-3
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-12-14 11:42:13 +08:00
|
|
|
Default: FALSE
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
min_pmtu - INTEGER
|
2023-01-30 07:10:48 +08:00
|
|
|
default 552 - minimum Path MTU. Unless this is changed manually,
|
2021-12-30 11:28:56 +08:00
|
|
|
each cached pmtu will never be lower than this setting.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-01-09 17:01:15 +08:00
|
|
|
ip_forward_use_pmtu - BOOLEAN
|
|
|
|
By default we don't trust protocol path MTUs while forwarding
|
|
|
|
because they could be easily forged and can lead to unwanted
|
|
|
|
fragmentation by the router.
|
|
|
|
You only need to enable this if you have user-space software
|
|
|
|
which tries to discover path mtus by itself and depends on the
|
|
|
|
kernel honoring this information. This is normally not the
|
|
|
|
case.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-01-09 17:01:15 +08:00
|
|
|
Default: 0 (disabled)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-01-09 17:01:15 +08:00
|
|
|
Possible values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - disabled
|
|
|
|
- 1 - enabled
|
2014-01-09 17:01:15 +08:00
|
|
|
|
2014-11-04 19:02:49 +08:00
|
|
|
fwmark_reflect - BOOLEAN
|
|
|
|
Controls the fwmark of kernel-generated IPv4 reply packets that are not
|
|
|
|
associated with a socket for example, TCP RSTs or ICMP echo replies).
|
|
|
|
If unset, these packets have a fwmark of zero. If set, they have the
|
|
|
|
fwmark of the packet they are replying to.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-11-04 19:02:49 +08:00
|
|
|
Default: 0
|
|
|
|
|
2016-04-07 22:21:00 +08:00
|
|
|
fib_multipath_use_neigh - BOOLEAN
|
|
|
|
Use status of existing neighbor entry when determining nexthop for
|
|
|
|
multipath routes. If disabled, neighbor information is not used and
|
|
|
|
packets could be directed to a failed nexthop. Only valid for kernels
|
|
|
|
built with CONFIG_IP_ROUTE_MULTIPATH enabled.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-04-07 22:21:00 +08:00
|
|
|
Default: 0 (disabled)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-04-07 22:21:00 +08:00
|
|
|
Possible values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - disabled
|
|
|
|
- 1 - enabled
|
2016-04-07 22:21:00 +08:00
|
|
|
|
2017-03-16 21:28:00 +08:00
|
|
|
fib_multipath_hash_policy - INTEGER
|
|
|
|
Controls which hash policy to use for multipath routes. Only valid
|
|
|
|
for kernels built with CONFIG_IP_ROUTE_MULTIPATH enabled.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-03-16 21:28:00 +08:00
|
|
|
Default: 0 (Layer 3)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-03-16 21:28:00 +08:00
|
|
|
Possible values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - Layer 3
|
|
|
|
- 1 - Layer 4
|
|
|
|
- 2 - Layer 3 or inner Layer 3 if present
|
2021-05-18 02:15:19 +08:00
|
|
|
- 3 - Custom multipath hash. Fields used for multipath hash calculation
|
|
|
|
are determined by fib_multipath_hash_fields sysctl
|
2017-03-16 21:28:00 +08:00
|
|
|
|
2021-05-18 02:15:18 +08:00
|
|
|
fib_multipath_hash_fields - UNSIGNED INTEGER
|
|
|
|
When fib_multipath_hash_policy is set to 3 (custom multipath hash), the
|
|
|
|
fields used for multipath hash calculation are determined by this
|
|
|
|
sysctl.
|
|
|
|
|
|
|
|
This value is a bitmask which enables various fields for multipath hash
|
|
|
|
calculation.
|
|
|
|
|
|
|
|
Possible fields are:
|
|
|
|
|
|
|
|
====== ============================
|
|
|
|
0x0001 Source IP address
|
|
|
|
0x0002 Destination IP address
|
|
|
|
0x0004 IP protocol
|
|
|
|
0x0008 Unused (Flow Label)
|
|
|
|
0x0010 Source port
|
|
|
|
0x0020 Destination port
|
|
|
|
0x0040 Inner source IP address
|
|
|
|
0x0080 Inner destination IP address
|
|
|
|
0x0100 Inner IP protocol
|
|
|
|
0x0200 Inner Flow Label
|
|
|
|
0x0400 Inner source port
|
|
|
|
0x0800 Inner destination port
|
|
|
|
====== ============================
|
|
|
|
|
|
|
|
Default: 0x0007 (source IP, destination IP and IP protocol)
|
|
|
|
|
2019-03-21 00:18:59 +08:00
|
|
|
fib_sync_mem - UNSIGNED INTEGER
|
|
|
|
Amount of dirty memory from fib entries that can be backlogged before
|
|
|
|
synchronize_rcu is forced.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
Default: 512kB Minimum: 64kB Maximum: 64MB
|
2019-03-21 00:18:59 +08:00
|
|
|
|
2018-08-01 06:36:03 +08:00
|
|
|
ip_forward_update_priority - INTEGER
|
|
|
|
Whether to update SKB priority from "TOS" field in IPv4 header after it
|
|
|
|
is forwarded. The new SKB priority is mapped from TOS field value
|
|
|
|
according to an rt_tos2priority table (see e.g. man tc-prio).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-08-01 06:36:03 +08:00
|
|
|
Default: 1 (Update priority.)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-08-01 06:36:03 +08:00
|
|
|
Possible values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - Do not update priority.
|
|
|
|
- 1 - Update priority.
|
2018-08-01 06:36:03 +08:00
|
|
|
|
2010-11-08 17:13:48 +08:00
|
|
|
route/max_size - INTEGER
|
|
|
|
Maximum number of routes allowed in the kernel. Increase
|
|
|
|
this when using large numbers of interfaces and/or routes.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-01-08 07:45:56 +08:00
|
|
|
From linux kernel 3.6 onwards, this is deprecated for ipv4
|
|
|
|
as route cache is no longer used.
|
2010-11-08 17:13:48 +08:00
|
|
|
|
2023-01-21 07:23:31 +08:00
|
|
|
From linux kernel 6.3 onwards, this is deprecated for ipv6
|
|
|
|
as garbage collection manages cached route entries.
|
|
|
|
|
2013-01-22 13:20:05 +08:00
|
|
|
neigh/default/gc_thresh1 - INTEGER
|
|
|
|
Minimum number of entries to keep. Garbage collector will not
|
|
|
|
purge entries if there are fewer than this number.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-03-15 06:49:47 +08:00
|
|
|
Default: 128
|
2013-01-22 13:20:05 +08:00
|
|
|
|
2014-08-26 06:05:30 +08:00
|
|
|
neigh/default/gc_thresh2 - INTEGER
|
|
|
|
Threshold when garbage collector becomes more aggressive about
|
|
|
|
purging entries. Entries older than 5 seconds will be cleared
|
|
|
|
when over this number.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-08-26 06:05:30 +08:00
|
|
|
Default: 512
|
|
|
|
|
2010-11-08 17:13:48 +08:00
|
|
|
neigh/default/gc_thresh3 - INTEGER
|
neighbor: Improve garbage collection
The existing garbage collection algorithm has a number of problems:
1. The gc algorithm will not evict PERMANENT entries as those entries
are managed by userspace, yet the existing algorithm walks the entire
hash table which means it always considers PERMANENT entries when
looking for entries to evict. In some use cases (e.g., EVPN) there
can be tens of thousands of PERMANENT entries leading to wasted
CPU cycles when gc kicks in. As an example, with 32k permanent
entries, neigh_alloc has been observed taking more than 4 msec per
invocation.
2. Currently, when the number of neighbor entries hits gc_thresh2 and
the last flush for the table was more than 5 seconds ago gc kicks in
walks the entire hash table evicting *all* entries not in PERMANENT
or REACHABLE state and not marked as externally learned. There is no
discriminator on when the neigh entry was created or if it just moved
from REACHABLE to another NUD_VALID state (e.g., NUD_STALE).
It is possible for entries to be created or for established neighbor
entries to be moved to STALE (e.g., an external node sends an ARP
request) right before the 5 second window lapses:
-----|---------x|----------|-----
t-5 t t+5
If that happens those entries are evicted during gc causing unnecessary
thrashing on neighbor entries and userspace caches trying to track them.
Further, this contradicts the description of gc_thresh2 which says
"Entries older than 5 seconds will be cleared".
One workaround is to make gc_thresh2 == gc_thresh3 but that negates the
whole point of having separate thresholds.
3. Clearing *all* neigh non-PERMANENT/REACHABLE/externally learned entries
when gc_thresh2 is exceeded is over kill and contributes to trashing
especially during startup.
This patch addresses these problems as follows:
1. Use of a separate list_head to track entries that can be garbage
collected along with a separate counter. PERMANENT entries are not
added to this list.
The gc_thresh parameters are only compared to the new counter, not the
total entries in the table. The forced_gc function is updated to only
walk this new gc_list looking for entries to evict.
2. Entries are added to the list head at the tail and removed from the
front.
3. Entries are only evicted if they were last updated more than 5 seconds
ago, adhering to the original intent of gc_thresh2.
4. Forced gc is stopped once the number of gc_entries drops below
gc_thresh2.
5. Since gc checks do not apply to PERMANENT entries, gc levels are skipped
when allocating a new neighbor for a PERMANENT entry. By extension this
means there are no explicit limits on the number of PERMANENT entries
that can be created, but this is no different than FIB entries or FDB
entries.
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-12-08 04:24:57 +08:00
|
|
|
Maximum number of non-PERMANENT neighbor entries allowed. Increase
|
|
|
|
this when using large numbers of interfaces and when communicating
|
2010-11-08 17:13:48 +08:00
|
|
|
with large numbers of directly-connected peers.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-12-05 02:50:35 +08:00
|
|
|
Default: 1024
|
2010-11-08 17:13:48 +08:00
|
|
|
|
neigh: new unresolved queue limits
Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
>
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 09 Nov 2011 12:14:09 +0100
> >
> >> unres_qlen is the number of frames we are able to queue per unresolved
> >> neighbour. Its default value (3) was never changed and is responsible
> >> for strange drops, especially if IP fragments are used, or multiple
> >> sessions start in parallel. Even a single tcp flow can hit this limit.
> > ...
> >
> > Ok, I've applied this, let's see what happens :-)
>
> Early answer, build fails.
>
> Please test build this patch with DECNET enabled and resubmit. The
> decnet neigh layer still refers to the removed ->queue_len member.
>
> Thanks.
Ouch, this was fixed on one machine yesterday, but not the other one I
used this morning, sorry.
[PATCH V5 net-next] neigh: new unresolved queue limits
unres_qlen is the number of frames we are able to queue per unresolved
neighbour. Its default value (3) was never changed and is responsible
for strange drops, especially if IP fragments are used, or multiple
sessions start in parallel. Even a single tcp flow can hit this limit.
$ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-09 20:07:14 +08:00
|
|
|
neigh/default/unres_qlen_bytes - INTEGER
|
|
|
|
The maximum number of bytes which may be used by packets
|
|
|
|
queued for each unresolved address by other network layers.
|
|
|
|
(added in linux 3.3)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-01-03 15:50:29 +08:00
|
|
|
Setting negative value is meaningless and will return error.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-08-30 06:16:01 +08:00
|
|
|
Default: SK_WMEM_MAX, (same as net.core.wmem_default).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-08-30 06:16:01 +08:00
|
|
|
Exact value depends on architecture and kernel options,
|
|
|
|
but should be enough to allow queuing 256 packets
|
|
|
|
of medium size.
|
neigh: new unresolved queue limits
Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
>
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 09 Nov 2011 12:14:09 +0100
> >
> >> unres_qlen is the number of frames we are able to queue per unresolved
> >> neighbour. Its default value (3) was never changed and is responsible
> >> for strange drops, especially if IP fragments are used, or multiple
> >> sessions start in parallel. Even a single tcp flow can hit this limit.
> > ...
> >
> > Ok, I've applied this, let's see what happens :-)
>
> Early answer, build fails.
>
> Please test build this patch with DECNET enabled and resubmit. The
> decnet neigh layer still refers to the removed ->queue_len member.
>
> Thanks.
Ouch, this was fixed on one machine yesterday, but not the other one I
used this morning, sorry.
[PATCH V5 net-next] neigh: new unresolved queue limits
unres_qlen is the number of frames we are able to queue per unresolved
neighbour. Its default value (3) was never changed and is responsible
for strange drops, especially if IP fragments are used, or multiple
sessions start in parallel. Even a single tcp flow can hit this limit.
$ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-09 20:07:14 +08:00
|
|
|
|
|
|
|
neigh/default/unres_qlen - INTEGER
|
|
|
|
The maximum number of packets which may be queued for each
|
|
|
|
unresolved address by other network layers.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
neigh: new unresolved queue limits
Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
>
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 09 Nov 2011 12:14:09 +0100
> >
> >> unres_qlen is the number of frames we are able to queue per unresolved
> >> neighbour. Its default value (3) was never changed and is responsible
> >> for strange drops, especially if IP fragments are used, or multiple
> >> sessions start in parallel. Even a single tcp flow can hit this limit.
> > ...
> >
> > Ok, I've applied this, let's see what happens :-)
>
> Early answer, build fails.
>
> Please test build this patch with DECNET enabled and resubmit. The
> decnet neigh layer still refers to the removed ->queue_len member.
>
> Thanks.
Ouch, this was fixed on one machine yesterday, but not the other one I
used this morning, sorry.
[PATCH V5 net-next] neigh: new unresolved queue limits
unres_qlen is the number of frames we are able to queue per unresolved
neighbour. Its default value (3) was never changed and is responsible
for strange drops, especially if IP fragments are used, or multiple
sessions start in parallel. Even a single tcp flow can hit this limit.
$ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-09 20:07:14 +08:00
|
|
|
(deprecated in linux 3.3) : use unres_qlen_bytes instead.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-12-05 02:50:35 +08:00
|
|
|
Prior to linux 3.3, the default value is 3 which may cause
|
2012-12-07 00:27:51 +08:00
|
|
|
unexpected packet loss. The current default value is calculated
|
2012-12-05 02:50:35 +08:00
|
|
|
according to default value of unres_qlen_bytes and true size of
|
|
|
|
packet.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-08-30 06:16:01 +08:00
|
|
|
Default: 101
|
neigh: new unresolved queue limits
Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
>
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 09 Nov 2011 12:14:09 +0100
> >
> >> unres_qlen is the number of frames we are able to queue per unresolved
> >> neighbour. Its default value (3) was never changed and is responsible
> >> for strange drops, especially if IP fragments are used, or multiple
> >> sessions start in parallel. Even a single tcp flow can hit this limit.
> > ...
> >
> > Ok, I've applied this, let's see what happens :-)
>
> Early answer, build fails.
>
> Please test build this patch with DECNET enabled and resubmit. The
> decnet neigh layer still refers to the removed ->queue_len member.
>
> Thanks.
Ouch, this was fixed on one machine yesterday, but not the other one I
used this morning, sorry.
[PATCH V5 net-next] neigh: new unresolved queue limits
unres_qlen is the number of frames we are able to queue per unresolved
neighbour. Its default value (3) was never changed and is responsible
for strange drops, especially if IP fragments are used, or multiple
sessions start in parallel. Even a single tcp flow can hit this limit.
$ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-11-09 20:07:14 +08:00
|
|
|
|
2022-06-29 16:48:32 +08:00
|
|
|
neigh/default/interval_probe_time_ms - INTEGER
|
|
|
|
The probe interval for neighbor entries with NTF_MANAGED flag,
|
|
|
|
the min value is 1.
|
|
|
|
|
|
|
|
Default: 5000
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
mtu_expires - INTEGER
|
|
|
|
Time, in seconds, that cached PMTU information is kept.
|
|
|
|
|
|
|
|
min_adv_mss - INTEGER
|
|
|
|
The advertised MSS depends on the first hop route MTU, but will
|
|
|
|
never be lower than this setting.
|
|
|
|
|
2021-02-02 03:47:52 +08:00
|
|
|
fib_notify_on_flag_change - INTEGER
|
|
|
|
Whether to emit RTM_NEWROUTE notifications whenever RTM_F_OFFLOAD/
|
2021-02-07 16:22:51 +08:00
|
|
|
RTM_F_TRAP/RTM_F_OFFLOAD_FAILED flags are changed.
|
2021-02-02 03:47:52 +08:00
|
|
|
|
|
|
|
After installing a route to the kernel, user space receives an
|
|
|
|
acknowledgment, which means the route was installed in the kernel,
|
|
|
|
but not necessarily in hardware.
|
|
|
|
It is also possible for a route already installed in hardware to change
|
|
|
|
its action and therefore its flags. For example, a host route that is
|
|
|
|
trapping packets can be "promoted" to perform decapsulation following
|
|
|
|
the installation of an IPinIP/VXLAN tunnel.
|
|
|
|
The notifications will indicate to user-space the state of the route.
|
|
|
|
|
|
|
|
Default: 0 (Do not emit notifications.)
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
- 0 - Do not emit notifications.
|
|
|
|
- 1 - Emit notifications.
|
2021-02-07 16:22:51 +08:00
|
|
|
- 2 - Emit notifications only for RTM_F_OFFLOAD_FAILED flag change.
|
2021-02-02 03:47:52 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
IP Fragmentation:
|
|
|
|
|
2018-04-01 03:58:53 +08:00
|
|
|
ipfrag_high_thresh - LONG INTEGER
|
inet: frags: use rhashtables for reassembly units
Some applications still rely on IP fragmentation, and to be fair linux
reassembly unit is not working under any serious load.
It uses static hash tables of 1024 buckets, and up to 128 items per bucket (!!!)
A work queue is supposed to garbage collect items when host is under memory
pressure, and doing a hash rebuild, changing seed used in hash computations.
This work queue blocks softirqs for up to 25 ms when doing a hash rebuild,
occurring every 5 seconds if host is under fire.
Then there is the problem of sharing this hash table for all netns.
It is time to switch to rhashtables, and allocate one of them per netns
to speedup netns dismantle, since this is a critical metric these days.
Lookup is now using RCU. A followup patch will even remove
the refcount hold/release left from prior implementation and save
a couple of atomic operations.
Before this patch, 16 cpus (16 RX queue NIC) could not handle more
than 1 Mpps frags DDOS.
After the patch, I reach 9 Mpps without any tuning, and can use up to 2GB
of storage for the fragments (exact number depends on frags being evicted
after timeout)
$ grep FRAG /proc/net/sockstat
FRAG: inuse 1966916 memory 2140004608
A followup patch will change the limits for 64bit arches.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Florian Westphal <fw@strlen.de>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Stefan Schmidt <stefan@osg.samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-01 03:58:49 +08:00
|
|
|
Maximum memory used to reassemble IP fragments.
|
2009-02-23 12:39:04 +08:00
|
|
|
|
2018-04-01 03:58:53 +08:00
|
|
|
ipfrag_low_thresh - LONG INTEGER
|
inet: frags: use rhashtables for reassembly units
Some applications still rely on IP fragmentation, and to be fair linux
reassembly unit is not working under any serious load.
It uses static hash tables of 1024 buckets, and up to 128 items per bucket (!!!)
A work queue is supposed to garbage collect items when host is under memory
pressure, and doing a hash rebuild, changing seed used in hash computations.
This work queue blocks softirqs for up to 25 ms when doing a hash rebuild,
occurring every 5 seconds if host is under fire.
Then there is the problem of sharing this hash table for all netns.
It is time to switch to rhashtables, and allocate one of them per netns
to speedup netns dismantle, since this is a critical metric these days.
Lookup is now using RCU. A followup patch will even remove
the refcount hold/release left from prior implementation and save
a couple of atomic operations.
Before this patch, 16 cpus (16 RX queue NIC) could not handle more
than 1 Mpps frags DDOS.
After the patch, I reach 9 Mpps without any tuning, and can use up to 2GB
of storage for the fragments (exact number depends on frags being evicted
after timeout)
$ grep FRAG /proc/net/sockstat
FRAG: inuse 1966916 memory 2140004608
A followup patch will change the limits for 64bit arches.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Florian Westphal <fw@strlen.de>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Stefan Schmidt <stefan@osg.samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-01 03:58:49 +08:00
|
|
|
(Obsolete since linux-4.17)
|
2014-07-24 22:50:32 +08:00
|
|
|
Maximum memory used to reassemble IP fragments before the kernel
|
|
|
|
begins to remove incomplete fragment queues to free up resources.
|
|
|
|
The kernel still accepts new fragments for defragmentation.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
ipfrag_time - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
Time in seconds to keep an IP fragment in memory.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-12-14 15:14:27 +08:00
|
|
|
ipfrag_max_dist - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
ipfrag_max_dist is a non-negative integer value which defines the
|
|
|
|
maximum "disorder" which is allowed among fragments which share a
|
|
|
|
common IP source address. Note that reordering of packets is
|
|
|
|
not unusual, but if a large number of fragments arrive from a source
|
|
|
|
IP address while a particular fragment queue remains incomplete, it
|
|
|
|
probably indicates that one or more fragments belonging to that queue
|
|
|
|
have been lost. When ipfrag_max_dist is positive, an additional check
|
|
|
|
is done on fragments before they are added to a reassembly queue - if
|
|
|
|
ipfrag_max_dist (or more) fragments have arrived from a particular IP
|
|
|
|
address between additions to any IP fragment queue using that source
|
|
|
|
address, it's presumed that one or more fragments in the queue are
|
|
|
|
lost. The existing fragment queue will be dropped, and a new one
|
2005-12-14 15:14:27 +08:00
|
|
|
started. An ipfrag_max_dist value of zero disables this check.
|
|
|
|
|
|
|
|
Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can
|
|
|
|
result in unnecessarily dropping fragment queues when normal
|
2009-02-23 12:39:04 +08:00
|
|
|
reordering of packets occurs, which could lead to poor application
|
|
|
|
performance. Using a very large value, e.g. 50000, increases the
|
|
|
|
likelihood of incorrectly reassembling IP fragments that originate
|
2005-12-14 15:14:27 +08:00
|
|
|
from different IP datagrams, which could result in data corruption.
|
|
|
|
Default: 64
|
|
|
|
|
2022-04-13 22:00:00 +08:00
|
|
|
bc_forwarding - INTEGER
|
|
|
|
bc_forwarding enables the feature described in rfc1812#section-5.3.5.2
|
|
|
|
and rfc2644. It allows the router to forward directed broadcast.
|
|
|
|
To enable this feature, the 'all' entry and the input interface entry
|
|
|
|
should be set to 1.
|
|
|
|
Default: 0
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
INET peer storage
|
|
|
|
=================
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
inet_peer_threshold - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
The approximate size of the storage. Starting from this threshold
|
2005-04-17 06:20:36 +08:00
|
|
|
entries will be thrown aggressively. This threshold also determines
|
|
|
|
entries' time-to-live and time intervals between garbage collection
|
|
|
|
passes. More entries, less time-to-live, less GC interval.
|
|
|
|
|
|
|
|
inet_peer_minttl - INTEGER
|
|
|
|
Minimum time-to-live of entries. Should be enough to cover fragment
|
|
|
|
time-to-live on the reassembling side. This minimum time-to-live is
|
|
|
|
guaranteed if the pool size is less than inet_peer_threshold.
|
2008-07-02 08:22:48 +08:00
|
|
|
Measured in seconds.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
inet_peer_maxttl - INTEGER
|
|
|
|
Maximum time-to-live of entries. Unused entries will expire after
|
|
|
|
this period of time if there is no memory pressure on the pool (i.e.
|
|
|
|
when the number of entries in the pool is very small).
|
2008-07-02 08:22:48 +08:00
|
|
|
Measured in seconds.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
TCP variables
|
|
|
|
=============
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
somaxconn - INTEGER
|
|
|
|
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
|
2019-10-31 00:36:20 +08:00
|
|
|
Defaults to 4096. (Was 128 before linux-5.4)
|
|
|
|
See also tcp_max_syn_backlog for additional tuning for TCP sockets.
|
2006-11-10 08:37:26 +08:00
|
|
|
|
|
|
|
tcp_abort_on_overflow - BOOLEAN
|
|
|
|
If listening service is too slow to accept new connections,
|
|
|
|
reset them. Default state is FALSE. It means that if overflow
|
|
|
|
occurred due to a burst, connection will recover. Enable this
|
|
|
|
option _only_ if you are really sure that listening daemon
|
|
|
|
cannot be tuned to accept connections faster. Enabling this
|
|
|
|
option can harm clients of your server.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_adv_win_scale - INTEGER
|
|
|
|
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
|
|
|
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
|
|
|
if it is <= 0.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2010-11-22 20:54:21 +08:00
|
|
|
Possible values are [-31, 31], inclusive.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-05-02 10:28:41 +08:00
|
|
|
Default: 1
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_allowed_congestion_control - STRING
|
|
|
|
Show/set the congestion control choices available to non-privileged
|
|
|
|
processes. The list is a subset of those listed in
|
|
|
|
tcp_available_congestion_control.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default is "reno" and the default setting (tcp_congestion_control).
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_app_win - INTEGER
|
|
|
|
Reserve max(window/2^tcp_app_win, mss) of window for application
|
|
|
|
buffer. Value 0 is special, it means that nothing is reserved.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default: 31
|
2005-04-17 06:20:36 +08:00
|
|
|
|
tcp: auto corking
With the introduction of TCP Small Queues, TSO auto sizing, and TCP
pacing, we can implement Automatic Corking in the kernel, to help
applications doing small write()/sendmsg() to TCP sockets.
Idea is to change tcp_push() to check if the current skb payload is
under skb optimal size (a multiple of MSS bytes)
If under 'size_goal', and at least one packet is still in Qdisc or
NIC TX queues, set the TCP Small Queue Throttled bit, so that the push
will be delayed up to TX completion time.
This delay might allow the application to coalesce more bytes
in the skb in following write()/sendmsg()/sendfile() system calls.
The exact duration of the delay is depending on the dynamics
of the system, and might be zero if no packet for this flow
is actually held in Qdisc or NIC TX ring.
Using FQ/pacing is a way to increase the probability of
autocorking being triggered.
Add a new sysctl (/proc/sys/net/ipv4/tcp_autocorking) to control
this feature and default it to 1 (enabled)
Add a new SNMP counter : nstat -a | grep TcpExtTCPAutoCorking
This counter is incremented every time we detected skb was under used
and its flush was deferred.
Tested:
Interesting effects when using line buffered commands under ssh.
Excellent performance results in term of cpu usage and total throughput.
lpq83:~# echo 1 >/proc/sys/net/ipv4/tcp_autocorking
lpq83:~# perf stat ./super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128
9410.39
Performance counter stats for './super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128':
35209.439626 task-clock # 2.901 CPUs utilized
2,294 context-switches # 0.065 K/sec
101 CPU-migrations # 0.003 K/sec
4,079 page-faults # 0.116 K/sec
97,923,241,298 cycles # 2.781 GHz [83.31%]
51,832,908,236 stalled-cycles-frontend # 52.93% frontend cycles idle [83.30%]
25,697,986,603 stalled-cycles-backend # 26.24% backend cycles idle [66.70%]
102,225,978,536 instructions # 1.04 insns per cycle
# 0.51 stalled cycles per insn [83.38%]
18,657,696,819 branches # 529.906 M/sec [83.29%]
91,679,646 branch-misses # 0.49% of all branches [83.40%]
12.136204899 seconds time elapsed
lpq83:~# echo 0 >/proc/sys/net/ipv4/tcp_autocorking
lpq83:~# perf stat ./super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128
6624.89
Performance counter stats for './super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128':
40045.864494 task-clock # 3.301 CPUs utilized
171 context-switches # 0.004 K/sec
53 CPU-migrations # 0.001 K/sec
4,080 page-faults # 0.102 K/sec
111,340,458,645 cycles # 2.780 GHz [83.34%]
61,778,039,277 stalled-cycles-frontend # 55.49% frontend cycles idle [83.31%]
29,295,522,759 stalled-cycles-backend # 26.31% backend cycles idle [66.67%]
108,654,349,355 instructions # 0.98 insns per cycle
# 0.57 stalled cycles per insn [83.34%]
19,552,170,748 branches # 488.244 M/sec [83.34%]
157,875,417 branch-misses # 0.81% of all branches [83.34%]
12.130267788 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-06 14:36:05 +08:00
|
|
|
tcp_autocorking - BOOLEAN
|
|
|
|
Enable TCP auto corking :
|
|
|
|
When applications do consecutive small write()/sendmsg() system calls,
|
|
|
|
we try to coalesce these small writes as much as possible, to lower
|
|
|
|
total amount of sent packets. This is done if at least one prior
|
|
|
|
packet for the flow is waiting in Qdisc queues or device transmit
|
|
|
|
queue. Applications can still use TCP_CORK for optimal behavior
|
|
|
|
when they know how/when to uncork their sockets.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
tcp: auto corking
With the introduction of TCP Small Queues, TSO auto sizing, and TCP
pacing, we can implement Automatic Corking in the kernel, to help
applications doing small write()/sendmsg() to TCP sockets.
Idea is to change tcp_push() to check if the current skb payload is
under skb optimal size (a multiple of MSS bytes)
If under 'size_goal', and at least one packet is still in Qdisc or
NIC TX queues, set the TCP Small Queue Throttled bit, so that the push
will be delayed up to TX completion time.
This delay might allow the application to coalesce more bytes
in the skb in following write()/sendmsg()/sendfile() system calls.
The exact duration of the delay is depending on the dynamics
of the system, and might be zero if no packet for this flow
is actually held in Qdisc or NIC TX ring.
Using FQ/pacing is a way to increase the probability of
autocorking being triggered.
Add a new sysctl (/proc/sys/net/ipv4/tcp_autocorking) to control
this feature and default it to 1 (enabled)
Add a new SNMP counter : nstat -a | grep TcpExtTCPAutoCorking
This counter is incremented every time we detected skb was under used
and its flush was deferred.
Tested:
Interesting effects when using line buffered commands under ssh.
Excellent performance results in term of cpu usage and total throughput.
lpq83:~# echo 1 >/proc/sys/net/ipv4/tcp_autocorking
lpq83:~# perf stat ./super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128
9410.39
Performance counter stats for './super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128':
35209.439626 task-clock # 2.901 CPUs utilized
2,294 context-switches # 0.065 K/sec
101 CPU-migrations # 0.003 K/sec
4,079 page-faults # 0.116 K/sec
97,923,241,298 cycles # 2.781 GHz [83.31%]
51,832,908,236 stalled-cycles-frontend # 52.93% frontend cycles idle [83.30%]
25,697,986,603 stalled-cycles-backend # 26.24% backend cycles idle [66.70%]
102,225,978,536 instructions # 1.04 insns per cycle
# 0.51 stalled cycles per insn [83.38%]
18,657,696,819 branches # 529.906 M/sec [83.29%]
91,679,646 branch-misses # 0.49% of all branches [83.40%]
12.136204899 seconds time elapsed
lpq83:~# echo 0 >/proc/sys/net/ipv4/tcp_autocorking
lpq83:~# perf stat ./super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128
6624.89
Performance counter stats for './super_netperf 4 -t TCP_STREAM -H lpq84 -- -m 128':
40045.864494 task-clock # 3.301 CPUs utilized
171 context-switches # 0.004 K/sec
53 CPU-migrations # 0.001 K/sec
4,080 page-faults # 0.102 K/sec
111,340,458,645 cycles # 2.780 GHz [83.34%]
61,778,039,277 stalled-cycles-frontend # 55.49% frontend cycles idle [83.31%]
29,295,522,759 stalled-cycles-backend # 26.31% backend cycles idle [66.67%]
108,654,349,355 instructions # 0.98 insns per cycle
# 0.57 stalled cycles per insn [83.34%]
19,552,170,748 branches # 488.244 M/sec [83.34%]
157,875,417 branch-misses # 0.81% of all branches [83.34%]
12.130267788 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-06 14:36:05 +08:00
|
|
|
Default : 1
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_available_congestion_control - STRING
|
|
|
|
Shows the available congestion control choices that are registered.
|
|
|
|
More congestion control algorithms may be available as modules,
|
|
|
|
but not loaded.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-02-28 02:03:56 +08:00
|
|
|
tcp_base_mss - INTEGER
|
2008-07-11 07:50:26 +08:00
|
|
|
The initial value of search_low to be used by the packetization layer
|
|
|
|
Path MTU discovery (MTU probing). If MTU probing is enabled,
|
|
|
|
this is the initial MSS used by the connection.
|
2007-02-28 02:03:56 +08:00
|
|
|
|
2019-08-08 07:52:29 +08:00
|
|
|
tcp_mtu_probe_floor - INTEGER
|
|
|
|
If MTU probing is enabled this caps the minimum MSS used for search_low
|
|
|
|
for the connection.
|
|
|
|
|
|
|
|
Default : 48
|
|
|
|
|
2019-06-07 00:15:31 +08:00
|
|
|
tcp_min_snd_mss - INTEGER
|
|
|
|
TCP SYN and SYNACK messages usually advertise an ADVMSS option,
|
|
|
|
as described in RFC 1122 and RFC 6691.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-06-07 00:15:31 +08:00
|
|
|
If this ADVMSS option is smaller than tcp_min_snd_mss,
|
|
|
|
it is silently capped to tcp_min_snd_mss.
|
|
|
|
|
|
|
|
Default : 48 (at least 8 bytes of payload per segment)
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_congestion_control - STRING
|
|
|
|
Set the congestion control algorithm to be used for new
|
|
|
|
connections. The algorithm "reno" is always available, but
|
|
|
|
additional choices may be available based on kernel configuration.
|
|
|
|
Default is set as part of kernel configuration.
|
2011-11-30 09:02:41 +08:00
|
|
|
For passive connections, the listener congestion control choice
|
|
|
|
is inherited.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2011-11-30 09:02:41 +08:00
|
|
|
[see setsockopt(listenfd, SOL_TCP, TCP_CONGESTION, "name" ...) ]
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_dsack - BOOLEAN
|
|
|
|
Allows TCP to send "duplicate" SACKs.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-05-02 21:30:03 +08:00
|
|
|
tcp_early_retrans - INTEGER
|
2017-01-13 14:11:39 +08:00
|
|
|
Tail loss probe (TLP) converts RTOs occurring due to tail
|
|
|
|
losses into fast recovery (draft-ietf-tcpm-rack). Note that
|
|
|
|
TLP requires RACK to function properly (see tcp_recovery below)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-05-02 21:30:03 +08:00
|
|
|
Possible values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 disables TLP
|
|
|
|
- 3 or 4 enables TLP
|
|
|
|
|
tcp: Tail loss probe (TLP)
This patch series implement the Tail loss probe (TLP) algorithm described
in http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01. The
first patch implements the basic algorithm.
TLP's goal is to reduce tail latency of short transactions. It achieves
this by converting retransmission timeouts (RTOs) occuring due
to tail losses (losses at end of transactions) into fast recovery.
TLP transmits one packet in two round-trips when a connection is in
Open state and isn't receiving any ACKs. The transmitted packet, aka
loss probe, can be either new or a retransmission. When there is tail
loss, the ACK from a loss probe triggers FACK/early-retransmit based
fast recovery, thus avoiding a costly RTO. In the absence of loss,
there is no change in the connection state.
PTO stands for probe timeout. It is a timer event indicating
that an ACK is overdue and triggers a loss probe packet. The PTO value
is set to max(2*SRTT, 10ms) and is adjusted to account for delayed
ACK timer when there is only one oustanding packet.
TLP Algorithm
On transmission of new data in Open state:
-> packets_out > 1: schedule PTO in max(2*SRTT, 10ms).
-> packets_out == 1: schedule PTO in max(2*RTT, 1.5*RTT + 200ms)
-> PTO = min(PTO, RTO)
Conditions for scheduling PTO:
-> Connection is in Open state.
-> Connection is either cwnd limited or no new data to send.
-> Number of probes per tail loss episode is limited to one.
-> Connection is SACK enabled.
When PTO fires:
new_segment_exists:
-> transmit new segment.
-> packets_out++. cwnd remains same.
no_new_packet:
-> retransmit the last segment.
Its ACK triggers FACK or early retransmit based recovery.
ACK path:
-> rearm RTO at start of ACK processing.
-> reschedule PTO if need be.
In addition, the patch includes a small variation to the Early Retransmit
(ER) algorithm, such that ER and TLP together can in principle recover any
N-degree of tail loss through fast recovery. TLP is controlled by the same
sysctl as ER, tcp_early_retrans sysctl.
tcp_early_retrans==0; disables TLP and ER.
==1; enables RFC5827 ER.
==2; delayed ER.
==3; TLP and delayed ER. [DEFAULT]
==4; TLP only.
The TLP patch series have been extensively tested on Google Web servers.
It is most effective for short Web trasactions, where it reduced RTOs by 15%
and improved HTTP response time (average by 6%, 99th percentile by 10%).
The transmitted probes account for <0.5% of the overall transmissions.
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-11 18:00:43 +08:00
|
|
|
Default: 3
|
2012-05-02 21:30:03 +08:00
|
|
|
|
2011-02-03 07:39:58 +08:00
|
|
|
tcp_ecn - INTEGER
|
2012-11-28 17:53:10 +08:00
|
|
|
Control use of Explicit Congestion Notification (ECN) by TCP.
|
|
|
|
ECN is used only when both ends of the TCP connection indicate
|
|
|
|
support for it. This feature is useful in avoiding losses due
|
|
|
|
to congestion by allowing supporting routers to signal
|
|
|
|
congestion before having to drop packets.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2009-05-05 02:07:36 +08:00
|
|
|
Possible values are:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
= =====================================================
|
|
|
|
0 Disable ECN. Neither initiate nor accept ECN.
|
|
|
|
1 Enable ECN when requested by incoming connections and
|
|
|
|
also request ECN on outgoing connection attempts.
|
|
|
|
2 Enable ECN when requested by incoming connections
|
|
|
|
but do not request ECN on outgoing connections.
|
|
|
|
= =====================================================
|
|
|
|
|
2009-05-05 02:07:36 +08:00
|
|
|
Default: 2
|
2006-11-10 08:37:26 +08:00
|
|
|
|
tcp: add rfc3168, section 6.1.1.1. fallback
This work as a follow-up of commit f7b3bec6f516 ("net: allow setting ecn
via routing table") and adds RFC3168 section 6.1.1.1. fallback for outgoing
ECN connections. In other words, this work adds a retry with a non-ECN
setup SYN packet, as suggested from the RFC on the first timeout:
[...] A host that receives no reply to an ECN-setup SYN within the
normal SYN retransmission timeout interval MAY resend the SYN and
any subsequent SYN retransmissions with CWR and ECE cleared. [...]
Schematic client-side view when assuming the server is in tcp_ecn=2 mode,
that is, Linux default since 2009 via commit 255cac91c3c9 ("tcp: extend
ECN sysctl to allow server-side only ECN"):
1) Normal ECN-capable path:
SYN ECE CWR ----->
<----- SYN ACK ECE
ACK ----->
2) Path with broken middlebox, when client has fallback:
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ----->
<----- SYN ACK
ACK ----->
In case we would not have the fallback implemented, the middlebox drop
point would basically end up as:
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
In any case, it's rather a smaller percentage of sites where there would
occur such additional setup latency: it was found in end of 2014 that ~56%
of IPv4 and 65% of IPv6 servers of Alexa 1 million list would negotiate
ECN (aka tcp_ecn=2 default), 0.42% of these webservers will fail to connect
when trying to negotiate with ECN (tcp_ecn=1) due to timeouts, which the
fallback would mitigate with a slight latency trade-off. Recent related
paper on this topic:
Brian Trammell, Mirja Kühlewind, Damiano Boppart, Iain Learmonth,
Gorry Fairhurst, and Richard Scheffenegger:
"Enabling Internet-Wide Deployment of Explicit Congestion Notification."
Proc. PAM 2015, New York.
http://ecn.ethz.ch/ecn-pam15.pdf
Thus, when net.ipv4.tcp_ecn=1 is being set, the patch will perform RFC3168,
section 6.1.1.1. fallback on timeout. For users explicitly not wanting this
which can be in DC use case, we add a net.ipv4.tcp_ecn_fallback knob that
allows for disabling the fallback.
tp->ecn_flags are not being cleared in tcp_ecn_clear_syn() on output, but
rather we let tcp_ecn_rcv_synack() take that over on input path in case a
SYN ACK ECE was delayed. Thus a spurious SYN retransmission will not prevent
ECN being negotiated eventually in that case.
Reference: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
Reference: https://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Signed-off-by: Brian Trammell <trammell@tik.ee.ethz.ch>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Dave That <dave.taht@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-20 03:04:22 +08:00
|
|
|
tcp_ecn_fallback - BOOLEAN
|
|
|
|
If the kernel detects that ECN connection misbehaves, enable fall
|
|
|
|
back to non-ECN. Currently, this knob implements the fallback
|
|
|
|
from RFC3168, section 6.1.1.1., but we reserve that in future,
|
|
|
|
additional detection mechanisms could be implemented under this
|
|
|
|
knob. The value is not used, if tcp_ecn or per route (or congestion
|
|
|
|
control) ECN settings are disabled.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
tcp: add rfc3168, section 6.1.1.1. fallback
This work as a follow-up of commit f7b3bec6f516 ("net: allow setting ecn
via routing table") and adds RFC3168 section 6.1.1.1. fallback for outgoing
ECN connections. In other words, this work adds a retry with a non-ECN
setup SYN packet, as suggested from the RFC on the first timeout:
[...] A host that receives no reply to an ECN-setup SYN within the
normal SYN retransmission timeout interval MAY resend the SYN and
any subsequent SYN retransmissions with CWR and ECE cleared. [...]
Schematic client-side view when assuming the server is in tcp_ecn=2 mode,
that is, Linux default since 2009 via commit 255cac91c3c9 ("tcp: extend
ECN sysctl to allow server-side only ECN"):
1) Normal ECN-capable path:
SYN ECE CWR ----->
<----- SYN ACK ECE
ACK ----->
2) Path with broken middlebox, when client has fallback:
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ----->
<----- SYN ACK
ACK ----->
In case we would not have the fallback implemented, the middlebox drop
point would basically end up as:
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
In any case, it's rather a smaller percentage of sites where there would
occur such additional setup latency: it was found in end of 2014 that ~56%
of IPv4 and 65% of IPv6 servers of Alexa 1 million list would negotiate
ECN (aka tcp_ecn=2 default), 0.42% of these webservers will fail to connect
when trying to negotiate with ECN (tcp_ecn=1) due to timeouts, which the
fallback would mitigate with a slight latency trade-off. Recent related
paper on this topic:
Brian Trammell, Mirja Kühlewind, Damiano Boppart, Iain Learmonth,
Gorry Fairhurst, and Richard Scheffenegger:
"Enabling Internet-Wide Deployment of Explicit Congestion Notification."
Proc. PAM 2015, New York.
http://ecn.ethz.ch/ecn-pam15.pdf
Thus, when net.ipv4.tcp_ecn=1 is being set, the patch will perform RFC3168,
section 6.1.1.1. fallback on timeout. For users explicitly not wanting this
which can be in DC use case, we add a net.ipv4.tcp_ecn_fallback knob that
allows for disabling the fallback.
tp->ecn_flags are not being cleared in tcp_ecn_clear_syn() on output, but
rather we let tcp_ecn_rcv_synack() take that over on input path in case a
SYN ACK ECE was delayed. Thus a spurious SYN retransmission will not prevent
ECN being negotiated eventually in that case.
Reference: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
Reference: https://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Signed-off-by: Brian Trammell <trammell@tik.ee.ethz.ch>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Dave That <dave.taht@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-20 03:04:22 +08:00
|
|
|
Default: 1 (fallback enabled)
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_fack - BOOLEAN
|
2017-11-09 05:01:26 +08:00
|
|
|
This is a legacy option, it has no effect anymore.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
tcp_fin_timeout - INTEGER
|
2012-12-10 19:33:00 +08:00
|
|
|
The length of time an orphaned (no longer referenced by any
|
|
|
|
application) connection will remain in the FIN_WAIT_2 state
|
|
|
|
before it is aborted at the local end. While a perfectly
|
|
|
|
valid "receive only" state for an un-orphaned connection, an
|
|
|
|
orphaned connection in FIN_WAIT_2 state could otherwise wait
|
|
|
|
forever for the remote to close its end of the connection.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-12-10 19:33:00 +08:00
|
|
|
Cf. tcp_max_orphans
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-12-10 19:33:00 +08:00
|
|
|
Default: 60 seconds
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-02-28 02:10:55 +08:00
|
|
|
tcp_frto - INTEGER
|
2013-03-20 21:33:00 +08:00
|
|
|
Enables Forward RTO-Recovery (F-RTO) defined in RFC5682.
|
2007-09-21 02:35:26 +08:00
|
|
|
F-RTO is an enhanced recovery algorithm for TCP retransmission
|
2013-03-20 21:33:00 +08:00
|
|
|
timeouts. It is particularly beneficial in networks where the
|
|
|
|
RTT fluctuates (e.g., wireless). F-RTO is sender-side only
|
|
|
|
modification. It does not require any support from the peer.
|
|
|
|
|
|
|
|
By default it's enabled with a non-zero value. 0 disables F-RTO.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-10-29 08:30:29 +08:00
|
|
|
tcp_fwmark_accept - BOOLEAN
|
|
|
|
If set, incoming connections to listening sockets that do not have a
|
|
|
|
socket mark will set the mark of the accepting socket to the fwmark of
|
|
|
|
the incoming SYN packet. This will cause all packets on that connection
|
|
|
|
(starting from the first SYNACK) to be sent with that fwmark. The
|
|
|
|
listening socket's mark is unchanged. Listening sockets that already
|
|
|
|
have a fwmark set via setsockopt(SOL_SOCKET, SO_MARK, ...) are
|
|
|
|
unaffected.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
tcp: helpers to mitigate ACK loops by rate-limiting out-of-window dupacks
Helpers for mitigating ACK loops by rate-limiting dupacks sent in
response to incoming out-of-window packets.
This patch includes:
- rate-limiting logic
- sysctl to control how often we allow dupacks to out-of-window packets
- SNMP counter for cases where we rate-limited our dupack sending
The rate-limiting logic in this patch decides to not send dupacks in
response to out-of-window segments if (a) they are SYNs or pure ACKs
and (b) the remote endpoint is sending them faster than the configured
rate limit.
We rate-limit our responses rather than blocking them entirely or
resetting the connection, because legitimate connections can rely on
dupacks in response to some out-of-window segments. For example, zero
window probes are typically sent with a sequence number that is below
the current window, and ZWPs thus expect to thus elicit a dupack in
response.
We allow dupacks in response to TCP segments with data, because these
may be spurious retransmissions for which the remote endpoint wants to
receive DSACKs. This is safe because segments with data can't
realistically be part of ACK loops, which by their nature consist of
each side sending pure/data-less ACKs to each other.
The dupack interval is controlled by a new sysctl knob,
tcp_invalid_ratelimit, given in milliseconds, in case an administrator
needs to dial this upward in the face of a high-rate DoS attack. The
name and units are chosen to be analogous to the existing analogous
knob for ICMP, icmp_ratelimit.
The default value for tcp_invalid_ratelimit is 500ms, which allows at
most one such dupack per 500ms. This is chosen to be 2x faster than
the 1-second minimum RTO interval allowed by RFC 6298 (section 2, rule
2.4). We allow the extra 2x factor because network delay variations
can cause packets sent at 1 second intervals to be compressed and
arrive much closer.
Reported-by: Avery Fay <avery@mixpanel.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-07 05:04:38 +08:00
|
|
|
tcp_invalid_ratelimit - INTEGER
|
|
|
|
Limit the maximal rate for sending duplicate acknowledgments
|
|
|
|
in response to incoming TCP packets that are for an existing
|
|
|
|
connection but that are invalid due to any of these reasons:
|
|
|
|
|
|
|
|
(a) out-of-window sequence number,
|
|
|
|
(b) out-of-window acknowledgment number, or
|
|
|
|
(c) PAWS (Protection Against Wrapped Sequence numbers) check failure
|
|
|
|
|
|
|
|
This can help mitigate simple "ack loop" DoS attacks, wherein
|
|
|
|
a buggy or malicious middlebox or man-in-the-middle can
|
|
|
|
rewrite TCP header fields in manner that causes each endpoint
|
|
|
|
to think that the other is sending invalid TCP segments, thus
|
|
|
|
causing each side to send an unterminating stream of duplicate
|
|
|
|
acknowledgments for invalid segments.
|
|
|
|
|
|
|
|
Using 0 disables rate-limiting of dupacks in response to
|
|
|
|
invalid segments; otherwise this value specifies the minimal
|
|
|
|
space between sending such dupacks, in milliseconds.
|
|
|
|
|
|
|
|
Default: 500 (milliseconds).
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_keepalive_time - INTEGER
|
|
|
|
How often TCP sends out keepalive messages when keepalive is enabled.
|
|
|
|
Default: 2hours.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_keepalive_probes - INTEGER
|
|
|
|
How many keepalive probes TCP sends out, until it decides that the
|
|
|
|
connection is broken. Default value: 9.
|
|
|
|
|
|
|
|
tcp_keepalive_intvl - INTEGER
|
|
|
|
How frequently the probes are send out. Multiplied by
|
|
|
|
tcp_keepalive_probes it is time to kill not responding connection,
|
|
|
|
after probes started. Default value: 75sec i.e. connection
|
|
|
|
will be aborted after ~11 minutes of retries.
|
|
|
|
|
2015-12-17 05:20:44 +08:00
|
|
|
tcp_l3mdev_accept - BOOLEAN
|
|
|
|
Enables child sockets to inherit the L3 master device index.
|
|
|
|
Enabling this option allows a "global" listen socket to work
|
|
|
|
across L3 master domains (e.g., VRFs) with connected sockets
|
|
|
|
derived from the listen socket to be bound to the L3 domain in
|
|
|
|
which the packets originated. Only valid when the kernel was
|
|
|
|
compiled with CONFIG_NET_L3_MASTER_DEV.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
Default: 0 (disabled)
|
2015-12-17 05:20:44 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_low_latency - BOOLEAN
|
2017-07-30 09:57:20 +08:00
|
|
|
This is a legacy option, it has no effect anymore.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
tcp_max_orphans - INTEGER
|
|
|
|
Maximal number of TCP sockets not attached to any user file handle,
|
|
|
|
held by system. If this number is exceeded orphaned connections are
|
|
|
|
reset immediately and warning is printed. This limit exists
|
|
|
|
only to prevent simple DoS attacks, you _must_ not rely on this
|
|
|
|
or lower the limit artificially, but rather increase it
|
|
|
|
(probably, after increasing installed memory),
|
|
|
|
if network conditions require more than default value,
|
|
|
|
and tune network services to linger and kill such states
|
|
|
|
more aggressively. Let me to remind again: each orphan eats
|
|
|
|
up to ~64K of unswappable memory.
|
|
|
|
|
|
|
|
tcp_max_syn_backlog - INTEGER
|
2019-10-31 01:05:46 +08:00
|
|
|
Maximal number of remembered connection requests (SYN_RECV),
|
|
|
|
which have not received an acknowledgment from connecting client.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-10-31 01:05:46 +08:00
|
|
|
This is a per-listener limit.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2011-12-06 05:39:41 +08:00
|
|
|
The minimal value is 128 for low memory machines, and it will
|
|
|
|
increase in proportion to the memory of machine.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2011-12-06 05:39:41 +08:00
|
|
|
If server suffers from overload, try increasing this number.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-10-31 01:05:46 +08:00
|
|
|
Remember to also check /proc/sys/net/core/somaxconn
|
|
|
|
A SYN_RECV request socket consumes about 304 bytes of memory.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_max_tw_buckets - INTEGER
|
|
|
|
Maximal number of timewait sockets held by system simultaneously.
|
|
|
|
If this number is exceeded time-wait socket is immediately destroyed
|
|
|
|
and warning is printed. This limit exists only to prevent
|
|
|
|
simple DoS attacks, you _must_ not lower the limit artificially,
|
|
|
|
but rather increase it (probably, after increasing installed memory),
|
|
|
|
if network conditions require more than default value.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_mem - vector of 3 INTEGERs: min, pressure, max
|
|
|
|
min: below this number of pages TCP is not bothered about its
|
|
|
|
memory appetite.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
pressure: when amount of memory allocated by TCP exceeds this number
|
|
|
|
of pages, TCP moderates its memory consumption and enters memory
|
|
|
|
pressure mode, which is exited when memory consumption falls
|
|
|
|
under "min".
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
max: number of pages allowed for queueing by all TCP sockets.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Defaults are calculated at boot time from amount of available
|
|
|
|
memory.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-10-17 12:57:42 +08:00
|
|
|
tcp_min_rtt_wlen - INTEGER
|
|
|
|
The window length of the windowed min filter to track the minimum RTT.
|
|
|
|
A shorter window lets a flow more quickly pick up new (higher)
|
|
|
|
minimum RTT when it is moved to a longer path (e.g., due to traffic
|
|
|
|
engineering). A longer window makes the filter more resistant to RTT
|
|
|
|
inflations such as transient congestion. The unit is seconds.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-04-16 09:47:24 +08:00
|
|
|
Possible values: 0 - 86400 (1 day)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-10-17 12:57:42 +08:00
|
|
|
Default: 300
|
|
|
|
|
2007-02-28 02:03:56 +08:00
|
|
|
tcp_moderate_rcvbuf - BOOLEAN
|
2008-07-11 07:50:26 +08:00
|
|
|
If set, TCP performs receive buffer auto-tuning, attempting to
|
2007-02-28 02:03:56 +08:00
|
|
|
automatically size the buffer (no greater than tcp_rmem[2]) to
|
|
|
|
match the size required by the path for full throughput. Enabled by
|
|
|
|
default.
|
|
|
|
|
|
|
|
tcp_mtu_probing - INTEGER
|
|
|
|
Controls TCP Packetization-Layer Path MTU Discovery. Takes three
|
|
|
|
values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - Disabled
|
|
|
|
- 1 - Disabled by default, enabled when an ICMP black hole detected
|
|
|
|
- 2 - Always enabled, use initial MSS of tcp_base_mss.
|
2007-02-28 02:03:56 +08:00
|
|
|
|
2018-09-26 12:59:28 +08:00
|
|
|
tcp_probe_interval - UNSIGNED INTEGER
|
2015-03-06 11:18:25 +08:00
|
|
|
Controls how often to start TCP Packetization-Layer Path MTU
|
|
|
|
Discovery reprobe. The default is reprobing every 10 minutes as
|
|
|
|
per RFC4821.
|
|
|
|
|
|
|
|
tcp_probe_threshold - INTEGER
|
|
|
|
Controls when TCP Packetization-Layer Path MTU Discovery probing
|
|
|
|
will stop in respect to the width of search range in bytes. Default
|
|
|
|
is 8 bytes.
|
|
|
|
|
2007-02-28 02:03:56 +08:00
|
|
|
tcp_no_metrics_save - BOOLEAN
|
|
|
|
By default, TCP saves various connection metrics in the route cache
|
|
|
|
when the connection closes, so that connections established in the
|
|
|
|
near future can use these to set initial conditions. Usually, this
|
|
|
|
increases overall performance, but may sometimes cause performance
|
2007-10-20 07:30:25 +08:00
|
|
|
degradation. If set, TCP will not cache metrics on closing
|
2007-02-28 02:03:56 +08:00
|
|
|
connections.
|
|
|
|
|
2019-12-10 03:19:59 +08:00
|
|
|
tcp_no_ssthresh_metrics_save - BOOLEAN
|
|
|
|
Controls whether TCP saves ssthresh metrics in the route cache.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-12-10 03:19:59 +08:00
|
|
|
Default is 1, which disables ssthresh metrics.
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_orphan_retries - INTEGER
|
2009-09-01 18:24:04 +08:00
|
|
|
This value influences the timeout of a locally closed TCP connection,
|
|
|
|
when RTO retransmissions remain unacknowledged.
|
|
|
|
See tcp_retries2 for more details.
|
|
|
|
|
2011-07-09 00:31:31 +08:00
|
|
|
The default value is 8.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2009-09-01 18:24:04 +08:00
|
|
|
If your machine is a loaded WEB server,
|
2006-11-10 08:37:26 +08:00
|
|
|
you should think about lowering this value, such sockets
|
|
|
|
may consume significant resources. Cf. tcp_max_orphans.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-10-17 12:57:47 +08:00
|
|
|
tcp_recovery - INTEGER
|
|
|
|
This value is a bitmap to enable various experimental loss recovery
|
|
|
|
features.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
========= =============================================================
|
|
|
|
RACK: 0x1 enables the RACK loss detection for fast detection of lost
|
|
|
|
retransmissions and tail drops. It also subsumes and disables
|
|
|
|
RFC6675 recovery for SACK connections.
|
|
|
|
|
|
|
|
RACK: 0x2 makes RACK's reordering window static (min_rtt/4).
|
|
|
|
|
|
|
|
RACK: 0x4 disables RACK's DUPACK threshold heuristic
|
|
|
|
========= =============================================================
|
2015-10-17 12:57:47 +08:00
|
|
|
|
|
|
|
Default: 0x1
|
|
|
|
|
2022-07-27 19:18:21 +08:00
|
|
|
tcp_reflect_tos - BOOLEAN
|
|
|
|
For listening sockets, reuse the DSCP value of the initial SYN message
|
|
|
|
for outgoing packets. This allows to have both directions of a TCP
|
|
|
|
stream to use the same DSCP value, assuming DSCP remains unchanged for
|
|
|
|
the lifetime of the connection.
|
|
|
|
|
|
|
|
This options affects both IPv4 and IPv6.
|
|
|
|
|
|
|
|
Default: 0 (disabled)
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
tcp_reordering - INTEGER
|
2014-10-28 12:45:24 +08:00
|
|
|
Initial reordering level of packets in a TCP stream.
|
|
|
|
TCP stack can then dynamically adjust flow reordering level
|
|
|
|
between this initial value and tcp_max_reordering
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
Default: 3
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-10-28 12:45:24 +08:00
|
|
|
tcp_max_reordering - INTEGER
|
|
|
|
Maximal reordering level of packets in a TCP stream.
|
|
|
|
300 is a fairly conservative value, but you might increase it
|
|
|
|
if paths are using per packet load balancing (like bonding rr mode)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-10-28 12:45:24 +08:00
|
|
|
Default: 300
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
tcp_retrans_collapse - BOOLEAN
|
|
|
|
Bug-to-bug compatibility with some broken printers.
|
|
|
|
On retransmit try to send bigger packets to work around bugs in
|
|
|
|
certain TCP stacks.
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_retries1 - INTEGER
|
2009-09-01 18:24:04 +08:00
|
|
|
This value influences the time, after which TCP decides, that
|
|
|
|
something is wrong due to unacknowledged RTO retransmissions,
|
|
|
|
and reports this suspicion to the network layer.
|
|
|
|
See tcp_retries2 for more details.
|
|
|
|
|
|
|
|
RFC 1122 recommends at least 3 retransmissions, which is the
|
|
|
|
default.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_retries2 - INTEGER
|
2009-09-01 18:24:04 +08:00
|
|
|
This value influences the timeout of an alive TCP connection,
|
|
|
|
when RTO retransmissions remain unacknowledged.
|
|
|
|
Given a value of N, a hypothetical TCP connection following
|
|
|
|
exponential backoff with an initial RTO of TCP_RTO_MIN would
|
|
|
|
retransmit N times before killing the connection at the (N+1)th RTO.
|
|
|
|
|
|
|
|
The default value of 15 yields a hypothetical timeout of 924.6
|
|
|
|
seconds and is a lower bound for the effective timeout.
|
|
|
|
TCP will effectively time out at the first RTO which exceeds the
|
|
|
|
hypothetical timeout.
|
|
|
|
|
|
|
|
RFC 1122 recommends at least 100 seconds for the timeout,
|
|
|
|
which corresponds to a value of at least 8.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_rfc1337 - BOOLEAN
|
|
|
|
If set, the TCP stack behaves conforming to RFC1337. If unset,
|
|
|
|
we are not conforming to RFC, but prevent TCP TIME_WAIT
|
|
|
|
assassination.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default: 0
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
tcp_rmem - vector of 3 INTEGERs: min, default, max
|
|
|
|
min: Minimal size of receive buffer used by TCP sockets.
|
|
|
|
It is guaranteed to each TCP socket, even under moderate memory
|
|
|
|
pressure.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-02-05 10:07:10 +08:00
|
|
|
Default: 4K
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-07-11 07:47:41 +08:00
|
|
|
default: initial size of receive buffer used by TCP sockets.
|
2005-04-17 06:20:36 +08:00
|
|
|
This value overrides net.core.rmem_default used by other protocols.
|
2021-02-11 01:13:33 +08:00
|
|
|
Default: 131072 bytes.
|
|
|
|
This value results in initial window of 65535.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
max: maximal size of receive buffer allowed for automatically
|
|
|
|
selected receiver buffers for TCP socket. This value does not override
|
2008-07-11 07:47:41 +08:00
|
|
|
net.core.rmem_max. Calling setsockopt() with SO_RCVBUF disables
|
|
|
|
automatic tuning of that socket's receive buffer size, in which
|
|
|
|
case this value is ignored.
|
2021-02-11 01:13:33 +08:00
|
|
|
Default: between 131072 and 6MB, depending on RAM size.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_sack - BOOLEAN
|
|
|
|
Enable select acknowledgments (SACKS).
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-05-18 05:47:28 +08:00
|
|
|
tcp_comp_sack_delay_ns - LONG INTEGER
|
|
|
|
TCP tries to reduce number of SACK sent, using a timer
|
|
|
|
based on 5% of SRTT, capped by this sysctl, in nano seconds.
|
|
|
|
The default is 1ms, based on TSO autosizing period.
|
|
|
|
|
|
|
|
Default : 1,000,000 ns (1 ms)
|
|
|
|
|
2020-05-01 01:35:43 +08:00
|
|
|
tcp_comp_sack_slack_ns - LONG INTEGER
|
|
|
|
This sysctl control the slack used when arming the
|
|
|
|
timer used by SACK compression. This gives extra time
|
|
|
|
for small RTT flows, and reduces system overhead by allowing
|
|
|
|
opportunistic reduction of timer interrupts.
|
|
|
|
|
|
|
|
Default : 100,000 ns (100 us)
|
|
|
|
|
2018-05-18 05:47:29 +08:00
|
|
|
tcp_comp_sack_nr - INTEGER
|
2019-05-21 11:41:15 +08:00
|
|
|
Max number of SACK that can be compressed.
|
2018-05-18 05:47:29 +08:00
|
|
|
Using 0 disables SACK compression.
|
|
|
|
|
2019-05-21 11:41:15 +08:00
|
|
|
Default : 44
|
2018-05-18 05:47:29 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_slow_start_after_idle - BOOLEAN
|
|
|
|
If set, provide RFC2861 behavior and time out the congestion
|
|
|
|
window after an idle period. An idle period is defined at
|
|
|
|
the current RTO. If unset, the congestion window will not
|
|
|
|
be timed out after an idle period.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default: 1
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_stdurg - BOOLEAN
|
2008-07-11 07:50:26 +08:00
|
|
|
Use the Host requirements interpretation of the TCP urgent pointer field.
|
2006-11-10 08:37:26 +08:00
|
|
|
Most hosts use the older BSD interpretation, so if you turn this on
|
|
|
|
Linux might not communicate correctly with them.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default: FALSE
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_synack_retries - INTEGER
|
|
|
|
Number of times SYNACKs for a passive TCP connection attempt will
|
|
|
|
be retransmitted. Should not be higher than 255. Default value
|
2012-08-31 10:48:31 +08:00
|
|
|
is 5, which corresponds to 31seconds till the last retransmission
|
|
|
|
with the current initial RTO of 1second. With this the final timeout
|
|
|
|
for a passive TCP connection will happen after 63seconds.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-01-03 08:07:38 +08:00
|
|
|
tcp_syncookies - INTEGER
|
2013-06-21 15:18:32 +08:00
|
|
|
Only valid when the kernel was compiled with CONFIG_SYN_COOKIES
|
2006-11-10 08:37:26 +08:00
|
|
|
Send out syncookies when the syn backlog queue of a socket
|
2008-07-11 07:50:26 +08:00
|
|
|
overflows. This is to prevent against the common 'SYN flood attack'
|
2013-06-21 15:18:32 +08:00
|
|
|
Default: 1
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Note, that syncookies is fallback facility.
|
|
|
|
It MUST NOT be used to help highly loaded servers to stand
|
2008-07-11 07:50:26 +08:00
|
|
|
against legal connection rate. If you see SYN flood warnings
|
2006-11-10 08:37:26 +08:00
|
|
|
in your logs, but investigation shows that they occur
|
|
|
|
because of overload with legal connections, you should tune
|
|
|
|
another parameters until this warning disappear.
|
|
|
|
See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
syncookies seriously violate TCP protocol, do not allow
|
|
|
|
to use TCP extensions, can result in serious degradation
|
|
|
|
of some services (f.e. SMTP relaying), visible not by you,
|
|
|
|
but your clients and relays, contacting you. While you see
|
2008-07-11 07:50:26 +08:00
|
|
|
SYN flood warnings in logs not being really flooded, your server
|
2006-11-10 08:37:26 +08:00
|
|
|
is seriously misconfigured.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-07-26 23:43:23 +08:00
|
|
|
If you want to test which effects syncookies have to your
|
|
|
|
network connections you can set this knob to 2 to enable
|
|
|
|
unconditionally generation of syncookies.
|
|
|
|
|
2021-06-12 20:32:14 +08:00
|
|
|
tcp_migrate_req - BOOLEAN
|
|
|
|
The incoming connection is tied to a specific listening socket when
|
|
|
|
the initial SYN packet is received during the three-way handshake.
|
|
|
|
When a listener is closed, in-flight request sockets during the
|
|
|
|
handshake and established sockets in the accept queue are aborted.
|
|
|
|
|
|
|
|
If the listener has SO_REUSEPORT enabled, other listeners on the
|
|
|
|
same port should have been able to accept such connections. This
|
|
|
|
option makes it possible to migrate such child sockets to another
|
|
|
|
listener after close() or shutdown().
|
|
|
|
|
|
|
|
The BPF_SK_REUSEPORT_SELECT_OR_MIGRATE type of eBPF program should
|
|
|
|
usually be used to define the policy to pick an alive listener.
|
|
|
|
Otherwise, the kernel will randomly pick an alive listener only if
|
|
|
|
this option is enabled.
|
|
|
|
|
|
|
|
Note that migration between listeners with different settings may
|
|
|
|
crash applications. Let's say migration happens from listener A to
|
|
|
|
B, and only B has TCP_SAVE_SYN enabled. B cannot read SYN data from
|
|
|
|
the requests migrated from A. To avoid such a situation, cancel
|
|
|
|
migration by returning SK_DROP in the type of eBPF program, or
|
|
|
|
disable this option.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2012-07-19 14:43:09 +08:00
|
|
|
tcp_fastopen - INTEGER
|
2016-08-23 08:17:54 +08:00
|
|
|
Enable TCP Fast Open (RFC7413) to send and accept data in the opening
|
|
|
|
SYN packet.
|
2012-08-31 20:29:11 +08:00
|
|
|
|
2016-08-23 08:17:54 +08:00
|
|
|
The client support is enabled by flag 0x1 (on by default). The client
|
|
|
|
then must use sendmsg() or sendto() with the MSG_FASTOPEN flag,
|
|
|
|
rather than connect() to send data in SYN.
|
2012-07-19 14:43:09 +08:00
|
|
|
|
2016-08-23 08:17:54 +08:00
|
|
|
The server support is enabled by flag 0x2 (off by default). Then
|
|
|
|
either enable for all listeners with another flag (0x400) or
|
|
|
|
enable individual listeners via TCP_FASTOPEN socket option with
|
|
|
|
the option value being the length of the syn-data backlog.
|
2012-07-19 14:43:09 +08:00
|
|
|
|
2016-08-23 08:17:54 +08:00
|
|
|
The values (bitmap) are
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
===== ======== ======================================================
|
|
|
|
0x1 (client) enables sending data in the opening SYN on the client.
|
|
|
|
0x2 (server) enables the server support, i.e., allowing data in
|
2016-08-23 08:17:54 +08:00
|
|
|
a SYN packet to be accepted and passed to the
|
|
|
|
application before 3-way handshake finishes.
|
2020-04-28 06:01:49 +08:00
|
|
|
0x4 (client) send data in the opening SYN regardless of cookie
|
2016-08-23 08:17:54 +08:00
|
|
|
availability and without a cookie option.
|
2020-04-28 06:01:49 +08:00
|
|
|
0x200 (server) accept data-in-SYN w/o any cookie option present.
|
|
|
|
0x400 (server) enable all listeners to support Fast Open by
|
2016-08-23 08:17:54 +08:00
|
|
|
default without explicit TCP_FASTOPEN socket option.
|
2020-04-28 06:01:49 +08:00
|
|
|
===== ======== ======================================================
|
2016-08-23 08:17:54 +08:00
|
|
|
|
|
|
|
Default: 0x1
|
2012-08-31 20:29:11 +08:00
|
|
|
|
2020-07-04 06:41:13 +08:00
|
|
|
Note that additional client or server features are only
|
2016-08-23 08:17:54 +08:00
|
|
|
effective if the basic support (0x1 and 0x2) are enabled respectively.
|
2012-08-31 20:29:11 +08:00
|
|
|
|
net/tcp_fastopen: Disable active side TFO in certain scenarios
Middlebox firewall issues can potentially cause server's data being
blackholed after a successful 3WHS using TFO. Following are the related
reports from Apple:
https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf
Slide 31 identifies an issue where the client ACK to the server's data
sent during a TFO'd handshake is dropped.
C ---> syn-data ---> S
C <--- syn/ack ----- S
C (accept & write)
C <---- data ------- S
C ----- ACK -> X S
[retry and timeout]
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
Slide 5 shows a similar situation that the server's data gets dropped
after 3WHS.
C ---- syn-data ---> S
C <--- syn/ack ----- S
C ---- ack --------> S
S (accept & write)
C? X <- data ------ S
[retry and timeout]
This is the worst failure b/c the client can not detect such behavior to
mitigate the situation (such as disabling TFO). Failing to proceed, the
application (e.g., SSL library) may simply timeout and retry with TFO
again, and the process repeats indefinitely.
The proposed solution is to disable active TFO globally under the
following circumstances:
1. client side TFO socket detects out of order FIN
2. client side TFO socket receives out of order RST
We disable active side TFO globally for 1hr at first. Then if it
happens again, we disable it for 2h, then 4h, 8h, ...
And we reset the timeout to 1hr if a client side TFO sockets not opened
on loopback has successfully received data segs from server.
And we examine this condition during close().
The rational behind it is that when such firewall issue happens,
application running on the client should eventually close the socket as
it is not able to get the data it is expecting. Or application running
on the server should close the socket as it is not able to receive any
response from client.
In both cases, out of order FIN or RST will get received on the client
given that the firewall will not block them as no data are in those
frames.
And we want to disable active TFO globally as it helps if the middle box
is very close to the client and most of the connections are likely to
fail.
Also, add a debug sysctl:
tcp_fastopen_blackhole_detect_timeout_sec:
the initial timeout to use when firewall blackhole issue happens.
This can be set and read.
When setting it to 0, it means to disable the active disable logic.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-21 05:45:46 +08:00
|
|
|
tcp_fastopen_blackhole_timeout_sec - INTEGER
|
|
|
|
Initial time period in second to disable Fastopen on active TCP sockets
|
|
|
|
when a TFO firewall blackhole issue happens.
|
|
|
|
This time period will grow exponentially when more blackhole issues
|
|
|
|
get detected right after Fastopen is re-enabled and will reset to
|
|
|
|
initial value when the blackhole issue goes away.
|
2017-12-13 05:10:40 +08:00
|
|
|
0 to disable the blackhole detection.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2021-07-22 01:27:38 +08:00
|
|
|
By default, it is set to 0 (feature is disabled).
|
net/tcp_fastopen: Disable active side TFO in certain scenarios
Middlebox firewall issues can potentially cause server's data being
blackholed after a successful 3WHS using TFO. Following are the related
reports from Apple:
https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf
Slide 31 identifies an issue where the client ACK to the server's data
sent during a TFO'd handshake is dropped.
C ---> syn-data ---> S
C <--- syn/ack ----- S
C (accept & write)
C <---- data ------- S
C ----- ACK -> X S
[retry and timeout]
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
Slide 5 shows a similar situation that the server's data gets dropped
after 3WHS.
C ---- syn-data ---> S
C <--- syn/ack ----- S
C ---- ack --------> S
S (accept & write)
C? X <- data ------ S
[retry and timeout]
This is the worst failure b/c the client can not detect such behavior to
mitigate the situation (such as disabling TFO). Failing to proceed, the
application (e.g., SSL library) may simply timeout and retry with TFO
again, and the process repeats indefinitely.
The proposed solution is to disable active TFO globally under the
following circumstances:
1. client side TFO socket detects out of order FIN
2. client side TFO socket receives out of order RST
We disable active side TFO globally for 1hr at first. Then if it
happens again, we disable it for 2h, then 4h, 8h, ...
And we reset the timeout to 1hr if a client side TFO sockets not opened
on loopback has successfully received data segs from server.
And we examine this condition during close().
The rational behind it is that when such firewall issue happens,
application running on the client should eventually close the socket as
it is not able to get the data it is expecting. Or application running
on the server should close the socket as it is not able to receive any
response from client.
In both cases, out of order FIN or RST will get received on the client
given that the firewall will not block them as no data are in those
frames.
And we want to disable active TFO globally as it helps if the middle box
is very close to the client and most of the connections are likely to
fail.
Also, add a debug sysctl:
tcp_fastopen_blackhole_detect_timeout_sec:
the initial timeout to use when firewall blackhole issue happens.
This can be set and read.
When setting it to 0, it means to disable the active disable logic.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-21 05:45:46 +08:00
|
|
|
|
2019-05-30 00:34:00 +08:00
|
|
|
tcp_fastopen_key - list of comma separated 32-digit hexadecimal INTEGERs
|
|
|
|
The list consists of a primary key and an optional backup key. The
|
|
|
|
primary key is used for both creating and validating cookies, while the
|
|
|
|
optional backup key is only used for validating cookies. The purpose of
|
|
|
|
the backup key is to maximize TFO validation when keys are rotated.
|
|
|
|
|
|
|
|
A randomly chosen primary key may be configured by the kernel if
|
|
|
|
the tcp_fastopen sysctl is set to 0x400 (see above), or if the
|
|
|
|
TCP_FASTOPEN setsockopt() optname is set and a key has not been
|
|
|
|
previously configured via sysctl. If keys are configured via
|
|
|
|
setsockopt() by using the TCP_FASTOPEN_KEY optname, then those
|
|
|
|
per-socket keys will be used instead of any keys that are specified via
|
|
|
|
sysctl.
|
|
|
|
|
|
|
|
A key is specified as 4 8-digit hexadecimal integers which are separated
|
|
|
|
by a '-' as: xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx. Leading zeros may be
|
|
|
|
omitted. A primary and a backup key may be specified by separating them
|
|
|
|
by a comma. If only one key is specified, it becomes the primary key and
|
|
|
|
any previously configured backup keys are removed.
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_syn_retries - INTEGER
|
|
|
|
Number of times initial SYNs for an active TCP connection attempt
|
2016-01-20 16:12:33 +08:00
|
|
|
will be retransmitted. Should not be higher than 127. Default value
|
2013-01-03 15:50:29 +08:00
|
|
|
is 6, which corresponds to 63seconds till the last retransmission
|
2012-08-31 10:48:31 +08:00
|
|
|
with the current initial RTO of 1second. With this the final timeout
|
|
|
|
for an active TCP connection attempt will happen after 127seconds.
|
2006-11-10 08:37:26 +08:00
|
|
|
|
2016-12-01 18:32:07 +08:00
|
|
|
tcp_timestamps - INTEGER
|
2020-04-28 06:01:49 +08:00
|
|
|
Enable timestamps as defined in RFC1323.
|
|
|
|
|
|
|
|
- 0: Disabled.
|
|
|
|
- 1: Enable timestamps as defined in RFC1323 and use random offset for
|
|
|
|
each connection rather than only using the current time.
|
|
|
|
- 2: Like 1, but without random offsets.
|
|
|
|
|
2016-12-01 18:32:07 +08:00
|
|
|
Default: 1
|
2005-04-17 06:20:36 +08:00
|
|
|
|
tcp: TSO packets automatic sizing
After hearing many people over past years complaining against TSO being
bursty or even buggy, we are proud to present automatic sizing of TSO
packets.
One part of the problem is that tcp_tso_should_defer() uses an heuristic
relying on upcoming ACKS instead of a timer, but more generally, having
big TSO packets makes little sense for low rates, as it tends to create
micro bursts on the network, and general consensus is to reduce the
buffering amount.
This patch introduces a per socket sk_pacing_rate, that approximates
the current sending rate, and allows us to size the TSO packets so
that we try to send one packet every ms.
This field could be set by other transports.
Patch has no impact for high speed flows, where having large TSO packets
makes sense to reach line rate.
For other flows, this helps better packet scheduling and ACK clocking.
This patch increases performance of TCP flows in lossy environments.
A new sysctl (tcp_min_tso_segs) is added, to specify the
minimal size of a TSO packet (default being 2).
A follow-up patch will provide a new packet scheduler (FQ), using
sk_pacing_rate as an input to perform optional per flow pacing.
This explains why we chose to set sk_pacing_rate to twice the current
rate, allowing 'slow start' ramp up.
sk_pacing_rate = 2 * cwnd * mss / srtt
v2: Neal Cardwell reported a suspect deferring of last two segments on
initial write of 10 MSS, I had to change tcp_tso_should_defer() to take
into account tp->xmit_size_goal_segs
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Van Jacobson <vanj@google.com>
Cc: Tom Herbert <therbert@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-27 20:46:32 +08:00
|
|
|
tcp_min_tso_segs - INTEGER
|
|
|
|
Minimal number of segments per TSO frame.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
tcp: TSO packets automatic sizing
After hearing many people over past years complaining against TSO being
bursty or even buggy, we are proud to present automatic sizing of TSO
packets.
One part of the problem is that tcp_tso_should_defer() uses an heuristic
relying on upcoming ACKS instead of a timer, but more generally, having
big TSO packets makes little sense for low rates, as it tends to create
micro bursts on the network, and general consensus is to reduce the
buffering amount.
This patch introduces a per socket sk_pacing_rate, that approximates
the current sending rate, and allows us to size the TSO packets so
that we try to send one packet every ms.
This field could be set by other transports.
Patch has no impact for high speed flows, where having large TSO packets
makes sense to reach line rate.
For other flows, this helps better packet scheduling and ACK clocking.
This patch increases performance of TCP flows in lossy environments.
A new sysctl (tcp_min_tso_segs) is added, to specify the
minimal size of a TSO packet (default being 2).
A follow-up patch will provide a new packet scheduler (FQ), using
sk_pacing_rate as an input to perform optional per flow pacing.
This explains why we chose to set sk_pacing_rate to twice the current
rate, allowing 'slow start' ramp up.
sk_pacing_rate = 2 * cwnd * mss / srtt
v2: Neal Cardwell reported a suspect deferring of last two segments on
initial write of 10 MSS, I had to change tcp_tso_should_defer() to take
into account tp->xmit_size_goal_segs
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Van Jacobson <vanj@google.com>
Cc: Tom Herbert <therbert@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-27 20:46:32 +08:00
|
|
|
Since linux-3.12, TCP does an automatic sizing of TSO frames,
|
|
|
|
depending on flow rate, instead of filling 64Kbytes packets.
|
|
|
|
For specific usages, it's possible to force TCP to build big
|
|
|
|
TSO frames. Note that TCP stack might split too big TSO packets
|
|
|
|
if available window is too small.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
tcp: TSO packets automatic sizing
After hearing many people over past years complaining against TSO being
bursty or even buggy, we are proud to present automatic sizing of TSO
packets.
One part of the problem is that tcp_tso_should_defer() uses an heuristic
relying on upcoming ACKS instead of a timer, but more generally, having
big TSO packets makes little sense for low rates, as it tends to create
micro bursts on the network, and general consensus is to reduce the
buffering amount.
This patch introduces a per socket sk_pacing_rate, that approximates
the current sending rate, and allows us to size the TSO packets so
that we try to send one packet every ms.
This field could be set by other transports.
Patch has no impact for high speed flows, where having large TSO packets
makes sense to reach line rate.
For other flows, this helps better packet scheduling and ACK clocking.
This patch increases performance of TCP flows in lossy environments.
A new sysctl (tcp_min_tso_segs) is added, to specify the
minimal size of a TSO packet (default being 2).
A follow-up patch will provide a new packet scheduler (FQ), using
sk_pacing_rate as an input to perform optional per flow pacing.
This explains why we chose to set sk_pacing_rate to twice the current
rate, allowing 'slow start' ramp up.
sk_pacing_rate = 2 * cwnd * mss / srtt
v2: Neal Cardwell reported a suspect deferring of last two segments on
initial write of 10 MSS, I had to change tcp_tso_should_defer() to take
into account tp->xmit_size_goal_segs
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Van Jacobson <vanj@google.com>
Cc: Tom Herbert <therbert@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-08-27 20:46:32 +08:00
|
|
|
Default: 2
|
|
|
|
|
tcp: adjust TSO packet sizes based on min_rtt
Back when tcp_tso_autosize() and TCP pacing were introduced,
our focus was really to reduce burst sizes for long distance
flows.
The simple heuristic of using sk_pacing_rate/1024 has worked
well, but can lead to too small packets for hosts in the same
rack/cluster, when thousands of flows compete for the bottleneck.
Neal Cardwell had the idea of making the TSO burst size
a function of both sk_pacing_rate and tcp_min_rtt()
Indeed, for local flows, sending bigger bursts is better
to reduce cpu costs, as occasional losses can be repaired
quite fast.
This patch is based on Neal Cardwell implementation
done more than two years ago.
bbr is adjusting max_pacing_rate based on measured bandwidth,
while cubic would over estimate max_pacing_rate.
/proc/sys/net/ipv4/tcp_tso_rtt_log can be used to tune or disable
this new feature, in logarithmic steps.
Tested:
100Gbit NIC, two hosts in the same rack, 4K MTU.
600 flows rate-limited to 20000000 bytes per second.
Before patch: (TSO sizes would be limited to 20000000/1024/4096 -> 4 segments per TSO)
~# echo 0 >/proc/sys/net/ipv4/tcp_tso_rtt_log
~# nstat -n;perf stat ./super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000;nstat|egrep "TcpInSegs|TcpOutSegs|TcpRetransSegs|Delivered"
96005
Performance counter stats for './super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000':
65,945.29 msec task-clock # 2.845 CPUs utilized
1,314,632 context-switches # 19935.279 M/sec
5,292 cpu-migrations # 80.249 M/sec
940,641 page-faults # 14264.023 M/sec
201,117,030,926 cycles # 3049769.216 GHz (83.45%)
17,699,435,405 stalled-cycles-frontend # 8.80% frontend cycles idle (83.48%)
136,584,015,071 stalled-cycles-backend # 67.91% backend cycles idle (83.44%)
53,809,530,436 instructions # 0.27 insn per cycle
# 2.54 stalled cycles per insn (83.36%)
9,062,315,523 branches # 137422329.563 M/sec (83.22%)
153,008,621 branch-misses # 1.69% of all branches (83.32%)
23.182970846 seconds time elapsed
TcpInSegs 15648792 0.0
TcpOutSegs 58659110 0.0 # Average of 3.7 4K segments per TSO packet
TcpExtTCPDelivered 58654791 0.0
TcpExtTCPDeliveredCE 19 0.0
After patch:
~# echo 9 >/proc/sys/net/ipv4/tcp_tso_rtt_log
~# nstat -n;perf stat ./super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000;nstat|egrep "TcpInSegs|TcpOutSegs|TcpRetransSegs|Delivered"
96046
Performance counter stats for './super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000':
48,982.58 msec task-clock # 2.104 CPUs utilized
186,014 context-switches # 3797.599 M/sec
3,109 cpu-migrations # 63.472 M/sec
941,180 page-faults # 19214.814 M/sec
153,459,763,868 cycles # 3132982.807 GHz (83.56%)
12,069,861,356 stalled-cycles-frontend # 7.87% frontend cycles idle (83.32%)
120,485,917,953 stalled-cycles-backend # 78.51% backend cycles idle (83.24%)
36,803,672,106 instructions # 0.24 insn per cycle
# 3.27 stalled cycles per insn (83.18%)
5,947,266,275 branches # 121417383.427 M/sec (83.64%)
87,984,616 branch-misses # 1.48% of all branches (83.43%)
23.281200256 seconds time elapsed
TcpInSegs 1434706 0.0
TcpOutSegs 58883378 0.0 # Average of 41 4K segments per TSO packet
TcpExtTCPDelivered 58878971 0.0
TcpExtTCPDeliveredCE 9664 0.0
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Neal Cardwell <ncardwell@google.com>
Link: https://lore.kernel.org/r/20220309015757.2532973-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-09 09:57:57 +08:00
|
|
|
tcp_tso_rtt_log - INTEGER
|
|
|
|
Adjustment of TSO packet sizes based on min_rtt
|
|
|
|
|
|
|
|
Starting from linux-5.18, TCP autosizing can be tweaked
|
|
|
|
for flows having small RTT.
|
|
|
|
|
|
|
|
Old autosizing was splitting the pacing budget to send 1024 TSO
|
|
|
|
per second.
|
|
|
|
|
|
|
|
tso_packet_size = sk->sk_pacing_rate / 1024;
|
|
|
|
|
|
|
|
With the new mechanism, we increase this TSO sizing using:
|
|
|
|
|
|
|
|
distance = min_rtt_usec / (2^tcp_tso_rtt_log)
|
|
|
|
tso_packet_size += gso_max_size >> distance;
|
|
|
|
|
|
|
|
This means that flows between very close hosts can use bigger
|
|
|
|
TSO packets, reducing their cpu costs.
|
|
|
|
|
|
|
|
If you want to use the old autosizing, set this sysctl to 0.
|
|
|
|
|
|
|
|
Default: 9 (2^9 = 512 usec)
|
|
|
|
|
2015-08-22 08:38:02 +08:00
|
|
|
tcp_pacing_ss_ratio - INTEGER
|
|
|
|
sk->sk_pacing_rate is set by TCP stack using a ratio applied
|
|
|
|
to current rate. (current_rate = cwnd * mss / srtt)
|
|
|
|
If TCP is in slow start, tcp_pacing_ss_ratio is applied
|
|
|
|
to let TCP probe for bigger speeds, assuming cwnd can be
|
|
|
|
doubled every other RTT.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-08-22 08:38:02 +08:00
|
|
|
Default: 200
|
|
|
|
|
|
|
|
tcp_pacing_ca_ratio - INTEGER
|
|
|
|
sk->sk_pacing_rate is set by TCP stack using a ratio applied
|
|
|
|
to current rate. (current_rate = cwnd * mss / srtt)
|
|
|
|
If TCP is in congestion avoidance phase, tcp_pacing_ca_ratio
|
|
|
|
is applied to conservatively probe for bigger throughput.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-08-22 08:38:02 +08:00
|
|
|
Default: 120
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
tcp_tso_win_divisor - INTEGER
|
2006-11-10 08:37:26 +08:00
|
|
|
This allows control over what percentage of the congestion window
|
|
|
|
can be consumed by a single TSO frame.
|
|
|
|
The setting of this parameter is a choice between burstiness and
|
|
|
|
building larger TSO frames.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default: 3
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-06-04 01:41:17 +08:00
|
|
|
tcp_tw_reuse - INTEGER
|
|
|
|
Enable reuse of TIME-WAIT sockets for new connections when it is
|
|
|
|
safe from protocol viewpoint.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - disable
|
|
|
|
- 1 - global enable
|
|
|
|
- 2 - enable for loopback traffic only
|
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
It should not be changed without advice/request of technical
|
|
|
|
experts.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-06-04 01:41:17 +08:00
|
|
|
Default: 2
|
2006-11-10 08:35:15 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_window_scaling - BOOLEAN
|
|
|
|
Enable window scaling as defined in RFC1323.
|
2006-11-10 08:32:06 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
tcp_wmem - vector of 3 INTEGERs: min, default, max
|
2008-07-11 07:47:41 +08:00
|
|
|
min: Amount of memory reserved for send buffers for TCP sockets.
|
2006-11-10 08:37:26 +08:00
|
|
|
Each TCP socket has rights to use it due to fact of its birth.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-02-05 10:07:10 +08:00
|
|
|
Default: 4K
|
2005-06-24 03:22:36 +08:00
|
|
|
|
2008-07-11 07:47:41 +08:00
|
|
|
default: initial size of send buffer used by TCP sockets. This
|
|
|
|
value overrides net.core.wmem_default used by other protocols.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-07-11 07:47:41 +08:00
|
|
|
It is usually lower than net.core.wmem_default.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-11-10 08:37:26 +08:00
|
|
|
Default: 16K
|
|
|
|
|
2008-07-11 07:47:41 +08:00
|
|
|
max: Maximal amount of memory allowed for automatically tuned
|
|
|
|
send buffers for TCP sockets. This value does not override
|
|
|
|
net.core.wmem_max. Calling setsockopt() with SO_SNDBUF disables
|
|
|
|
automatic tuning of that socket's send buffer size, in which case
|
|
|
|
this value is ignored.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-07-11 07:47:41 +08:00
|
|
|
Default: between 64K and 4MB, depending on RAM size.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
tcp: TCP_NOTSENT_LOWAT socket option
Idea of this patch is to add optional limitation of number of
unsent bytes in TCP sockets, to reduce usage of kernel memory.
TCP receiver might announce a big window, and TCP sender autotuning
might allow a large amount of bytes in write queue, but this has little
performance impact if a large part of this buffering is wasted :
Write queue needs to be large only to deal with large BDP, not
necessarily to cope with scheduling delays (incoming ACKS make room
for the application to queue more bytes)
For most workloads, using a value of 128 KB or less is OK to give
applications enough time to react to POLLOUT events in time
(or being awaken in a blocking sendmsg())
This patch adds two ways to set the limit :
1) Per socket option TCP_NOTSENT_LOWAT
2) A sysctl (/proc/sys/net/ipv4/tcp_notsent_lowat) for sockets
not using TCP_NOTSENT_LOWAT socket option (or setting a zero value)
Default value being UINT_MAX (0xFFFFFFFF), meaning this has no effect.
This changes poll()/select()/epoll() to report POLLOUT
only if number of unsent bytes is below tp->nosent_lowat
Note this might increase number of sendmsg()/sendfile() calls
when using non blocking sockets,
and increase number of context switches for blocking sockets.
Note this is not related to SO_SNDLOWAT (as SO_SNDLOWAT is
defined as :
Specify the minimum number of bytes in the buffer until
the socket layer will pass the data to the protocol)
Tested:
netperf sessions, and watching /proc/net/protocols "memory" column for TCP
With 200 concurrent netperf -t TCP_STREAM sessions, amount of kernel memory
used by TCP buffers shrinks by ~55 % (20567 pages instead of 45458)
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 45458 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 45458 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 20567 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 20567 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
Using 128KB has no bad effect on the throughput or cpu usage
of a single flow, although there is an increase of context switches.
A bonus is that we hold socket lock for a shorter amount
of time and should improve latencies of ACK processing.
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1651584 6291456 16384 20.00 17447.90 10^6bits/s 3.13 S -1.00 U 0.353 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
412,514 context-switches
200.034645535 seconds time elapsed
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1593240 6291456 16384 20.00 17321.16 10^6bits/s 3.35 S -1.00 U 0.381 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
2,675,818 context-switches
200.029651391 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-By: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-07-23 11:27:07 +08:00
|
|
|
tcp_notsent_lowat - UNSIGNED INTEGER
|
|
|
|
A TCP socket can control the amount of unsent bytes in its write queue,
|
|
|
|
thanks to TCP_NOTSENT_LOWAT socket option. poll()/select()/epoll()
|
|
|
|
reports POLLOUT events if the amount of unsent bytes is below a per
|
|
|
|
socket value, and if the write queue is not full. sendmsg() will
|
|
|
|
also not add new buffers if the limit is hit.
|
|
|
|
|
|
|
|
This global variable controls the amount of unsent data for
|
|
|
|
sockets not using TCP_NOTSENT_LOWAT. For these sockets, a change
|
|
|
|
to the global variable has immediate effect.
|
|
|
|
|
|
|
|
Default: UINT_MAX (0xFFFFFFFF)
|
|
|
|
|
2006-03-21 14:40:29 +08:00
|
|
|
tcp_workaround_signed_windows - BOOLEAN
|
|
|
|
If set, assume no receipt of a window scaling option means the
|
|
|
|
remote TCP is broken and treats the window as a signed quantity.
|
|
|
|
If unset, assume the remote TCP is not broken even if we do
|
|
|
|
not receive a window scaling option from them.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-03-21 14:40:29 +08:00
|
|
|
Default: 0
|
|
|
|
|
2010-02-18 10:47:01 +08:00
|
|
|
tcp_thin_linear_timeouts - BOOLEAN
|
|
|
|
Enable dynamic triggering of linear timeouts for thin streams.
|
|
|
|
If set, a check is performed upon retransmission by timeout to
|
|
|
|
determine if the stream is thin (less than 4 packets in flight).
|
|
|
|
As long as the stream is found to be thin, up to 6 linear
|
|
|
|
timeouts may be performed before exponential backoff mode is
|
|
|
|
initiated. This improves retransmission latency for
|
|
|
|
non-aggressive thin streams, often found to be time-dependent.
|
|
|
|
For more information on thin streams, see
|
2020-05-01 00:04:29 +08:00
|
|
|
Documentation/networking/tcp-thin.rst
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2010-02-18 10:47:01 +08:00
|
|
|
Default: 0
|
|
|
|
|
tcp: TCP Small Queues
This introduce TSQ (TCP Small Queues)
TSQ goal is to reduce number of TCP packets in xmit queues (qdisc &
device queues), to reduce RTT and cwnd bias, part of the bufferbloat
problem.
sk->sk_wmem_alloc not allowed to grow above a given limit,
allowing no more than ~128KB [1] per tcp socket in qdisc/dev layers at a
given time.
TSO packets are sized/capped to half the limit, so that we have two
TSO packets in flight, allowing better bandwidth use.
As a side effect, setting the limit to 40000 automatically reduces the
standard gso max limit (65536) to 40000/2 : It can help to reduce
latencies of high prio packets, having smaller TSO packets.
This means we divert sock_wfree() to a tcp_wfree() handler, to
queue/send following frames when skb_orphan() [2] is called for the
already queued skbs.
Results on my dev machines (tg3/ixgbe nics) are really impressive,
using standard pfifo_fast, and with or without TSO/GSO.
Without reduction of nominal bandwidth, we have reduction of buffering
per bulk sender :
< 1ms on Gbit (instead of 50ms with TSO)
< 8ms on 100Mbit (instead of 132 ms)
I no longer have 4 MBytes backlogged in qdisc by a single netperf
session, and both side socket autotuning no longer use 4 Mbytes.
As skb destructor cannot restart xmit itself ( as qdisc lock might be
taken at this point ), we delegate the work to a tasklet. We use one
tasklest per cpu for performance reasons.
If tasklet finds a socket owned by the user, it sets TSQ_OWNED flag.
This flag is tested in a new protocol method called from release_sock(),
to eventually send new segments.
[1] New /proc/sys/net/ipv4/tcp_limit_output_bytes tunable
[2] skb_orphan() is usually called at TX completion time,
but some drivers call it in their start_xmit() handler.
These drivers should at least use BQL, or else a single TCP
session can still fill the whole NIC TX ring, since TSQ will
have no effect.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Dave Taht <dave.taht@bufferbloat.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Matt Mathis <mattmathis@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-07-11 13:50:31 +08:00
|
|
|
tcp_limit_output_bytes - INTEGER
|
|
|
|
Controls TCP Small Queue limit per tcp socket.
|
|
|
|
TCP bulk sender tends to increase packets in flight until it
|
|
|
|
gets losses notifications. With SNDBUF autotuning, this can
|
2018-06-27 21:34:26 +08:00
|
|
|
result in a large amount of packets queued on the local machine
|
|
|
|
(e.g.: qdiscs, CPU backlog, or device) hurting latency of other
|
|
|
|
flows, for typical pfifo_fast qdiscs. tcp_limit_output_bytes
|
|
|
|
limits the number of bytes on qdisc or device to reduce artificial
|
|
|
|
RTT/cwnd and reduce bufferbloat.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-11-11 23:34:28 +08:00
|
|
|
Default: 1048576 (16 * 65536)
|
tcp: TCP Small Queues
This introduce TSQ (TCP Small Queues)
TSQ goal is to reduce number of TCP packets in xmit queues (qdisc &
device queues), to reduce RTT and cwnd bias, part of the bufferbloat
problem.
sk->sk_wmem_alloc not allowed to grow above a given limit,
allowing no more than ~128KB [1] per tcp socket in qdisc/dev layers at a
given time.
TSO packets are sized/capped to half the limit, so that we have two
TSO packets in flight, allowing better bandwidth use.
As a side effect, setting the limit to 40000 automatically reduces the
standard gso max limit (65536) to 40000/2 : It can help to reduce
latencies of high prio packets, having smaller TSO packets.
This means we divert sock_wfree() to a tcp_wfree() handler, to
queue/send following frames when skb_orphan() [2] is called for the
already queued skbs.
Results on my dev machines (tg3/ixgbe nics) are really impressive,
using standard pfifo_fast, and with or without TSO/GSO.
Without reduction of nominal bandwidth, we have reduction of buffering
per bulk sender :
< 1ms on Gbit (instead of 50ms with TSO)
< 8ms on 100Mbit (instead of 132 ms)
I no longer have 4 MBytes backlogged in qdisc by a single netperf
session, and both side socket autotuning no longer use 4 Mbytes.
As skb destructor cannot restart xmit itself ( as qdisc lock might be
taken at this point ), we delegate the work to a tasklet. We use one
tasklest per cpu for performance reasons.
If tasklet finds a socket owned by the user, it sets TSQ_OWNED flag.
This flag is tested in a new protocol method called from release_sock(),
to eventually send new segments.
[1] New /proc/sys/net/ipv4/tcp_limit_output_bytes tunable
[2] skb_orphan() is usually called at TX completion time,
but some drivers call it in their start_xmit() handler.
These drivers should at least use BQL, or else a single TCP
session can still fill the whole NIC TX ring, since TSQ will
have no effect.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Dave Taht <dave.taht@bufferbloat.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Matt Mathis <mattmathis@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-07-11 13:50:31 +08:00
|
|
|
|
2012-07-17 16:13:05 +08:00
|
|
|
tcp_challenge_ack_limit - INTEGER
|
|
|
|
Limits number of Challenge ACK sent per second, as recommended
|
|
|
|
in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
|
2022-08-31 02:56:56 +08:00
|
|
|
Note that this per netns rate limit can allow some side channel
|
|
|
|
attacks and probably should not be enabled.
|
|
|
|
TCP stack implements per TCP socket limits anyway.
|
|
|
|
Default: INT_MAX (unlimited)
|
2012-07-17 16:13:05 +08:00
|
|
|
|
tcp: Introduce optional per-netns ehash.
The more sockets we have in the hash table, the longer we spend looking
up the socket. While running a number of small workloads on the same
host, they penalise each other and cause performance degradation.
The root cause might be a single workload that consumes much more
resources than the others. It often happens on a cloud service where
different workloads share the same computing resource.
On EC2 c5.24xlarge instance (196 GiB memory and 524288 (1Mi / 2) ehash
entries), after running iperf3 in different netns, creating 24Mi sockets
without data transfer in the root netns causes about 10% performance
regression for the iperf3's connection.
thash_entries sockets length Gbps
524288 1 1 50.7
24Mi 48 45.1
It is basically related to the length of the list of each hash bucket.
For testing purposes to see how performance drops along the length,
I set 131072 (1Mi / 8) to thash_entries, and here's the result.
thash_entries sockets length Gbps
131072 1 1 50.7
1Mi 8 49.9
2Mi 16 48.9
4Mi 32 47.3
8Mi 64 44.6
16Mi 128 40.6
24Mi 192 36.3
32Mi 256 32.5
40Mi 320 27.0
48Mi 384 25.0
To resolve the socket lookup degradation, we introduce an optional
per-netns hash table for TCP, but it's just ehash, and we still share
the global bhash, bhash2 and lhash2.
With a smaller ehash, we can look up non-listener sockets faster and
isolate such noisy neighbours. In addition, we can reduce lock contention.
We can control the ehash size by a new sysctl knob. However, depending
on workloads, it will require very sensitive tuning, so we disable the
feature by default (net.ipv4.tcp_child_ehash_entries == 0). Moreover,
we can fall back to using the global ehash in case we fail to allocate
enough memory for a new ehash. The maximum size is 16Mi, which is large
enough that even if we have 48Mi sockets, the average list length is 3,
and regression would be less than 1%.
We can check the current ehash size by another read-only sysctl knob,
net.ipv4.tcp_ehash_entries. A negative value means the netns shares
the global ehash (per-netns ehash is disabled or failed to allocate
memory).
# dmesg | cut -d ' ' -f 5- | grep "established hash"
TCP established hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
# sysctl net.ipv4.tcp_ehash_entries
net.ipv4.tcp_ehash_entries = 524288 # can be changed by thash_entries
# sysctl net.ipv4.tcp_child_ehash_entries
net.ipv4.tcp_child_ehash_entries = 0 # disabled by default
# ip netns add test1
# ip netns exec test1 sysctl net.ipv4.tcp_ehash_entries
net.ipv4.tcp_ehash_entries = -524288 # share the global ehash
# sysctl -w net.ipv4.tcp_child_ehash_entries=100
net.ipv4.tcp_child_ehash_entries = 100
# ip netns add test2
# ip netns exec test2 sysctl net.ipv4.tcp_ehash_entries
net.ipv4.tcp_ehash_entries = 128 # own a per-netns ehash with 2^n buckets
When more than two processes in the same netns create per-netns ehash
concurrently with different sizes, we need to guarantee the size in
one of the following ways:
1) Share the global ehash and create per-netns ehash
First, unshare() with tcp_child_ehash_entries==0. It creates dedicated
netns sysctl knobs where we can safely change tcp_child_ehash_entries
and clone()/unshare() to create a per-netns ehash.
2) Control write on sysctl by BPF
We can use BPF_PROG_TYPE_CGROUP_SYSCTL to allow/deny read/write on
sysctl knobs.
Note that the global ehash allocated at the boot time is spread over
available NUMA nodes, but inet_pernet_hashinfo_alloc() will allocate
pages for each per-netns ehash depending on the current process's NUMA
policy. By default, the allocation is done in the local node only, so
the per-netns hash table could fully reside on a random node. Thus,
depending on the NUMA policy the netns is created with and the CPU the
current thread is running on, we could see some performance differences
for highly optimised networking applications.
Note also that the default values of two sysctl knobs depend on the ehash
size and should be tuned carefully:
tcp_max_tw_buckets : tcp_child_ehash_entries / 2
tcp_max_syn_backlog : max(128, tcp_child_ehash_entries / 128)
As a bonus, we can dismantle netns faster. Currently, while destroying
netns, we call inet_twsk_purge(), which walks through the global ehash.
It can be potentially big because it can have many sockets other than
TIME_WAIT in all netns. Splitting ehash changes that situation, where
it's only necessary for inet_twsk_purge() to clean up TIME_WAIT sockets
in each netns.
With regard to this, we do not free the per-netns ehash in inet_twsk_kill()
to avoid UAF while iterating the per-netns ehash in inet_twsk_purge().
Instead, we do it in tcp_sk_exit_batch() after calling tcp_twsk_purge() to
keep it protocol-family-independent.
In the future, we could optimise ehash lookup/iteration further by removing
netns comparison for the per-netns ehash.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-08 09:10:22 +08:00
|
|
|
tcp_ehash_entries - INTEGER
|
|
|
|
Show the number of hash buckets for TCP sockets in the current
|
|
|
|
networking namespace.
|
|
|
|
|
|
|
|
A negative value means the networking namespace does not own its
|
|
|
|
hash buckets and shares the initial networking namespace's one.
|
|
|
|
|
|
|
|
tcp_child_ehash_entries - INTEGER
|
|
|
|
Control the number of hash buckets for TCP sockets in the child
|
|
|
|
networking namespace, which must be set before clone() or unshare().
|
|
|
|
|
|
|
|
If the value is not 0, the kernel uses a value rounded up to 2^n
|
|
|
|
as the actual hash bucket size. 0 is a special value, meaning
|
|
|
|
the child networking namespace will share the initial networking
|
|
|
|
namespace's hash buckets.
|
|
|
|
|
|
|
|
Note that the child will use the global one in case the kernel
|
|
|
|
fails to allocate enough memory. In addition, the global hash
|
|
|
|
buckets are spread over available NUMA nodes, but the allocation
|
|
|
|
of the child hash table depends on the current process's NUMA
|
|
|
|
policy, which could result in performance differences.
|
|
|
|
|
|
|
|
Note also that the default value of tcp_max_tw_buckets and
|
|
|
|
tcp_max_syn_backlog depend on the hash bucket size.
|
|
|
|
|
|
|
|
Possible values: 0, 2^n (n: 0 - 24 (16Mi))
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2022-10-26 21:51:11 +08:00
|
|
|
tcp_plb_enabled - BOOLEAN
|
|
|
|
If set and the underlying congestion control (e.g. DCTCP) supports
|
|
|
|
and enables PLB feature, TCP PLB (Protective Load Balancing) is
|
|
|
|
enabled. PLB is described in the following paper:
|
|
|
|
https://doi.org/10.1145/3544216.3544226. Based on PLB parameters,
|
|
|
|
upon sensing sustained congestion, TCP triggers a change in
|
|
|
|
flow label field for outgoing IPv6 packets. A change in flow label
|
|
|
|
field potentially changes the path of outgoing packets for switches
|
|
|
|
that use ECMP/WCMP for routing.
|
|
|
|
|
|
|
|
PLB changes socket txhash which results in a change in IPv6 Flow Label
|
|
|
|
field, and currently no-op for IPv4 headers. It is possible
|
|
|
|
to apply PLB for IPv4 with other network header fields (e.g. TCP
|
|
|
|
or IPv4 options) or using encapsulation where outer header is used
|
|
|
|
by switches to determine next hop. In either case, further host
|
|
|
|
and switch side changes will be needed.
|
|
|
|
|
|
|
|
When set, PLB assumes that congestion signal (e.g. ECN) is made
|
|
|
|
available and used by congestion control module to estimate a
|
|
|
|
congestion measure (e.g. ce_ratio). PLB needs a congestion measure to
|
|
|
|
make repathing decisions.
|
|
|
|
|
|
|
|
Default: FALSE
|
|
|
|
|
|
|
|
tcp_plb_idle_rehash_rounds - INTEGER
|
|
|
|
Number of consecutive congested rounds (RTT) seen after which
|
|
|
|
a rehash can be performed, given there are no packets in flight.
|
|
|
|
This is referred to as M in PLB paper:
|
|
|
|
https://doi.org/10.1145/3544216.3544226.
|
|
|
|
|
|
|
|
Possible Values: 0 - 31
|
|
|
|
|
|
|
|
Default: 3
|
|
|
|
|
|
|
|
tcp_plb_rehash_rounds - INTEGER
|
|
|
|
Number of consecutive congested rounds (RTT) seen after which
|
|
|
|
a forced rehash can be performed. Be careful when setting this
|
|
|
|
parameter, as a small value increases the risk of retransmissions.
|
|
|
|
This is referred to as N in PLB paper:
|
|
|
|
https://doi.org/10.1145/3544216.3544226.
|
|
|
|
|
|
|
|
Possible Values: 0 - 31
|
|
|
|
|
|
|
|
Default: 12
|
|
|
|
|
|
|
|
tcp_plb_suspend_rto_sec - INTEGER
|
|
|
|
Time, in seconds, to suspend PLB in event of an RTO. In order to avoid
|
|
|
|
having PLB repath onto a connectivity "black hole", after an RTO a TCP
|
|
|
|
connection suspends PLB repathing for a random duration between 1x and
|
|
|
|
2x of this parameter. Randomness is added to avoid concurrent rehashing
|
|
|
|
of multiple TCP connections. This should be set corresponding to the
|
|
|
|
amount of time it takes to repair a failed link.
|
|
|
|
|
|
|
|
Possible Values: 0 - 255
|
|
|
|
|
|
|
|
Default: 60
|
|
|
|
|
|
|
|
tcp_plb_cong_thresh - INTEGER
|
|
|
|
Fraction of packets marked with congestion over a round (RTT) to
|
|
|
|
tag that round as congested. This is referred to as K in the PLB paper:
|
|
|
|
https://doi.org/10.1145/3544216.3544226.
|
|
|
|
|
|
|
|
The 0-1 fraction range is mapped to 0-256 range to avoid floating
|
|
|
|
point operations. For example, 128 means that if at least 50% of
|
|
|
|
the packets in a round were marked as congested then the round
|
|
|
|
will be tagged as congested.
|
|
|
|
|
|
|
|
Setting threshold to 0 means that PLB repaths every RTT regardless
|
|
|
|
of congestion. This is not intended behavior for PLB and should be
|
|
|
|
used only for experimentation purpose.
|
|
|
|
|
|
|
|
Possible Values: 0 - 256
|
|
|
|
|
|
|
|
Default: 128
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
UDP variables
|
|
|
|
=============
|
2007-12-31 16:29:24 +08:00
|
|
|
|
2017-01-27 02:02:24 +08:00
|
|
|
udp_l3mdev_accept - BOOLEAN
|
|
|
|
Enabling this option allows a "global" bound socket to work
|
|
|
|
across L3 master domains (e.g., VRFs) with packets capable of
|
|
|
|
being received regardless of the L3 domain in which they
|
|
|
|
originated. Only valid when the kernel was compiled with
|
|
|
|
CONFIG_NET_L3_MASTER_DEV.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
Default: 0 (disabled)
|
2017-01-27 02:02:24 +08:00
|
|
|
|
2007-12-31 16:29:24 +08:00
|
|
|
udp_mem - vector of 3 INTEGERs: min, pressure, max
|
|
|
|
Number of pages allowed for queueing by all UDP sockets.
|
|
|
|
|
2021-11-05 15:35:41 +08:00
|
|
|
min: Number of pages allowed for queueing by all UDP sockets.
|
2007-12-31 16:29:24 +08:00
|
|
|
|
|
|
|
pressure: This value was introduced to follow format of tcp_mem.
|
|
|
|
|
2021-11-05 15:35:41 +08:00
|
|
|
max: This value was introduced to follow format of tcp_mem.
|
2007-12-31 16:29:24 +08:00
|
|
|
|
|
|
|
Default is calculated at boot time from amount of available memory.
|
|
|
|
|
|
|
|
udp_rmem_min - INTEGER
|
|
|
|
Minimal size of receive buffer used by UDP sockets in moderation.
|
|
|
|
Each UDP socket is able to use the size for receiving data, even if
|
|
|
|
total pages of UDP sockets exceed udp_mem pressure. The unit is byte.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-03-14 12:57:17 +08:00
|
|
|
Default: 4K
|
2007-12-31 16:29:24 +08:00
|
|
|
|
|
|
|
udp_wmem_min - INTEGER
|
2022-07-19 01:56:59 +08:00
|
|
|
UDP does not have tx memory accounting and this tunable has no effect.
|
2007-12-31 16:29:24 +08:00
|
|
|
|
udp: Introduce optional per-netns hash table.
The maximum hash table size is 64K due to the nature of the protocol. [0]
It's smaller than TCP, and fewer sockets can cause a performance drop.
On an EC2 c5.24xlarge instance (192 GiB memory), after running iperf3 in
different netns, creating 32Mi sockets without data transfer in the root
netns causes regression for the iperf3's connection.
uhash_entries sockets length Gbps
64K 1 1 5.69
1Mi 16 5.27
2Mi 32 4.90
4Mi 64 4.09
8Mi 128 2.96
16Mi 256 2.06
32Mi 512 1.12
The per-netns hash table breaks the lengthy lists into shorter ones. It is
useful on a multi-tenant system with thousands of netns. With smaller hash
tables, we can look up sockets faster, isolate noisy neighbours, and reduce
lock contention.
The max size of the per-netns table is 64K as well. This is because the
possible hash range by udp_hashfn() always fits in 64K within the same
netns and we cannot make full use of the whole buckets larger than 64K.
/* 0 < num < 64K -> X < hash < X + 64K */
(num + net_hash_mix(net)) & mask;
Also, the min size is 128. We use a bitmap to search for an available
port in udp_lib_get_port(). To keep the bitmap on the stack and not
fire the CONFIG_FRAME_WARN error at build time, we round up the table
size to 128.
The sysctl usage is the same with TCP:
$ dmesg | cut -d ' ' -f 6- | grep "UDP hash"
UDP hash table entries: 65536 (order: 9, 2097152 bytes, vmalloc)
# sysctl net.ipv4.udp_hash_entries
net.ipv4.udp_hash_entries = 65536 # can be changed by uhash_entries
# sysctl net.ipv4.udp_child_hash_entries
net.ipv4.udp_child_hash_entries = 0 # disabled by default
# ip netns add test1
# ip netns exec test1 sysctl net.ipv4.udp_hash_entries
net.ipv4.udp_hash_entries = -65536 # share the global table
# sysctl -w net.ipv4.udp_child_hash_entries=100
net.ipv4.udp_child_hash_entries = 100
# ip netns add test2
# ip netns exec test2 sysctl net.ipv4.udp_hash_entries
net.ipv4.udp_hash_entries = 128 # own a per-netns table with 2^n buckets
We could optimise the hash table lookup/iteration further by removing
the netns comparison for the per-netns one in the future. Also, we
could optimise the sparse udp_hslot layout by putting it in udp_table.
[0]: https://lore.kernel.org/netdev/4ACC2815.7010101@gmail.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-11-15 05:57:57 +08:00
|
|
|
udp_hash_entries - INTEGER
|
|
|
|
Show the number of hash buckets for UDP sockets in the current
|
|
|
|
networking namespace.
|
|
|
|
|
|
|
|
A negative value means the networking namespace does not own its
|
|
|
|
hash buckets and shares the initial networking namespace's one.
|
|
|
|
|
|
|
|
udp_child_ehash_entries - INTEGER
|
|
|
|
Control the number of hash buckets for UDP sockets in the child
|
|
|
|
networking namespace, which must be set before clone() or unshare().
|
|
|
|
|
|
|
|
If the value is not 0, the kernel uses a value rounded up to 2^n
|
|
|
|
as the actual hash bucket size. 0 is a special value, meaning
|
|
|
|
the child networking namespace will share the initial networking
|
|
|
|
namespace's hash buckets.
|
|
|
|
|
|
|
|
Note that the child will use the global one in case the kernel
|
|
|
|
fails to allocate enough memory. In addition, the global hash
|
|
|
|
buckets are spread over available NUMA nodes, but the allocation
|
|
|
|
of the child hash table depends on the current process's NUMA
|
|
|
|
policy, which could result in performance differences.
|
|
|
|
|
|
|
|
Possible values: 0, 2^n (n: 7 (128) - 16 (64K))
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
RAW variables
|
|
|
|
=============
|
2018-11-07 23:36:05 +08:00
|
|
|
|
|
|
|
raw_l3mdev_accept - BOOLEAN
|
|
|
|
Enabling this option allows a "global" bound socket to work
|
|
|
|
across L3 master domains (e.g., VRFs) with packets capable of
|
|
|
|
being received regardless of the L3 domain in which they
|
|
|
|
originated. Only valid when the kernel was compiled with
|
|
|
|
CONFIG_NET_L3_MASTER_DEV.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-11-07 23:36:05 +08:00
|
|
|
Default: 1 (enabled)
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
CIPSOv4 Variables
|
|
|
|
=================
|
2006-08-04 07:45:49 +08:00
|
|
|
|
|
|
|
cipso_cache_enable - BOOLEAN
|
|
|
|
If set, enable additions to and lookups from the CIPSO label mapping
|
|
|
|
cache. If unset, additions are ignored and lookups always result in a
|
|
|
|
miss. However, regardless of the setting the cache is still
|
|
|
|
invalidated when required when means you can safely toggle this on and
|
|
|
|
off and the cache will always be "safe".
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-08-04 07:45:49 +08:00
|
|
|
Default: 1
|
|
|
|
|
|
|
|
cipso_cache_bucket_size - INTEGER
|
|
|
|
The CIPSO label cache consists of a fixed size hash table with each
|
|
|
|
hash bucket containing a number of cache entries. This variable limits
|
2022-07-07 07:40:01 +08:00
|
|
|
the number of entries in each hash bucket; the larger the value is, the
|
2006-08-04 07:45:49 +08:00
|
|
|
more CIPSO label mappings that can be cached. When the number of
|
|
|
|
entries in a given hash bucket reaches this limit adding new entries
|
|
|
|
causes the oldest entry in the bucket to be removed to make room.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-08-04 07:45:49 +08:00
|
|
|
Default: 10
|
|
|
|
|
|
|
|
cipso_rbm_optfmt - BOOLEAN
|
|
|
|
Enable the "Optimized Tag 1 Format" as defined in section 3.4.2.6 of
|
|
|
|
the CIPSO draft specification (see Documentation/netlabel for details).
|
|
|
|
This means that when set the CIPSO tag will be padded with empty
|
|
|
|
categories in order to make the packet data 32-bit aligned.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-08-04 07:45:49 +08:00
|
|
|
Default: 0
|
|
|
|
|
|
|
|
cipso_rbm_structvalid - BOOLEAN
|
|
|
|
If set, do a very strict check of the CIPSO option when
|
|
|
|
ip_options_compile() is called. If unset, relax the checks done during
|
|
|
|
ip_options_compile(). Either way is "safe" as errors are caught else
|
|
|
|
where in the CIPSO processing code but setting this to 0 (False) should
|
|
|
|
result in less work (i.e. it should be faster) but could cause problems
|
|
|
|
with other implementations that require strict checking.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2006-08-04 07:45:49 +08:00
|
|
|
Default: 0
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
IP Variables
|
|
|
|
============
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
ip_local_port_range - 2 INTEGERS
|
|
|
|
Defines the local port range that is used by TCP and UDP to
|
2009-02-23 12:39:04 +08:00
|
|
|
choose the local port. The first number is the first, the
|
tcp/dccp: try to not exhaust ip_local_port_range in connect()
A long standing problem on busy servers is the tiny available TCP port
range (/proc/sys/net/ipv4/ip_local_port_range) and the default
sequential allocation of source ports in connect() system call.
If a host is having a lot of active TCP sessions, chances are
very high that all ports are in use by at least one flow,
and subsequent bind(0) attempts fail, or have to scan a big portion of
space to find a slot.
In this patch, I changed the starting point in __inet_hash_connect()
so that we try to favor even [1] ports, leaving odd ports for bind()
users.
We still perform a sequential search, so there is no guarantee, but
if connect() targets are very different, end result is we leave
more ports available to bind(), and we spread them all over the range,
lowering time for both connect() and bind() to find a slot.
This strategy only works well if /proc/sys/net/ipv4/ip_local_port_range
is even, ie if start/end values have different parity.
Therefore, default /proc/sys/net/ipv4/ip_local_port_range was changed to
32768 - 60999 (instead of 32768 - 61000)
There is no change on security aspects here, only some poor hashing
schemes could be eventually impacted by this change.
[1] : The odd/even property depends on ip_local_port_range values parity
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-25 05:49:35 +08:00
|
|
|
second the last local port number.
|
2019-11-26 06:48:00 +08:00
|
|
|
If possible, it is better these numbers have different parity
|
|
|
|
(one even and one odd value).
|
|
|
|
Must be greater than or equal to ip_unprivileged_port_start.
|
tcp/dccp: try to not exhaust ip_local_port_range in connect()
A long standing problem on busy servers is the tiny available TCP port
range (/proc/sys/net/ipv4/ip_local_port_range) and the default
sequential allocation of source ports in connect() system call.
If a host is having a lot of active TCP sessions, chances are
very high that all ports are in use by at least one flow,
and subsequent bind(0) attempts fail, or have to scan a big portion of
space to find a slot.
In this patch, I changed the starting point in __inet_hash_connect()
so that we try to favor even [1] ports, leaving odd ports for bind()
users.
We still perform a sequential search, so there is no guarantee, but
if connect() targets are very different, end result is we leave
more ports available to bind(), and we spread them all over the range,
lowering time for both connect() and bind() to find a slot.
This strategy only works well if /proc/sys/net/ipv4/ip_local_port_range
is even, ie if start/end values have different parity.
Therefore, default /proc/sys/net/ipv4/ip_local_port_range was changed to
32768 - 60999 (instead of 32768 - 61000)
There is no change on security aspects here, only some poor hashing
schemes could be eventually impacted by this change.
[1] : The odd/even property depends on ip_local_port_range values parity
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-25 05:49:35 +08:00
|
|
|
The default values are 32768 and 60999 respectively.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-05-05 08:27:06 +08:00
|
|
|
ip_local_reserved_ports - list of comma separated ranges
|
|
|
|
Specify the ports which are reserved for known third-party
|
|
|
|
applications. These ports will not be used by automatic port
|
|
|
|
assignments (e.g. when calling connect() or bind() with port
|
|
|
|
number 0). Explicit port allocation behavior is unchanged.
|
|
|
|
|
|
|
|
The format used for both input and output is a comma separated
|
|
|
|
list of ranges (e.g. "1,2-4,10-10" for ports 1, 2, 3, 4 and
|
|
|
|
10). Writing to the file will clear all previously reserved
|
|
|
|
ports and update the current list with the one given in the
|
|
|
|
input.
|
|
|
|
|
|
|
|
Note that ip_local_port_range and ip_local_reserved_ports
|
|
|
|
settings are independent and both are considered by the kernel
|
|
|
|
when determining which ports are available for automatic port
|
|
|
|
assignments.
|
|
|
|
|
|
|
|
You can reserve ports which are not in the current
|
2020-04-28 06:01:49 +08:00
|
|
|
ip_local_port_range, e.g.::
|
2010-05-05 08:27:06 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
$ cat /proc/sys/net/ipv4/ip_local_port_range
|
|
|
|
32000 60999
|
|
|
|
$ cat /proc/sys/net/ipv4/ip_local_reserved_ports
|
|
|
|
8080,9148
|
2010-05-05 08:27:06 +08:00
|
|
|
|
|
|
|
although this is redundant. However such a setting is useful
|
|
|
|
if later the port range is changed to a value that will
|
2021-04-01 23:57:05 +08:00
|
|
|
include the reserved ports. Also keep in mind, that overlapping
|
|
|
|
of these ranges may affect probability of selecting ephemeral
|
|
|
|
ports which are right after block of reserved ports.
|
2010-05-05 08:27:06 +08:00
|
|
|
|
|
|
|
Default: Empty
|
|
|
|
|
2017-01-21 09:49:11 +08:00
|
|
|
ip_unprivileged_port_start - INTEGER
|
|
|
|
This is a per-namespace sysctl. It defines the first
|
|
|
|
unprivileged port in the network namespace. Privileged ports
|
|
|
|
require root or CAP_NET_BIND_SERVICE in order to bind to them.
|
2019-11-26 06:48:00 +08:00
|
|
|
To disable all privileged ports, set this to 0. They must not
|
|
|
|
overlap with the ip_local_port_range.
|
2017-01-21 09:49:11 +08:00
|
|
|
|
|
|
|
Default: 1024
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
ip_nonlocal_bind - BOOLEAN
|
|
|
|
If set, allows processes to bind() to non-local IP addresses,
|
|
|
|
which can be quite useful - but may break some applications.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 0
|
|
|
|
|
tcp: bind(0) remove the SO_REUSEADDR restriction when ephemeral ports are exhausted.
Commit aacd9289af8b82f5fb01bcdd53d0e3406d1333c7 ("tcp: bind() use stronger
condition for bind_conflict") introduced a restriction to forbid to bind
SO_REUSEADDR enabled sockets to the same (addr, port) tuple in order to
assign ports dispersedly so that we can connect to the same remote host.
The change results in accelerating port depletion so that we fail to bind
sockets to the same local port even if we want to connect to the different
remote hosts.
You can reproduce this issue by following instructions below.
1. # sysctl -w net.ipv4.ip_local_port_range="32768 32768"
2. set SO_REUSEADDR to two sockets.
3. bind two sockets to (localhost, 0) and the latter fails.
Therefore, when ephemeral ports are exhausted, bind(0) should fallback to
the legacy behaviour to enable the SO_REUSEADDR option and make it possible
to connect to different remote (addr, port) tuples.
This patch allows us to bind SO_REUSEADDR enabled sockets to the same
(addr, port) only when net.ipv4.ip_autobind_reuse is set 1 and all
ephemeral ports are exhausted. This also allows connect() and listen() to
share ports in the following way and may break some applications. So the
ip_autobind_reuse is 0 by default and disables the feature.
1. setsockopt(sk1, SO_REUSEADDR)
2. setsockopt(sk2, SO_REUSEADDR)
3. bind(sk1, saddr, 0)
4. bind(sk2, saddr, 0)
5. connect(sk1, daddr)
6. listen(sk2)
If it is set 1, we can fully utilize the 4-tuples, but we should use
IP_BIND_ADDRESS_NO_PORT for bind()+connect() as possible.
The notable thing is that if all sockets bound to the same port have
both SO_REUSEADDR and SO_REUSEPORT enabled, we can bind sockets to an
ephemeral port and also do listen().
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-10 16:05:25 +08:00
|
|
|
ip_autobind_reuse - BOOLEAN
|
|
|
|
By default, bind() does not select the ports automatically even if
|
|
|
|
the new socket and all sockets bound to the port have SO_REUSEADDR.
|
|
|
|
ip_autobind_reuse allows bind() to reuse the port and this is useful
|
|
|
|
when you use bind()+connect(), but may break some applications.
|
|
|
|
The preferred solution is to use IP_BIND_ADDRESS_NO_PORT and this
|
|
|
|
option should only be set by experts.
|
|
|
|
Default: 0
|
|
|
|
|
2022-07-12 08:15:32 +08:00
|
|
|
ip_dynaddr - INTEGER
|
2005-04-17 06:20:36 +08:00
|
|
|
If set non-zero, enables support for dynamic addresses.
|
|
|
|
If set to a non-zero value larger than 1, a kernel log
|
|
|
|
message will be printed when dynamic address rewriting
|
|
|
|
occurs.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 0
|
|
|
|
|
2013-06-11 18:54:39 +08:00
|
|
|
ip_early_demux - BOOLEAN
|
|
|
|
Optimize input packet processing down to one demux for
|
|
|
|
certain kinds of local sockets. Currently we only do this
|
2017-03-24 03:34:16 +08:00
|
|
|
for established TCP and connected UDP sockets.
|
2013-06-11 18:54:39 +08:00
|
|
|
|
|
|
|
It may add an additional cost for pure routing workloads that
|
|
|
|
reduces overall throughput, in such case you should disable it.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-06-11 18:54:39 +08:00
|
|
|
Default: 1
|
|
|
|
|
2020-04-22 04:34:48 +08:00
|
|
|
ping_group_range - 2 INTEGERS
|
|
|
|
Restrict ICMP_PROTO datagram sockets to users in the group range.
|
|
|
|
The default is "1 0", meaning, that nobody (not even root) may
|
|
|
|
create ping sockets. Setting it to "100 100" would grant permissions
|
|
|
|
to the single group. "0 4294967295" would enable it for the world, "100
|
|
|
|
4294967295" would enable it for the users, but not daemons.
|
|
|
|
|
2017-03-24 03:34:16 +08:00
|
|
|
tcp_early_demux - BOOLEAN
|
|
|
|
Enable early demux for established TCP sockets.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-03-24 03:34:16 +08:00
|
|
|
Default: 1
|
|
|
|
|
|
|
|
udp_early_demux - BOOLEAN
|
|
|
|
Enable early demux for connected UDP sockets. Disable this if
|
|
|
|
your system could experience more unconnected load.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-03-24 03:34:16 +08:00
|
|
|
Default: 1
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
icmp_echo_ignore_all - BOOLEAN
|
2005-10-04 07:07:30 +08:00
|
|
|
If set non-zero, then the kernel will ignore all ICMP ECHO
|
|
|
|
requests sent to it.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-10-04 07:07:30 +08:00
|
|
|
Default: 0
|
|
|
|
|
2021-03-30 09:45:29 +08:00
|
|
|
icmp_echo_enable_probe - BOOLEAN
|
|
|
|
If set to one, then the kernel will respond to RFC 8335 PROBE
|
|
|
|
requests sent to it.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
icmp_echo_ignore_broadcasts - BOOLEAN
|
2005-10-04 07:07:30 +08:00
|
|
|
If set non-zero, then the kernel will ignore all ICMP ECHO and
|
|
|
|
TIMESTAMP requests sent to it via broadcast/multicast.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-10-04 07:07:30 +08:00
|
|
|
Default: 1
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
icmp_ratelimit - INTEGER
|
|
|
|
Limit the maximal rates for sending ICMP packets whose type matches
|
|
|
|
icmp_ratemask (see below) to specific targets.
|
2008-07-02 10:29:07 +08:00
|
|
|
0 to disable any limiting,
|
|
|
|
otherwise the minimal space between responses in milliseconds.
|
2014-09-19 22:38:40 +08:00
|
|
|
Note that another sysctl, icmp_msgs_per_sec limits the number
|
|
|
|
of ICMP packets sent on all targets.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-07-02 10:29:07 +08:00
|
|
|
Default: 1000
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 22:38:40 +08:00
|
|
|
icmp_msgs_per_sec - INTEGER
|
|
|
|
Limit maximal number of ICMP packets sent per second from this host.
|
|
|
|
Only messages whose type matches icmp_ratemask (see below) are
|
2020-10-16 02:42:00 +08:00
|
|
|
controlled by this limit. For security reasons, the precise count
|
|
|
|
of messages per second is randomized.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-07-02 10:29:07 +08:00
|
|
|
Default: 1000
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-09-19 22:38:40 +08:00
|
|
|
icmp_msgs_burst - INTEGER
|
|
|
|
icmp_msgs_per_sec controls number of ICMP packets sent per second,
|
|
|
|
while icmp_msgs_burst controls the burst size of these packets.
|
2020-10-16 02:42:00 +08:00
|
|
|
For security reasons, the precise burst size is randomized.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-09-19 22:38:40 +08:00
|
|
|
Default: 50
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
icmp_ratemask - INTEGER
|
|
|
|
Mask made of ICMP types for which rates are being limited.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Significant bits: IHGFEDCBA9876543210
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default mask: 0000001100000011000 (6168)
|
|
|
|
|
|
|
|
Bit definitions (see include/linux/icmp.h):
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
= =========================
|
2005-04-17 06:20:36 +08:00
|
|
|
0 Echo Reply
|
2020-04-28 06:01:49 +08:00
|
|
|
3 Destination Unreachable [1]_
|
|
|
|
4 Source Quench [1]_
|
2005-04-17 06:20:36 +08:00
|
|
|
5 Redirect
|
|
|
|
8 Echo Request
|
2020-04-28 06:01:49 +08:00
|
|
|
B Time Exceeded [1]_
|
|
|
|
C Parameter Problem [1]_
|
2005-04-17 06:20:36 +08:00
|
|
|
D Timestamp Request
|
|
|
|
E Timestamp Reply
|
|
|
|
F Info Request
|
|
|
|
G Info Reply
|
|
|
|
H Address Mask Request
|
|
|
|
I Address Mask Reply
|
2020-04-28 06:01:49 +08:00
|
|
|
= =========================
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
.. [1] These are rate limited by default (see default mask above)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
icmp_ignore_bogus_error_responses - BOOLEAN
|
|
|
|
Some routers violate RFC1122 by sending bogus responses to broadcast
|
|
|
|
frames. Such violations are normally logged via a kernel warning.
|
|
|
|
If this is set to TRUE, the kernel will not give such warnings, which
|
|
|
|
will avoid log file clutter.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-06-08 04:16:19 +08:00
|
|
|
Default: 1
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-02-03 09:02:25 +08:00
|
|
|
icmp_errors_use_inbound_ifaddr - BOOLEAN
|
|
|
|
|
2015-10-14 20:25:53 +08:00
|
|
|
If zero, icmp error messages are sent with the primary address of
|
|
|
|
the exiting interface.
|
2009-02-23 12:39:04 +08:00
|
|
|
|
2006-02-03 09:02:25 +08:00
|
|
|
If non-zero, the message will be sent with the primary address of
|
|
|
|
the interface that received the packet that caused the icmp error.
|
2021-01-31 03:05:18 +08:00
|
|
|
This is the behaviour many network administrators will expect from
|
2006-02-03 09:02:25 +08:00
|
|
|
a router. And it can make debugging complicated network layouts
|
2009-02-23 12:39:04 +08:00
|
|
|
much easier.
|
2006-02-03 09:02:25 +08:00
|
|
|
|
|
|
|
Note that if no primary address exists for the interface selected,
|
|
|
|
then the primary address of the first non-loopback interface that
|
2006-10-04 04:54:15 +08:00
|
|
|
has one will be used regardless of this setting.
|
2006-02-03 09:02:25 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
igmp_max_memberships - INTEGER
|
|
|
|
Change the maximum number of multicast groups we can subscribe to.
|
|
|
|
Default: 20
|
|
|
|
|
2010-11-15 13:41:31 +08:00
|
|
|
Theoretical maximum value is bounded by having to send a membership
|
|
|
|
report in a single datagram (i.e. the report can't span multiple
|
|
|
|
datagrams, or risk confusing the switch and leaving groups you don't
|
|
|
|
intend to).
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-11-15 13:41:31 +08:00
|
|
|
The number of supported groups 'M' is bounded by the number of group
|
|
|
|
report entries you can fit into a single datagram of 65535 bytes.
|
|
|
|
|
|
|
|
M = 65536-sizeof (ip header)/(sizeof(Group record))
|
|
|
|
|
|
|
|
Group records are variable length, with a minimum of 12 bytes.
|
|
|
|
So net.ipv4.igmp_max_memberships should not be set higher than:
|
|
|
|
|
|
|
|
(65536-24) / 12 = 5459
|
|
|
|
|
|
|
|
The value 5459 assumes no IP header options, so in practice
|
|
|
|
this number may be lower.
|
|
|
|
|
2016-03-22 04:21:40 +08:00
|
|
|
igmp_max_msf - INTEGER
|
|
|
|
Maximum number of addresses allowed in the source filter list for a
|
|
|
|
multicast group.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-03-22 04:21:40 +08:00
|
|
|
Default: 10
|
|
|
|
|
2014-09-02 21:49:26 +08:00
|
|
|
igmp_qrv - INTEGER
|
2016-03-22 04:21:40 +08:00
|
|
|
Controls the IGMP query robustness variable (see RFC2236 8.1).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-03-22 04:21:40 +08:00
|
|
|
Default: 2 (as specified by RFC2236 8.1)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-03-22 04:21:40 +08:00
|
|
|
Minimum: 1 (as specified by RFC6636 4.5)
|
2014-09-02 21:49:26 +08:00
|
|
|
|
2016-11-07 14:51:23 +08:00
|
|
|
force_igmp_version - INTEGER
|
2020-04-28 06:01:49 +08:00
|
|
|
- 0 - (default) No enforcement of a IGMP version, IGMPv1/v2 fallback
|
|
|
|
allowed. Will back to IGMPv3 mode again if all IGMPv1/v2 Querier
|
|
|
|
Present timer expires.
|
|
|
|
- 1 - Enforce to use IGMP version 1. Will also reply IGMPv1 report if
|
|
|
|
receive IGMPv2/v3 query.
|
|
|
|
- 2 - Enforce to use IGMP version 2. Will fallback to IGMPv1 if receive
|
|
|
|
IGMPv1 query message. Will reply report if receive IGMPv3 query.
|
|
|
|
- 3 - Enforce to use IGMP version 3. The same react with default 0.
|
|
|
|
|
|
|
|
.. note::
|
2016-11-07 14:51:23 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
this is not the same with force_mld_version because IGMPv3 RFC3376
|
|
|
|
Security Considerations does not have clear description that we could
|
|
|
|
ignore other version messages completely as MLDv2 RFC3810. So make
|
|
|
|
this value as default 0 is recommended.
|
2016-11-07 14:51:23 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``conf/interface/*``
|
|
|
|
changes special settings per interface (where
|
|
|
|
interface" is the name of your network interface)
|
2016-03-22 04:21:39 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``conf/all/*``
|
|
|
|
is special, changes the settings for all interfaces
|
2016-03-22 04:21:39 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
log_martians - BOOLEAN
|
|
|
|
Log packets with impossible addresses to kernel log.
|
|
|
|
log_martians for the interface will be enabled if at least one of
|
|
|
|
conf/{all,interface}/log_martians is set to TRUE,
|
|
|
|
it will be disabled otherwise
|
|
|
|
|
|
|
|
accept_redirects - BOOLEAN
|
|
|
|
Accept ICMP redirect messages.
|
|
|
|
accept_redirects for the interface will be enabled if:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
- both conf/{all,interface}/accept_redirects are TRUE in the case
|
|
|
|
forwarding for the interface is enabled
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
or
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
- at least one of conf/{all,interface}/accept_redirects is TRUE in the
|
|
|
|
case forwarding for the interface is disabled
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
accept_redirects for the interface will be disabled otherwise
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
default:
|
|
|
|
|
|
|
|
- TRUE (host)
|
|
|
|
- FALSE (router)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
forwarding - BOOLEAN
|
2017-03-10 20:24:57 +08:00
|
|
|
Enable IP forwarding on this interface. This controls whether packets
|
|
|
|
received _on_ this interface can be forwarded.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
mc_forwarding - BOOLEAN
|
|
|
|
Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE
|
|
|
|
and a multicast routing daemon is required.
|
2009-02-23 12:39:04 +08:00
|
|
|
conf/all/mc_forwarding must also be set to TRUE to enable multicast
|
|
|
|
routing for the interface
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
medium_id - INTEGER
|
|
|
|
Integer value used to differentiate the devices by the medium they
|
|
|
|
are attached to. Two devices can have different id values when
|
|
|
|
the broadcast packets are received only on one of them.
|
|
|
|
The default value 0 means that the device is the only interface
|
|
|
|
to its medium, value of -1 means that medium is not known.
|
2009-02-23 12:39:04 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Currently, it is used to change the proxy_arp behavior:
|
|
|
|
the proxy_arp feature is enabled for packets forwarded between
|
|
|
|
two devices attached to different media.
|
|
|
|
|
|
|
|
proxy_arp - BOOLEAN
|
|
|
|
Do proxy arp.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
proxy_arp for the interface will be enabled if at least one of
|
|
|
|
conf/{all,interface}/proxy_arp is set to TRUE,
|
|
|
|
it will be disabled otherwise
|
|
|
|
|
2010-01-05 13:50:47 +08:00
|
|
|
proxy_arp_pvlan - BOOLEAN
|
|
|
|
Private VLAN proxy arp.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2010-01-05 13:50:47 +08:00
|
|
|
Basically allow proxy arp replies back to the same interface
|
|
|
|
(from which the ARP request/solicitation was received).
|
|
|
|
|
|
|
|
This is done to support (ethernet) switch features, like RFC
|
|
|
|
3069, where the individual ports are NOT allowed to
|
|
|
|
communicate with each other, but they are allowed to talk to
|
|
|
|
the upstream router. As described in RFC 3069, it is possible
|
|
|
|
to allow these hosts to communicate through the upstream
|
|
|
|
router by proxy_arp'ing. Don't need to be used together with
|
|
|
|
proxy_arp.
|
|
|
|
|
|
|
|
This technology is known by different names:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2010-01-05 13:50:47 +08:00
|
|
|
In RFC 3069 it is called VLAN Aggregation.
|
|
|
|
Cisco and Allied Telesyn call it Private VLAN.
|
|
|
|
Hewlett-Packard call it Source-Port filtering or port-isolation.
|
|
|
|
Ericsson call it MAC-Forced Forwarding (RFC Draft).
|
|
|
|
|
2023-01-31 01:14:28 +08:00
|
|
|
proxy_delay - INTEGER
|
|
|
|
Delay proxy response.
|
|
|
|
|
|
|
|
Delay response to a neighbor solicitation when proxy_arp
|
|
|
|
or proxy_ndp is enabled. A random value between [0, proxy_delay)
|
|
|
|
will be chosen, setting to zero means reply with no delay.
|
|
|
|
Value in jiffies. Defaults to 80.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
shared_media - BOOLEAN
|
|
|
|
Send(router) or accept(host) RFC1620 shared media redirects.
|
2016-05-27 00:28:05 +08:00
|
|
|
Overrides secure_redirects.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
shared_media for the interface will be enabled if at least one of
|
|
|
|
conf/{all,interface}/shared_media is set to TRUE,
|
|
|
|
it will be disabled otherwise
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
default TRUE
|
|
|
|
|
|
|
|
secure_redirects - BOOLEAN
|
2016-05-27 00:28:05 +08:00
|
|
|
Accept ICMP redirect messages only to gateways listed in the
|
|
|
|
interface's current gateway list. Even if disabled, RFC1122 redirect
|
|
|
|
rules still apply.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-05-27 00:28:05 +08:00
|
|
|
Overridden by shared_media.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
secure_redirects for the interface will be enabled if at least one of
|
|
|
|
conf/{all,interface}/secure_redirects is set to TRUE,
|
|
|
|
it will be disabled otherwise
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
default TRUE
|
|
|
|
|
|
|
|
send_redirects - BOOLEAN
|
|
|
|
Send redirects, if router.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
send_redirects for the interface will be enabled if at least one of
|
|
|
|
conf/{all,interface}/send_redirects is set to TRUE,
|
|
|
|
it will be disabled otherwise
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: TRUE
|
|
|
|
|
|
|
|
bootp_relay - BOOLEAN
|
|
|
|
Accept packets with source address 0.b.c.d destined
|
|
|
|
not to this host as local ones. It is supposed, that
|
|
|
|
BOOTP relay daemon will catch and forward such packets.
|
|
|
|
conf/all/bootp_relay must also be set to TRUE to enable BOOTP relay
|
|
|
|
for the interface
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
default FALSE
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Not Implemented Yet.
|
|
|
|
|
|
|
|
accept_source_route - BOOLEAN
|
|
|
|
Accept packets with SRR option.
|
|
|
|
conf/all/accept_source_route must also be set to TRUE to accept packets
|
|
|
|
with SRR option on the interface
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
default
|
|
|
|
|
|
|
|
- TRUE (router)
|
|
|
|
- FALSE (host)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-12-03 09:25:58 +08:00
|
|
|
accept_local - BOOLEAN
|
2014-09-11 00:20:23 +08:00
|
|
|
Accept packets with local source addresses. In combination with
|
|
|
|
suitable routing, this can be used to direct packets between two
|
|
|
|
local interfaces over the wire and have them accepted properly.
|
2009-12-03 09:25:58 +08:00
|
|
|
default FALSE
|
|
|
|
|
2012-06-12 08:44:01 +08:00
|
|
|
route_localnet - BOOLEAN
|
|
|
|
Do not consider loopback addresses as martian source or destination
|
|
|
|
while routing. This enables the use of 127/8 for local routing purposes.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-06-12 08:44:01 +08:00
|
|
|
default FALSE
|
|
|
|
|
2009-02-20 16:25:36 +08:00
|
|
|
rp_filter - INTEGER
|
2020-04-28 06:01:49 +08:00
|
|
|
- 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.
|
2009-02-20 16:25:36 +08:00
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
Current recommended practice in RFC3704 is to enable strict mode
|
2009-02-23 12:37:55 +08:00
|
|
|
to prevent IP spoofing from DDos attacks. If using asymmetric routing
|
2009-02-23 12:39:04 +08:00
|
|
|
or other complicated routing, then loose mode is recommended.
|
2009-02-20 16:25:36 +08:00
|
|
|
|
2009-12-03 07:39:04 +08:00
|
|
|
The max value from conf/{all,interface}/rp_filter is used
|
|
|
|
when doing source validation on the {interface}.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
Default value is 0. Note that some distributions enable it
|
|
|
|
in startup scripts.
|
|
|
|
|
2021-02-09 09:37:01 +08:00
|
|
|
src_valid_mark - BOOLEAN
|
|
|
|
- 0 - The fwmark of the packet is not included in reverse path
|
|
|
|
route lookup. This allows for asymmetric routing configurations
|
|
|
|
utilizing the fwmark in only one direction, e.g., transparent
|
|
|
|
proxying.
|
|
|
|
|
|
|
|
- 1 - The fwmark of the packet is included in reverse path route
|
|
|
|
lookup. This permits rp_filter to function when the fwmark is
|
|
|
|
used for routing traffic in both directions.
|
|
|
|
|
|
|
|
This setting also affects the utilization of fmwark when
|
|
|
|
performing source address selection for ICMP replies, or
|
|
|
|
determining addresses stored for the IPOPT_TS_TSANDADDR and
|
|
|
|
IPOPT_RR IP options.
|
|
|
|
|
|
|
|
The max value from conf/{all,interface}/src_valid_mark is used.
|
|
|
|
|
|
|
|
Default value is 0.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
arp_filter - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1 - Allows you to have multiple network interfaces on the same
|
|
|
|
subnet, and have the ARPs for each interface be answered
|
|
|
|
based on whether or not the kernel would route a packet from
|
|
|
|
the ARP'd IP out that interface (therefore you must use source
|
|
|
|
based routing for this to work). In other words it allows control
|
|
|
|
of which cards (usually 1) will respond to an arp request.
|
|
|
|
|
|
|
|
- 0 - (default) The kernel can respond to arp requests with addresses
|
|
|
|
from other interfaces. This may seem wrong but it usually makes
|
|
|
|
sense, because it increases the chance of successful communication.
|
|
|
|
IP addresses are owned by the complete host on Linux, not by
|
|
|
|
particular interfaces. Only for more complex setups like load-
|
|
|
|
balancing, does this behaviour cause problems.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
arp_filter for the interface will be enabled if at least one of
|
|
|
|
conf/{all,interface}/arp_filter is set to TRUE,
|
|
|
|
it will be disabled otherwise
|
|
|
|
|
|
|
|
arp_announce - INTEGER
|
|
|
|
Define different restriction levels for announcing the local
|
|
|
|
source IP address from IP packets in ARP requests sent on
|
|
|
|
interface:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - (default) Use any local address, configured on any interface
|
|
|
|
- 1 - Try to avoid local addresses that are not in the target's
|
|
|
|
subnet for this interface. This mode is useful when target
|
|
|
|
hosts reachable via this interface require the source IP
|
|
|
|
address in ARP requests to be part of their logical network
|
|
|
|
configured on the receiving interface. When we generate the
|
|
|
|
request we will check all our subnets that include the
|
|
|
|
target IP and will preserve the source address if it is from
|
|
|
|
such subnet. If there is no such subnet we select source
|
|
|
|
address according to the rules for level 2.
|
|
|
|
- 2 - Always use the best local address for this target.
|
|
|
|
In this mode we ignore the source address in the IP packet
|
|
|
|
and try to select local address that we prefer for talks with
|
|
|
|
the target host. Such local address is selected by looking
|
|
|
|
for primary IP addresses on all our subnets on the outgoing
|
|
|
|
interface that include the target IP address. If no suitable
|
|
|
|
local address is found we select the first local address
|
|
|
|
we have on the outgoing interface or on all other interfaces,
|
|
|
|
with the hope we will receive reply for our request and
|
|
|
|
even sometimes no matter the source IP address we announce.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
The max value from conf/{all,interface}/arp_announce is used.
|
|
|
|
|
|
|
|
Increasing the restriction level gives more chance for
|
|
|
|
receiving answer from the resolved target while decreasing
|
|
|
|
the level announces more valid sender's information.
|
|
|
|
|
|
|
|
arp_ignore - INTEGER
|
|
|
|
Define different modes for sending replies in response to
|
|
|
|
received ARP requests that resolve local target IP addresses:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - (default): reply for any local target IP address, configured
|
|
|
|
on any interface
|
|
|
|
- 1 - reply only if the target IP address is local address
|
|
|
|
configured on the incoming interface
|
|
|
|
- 2 - reply only if the target IP address is local address
|
|
|
|
configured on the incoming interface and both with the
|
|
|
|
sender's IP address are part from same subnet on this interface
|
|
|
|
- 3 - do not reply for local addresses configured with scope host,
|
|
|
|
only resolutions for global and link addresses are replied
|
|
|
|
- 4-7 - reserved
|
|
|
|
- 8 - do not reply for all local addresses
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
The max value from conf/{all,interface}/arp_ignore is used
|
|
|
|
when ARP request is received on the {interface}
|
|
|
|
|
2009-02-01 17:04:33 +08:00
|
|
|
arp_notify - BOOLEAN
|
|
|
|
Define mode for notification of address and device changes.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
== ==========================================================
|
|
|
|
0 (default): do nothing
|
|
|
|
1 Generate gratuitous arp requests when device is brought up
|
|
|
|
or hardware address changes.
|
|
|
|
== ==========================================================
|
2009-02-01 17:04:33 +08:00
|
|
|
|
2022-07-14 07:40:47 +08:00
|
|
|
arp_accept - INTEGER
|
|
|
|
Define behavior for accepting gratuitous ARP (garp) frames from devices
|
|
|
|
that are not already present in the ARP table:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - don't create new entries in the ARP table
|
|
|
|
- 1 - create new entries in the ARP table
|
2022-07-14 07:40:47 +08:00
|
|
|
- 2 - create new entries only if the source IP address is in the same
|
|
|
|
subnet as an address configured on the interface that received the
|
|
|
|
garp message.
|
2010-01-18 20:58:44 +08:00
|
|
|
|
|
|
|
Both replies and requests type gratuitous arp will trigger the
|
|
|
|
ARP table to be updated, if this setting is on.
|
|
|
|
|
|
|
|
If the ARP table already contains the IP address of the
|
|
|
|
gratuitous arp frame, the arp table will be updated regardless
|
|
|
|
if this setting is on or off.
|
|
|
|
|
net: arp: introduce arp_evict_nocarrier sysctl parameter
This change introduces a new sysctl parameter, arp_evict_nocarrier.
When set (default) the ARP cache will be cleared on a NOCARRIER event.
This new option has been defaulted to '1' which maintains existing
behavior.
Clearing the ARP cache on NOCARRIER is relatively new, introduced by:
commit 859bd2ef1fc1110a8031b967ee656c53a6260a76
Author: David Ahern <dsahern@gmail.com>
Date: Thu Oct 11 20:33:49 2018 -0700
net: Evict neighbor entries on carrier down
The reason for this changes is to prevent the ARP cache from being
cleared when a wireless device roams. Specifically for wireless roams
the ARP cache should not be cleared because the underlying network has not
changed. Clearing the ARP cache in this case can introduce significant
delays sending out packets after a roam.
A user reported such a situation here:
https://lore.kernel.org/linux-wireless/CACsRnHWa47zpx3D1oDq9JYnZWniS8yBwW1h0WAVZ6vrbwL_S0w@mail.gmail.com/
After some investigation it was found that the kernel was holding onto
packets until ARP finished which resulted in this 1 second delay. It
was also found that the first ARP who-has was never responded to,
which is actually what caues the delay. This change is more or less
working around this behavior, but again, there is no reason to clear
the cache on a roam anyways.
As for the unanswered who-has, we know the packet made it OTA since
it was seen while monitoring. Why it never received a response is
unknown. In any case, since this is a problem on the AP side of things
all that can be done is to work around it until it is solved.
Some background on testing/reproducing the packet delay:
Hardware:
- 2 access points configured for Fast BSS Transition (Though I don't
see why regular reassociation wouldn't have the same behavior)
- Wireless station running IWD as supplicant
- A device on network able to respond to pings (I used one of the APs)
Procedure:
- Connect to first AP
- Ping once to establish an ARP entry
- Start a tcpdump
- Roam to second AP
- Wait for operstate UP event, and note the timestamp
- Start pinging
Results:
Below is the tcpdump after UP. It was recorded the interface went UP at
10:42:01.432875.
10:42:01.461871 ARP, Request who-has 192.168.254.1 tell 192.168.254.71, length 28
10:42:02.497976 ARP, Request who-has 192.168.254.1 tell 192.168.254.71, length 28
10:42:02.507162 ARP, Reply 192.168.254.1 is-at ac:86:74:55:b0:20, length 46
10:42:02.507185 IP 192.168.254.71 > 192.168.254.1: ICMP echo request, id 52792, seq 1, length 64
10:42:02.507205 IP 192.168.254.71 > 192.168.254.1: ICMP echo request, id 52792, seq 2, length 64
10:42:02.507212 IP 192.168.254.71 > 192.168.254.1: ICMP echo request, id 52792, seq 3, length 64
10:42:02.507219 IP 192.168.254.71 > 192.168.254.1: ICMP echo request, id 52792, seq 4, length 64
10:42:02.507225 IP 192.168.254.71 > 192.168.254.1: ICMP echo request, id 52792, seq 5, length 64
10:42:02.507232 IP 192.168.254.71 > 192.168.254.1: ICMP echo request, id 52792, seq 6, length 64
10:42:02.515373 IP 192.168.254.1 > 192.168.254.71: ICMP echo reply, id 52792, seq 1, length 64
10:42:02.521399 IP 192.168.254.1 > 192.168.254.71: ICMP echo reply, id 52792, seq 2, length 64
10:42:02.521612 IP 192.168.254.1 > 192.168.254.71: ICMP echo reply, id 52792, seq 3, length 64
10:42:02.521941 IP 192.168.254.1 > 192.168.254.71: ICMP echo reply, id 52792, seq 4, length 64
10:42:02.522419 IP 192.168.254.1 > 192.168.254.71: ICMP echo reply, id 52792, seq 5, length 64
10:42:02.523085 IP 192.168.254.1 > 192.168.254.71: ICMP echo reply, id 52792, seq 6, length 64
You can see the first ARP who-has went out very quickly after UP, but
was never responded to. Nearly a second later the kernel retries and
gets a response. Only then do the ping packets go out. If an ARP entry
is manually added prior to UP (after the cache is cleared) it is seen
that the first ping is never responded to, so its not only an issue with
ARP but with data packets in general.
As mentioned prior, the wireless interface was also monitored to verify
the ping/ARP packet made it OTA which was observed to be true.
Signed-off-by: James Prestwood <prestwoj@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-02 01:36:28 +08:00
|
|
|
arp_evict_nocarrier - BOOLEAN
|
|
|
|
Clears the ARP cache on NOCARRIER events. This option is important for
|
|
|
|
wireless devices where the ARP cache should not be cleared when roaming
|
|
|
|
between access points on the same network. In most cases this should
|
|
|
|
remain as the default (1).
|
|
|
|
|
|
|
|
- 1 - (default): Clear the ARP cache on NOCARRIER events
|
|
|
|
- 0 - Do not clear ARP cache on NOCARRIER events
|
|
|
|
|
2015-03-19 21:42:04 +08:00
|
|
|
mcast_solicit - INTEGER
|
|
|
|
The maximum number of multicast probes in INCOMPLETE state,
|
|
|
|
when the associated hardware address is unknown. Defaults
|
|
|
|
to 3.
|
|
|
|
|
|
|
|
ucast_solicit - INTEGER
|
|
|
|
The maximum number of unicast probes in PROBE state, when
|
|
|
|
the hardware address is being reconfirmed. Defaults to 3.
|
2006-03-21 14:40:03 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
app_solicit - INTEGER
|
|
|
|
The maximum number of probes to send to the user space ARP daemon
|
|
|
|
via netlink before dropping back to multicast probes (see
|
2015-03-19 21:42:04 +08:00
|
|
|
mcast_resolicit). Defaults to 0.
|
|
|
|
|
|
|
|
mcast_resolicit - INTEGER
|
|
|
|
The maximum number of multicast probes after unicast and
|
|
|
|
app probes in PROBE state. Defaults to 0.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
disable_policy - BOOLEAN
|
|
|
|
Disable IPSEC policy (SPD) for this interface
|
|
|
|
|
|
|
|
disable_xfrm - BOOLEAN
|
|
|
|
Disable IPSEC encryption on this interface, whatever the policy
|
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
igmpv2_unsolicited_report_interval - INTEGER
|
|
|
|
The interval in milliseconds in which the next unsolicited
|
|
|
|
IGMPv1 or IGMPv2 report retransmit will take place.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
Default: 10000 (10 seconds)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
igmpv3_unsolicited_report_interval - INTEGER
|
|
|
|
The interval in milliseconds in which the next unsolicited
|
|
|
|
IGMPv3 report retransmit will take place.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
Default: 1000 (1 seconds)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-11-08 03:35:13 +08:00
|
|
|
ignore_routes_with_linkdown - BOOLEAN
|
|
|
|
Ignore routes whose link is down when performing a FIB lookup.
|
|
|
|
|
2014-01-28 12:26:42 +08:00
|
|
|
promote_secondaries - BOOLEAN
|
|
|
|
When a primary IP address is removed from this interface
|
|
|
|
promote a corresponding secondary IP address instead of
|
|
|
|
removing all the corresponding secondary IP addresses.
|
|
|
|
|
2016-02-04 20:31:17 +08:00
|
|
|
drop_unicast_in_l2_multicast - BOOLEAN
|
|
|
|
Drop any unicast IP packets that are received in link-layer
|
|
|
|
multicast (or broadcast) frames.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-02-04 20:31:17 +08:00
|
|
|
This behavior (for multicast) is actually a SHOULD in RFC
|
|
|
|
1122, but is disabled by default for compatibility reasons.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-02-04 20:31:17 +08:00
|
|
|
Default: off (0)
|
|
|
|
|
2016-02-04 20:31:18 +08:00
|
|
|
drop_gratuitous_arp - BOOLEAN
|
|
|
|
Drop all gratuitous ARP frames, for example if there's a known
|
|
|
|
good ARP proxy on the network and such frames need not be used
|
|
|
|
(or in the case of 802.11, must not be used to prevent attacks.)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-02-04 20:31:18 +08:00
|
|
|
Default: off (0)
|
|
|
|
|
2014-01-28 12:26:42 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
tag - INTEGER
|
|
|
|
Allows you to write a number, which can be used as required.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default value is 0.
|
|
|
|
|
2015-08-12 04:35:01 +08:00
|
|
|
xfrm4_gc_thresh - INTEGER
|
2019-04-09 23:16:59 +08:00
|
|
|
(Obsolete since linux-4.14)
|
2015-08-12 04:35:01 +08:00
|
|
|
The threshold at which we will start garbage collecting for IPv4
|
|
|
|
destination cache entries. At twice this value the system will
|
2017-07-17 19:57:20 +08:00
|
|
|
refuse new allocations.
|
2015-08-12 04:35:01 +08:00
|
|
|
|
2015-08-31 18:30:38 +08:00
|
|
|
igmp_link_local_mcast_reports - BOOLEAN
|
|
|
|
Enable IGMP reports for link local multicast groups in the
|
|
|
|
224.0.0.X range.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-08-31 18:30:38 +08:00
|
|
|
Default TRUE
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Alexey Kuznetsov.
|
|
|
|
kuznet@ms2.inr.ac.ru
|
|
|
|
|
|
|
|
Updated by:
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- Andi Kleen
|
|
|
|
ak@muc.de
|
|
|
|
- Nicolas Delon
|
|
|
|
delon.nicolas@wanadoo.fr
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
/proc/sys/net/ipv6/* Variables
|
|
|
|
==============================
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ also
|
|
|
|
apply to IPv6 [XXX?].
|
|
|
|
|
|
|
|
bindv6only - BOOLEAN
|
|
|
|
Default value for IPV6_V6ONLY socket option,
|
2009-02-23 12:39:04 +08:00
|
|
|
which restricts use of the IPv6 socket to IPv6 communication
|
2005-04-17 06:20:36 +08:00
|
|
|
only.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- TRUE: disable IPv4-mapped address feature
|
|
|
|
- FALSE: enable IPv4-mapped address feature
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-08-23 02:28:57 +08:00
|
|
|
Default: FALSE (as specified in RFC3493)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-01-18 00:15:05 +08:00
|
|
|
flowlabel_consistency - BOOLEAN
|
|
|
|
Protect the consistency (and unicity) of flow label.
|
|
|
|
You have to disable it to use IPV6_FL_F_REFLECT flag on the
|
|
|
|
flow label manager.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- TRUE: enabled
|
|
|
|
- FALSE: disabled
|
|
|
|
|
2014-01-18 00:15:05 +08:00
|
|
|
Default: TRUE
|
|
|
|
|
2015-08-01 07:52:12 +08:00
|
|
|
auto_flowlabels - INTEGER
|
|
|
|
Automatically generate flow labels based on a flow hash of the
|
|
|
|
packet. This allows intermediate devices, such as routers, to
|
|
|
|
identify packet flows for mechanisms like Equal Cost Multipath
|
2014-07-02 12:33:10 +08:00
|
|
|
Routing (see RFC 6438).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
= ===========================================================
|
|
|
|
0 automatic flow labels are completely disabled
|
|
|
|
1 automatic flow labels are enabled by default, they can be
|
2015-08-01 07:52:12 +08:00
|
|
|
disabled on a per socket basis using the IPV6_AUTOFLOWLABEL
|
|
|
|
socket option
|
2020-04-28 06:01:49 +08:00
|
|
|
2 automatic flow labels are allowed, they may be enabled on a
|
2015-08-01 07:52:12 +08:00
|
|
|
per socket basis using the IPV6_AUTOFLOWLABEL socket option
|
2020-04-28 06:01:49 +08:00
|
|
|
3 automatic flow labels are enabled and enforced, they cannot
|
2015-08-01 07:52:12 +08:00
|
|
|
be disabled by the socket option
|
2020-04-28 06:01:49 +08:00
|
|
|
= ===========================================================
|
|
|
|
|
2015-08-01 07:52:14 +08:00
|
|
|
Default: 1
|
2014-07-02 12:33:10 +08:00
|
|
|
|
ipv6: Flow label state ranges
This patch divides the IPv6 flow label space into two ranges:
0-7ffff is reserved for flow label manager, 80000-fffff will be
used for creating auto flow labels (per RFC6438). This only affects how
labels are set on transmit, it does not affect receive. This range split
can be disbaled by systcl.
Background:
IPv6 flow labels have been an unmitigated disappointment thus far
in the lifetime of IPv6. Support in HW devices to use them for ECMP
is lacking, and OSes don't turn them on by default. If we had these
we could get much better hashing in IPv6 networks without resorting
to DPI, possibly eliminating some of the motivations to to define new
encaps in UDP just for getting ECMP.
Unfortunately, the initial specfications of IPv6 did not clarify
how they are to be used. There has always been a vague concept that
these can be used for ECMP, flow hashing, etc. and we do now have a
good standard how to this in RFC6438. The problem is that flow labels
can be either stateful or stateless (as in RFC6438), and we are
presented with the possibility that a stateless label may collide
with a stateful one. Attempts to split the flow label space were
rejected in IETF. When we added support in Linux for RFC6438, we
could not turn on flow labels by default due to this conflict.
This patch splits the flow label space and should give us
a path to enabling auto flow labels by default for all IPv6 packets.
This is an API change so we need to consider compatibility with
existing deployment. The stateful range is chosen to be the lower
values in hopes that most uses would have chosen small numbers.
Once we resolve the stateless/stateful issue, we can proceed to
look at enabling RFC6438 flow labels by default (starting with
scaled testing).
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-04-30 06:33:21 +08:00
|
|
|
flowlabel_state_ranges - BOOLEAN
|
|
|
|
Split the flow label number space into two ranges. 0-0x7FFFF is
|
|
|
|
reserved for the IPv6 flow manager facility, 0x80000-0xFFFFF
|
|
|
|
is reserved for stateless flow labels as described in RFC6437.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- TRUE: enabled
|
|
|
|
- FALSE: disabled
|
|
|
|
|
ipv6: Flow label state ranges
This patch divides the IPv6 flow label space into two ranges:
0-7ffff is reserved for flow label manager, 80000-fffff will be
used for creating auto flow labels (per RFC6438). This only affects how
labels are set on transmit, it does not affect receive. This range split
can be disbaled by systcl.
Background:
IPv6 flow labels have been an unmitigated disappointment thus far
in the lifetime of IPv6. Support in HW devices to use them for ECMP
is lacking, and OSes don't turn them on by default. If we had these
we could get much better hashing in IPv6 networks without resorting
to DPI, possibly eliminating some of the motivations to to define new
encaps in UDP just for getting ECMP.
Unfortunately, the initial specfications of IPv6 did not clarify
how they are to be used. There has always been a vague concept that
these can be used for ECMP, flow hashing, etc. and we do now have a
good standard how to this in RFC6438. The problem is that flow labels
can be either stateful or stateless (as in RFC6438), and we are
presented with the possibility that a stateless label may collide
with a stateful one. Attempts to split the flow label space were
rejected in IETF. When we added support in Linux for RFC6438, we
could not turn on flow labels by default due to this conflict.
This patch splits the flow label space and should give us
a path to enabling auto flow labels by default for all IPv6 packets.
This is an API change so we need to consider compatibility with
existing deployment. The stateful range is chosen to be the lower
values in hopes that most uses would have chosen small numbers.
Once we resolve the stateless/stateful issue, we can proceed to
look at enabling RFC6438 flow labels by default (starting with
scaled testing).
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-04-30 06:33:21 +08:00
|
|
|
Default: true
|
|
|
|
|
2019-06-05 22:55:09 +08:00
|
|
|
flowlabel_reflect - INTEGER
|
|
|
|
Control flow label reflection. Needed for Path MTU
|
2017-08-23 15:55:41 +08:00
|
|
|
Discovery to work with Equal Cost Multipath Routing in anycast
|
|
|
|
environments. See RFC 7690 and:
|
|
|
|
https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01
|
2019-06-05 22:55:09 +08:00
|
|
|
|
2019-07-01 21:39:36 +08:00
|
|
|
This is a bitmask.
|
2019-06-05 22:55:09 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: enabled for established flows
|
|
|
|
|
|
|
|
Note that this prevents automatic flowlabel changes, as done
|
|
|
|
in "tcp: change IPv6 flow-label upon receiving spurious retransmission"
|
|
|
|
and "tcp: Change txhash on every SYN and RTO retransmit"
|
2019-06-05 22:55:09 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 2: enabled for TCP RESET packets (no active listener)
|
|
|
|
If set, a RST packet sent in response to a SYN packet on a closed
|
|
|
|
port will reflect the incoming flow label.
|
2019-06-05 22:55:09 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 4: enabled for ICMPv6 echo reply messages.
|
2019-07-01 21:39:36 +08:00
|
|
|
|
2019-06-05 22:55:09 +08:00
|
|
|
Default: 0
|
2017-08-23 15:55:41 +08:00
|
|
|
|
2018-03-03 00:32:18 +08:00
|
|
|
fib_multipath_hash_policy - INTEGER
|
|
|
|
Controls which hash policy to use for multipath routes.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-03-03 00:32:18 +08:00
|
|
|
Default: 0 (Layer 3)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-03-03 00:32:18 +08:00
|
|
|
Possible values:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- 0 - Layer 3 (source and destination addresses plus flow label)
|
|
|
|
- 1 - Layer 4 (standard 5-tuple)
|
|
|
|
- 2 - Layer 3 or inner Layer 3 if present
|
2021-05-18 02:15:23 +08:00
|
|
|
- 3 - Custom multipath hash. Fields used for multipath hash calculation
|
|
|
|
are determined by fib_multipath_hash_fields sysctl
|
2018-03-03 00:32:18 +08:00
|
|
|
|
2021-05-18 02:15:22 +08:00
|
|
|
fib_multipath_hash_fields - UNSIGNED INTEGER
|
|
|
|
When fib_multipath_hash_policy is set to 3 (custom multipath hash), the
|
|
|
|
fields used for multipath hash calculation are determined by this
|
|
|
|
sysctl.
|
|
|
|
|
|
|
|
This value is a bitmask which enables various fields for multipath hash
|
|
|
|
calculation.
|
|
|
|
|
|
|
|
Possible fields are:
|
|
|
|
|
|
|
|
====== ============================
|
|
|
|
0x0001 Source IP address
|
|
|
|
0x0002 Destination IP address
|
|
|
|
0x0004 IP protocol
|
|
|
|
0x0008 Flow Label
|
|
|
|
0x0010 Source port
|
|
|
|
0x0020 Destination port
|
|
|
|
0x0040 Inner source IP address
|
|
|
|
0x0080 Inner destination IP address
|
|
|
|
0x0100 Inner IP protocol
|
|
|
|
0x0200 Inner Flow Label
|
|
|
|
0x0400 Inner source port
|
|
|
|
0x0800 Inner destination port
|
|
|
|
====== ============================
|
|
|
|
|
|
|
|
Default: 0x0007 (source IP, destination IP and IP protocol)
|
|
|
|
|
2014-01-07 21:57:27 +08:00
|
|
|
anycast_src_echo_reply - BOOLEAN
|
|
|
|
Controls the use of anycast addresses as source addresses for ICMPv6
|
|
|
|
echo reply
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- TRUE: enabled
|
|
|
|
- FALSE: disabled
|
|
|
|
|
2014-01-07 21:57:27 +08:00
|
|
|
Default: FALSE
|
|
|
|
|
2015-03-24 06:36:06 +08:00
|
|
|
idgen_delay - INTEGER
|
|
|
|
Controls the delay in seconds after which time to retry
|
|
|
|
privacy stable address generation if a DAD conflict is
|
|
|
|
detected.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-03-24 06:36:06 +08:00
|
|
|
Default: 1 (as specified in RFC7217)
|
|
|
|
|
|
|
|
idgen_retries - INTEGER
|
|
|
|
Controls the number of retries to generate a stable privacy
|
|
|
|
address if a DAD conflict is detected.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-03-24 06:36:06 +08:00
|
|
|
Default: 3 (as specified in RFC7217)
|
|
|
|
|
2014-09-02 21:49:25 +08:00
|
|
|
mld_qrv - INTEGER
|
|
|
|
Controls the MLD query robustness variable (see RFC3810 9.1).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-09-02 21:49:25 +08:00
|
|
|
Default: 2 (as specified by RFC3810 9.1)
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-09-02 21:49:25 +08:00
|
|
|
Minimum: 1 (as specified by RFC6636 4.5)
|
|
|
|
|
2018-04-19 04:03:06 +08:00
|
|
|
max_dst_opts_number - INTEGER
|
2017-10-31 05:16:00 +08:00
|
|
|
Maximum number of non-padding TLVs allowed in a Destination
|
|
|
|
options extension header. If this value is less than zero
|
|
|
|
then unknown options are disallowed and the number of known
|
|
|
|
TLVs allowed is the absolute value of this number.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-10-31 05:16:00 +08:00
|
|
|
Default: 8
|
|
|
|
|
2018-04-19 04:03:06 +08:00
|
|
|
max_hbh_opts_number - INTEGER
|
2017-10-31 05:16:00 +08:00
|
|
|
Maximum number of non-padding TLVs allowed in a Hop-by-Hop
|
|
|
|
options extension header. If this value is less than zero
|
|
|
|
then unknown options are disallowed and the number of known
|
|
|
|
TLVs allowed is the absolute value of this number.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-10-31 05:16:00 +08:00
|
|
|
Default: 8
|
|
|
|
|
2018-04-19 04:03:06 +08:00
|
|
|
max_dst_opts_length - INTEGER
|
2017-10-31 05:16:00 +08:00
|
|
|
Maximum length allowed for a Destination options extension
|
|
|
|
header.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-10-31 05:16:00 +08:00
|
|
|
Default: INT_MAX (unlimited)
|
|
|
|
|
2018-04-19 04:03:06 +08:00
|
|
|
max_hbh_length - INTEGER
|
2017-10-31 05:16:00 +08:00
|
|
|
Maximum length allowed for a Hop-by-Hop options extension
|
|
|
|
header.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2017-10-31 05:16:00 +08:00
|
|
|
Default: INT_MAX (unlimited)
|
|
|
|
|
2018-10-12 11:17:21 +08:00
|
|
|
skip_notify_on_dev_down - BOOLEAN
|
|
|
|
Controls whether an RTM_DELROUTE message is generated for routes
|
|
|
|
removed when a device is taken down or deleted. IPv4 does not
|
|
|
|
generate this message; IPv6 does by default. Setting this sysctl
|
|
|
|
to true skips the message, making IPv4 and IPv6 on par in relying
|
|
|
|
on userspace caches to track link events and evict routes.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-10-12 11:17:21 +08:00
|
|
|
Default: false (generate message)
|
|
|
|
|
2020-04-28 04:56:46 +08:00
|
|
|
nexthop_compat_mode - BOOLEAN
|
|
|
|
New nexthop API provides a means for managing nexthops independent of
|
2023-01-30 07:10:48 +08:00
|
|
|
prefixes. Backwards compatibility with old route format is enabled by
|
2020-04-28 04:56:46 +08:00
|
|
|
default which means route dumps and notifications contain the new
|
|
|
|
nexthop attribute but also the full, expanded nexthop definition.
|
|
|
|
Further, updates or deletes of a nexthop configuration generate route
|
|
|
|
notifications for each fib entry using the nexthop. Once a system
|
|
|
|
understands the new API, this sysctl can be disabled to achieve full
|
|
|
|
performance benefits of the new API by disabling the nexthop expansion
|
|
|
|
and extraneous notifications.
|
|
|
|
Default: true (backward compat mode)
|
|
|
|
|
2021-02-02 03:47:55 +08:00
|
|
|
fib_notify_on_flag_change - INTEGER
|
|
|
|
Whether to emit RTM_NEWROUTE notifications whenever RTM_F_OFFLOAD/
|
2021-02-07 16:22:53 +08:00
|
|
|
RTM_F_TRAP/RTM_F_OFFLOAD_FAILED flags are changed.
|
2021-02-02 03:47:55 +08:00
|
|
|
|
|
|
|
After installing a route to the kernel, user space receives an
|
|
|
|
acknowledgment, which means the route was installed in the kernel,
|
|
|
|
but not necessarily in hardware.
|
|
|
|
It is also possible for a route already installed in hardware to change
|
|
|
|
its action and therefore its flags. For example, a host route that is
|
|
|
|
trapping packets can be "promoted" to perform decapsulation following
|
|
|
|
the installation of an IPinIP/VXLAN tunnel.
|
|
|
|
The notifications will indicate to user-space the state of the route.
|
|
|
|
|
|
|
|
Default: 0 (Do not emit notifications.)
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
- 0 - Do not emit notifications.
|
|
|
|
- 1 - Emit notifications.
|
2021-02-07 16:22:53 +08:00
|
|
|
- 2 - Emit notifications only for RTM_F_OFFLOAD_FAILED flag change.
|
2021-02-02 03:47:55 +08:00
|
|
|
|
2021-07-21 03:43:00 +08:00
|
|
|
ioam6_id - INTEGER
|
|
|
|
Define the IOAM id of this node. Uses only 24 bits out of 32 in total.
|
|
|
|
|
|
|
|
Min: 0
|
|
|
|
Max: 0xFFFFFF
|
|
|
|
|
|
|
|
Default: 0xFFFFFF
|
|
|
|
|
|
|
|
ioam6_id_wide - LONG INTEGER
|
|
|
|
Define the wide IOAM id of this node. Uses only 56 bits out of 64 in
|
|
|
|
total. Can be different from ioam6_id.
|
|
|
|
|
|
|
|
Min: 0
|
|
|
|
Max: 0xFFFFFFFFFFFFFF
|
|
|
|
|
|
|
|
Default: 0xFFFFFFFFFFFFFF
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
IPv6 Fragmentation:
|
|
|
|
|
|
|
|
ip6frag_high_thresh - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
Maximum memory used to reassemble IPv6 fragments. When
|
2005-04-17 06:20:36 +08:00
|
|
|
ip6frag_high_thresh bytes of memory is allocated for this purpose,
|
|
|
|
the fragment handler will toss packets until ip6frag_low_thresh
|
|
|
|
is reached.
|
2009-02-23 12:39:04 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
ip6frag_low_thresh - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
See ip6frag_high_thresh
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
ip6frag_time - INTEGER
|
|
|
|
Time in seconds to keep an IPv6 fragment in memory.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``conf/default/*``:
|
2005-04-17 06:20:36 +08:00
|
|
|
Change the interface-specific default settings.
|
|
|
|
|
2021-01-21 23:02:44 +08:00
|
|
|
These settings would be used during creating new interfaces.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``conf/all/*``:
|
2009-02-23 12:39:04 +08:00
|
|
|
Change all the interface-specific settings.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
[XXX: Other special features than forwarding?]
|
|
|
|
|
2021-01-21 23:02:44 +08:00
|
|
|
conf/all/disable_ipv6 - BOOLEAN
|
|
|
|
Changing this value is same as changing ``conf/default/disable_ipv6``
|
|
|
|
setting and also all per-interface ``disable_ipv6`` settings to the same
|
|
|
|
value.
|
|
|
|
|
|
|
|
Reading this value does not have any particular meaning. It does not say
|
|
|
|
whether IPv6 support is enabled or disabled. Returned value can be 1
|
|
|
|
also in the case when some interface has ``disable_ipv6`` set to 0 and
|
|
|
|
has configured IPv6 addresses.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
conf/all/forwarding - BOOLEAN
|
2009-02-23 12:39:04 +08:00
|
|
|
Enable global IPv6 forwarding between all interfaces.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
IPv4 and IPv6 work differently here; e.g. netfilter must be used
|
2005-04-17 06:20:36 +08:00
|
|
|
to control which interfaces may forward packets and which not.
|
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
This also sets all interfaces' Host/Router setting
|
2005-04-17 06:20:36 +08:00
|
|
|
'forwarding' to the specified value. See below for details.
|
|
|
|
|
|
|
|
This referred to as global forwarding.
|
|
|
|
|
2006-09-23 05:43:49 +08:00
|
|
|
proxy_ndp - BOOLEAN
|
|
|
|
Do proxy ndp.
|
|
|
|
|
2014-11-04 19:02:49 +08:00
|
|
|
fwmark_reflect - BOOLEAN
|
|
|
|
Controls the fwmark of kernel-generated IPv6 reply packets that are not
|
|
|
|
associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
|
|
|
|
If unset, these packets have a fwmark of zero. If set, they have the
|
|
|
|
fwmark of the packet they are replying to.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2014-11-04 19:02:49 +08:00
|
|
|
Default: 0
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``conf/interface/*``:
|
2005-04-17 06:20:36 +08:00
|
|
|
Change special settings per interface.
|
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
The functional behaviour for certain settings is different
|
2005-04-17 06:20:36 +08:00
|
|
|
depending on whether local forwarding is enabled or not.
|
|
|
|
|
2011-09-29 03:51:54 +08:00
|
|
|
accept_ra - INTEGER
|
2005-04-17 06:20:36 +08:00
|
|
|
Accept Router Advertisements; autoconfigure using them.
|
2009-02-23 12:39:04 +08:00
|
|
|
|
ipv6: Send ICMPv6 RSes only when RAs are accepted
This patch improves the logic determining when to send ICMPv6 Router
Solicitations, so that they are 1) always sent when the kernel is
accepting Router Advertisements, and 2) never sent when the kernel is
not accepting RAs. In other words, the operational setting of the
"accept_ra" sysctl is used.
The change also makes the special "Hybrid Router" forwarding mode
("forwarding" sysctl set to 2) operate exactly the same as the standard
Router mode (forwarding=1). The only difference between the two was
that RSes was being sent in the Hybrid Router mode only. The sysctl
documentation describing the special Hybrid Router mode has therefore
been removed.
Rationale for the change:
Currently, the value of forwarding sysctl is the only thing determining
whether or not to send RSes. If it has the value 0 or 2, they are sent,
otherwise they are not. This leads to inconsistent behaviour in the
following cases:
* accept_ra=0, forwarding=0
* accept_ra=0, forwarding=2
* accept_ra=1, forwarding=2
* accept_ra=2, forwarding=1
In the first three cases, the kernel will send RSes, even though it will
not accept any RAs received in reply. In the last case, it will not send
any RSes, even though it will accept and process any RAs received. (Most
routers will send unsolicited RAs periodically, so suppressing RSes in
the last case will merely delay auto-configuration, not prevent it.)
Also, it is my opinion that having the forwarding sysctl control RS
sending behaviour (completely independent of whether RAs are being
accepted or not) is simply not what most users would intuitively expect
to be the case.
Signed-off-by: Tore Anderson <tore@fud.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-29 07:47:33 +08:00
|
|
|
It also determines whether or not to transmit Router
|
|
|
|
Solicitations. If and only if the functional setting is to
|
|
|
|
accept Router Advertisements, Router Solicitations will be
|
|
|
|
transmitted.
|
|
|
|
|
2010-09-03 13:47:30 +08:00
|
|
|
Possible values are:
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
== ===========================================================
|
|
|
|
0 Do not accept Router Advertisements.
|
|
|
|
1 Accept Router Advertisements if forwarding is disabled.
|
|
|
|
2 Overrule forwarding behaviour. Accept Router Advertisements
|
|
|
|
even if forwarding is enabled.
|
|
|
|
== ===========================================================
|
|
|
|
|
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if local forwarding is disabled.
|
|
|
|
- disabled if local forwarding is enabled.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-03-21 08:55:08 +08:00
|
|
|
accept_ra_defrtr - BOOLEAN
|
|
|
|
Learn default router in Router Advertisement.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if accept_ra is enabled.
|
|
|
|
- disabled if accept_ra is disabled.
|
2006-03-21 08:55:08 +08:00
|
|
|
|
net: allow user to set metric on default route learned via Router Advertisement
For IPv4, default route is learned via DHCPv4 and user is allowed to change
metric using config etc/network/interfaces. But for IPv6, default route can
be learned via RA, for which, currently a fixed metric value 1024 is used.
Ideally, user should be able to configure metric on default route for IPv6
similar to IPv4. This patch adds sysctl for the same.
Logs:
For IPv4:
Config in etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
metric 4261413864
IPv4 Kernel Route Table:
$ ip route list
default via 172.21.47.1 dev eth0 metric 4261413864
FRR Table, if a static route is configured:
[In real scenario, it is useful to prefer BGP learned default route over DHCPv4 default route.]
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
> - selected route, * - FIB route
S>* 0.0.0.0/0 [20/0] is directly connected, eth0, 00:00:03
K 0.0.0.0/0 [254/1000] via 172.21.47.1, eth0, 6d08h51m
i.e. User can prefer Default Router learned via Routing Protocol in IPv4.
Similar behavior is not possible for IPv6, without this fix.
After fix [for IPv6]:
sudo sysctl -w net.ipv6.conf.eth0.net.ipv6.conf.eth0.ra_defrtr_metric=1996489705
IP monitor: [When IPv6 RA is received]
default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489705 pref high
Kernel IPv6 routing table
$ ip -6 route list
default via fe80::be16:65ff:feb3:ce8e dev eth0 proto ra metric 1996489705 expires 21sec hoplimit 64 pref high
FRR Table, if a static route is configured:
[In real scenario, it is useful to prefer BGP learned default route over IPv6 RA default route.]
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
> - selected route, * - FIB route
S>* ::/0 [20/0] is directly connected, eth0, 00:00:06
K ::/0 [119/1001] via fe80::xx16:xxxx:feb3:ce8e, eth0, 6d07h43m
If the metric is changed later, the effect will be seen only when next IPv6
RA is received, because the default route must be fully controlled by RA msg.
Below metric is changed from 1996489705 to 1996489704.
$ sudo sysctl -w net.ipv6.conf.eth0.ra_defrtr_metric=1996489704
net.ipv6.conf.eth0.ra_defrtr_metric = 1996489704
IP monitor:
[On next IPv6 RA msg, Kernel deletes prev route and installs new route with updated metric]
Deleted default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489705 expires 3sec hoplimit 64 pref high
default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489704 pref high
Signed-off-by: Praveen Chaudhary <pchaudhary@linkedin.com>
Signed-off-by: Zhenggen Xu <zxu@linkedin.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210125214430.24079-1-pchaudhary@linkedin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 05:44:30 +08:00
|
|
|
ra_defrtr_metric - UNSIGNED INTEGER
|
|
|
|
Route metric for default route learned in Router Advertisement. This value
|
|
|
|
will be assigned as metric for the default route learned via IPv6 Router
|
|
|
|
Advertisement. Takes affect only if accept_ra_defrtr is enabled.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
1 to 0xFFFFFFFF
|
|
|
|
|
|
|
|
Default: IP6_RT_PRIO_USER i.e. 1024.
|
|
|
|
|
2014-06-26 05:44:53 +08:00
|
|
|
accept_ra_from_local - BOOLEAN
|
|
|
|
Accept RA with source-address that is found on local machine
|
2020-04-28 06:01:49 +08:00
|
|
|
if the RA is otherwise proper and able to be accepted.
|
|
|
|
|
|
|
|
Default is to NOT accept these as it may be an un-intended
|
|
|
|
network loop.
|
2014-06-26 05:44:53 +08:00
|
|
|
|
|
|
|
Functional default:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
- enabled if accept_ra_from_local is enabled
|
|
|
|
on a specific interface.
|
|
|
|
- disabled if accept_ra_from_local is disabled
|
|
|
|
on a specific interface.
|
2014-06-26 05:44:53 +08:00
|
|
|
|
2015-07-30 14:28:42 +08:00
|
|
|
accept_ra_min_hop_limit - INTEGER
|
|
|
|
Minimum hop limit Information in Router Advertisement.
|
|
|
|
|
|
|
|
Hop limit Information in Router Advertisement less than this
|
|
|
|
variable shall be ignored.
|
|
|
|
|
|
|
|
Default: 1
|
|
|
|
|
2006-03-21 08:55:26 +08:00
|
|
|
accept_ra_pinfo - BOOLEAN
|
2006-10-04 04:50:39 +08:00
|
|
|
Learn Prefix Information in Router Advertisement.
|
2006-03-21 08:55:26 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if accept_ra is enabled.
|
|
|
|
- disabled if accept_ra is disabled.
|
2006-03-21 08:55:26 +08:00
|
|
|
|
2017-03-22 17:19:04 +08:00
|
|
|
accept_ra_rt_info_min_plen - INTEGER
|
|
|
|
Minimum prefix length of Route Information in RA.
|
|
|
|
|
|
|
|
Route Information w/ prefix smaller than this variable shall
|
|
|
|
be ignored.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
* 0 if accept_ra_rtr_pref is enabled.
|
|
|
|
* -1 if accept_ra_rtr_pref is disabled.
|
2017-03-22 17:19:04 +08:00
|
|
|
|
2006-03-21 09:07:03 +08:00
|
|
|
accept_ra_rt_info_max_plen - INTEGER
|
|
|
|
Maximum prefix length of Route Information in RA.
|
|
|
|
|
2017-03-22 17:19:04 +08:00
|
|
|
Route Information w/ prefix larger than this variable shall
|
|
|
|
be ignored.
|
2006-03-21 09:07:03 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
* 0 if accept_ra_rtr_pref is enabled.
|
|
|
|
* -1 if accept_ra_rtr_pref is disabled.
|
2006-03-21 09:07:03 +08:00
|
|
|
|
2006-03-21 09:05:30 +08:00
|
|
|
accept_ra_rtr_pref - BOOLEAN
|
|
|
|
Accept Router Preference in RA.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if accept_ra is enabled.
|
|
|
|
- disabled if accept_ra is disabled.
|
2006-03-21 09:05:30 +08:00
|
|
|
|
2015-01-21 01:06:05 +08:00
|
|
|
accept_ra_mtu - BOOLEAN
|
|
|
|
Apply the MTU value specified in RA option 5 (RFC4861). If
|
|
|
|
disabled, the MTU specified in the RA will be ignored.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if accept_ra is enabled.
|
|
|
|
- disabled if accept_ra is disabled.
|
2015-01-21 01:06:05 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
accept_redirects - BOOLEAN
|
|
|
|
Accept Redirects.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if local forwarding is disabled.
|
|
|
|
- disabled if local forwarding is enabled.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-04-25 05:58:30 +08:00
|
|
|
accept_source_route - INTEGER
|
|
|
|
Accept source routing (routing extension header).
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- >= 0: Accept only routing header type 2.
|
|
|
|
- < 0: Do not accept routing header.
|
2007-04-25 05:58:30 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
autoconf - BOOLEAN
|
2009-02-23 12:39:04 +08:00
|
|
|
Autoconfigure addresses using Prefix Information in Router
|
2005-04-17 06:20:36 +08:00
|
|
|
Advertisements.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
Functional default:
|
|
|
|
|
|
|
|
- enabled if accept_ra_pinfo is enabled.
|
|
|
|
- disabled if accept_ra_pinfo is disabled.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
dad_transmits - INTEGER
|
|
|
|
The amount of Duplicate Address Detection probes to send.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 1
|
2009-02-23 12:39:04 +08:00
|
|
|
|
2011-09-29 03:51:54 +08:00
|
|
|
forwarding - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
Configure interface-specific Host/Router behaviour.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
It is recommended to have the same setting on all
|
|
|
|
interfaces; mixed router/host scenarios are rather uncommon.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-09-03 13:47:30 +08:00
|
|
|
Possible values are:
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 0 Forwarding disabled
|
|
|
|
- 1 Forwarding enabled
|
|
|
|
|
|
|
|
**FALSE (0)**:
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
By default, Host behaviour is assumed. This means:
|
|
|
|
|
|
|
|
1. IsRouter flag is not set in Neighbour Advertisements.
|
ipv6: Send ICMPv6 RSes only when RAs are accepted
This patch improves the logic determining when to send ICMPv6 Router
Solicitations, so that they are 1) always sent when the kernel is
accepting Router Advertisements, and 2) never sent when the kernel is
not accepting RAs. In other words, the operational setting of the
"accept_ra" sysctl is used.
The change also makes the special "Hybrid Router" forwarding mode
("forwarding" sysctl set to 2) operate exactly the same as the standard
Router mode (forwarding=1). The only difference between the two was
that RSes was being sent in the Hybrid Router mode only. The sysctl
documentation describing the special Hybrid Router mode has therefore
been removed.
Rationale for the change:
Currently, the value of forwarding sysctl is the only thing determining
whether or not to send RSes. If it has the value 0 or 2, they are sent,
otherwise they are not. This leads to inconsistent behaviour in the
following cases:
* accept_ra=0, forwarding=0
* accept_ra=0, forwarding=2
* accept_ra=1, forwarding=2
* accept_ra=2, forwarding=1
In the first three cases, the kernel will send RSes, even though it will
not accept any RAs received in reply. In the last case, it will not send
any RSes, even though it will accept and process any RAs received. (Most
routers will send unsolicited RAs periodically, so suppressing RSes in
the last case will merely delay auto-configuration, not prevent it.)
Also, it is my opinion that having the forwarding sysctl control RS
sending behaviour (completely independent of whether RAs are being
accepted or not) is simply not what most users would intuitively expect
to be the case.
Signed-off-by: Tore Anderson <tore@fud.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-29 07:47:33 +08:00
|
|
|
2. If accept_ra is TRUE (default), transmit Router
|
|
|
|
Solicitations.
|
2009-02-23 12:39:04 +08:00
|
|
|
3. If accept_ra is TRUE (default), accept Router
|
2005-04-17 06:20:36 +08:00
|
|
|
Advertisements (and do autoconfiguration).
|
|
|
|
4. If accept_redirects is TRUE (default), accept Redirects.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
**TRUE (1)**:
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-02-23 12:39:04 +08:00
|
|
|
If local forwarding is enabled, Router behaviour is assumed.
|
2005-04-17 06:20:36 +08:00
|
|
|
This means exactly the reverse from the above:
|
|
|
|
|
|
|
|
1. IsRouter flag is set in Neighbour Advertisements.
|
ipv6: Send ICMPv6 RSes only when RAs are accepted
This patch improves the logic determining when to send ICMPv6 Router
Solicitations, so that they are 1) always sent when the kernel is
accepting Router Advertisements, and 2) never sent when the kernel is
not accepting RAs. In other words, the operational setting of the
"accept_ra" sysctl is used.
The change also makes the special "Hybrid Router" forwarding mode
("forwarding" sysctl set to 2) operate exactly the same as the standard
Router mode (forwarding=1). The only difference between the two was
that RSes was being sent in the Hybrid Router mode only. The sysctl
documentation describing the special Hybrid Router mode has therefore
been removed.
Rationale for the change:
Currently, the value of forwarding sysctl is the only thing determining
whether or not to send RSes. If it has the value 0 or 2, they are sent,
otherwise they are not. This leads to inconsistent behaviour in the
following cases:
* accept_ra=0, forwarding=0
* accept_ra=0, forwarding=2
* accept_ra=1, forwarding=2
* accept_ra=2, forwarding=1
In the first three cases, the kernel will send RSes, even though it will
not accept any RAs received in reply. In the last case, it will not send
any RSes, even though it will accept and process any RAs received. (Most
routers will send unsolicited RAs periodically, so suppressing RSes in
the last case will merely delay auto-configuration, not prevent it.)
Also, it is my opinion that having the forwarding sysctl control RS
sending behaviour (completely independent of whether RAs are being
accepted or not) is simply not what most users would intuitively expect
to be the case.
Signed-off-by: Tore Anderson <tore@fud.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-08-29 07:47:33 +08:00
|
|
|
2. Router Solicitations are not sent unless accept_ra is 2.
|
2010-09-03 13:47:30 +08:00
|
|
|
3. Router Advertisements are ignored unless accept_ra is 2.
|
2005-04-17 06:20:36 +08:00
|
|
|
4. Redirects are ignored.
|
|
|
|
|
2010-09-03 13:47:30 +08:00
|
|
|
Default: 0 (disabled) if global forwarding is disabled (default),
|
2020-04-28 06:01:49 +08:00
|
|
|
otherwise 1 (enabled).
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
hop_limit - INTEGER
|
|
|
|
Default Hop Limit to set.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 64
|
|
|
|
|
|
|
|
mtu - INTEGER
|
|
|
|
Default Maximum Transfer Unit
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 1280 (IPv6 required minimum)
|
|
|
|
|
2015-07-09 07:58:22 +08:00
|
|
|
ip_nonlocal_bind - BOOLEAN
|
|
|
|
If set, allows processes to bind() to non-local IPv6 addresses,
|
|
|
|
which can be quite useful - but may break some applications.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2015-07-09 07:58:22 +08:00
|
|
|
Default: 0
|
|
|
|
|
2006-03-21 09:05:47 +08:00
|
|
|
router_probe_interval - INTEGER
|
|
|
|
Minimum interval (in seconds) between Router Probing described
|
|
|
|
in RFC4191.
|
|
|
|
|
|
|
|
Default: 60
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
router_solicitation_delay - INTEGER
|
|
|
|
Number of seconds to wait after interface is brought up
|
|
|
|
before sending Router Solicitations.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 1
|
|
|
|
|
|
|
|
router_solicitation_interval - INTEGER
|
|
|
|
Number of seconds to wait between Router Solicitations.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 4
|
|
|
|
|
|
|
|
router_solicitations - INTEGER
|
2009-02-23 12:39:04 +08:00
|
|
|
Number of Router Solicitations to send until assuming no
|
2005-04-17 06:20:36 +08:00
|
|
|
routers are present.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 3
|
|
|
|
|
2015-07-22 15:38:25 +08:00
|
|
|
use_oif_addrs_only - BOOLEAN
|
|
|
|
When enabled, the candidate source addresses for destinations
|
|
|
|
routed via this interface are restricted to the set of addresses
|
|
|
|
configured on this interface (vis. RFC 6724, section 4).
|
|
|
|
|
|
|
|
Default: false
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
use_tempaddr - INTEGER
|
|
|
|
Preference for Privacy Extensions (RFC3041).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* <= 0 : disable Privacy Extensions
|
|
|
|
* == 1 : enable Privacy Extensions, but prefer public
|
|
|
|
addresses over temporary addresses.
|
|
|
|
* > 1 : enable Privacy Extensions and prefer temporary
|
|
|
|
addresses over public addresses.
|
|
|
|
|
|
|
|
Default:
|
|
|
|
|
|
|
|
* 0 (for most devices)
|
|
|
|
* -1 (for point-to-point devices and loopback devices)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
temp_valid_lft - INTEGER
|
|
|
|
valid lifetime (in seconds) for temporary addresses.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2020-05-01 11:51:47 +08:00
|
|
|
Default: 172800 (2 days)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
temp_prefered_lft - INTEGER
|
|
|
|
Preferred lifetime (in seconds) for temporary addresses.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 86400 (1 day)
|
|
|
|
|
net: ipv6: Make address flushing on ifdown optional
Currently, all ipv6 addresses are flushed when the interface is configured
down, including global, static addresses:
$ ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2100:1::2/120 scope global
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe79:34bd/64 scope link
valid_lft forever preferred_lft forever
$ ip link set dev eth1 down
$ ip -6 addr show dev eth1
<< nothing; all addresses have been flushed>>
Add a new sysctl to make this behavior optional. The new setting defaults to
flush all addresses to maintain backwards compatibility. When the set global
addresses with no expire times are not flushed on an admin down. The sysctl
is per-interface or system-wide for all interfaces
$ sysctl -w net.ipv6.conf.eth1.keep_addr_on_down=1
or
$ sysctl -w net.ipv6.conf.all.keep_addr_on_down=1
Will keep addresses on eth1 on an admin down.
$ ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2100:1::2/120 scope global
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe79:34bd/64 scope link
valid_lft forever preferred_lft forever
$ ip link set dev eth1 down
$ ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST> mtu 1500 state DOWN qlen 1000
inet6 2100:1::2/120 scope global tentative
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe79:34bd/64 scope link tentative
valid_lft forever preferred_lft forever
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-25 01:25:37 +08:00
|
|
|
keep_addr_on_down - INTEGER
|
|
|
|
Keep all IPv6 addresses on an interface down event. If set static
|
|
|
|
global addresses with no expiration time are not flushed.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* >0 : enabled
|
|
|
|
* 0 : system default
|
|
|
|
* <0 : disabled
|
net: ipv6: Make address flushing on ifdown optional
Currently, all ipv6 addresses are flushed when the interface is configured
down, including global, static addresses:
$ ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2100:1::2/120 scope global
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe79:34bd/64 scope link
valid_lft forever preferred_lft forever
$ ip link set dev eth1 down
$ ip -6 addr show dev eth1
<< nothing; all addresses have been flushed>>
Add a new sysctl to make this behavior optional. The new setting defaults to
flush all addresses to maintain backwards compatibility. When the set global
addresses with no expire times are not flushed on an admin down. The sysctl
is per-interface or system-wide for all interfaces
$ sysctl -w net.ipv6.conf.eth1.keep_addr_on_down=1
or
$ sysctl -w net.ipv6.conf.all.keep_addr_on_down=1
Will keep addresses on eth1 on an admin down.
$ ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2100:1::2/120 scope global
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe79:34bd/64 scope link
valid_lft forever preferred_lft forever
$ ip link set dev eth1 down
$ ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST> mtu 1500 state DOWN qlen 1000
inet6 2100:1::2/120 scope global tentative
valid_lft forever preferred_lft forever
inet6 fe80::e0:f9ff:fe79:34bd/64 scope link tentative
valid_lft forever preferred_lft forever
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-25 01:25:37 +08:00
|
|
|
|
|
|
|
Default: 0 (addresses are removed)
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
max_desync_factor - INTEGER
|
|
|
|
Maximum value for DESYNC_FACTOR, which is a random value
|
2009-02-23 12:39:04 +08:00
|
|
|
that ensures that clients don't synchronize with each
|
2005-04-17 06:20:36 +08:00
|
|
|
other and generate new addresses at exactly the same time.
|
|
|
|
value is in seconds.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 600
|
2009-02-23 12:39:04 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
regen_max_retry - INTEGER
|
|
|
|
Number of attempts before give up attempting to generate
|
|
|
|
valid temporary addresses.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 5
|
|
|
|
|
|
|
|
max_addresses - INTEGER
|
2010-02-22 20:27:21 +08:00
|
|
|
Maximum number of autoconfigured addresses per interface. Setting
|
|
|
|
to zero disables the limitation. It is not recommended to set this
|
|
|
|
value too large (or to zero) because it would be an easy way to
|
|
|
|
crash the kernel by allowing too many addresses to be created.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 16
|
|
|
|
|
2008-06-28 13:17:11 +08:00
|
|
|
disable_ipv6 - BOOLEAN
|
2009-03-19 09:22:48 +08:00
|
|
|
Disable IPv6 operation. If accept_dad is set to 2, this value
|
|
|
|
will be dynamically set to TRUE if DAD fails for the link-local
|
|
|
|
address.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-06-28 13:17:11 +08:00
|
|
|
Default: FALSE (enable IPv6 operation)
|
|
|
|
|
2009-06-01 18:07:33 +08:00
|
|
|
When this value is changed from 1 to 0 (IPv6 is being enabled),
|
|
|
|
it will dynamically create a link-local address on the given
|
|
|
|
interface and start Duplicate Address Detection, if necessary.
|
|
|
|
|
|
|
|
When this value is changed from 0 to 1 (IPv6 is being disabled),
|
2018-03-29 17:02:25 +08:00
|
|
|
it will dynamically delete all addresses and routes on the given
|
|
|
|
interface. From now on it will not possible to add addresses/routes
|
|
|
|
to the selected interface.
|
2009-06-01 18:07:33 +08:00
|
|
|
|
2008-06-28 13:18:38 +08:00
|
|
|
accept_dad - INTEGER
|
|
|
|
Whether to accept DAD (Duplicate Address Detection).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
== ==============================================================
|
|
|
|
0 Disable DAD
|
|
|
|
1 Enable DAD (default)
|
|
|
|
2 Enable DAD, and disable IPv6 operation if MAC-based duplicate
|
|
|
|
link-local address has been found.
|
|
|
|
== ==============================================================
|
2008-06-28 13:18:38 +08:00
|
|
|
|
ipv6: fix net.ipv6.conf.all interface DAD handlers
Currently, writing into
net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
Fix handling of these flags by:
- using the maximum of global and per-interface values for the
accept_dad flag. That is, if at least one of the two values is
non-zero, enable DAD on the interface. If at least one value is
set to 2, enable DAD and disable IPv6 operation on the interface if
MAC-based link-local address was found
- using the logical OR of global and per-interface values for the
optimistic_dad flag. If at least one of them is set to one, optimistic
duplicate address detection (RFC 4429) is enabled on the interface
- using the logical OR of global and per-interface values for the
use_optimistic flag. If at least one of them is set to one,
optimistic addresses won't be marked as deprecated during source address
selection on the interface.
While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
drop inline, and let the compiler decide.
Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-12 23:46:37 +08:00
|
|
|
DAD operation and mode on a given interface will be selected according
|
|
|
|
to the maximum value of conf/{all,interface}/accept_dad.
|
|
|
|
|
2009-10-02 19:39:15 +08:00
|
|
|
force_tllao - BOOLEAN
|
|
|
|
Enable sending the target link-layer address option even when
|
|
|
|
responding to a unicast neighbor solicitation.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2009-10-02 19:39:15 +08:00
|
|
|
Default: FALSE
|
|
|
|
|
|
|
|
Quoting from RFC 2461, section 4.4, Target link-layer address:
|
|
|
|
|
|
|
|
"The option MUST be included for multicast solicitations in order to
|
|
|
|
avoid infinite Neighbor Solicitation "recursion" when the peer node
|
|
|
|
does not have a cache entry to return a Neighbor Advertisements
|
|
|
|
message. When responding to unicast solicitations, the option can be
|
|
|
|
omitted since the sender of the solicitation has the correct link-
|
|
|
|
layer address; otherwise it would not have be able to send the unicast
|
|
|
|
solicitation in the first place. However, including the link-layer
|
|
|
|
address in this case adds little overhead and eliminates a potential
|
|
|
|
race condition where the sender deletes the cached link-layer address
|
|
|
|
prior to receiving a response to a previous solicitation."
|
|
|
|
|
2013-01-01 08:35:31 +08:00
|
|
|
ndisc_notify - BOOLEAN
|
|
|
|
Define mode for notification of address and device changes.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* 0 - (default): do nothing
|
|
|
|
* 1 - Generate unsolicited neighbour advertisements when device is brought
|
|
|
|
up or hardware address changes.
|
2013-01-01 08:35:31 +08:00
|
|
|
|
net: ipv6: sysctl to specify IPv6 ND traffic class
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Solicitation (ICMPv6 type 135)
ndisc_send_ns() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Advertisement (ICMPv6 type 136)
ndisc_send_na() -> ndisc_send_skb() -> ip6_nd_hdr()
- Redirect (ICMPv6 type 137)
ndisc_send_redirect() -> ndisc_send_skb() -> ip6_nd_hdr()
and if the kernel ever gets around to generating RA's,
it would presumably also include:
- Router Advertisement (ICMPv6 type 134)
(radvd daemon could pick up on the kernel setting and use it)
Interface drivers may examine the Traffic Class value and translate
the DiffServ Code Point into a link-layer appropriate traffic
prioritization scheme. An example of mapping IETF DSCP values to
IEEE 802.11 User Priority values can be found here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11
The expected primary use case is to properly prioritize ND over wifi.
Testing:
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
0
jzem22:~# echo -1 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 256 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 0 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# echo 255 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
255
jzem22:~# echo 34 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
34
jzem22:~# echo $[0xDC] > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# tcpdump -v -i eth0 icmp6 and src host jzem22.pgc and dst host fe80::1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP6 (class 0xdc, hlim 255, next-header ICMPv6 (58) payload length: 24)
jzem22.pgc > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement,
length 24, tgt is jzem22.pgc, Flags [solicited]
(based on original change written by Erik Kline, with minor changes)
v2: fix 'suspicious rcu_dereference_check() usage'
by explicitly grabbing the rcu_read_lock.
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Erik Kline <ek@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-08 13:52:09 +08:00
|
|
|
ndisc_tclass - INTEGER
|
|
|
|
The IPv6 Traffic Class to use by default when sending IPv6 Neighbor
|
|
|
|
Discovery (Router Solicitation, Router Advertisement, Neighbor
|
|
|
|
Solicitation, Neighbor Advertisement, Redirect) messages.
|
|
|
|
These 8 bits can be interpreted as 6 high order bits holding the DSCP
|
|
|
|
value and 2 low order bits representing ECN (which you probably want
|
|
|
|
to leave cleared).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* 0 - (default)
|
net: ipv6: sysctl to specify IPv6 ND traffic class
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Solicitation (ICMPv6 type 135)
ndisc_send_ns() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Advertisement (ICMPv6 type 136)
ndisc_send_na() -> ndisc_send_skb() -> ip6_nd_hdr()
- Redirect (ICMPv6 type 137)
ndisc_send_redirect() -> ndisc_send_skb() -> ip6_nd_hdr()
and if the kernel ever gets around to generating RA's,
it would presumably also include:
- Router Advertisement (ICMPv6 type 134)
(radvd daemon could pick up on the kernel setting and use it)
Interface drivers may examine the Traffic Class value and translate
the DiffServ Code Point into a link-layer appropriate traffic
prioritization scheme. An example of mapping IETF DSCP values to
IEEE 802.11 User Priority values can be found here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11
The expected primary use case is to properly prioritize ND over wifi.
Testing:
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
0
jzem22:~# echo -1 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 256 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 0 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# echo 255 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
255
jzem22:~# echo 34 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
34
jzem22:~# echo $[0xDC] > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# tcpdump -v -i eth0 icmp6 and src host jzem22.pgc and dst host fe80::1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP6 (class 0xdc, hlim 255, next-header ICMPv6 (58) payload length: 24)
jzem22.pgc > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement,
length 24, tgt is jzem22.pgc, Flags [solicited]
(based on original change written by Erik Kline, with minor changes)
v2: fix 'suspicious rcu_dereference_check() usage'
by explicitly grabbing the rcu_read_lock.
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Erik Kline <ek@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-08 13:52:09 +08:00
|
|
|
|
2021-11-02 01:36:29 +08:00
|
|
|
ndisc_evict_nocarrier - BOOLEAN
|
|
|
|
Clears the neighbor discovery table on NOCARRIER events. This option is
|
|
|
|
important for wireless devices where the neighbor discovery cache should
|
|
|
|
not be cleared when roaming between access points on the same network.
|
|
|
|
In most cases this should remain as the default (1).
|
|
|
|
|
|
|
|
- 1 - (default): Clear neighbor discover cache on NOCARRIER events.
|
|
|
|
- 0 - Do not clear neighbor discovery cache on NOCARRIER events.
|
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
mldv1_unsolicited_report_interval - INTEGER
|
|
|
|
The interval in milliseconds in which the next unsolicited
|
|
|
|
MLDv1 report retransmit will take place.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
Default: 10000 (10 seconds)
|
|
|
|
|
|
|
|
mldv2_unsolicited_report_interval - INTEGER
|
|
|
|
The interval in milliseconds in which the next unsolicited
|
|
|
|
MLDv2 report retransmit will take place.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2013-08-14 07:03:46 +08:00
|
|
|
Default: 1000 (1 second)
|
|
|
|
|
2013-09-04 06:19:44 +08:00
|
|
|
force_mld_version - INTEGER
|
2020-04-28 06:01:49 +08:00
|
|
|
* 0 - (default) No enforcement of a MLD version, MLDv1 fallback allowed
|
|
|
|
* 1 - Enforce to use MLD version 1
|
|
|
|
* 2 - Enforce to use MLD version 2
|
2013-09-04 06:19:44 +08:00
|
|
|
|
2013-08-27 07:36:51 +08:00
|
|
|
suppress_frag_ndisc - INTEGER
|
|
|
|
Control RFC 6980 (Security Implications of IPv6 Fragmentation
|
|
|
|
with IPv6 Neighbor Discovery) behavior:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* 1 - (default) discard fragmented neighbor discovery packets
|
|
|
|
* 0 - allow fragmented neighbor discovery packets
|
2013-08-27 07:36:51 +08:00
|
|
|
|
net: ipv6: Add a sysctl to make optimistic addresses useful candidates
Add a sysctl that causes an interface's optimistic addresses
to be considered equivalent to other non-deprecated addresses
for source address selection purposes. Preferred addresses
will still take precedence over optimistic addresses, subject
to other ranking in the source address selection algorithm.
This is useful where different interfaces are connected to
different networks from different ISPs (e.g., a cell network
and a home wifi network).
The current behaviour complies with RFC 3484/6724, and it
makes sense if the host has only one interface, or has
multiple interfaces on the same network (same or cooperating
administrative domain(s), but not in the multiple distinct
networks case.
For example, if a mobile device has an IPv6 address on an LTE
network and then connects to IPv6-enabled wifi, while the wifi
IPv6 address is undergoing DAD, IPv6 connections will try use
the wifi default route with the LTE IPv6 address, and will get
stuck until they time out.
Also, because optimistic nodes can receive frames, issue
an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
flag appropriately set). A second RTM_NEWADDR is sent if DAD
completes (the address flags have changed), otherwise an
RTM_DELADDR is sent.
Also: add an entry in ip-sysctl.txt for optimistic_dad.
Signed-off-by: Erik Kline <ek@google.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-28 17:11:14 +08:00
|
|
|
optimistic_dad - BOOLEAN
|
|
|
|
Whether to perform Optimistic Duplicate Address Detection (RFC 4429).
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* 0: disabled (default)
|
|
|
|
* 1: enabled
|
ipv6: fix net.ipv6.conf.all interface DAD handlers
Currently, writing into
net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
Fix handling of these flags by:
- using the maximum of global and per-interface values for the
accept_dad flag. That is, if at least one of the two values is
non-zero, enable DAD on the interface. If at least one value is
set to 2, enable DAD and disable IPv6 operation on the interface if
MAC-based link-local address was found
- using the logical OR of global and per-interface values for the
optimistic_dad flag. If at least one of them is set to one, optimistic
duplicate address detection (RFC 4429) is enabled on the interface
- using the logical OR of global and per-interface values for the
use_optimistic flag. If at least one of them is set to one,
optimistic addresses won't be marked as deprecated during source address
selection on the interface.
While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
drop inline, and let the compiler decide.
Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-12 23:46:37 +08:00
|
|
|
|
|
|
|
Optimistic Duplicate Address Detection for the interface will be enabled
|
|
|
|
if at least one of conf/{all,interface}/optimistic_dad is set to 1,
|
|
|
|
it will be disabled otherwise.
|
net: ipv6: Add a sysctl to make optimistic addresses useful candidates
Add a sysctl that causes an interface's optimistic addresses
to be considered equivalent to other non-deprecated addresses
for source address selection purposes. Preferred addresses
will still take precedence over optimistic addresses, subject
to other ranking in the source address selection algorithm.
This is useful where different interfaces are connected to
different networks from different ISPs (e.g., a cell network
and a home wifi network).
The current behaviour complies with RFC 3484/6724, and it
makes sense if the host has only one interface, or has
multiple interfaces on the same network (same or cooperating
administrative domain(s), but not in the multiple distinct
networks case.
For example, if a mobile device has an IPv6 address on an LTE
network and then connects to IPv6-enabled wifi, while the wifi
IPv6 address is undergoing DAD, IPv6 connections will try use
the wifi default route with the LTE IPv6 address, and will get
stuck until they time out.
Also, because optimistic nodes can receive frames, issue
an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
flag appropriately set). A second RTM_NEWADDR is sent if DAD
completes (the address flags have changed), otherwise an
RTM_DELADDR is sent.
Also: add an entry in ip-sysctl.txt for optimistic_dad.
Signed-off-by: Erik Kline <ek@google.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-28 17:11:14 +08:00
|
|
|
|
|
|
|
use_optimistic - BOOLEAN
|
|
|
|
If enabled, do not classify optimistic addresses as deprecated during
|
|
|
|
source address selection. Preferred addresses will still be chosen
|
|
|
|
before optimistic addresses, subject to other ranking in the source
|
|
|
|
address selection algorithm.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
|
|
|
* 0: disabled (default)
|
|
|
|
* 1: enabled
|
ipv6: fix net.ipv6.conf.all interface DAD handlers
Currently, writing into
net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
Fix handling of these flags by:
- using the maximum of global and per-interface values for the
accept_dad flag. That is, if at least one of the two values is
non-zero, enable DAD on the interface. If at least one value is
set to 2, enable DAD and disable IPv6 operation on the interface if
MAC-based link-local address was found
- using the logical OR of global and per-interface values for the
optimistic_dad flag. If at least one of them is set to one, optimistic
duplicate address detection (RFC 4429) is enabled on the interface
- using the logical OR of global and per-interface values for the
use_optimistic flag. If at least one of them is set to one,
optimistic addresses won't be marked as deprecated during source address
selection on the interface.
While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
drop inline, and let the compiler decide.
Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates")
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-12 23:46:37 +08:00
|
|
|
|
|
|
|
This will be enabled if at least one of
|
|
|
|
conf/{all,interface}/use_optimistic is set to 1, disabled otherwise.
|
net: ipv6: Add a sysctl to make optimistic addresses useful candidates
Add a sysctl that causes an interface's optimistic addresses
to be considered equivalent to other non-deprecated addresses
for source address selection purposes. Preferred addresses
will still take precedence over optimistic addresses, subject
to other ranking in the source address selection algorithm.
This is useful where different interfaces are connected to
different networks from different ISPs (e.g., a cell network
and a home wifi network).
The current behaviour complies with RFC 3484/6724, and it
makes sense if the host has only one interface, or has
multiple interfaces on the same network (same or cooperating
administrative domain(s), but not in the multiple distinct
networks case.
For example, if a mobile device has an IPv6 address on an LTE
network and then connects to IPv6-enabled wifi, while the wifi
IPv6 address is undergoing DAD, IPv6 connections will try use
the wifi default route with the LTE IPv6 address, and will get
stuck until they time out.
Also, because optimistic nodes can receive frames, issue
an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
flag appropriately set). A second RTM_NEWADDR is sent if DAD
completes (the address flags have changed), otherwise an
RTM_DELADDR is sent.
Also: add an entry in ip-sysctl.txt for optimistic_dad.
Signed-off-by: Erik Kline <ek@google.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-28 17:11:14 +08:00
|
|
|
|
2015-03-24 06:36:06 +08:00
|
|
|
stable_secret - IPv6 address
|
|
|
|
This IPv6 address will be used as a secret to generate IPv6
|
|
|
|
addresses for link-local addresses and autoconfigured
|
|
|
|
ones. All addresses generated after setting this secret will
|
|
|
|
be stable privacy ones by default. This can be changed via the
|
|
|
|
addrgenmode ip-link. conf/default/stable_secret is used as the
|
|
|
|
secret for the namespace, the interface specific ones can
|
|
|
|
overwrite that. Writes to conf/all/stable_secret are refused.
|
|
|
|
|
|
|
|
It is recommended to generate this secret during installation
|
|
|
|
of a system and keep it stable after that.
|
|
|
|
|
|
|
|
By default the stable secret is unset.
|
|
|
|
|
2018-07-09 18:25:18 +08:00
|
|
|
addr_gen_mode - INTEGER
|
|
|
|
Defines how link-local and autoconf addresses are generated.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
= =================================================================
|
|
|
|
0 generate address based on EUI64 (default)
|
|
|
|
1 do no generate a link-local address, use EUI64 for addresses
|
|
|
|
generated from autoconf
|
|
|
|
2 generate stable privacy addresses, using the secret from
|
2018-07-09 18:25:18 +08:00
|
|
|
stable_secret (RFC7217)
|
2020-04-28 06:01:49 +08:00
|
|
|
3 generate stable privacy addresses, using a random secret if unset
|
|
|
|
= =================================================================
|
2018-07-09 18:25:18 +08:00
|
|
|
|
2016-02-04 20:31:19 +08:00
|
|
|
drop_unicast_in_l2_multicast - BOOLEAN
|
|
|
|
Drop any unicast IPv6 packets that are received in link-layer
|
|
|
|
multicast (or broadcast) frames.
|
|
|
|
|
|
|
|
By default this is turned off.
|
|
|
|
|
2016-02-04 20:31:20 +08:00
|
|
|
drop_unsolicited_na - BOOLEAN
|
|
|
|
Drop all unsolicited neighbor advertisements, for example if there's
|
|
|
|
a known good NA proxy on the network and such frames need not be used
|
|
|
|
(or in the case of 802.11, must not be used to prevent attacks.)
|
|
|
|
|
|
|
|
By default this is turned off.
|
|
|
|
|
2022-07-14 07:40:48 +08:00
|
|
|
accept_untracked_na - INTEGER
|
|
|
|
Define behavior for accepting neighbor advertisements from devices that
|
|
|
|
are absent in the neighbor cache:
|
|
|
|
|
|
|
|
- 0 - (default) Do not accept unsolicited and untracked neighbor
|
|
|
|
advertisements.
|
|
|
|
|
|
|
|
- 1 - Add a new neighbor cache entry in STALE state for routers on
|
|
|
|
receiving a neighbor advertisement (either solicited or unsolicited)
|
|
|
|
with target link-layer address option specified if no neighbor entry
|
|
|
|
is already present for the advertised IPv6 address. Without this knob,
|
|
|
|
NAs received for untracked addresses (absent in neighbor cache) are
|
|
|
|
silently ignored.
|
|
|
|
|
|
|
|
This is as per router-side behavior documented in RFC9131.
|
|
|
|
|
|
|
|
This has lower precedence than drop_unsolicited_na.
|
|
|
|
|
|
|
|
This will optimize the return path for the initial off-link
|
|
|
|
communication that is initiated by a directly connected host, by
|
|
|
|
ensuring that the first-hop router which turns on this setting doesn't
|
|
|
|
have to buffer the initial return packets to do neighbor-solicitation.
|
|
|
|
The prerequisite is that the host is configured to send unsolicited
|
|
|
|
neighbor advertisements on interface bringup. This setting should be
|
|
|
|
used in conjunction with the ndisc_notify setting on the host to
|
|
|
|
satisfy this prerequisite.
|
|
|
|
|
|
|
|
- 2 - Extend option (1) to add a new neighbor cache entry only if the
|
|
|
|
source IP address is in the same subnet as an address configured on
|
|
|
|
the interface that received the neighbor advertisement.
|
2022-04-15 16:34:02 +08:00
|
|
|
|
2016-12-03 06:00:08 +08:00
|
|
|
enhanced_dad - BOOLEAN
|
|
|
|
Include a nonce option in the IPv6 neighbor solicitation messages used for
|
|
|
|
duplicate address detection per RFC7527. A received DAD NS will only signal
|
|
|
|
a duplicate address if the nonce is different. This avoids any false
|
|
|
|
detection of duplicates due to loopback of the NS messages that we send.
|
|
|
|
The nonce option will be sent on an interface unless both of
|
|
|
|
conf/{all,interface}/enhanced_dad are set to FALSE.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2016-12-03 06:00:08 +08:00
|
|
|
Default: TRUE
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``icmp/*``:
|
|
|
|
===========
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
ratelimit - INTEGER
|
2019-04-18 04:35:49 +08:00
|
|
|
Limit the maximal rates for sending ICMPv6 messages.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-07-02 10:29:07 +08:00
|
|
|
0 to disable any limiting,
|
|
|
|
otherwise the minimal space between responses in milliseconds.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2008-07-02 10:29:07 +08:00
|
|
|
Default: 1000
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2019-04-18 04:35:49 +08:00
|
|
|
ratemask - list of comma separated ranges
|
|
|
|
For ICMPv6 message types matching the ranges in the ratemask, limit
|
|
|
|
the sending of the message according to ratelimit parameter.
|
|
|
|
|
|
|
|
The format used for both input and output is a comma separated
|
|
|
|
list of ranges (e.g. "0-127,129" for ICMPv6 message type 0 to 127 and
|
|
|
|
129). Writing to the file will clear all previous ranges of ICMPv6
|
|
|
|
message types and update the current list with the input.
|
|
|
|
|
|
|
|
Refer to: https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml
|
|
|
|
for numerical values of ICMPv6 message types, e.g. echo request is 128
|
|
|
|
and echo reply is 129.
|
|
|
|
|
|
|
|
Default: 0-1,3-127 (rate limit ICMPv6 errors except Packet Too Big)
|
|
|
|
|
2018-08-10 23:48:15 +08:00
|
|
|
echo_ignore_all - BOOLEAN
|
|
|
|
If set non-zero, then the kernel will ignore all ICMP ECHO
|
|
|
|
requests sent to it over the IPv6 protocol.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2018-08-10 23:48:15 +08:00
|
|
|
Default: 0
|
|
|
|
|
2019-03-20 00:37:12 +08:00
|
|
|
echo_ignore_multicast - BOOLEAN
|
|
|
|
If set non-zero, then the kernel will ignore all ICMP ECHO
|
|
|
|
requests sent to it over the IPv6 protocol via multicast.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-03-20 00:37:12 +08:00
|
|
|
Default: 0
|
|
|
|
|
2019-03-20 22:29:27 +08:00
|
|
|
echo_ignore_anycast - BOOLEAN
|
|
|
|
If set non-zero, then the kernel will ignore all ICMP ECHO
|
|
|
|
requests sent to it over the IPv6 protocol destined to anycast address.
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2019-03-20 22:29:27 +08:00
|
|
|
Default: 0
|
|
|
|
|
2015-08-12 04:35:01 +08:00
|
|
|
xfrm6_gc_thresh - INTEGER
|
2019-04-09 23:16:59 +08:00
|
|
|
(Obsolete since linux-4.14)
|
2015-08-12 04:35:01 +08:00
|
|
|
The threshold at which we will start garbage collecting for IPv6
|
|
|
|
destination cache entries. At twice this value the system will
|
2017-07-17 19:57:20 +08:00
|
|
|
refuse new allocations.
|
2015-08-12 04:35:01 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
IPv6 Update by:
|
|
|
|
Pekka Savola <pekkas@netcore.fi>
|
|
|
|
YOSHIFUJI Hideaki / USAGI Project <yoshfuji@linux-ipv6.org>
|
|
|
|
|
|
|
|
|
|
|
|
/proc/sys/net/bridge/* Variables:
|
2020-04-28 06:01:49 +08:00
|
|
|
=================================
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
bridge-nf-call-arptables - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1 : pass bridged ARP traffic to arptables' FORWARD chain.
|
|
|
|
- 0 : disable this.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 1
|
|
|
|
|
|
|
|
bridge-nf-call-iptables - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1 : pass bridged IPv4 traffic to iptables' chains.
|
|
|
|
- 0 : disable this.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 1
|
|
|
|
|
|
|
|
bridge-nf-call-ip6tables - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1 : pass bridged IPv6 traffic to ip6tables' chains.
|
|
|
|
- 0 : disable this.
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
Default: 1
|
|
|
|
|
|
|
|
bridge-nf-filter-vlan-tagged - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables.
|
|
|
|
- 0 : disable this.
|
|
|
|
|
2012-05-09 01:36:44 +08:00
|
|
|
Default: 0
|
2007-04-13 13:14:23 +08:00
|
|
|
|
|
|
|
bridge-nf-filter-pppoe-tagged - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
|
|
|
|
- 0 : disable this.
|
|
|
|
|
2012-05-09 01:36:44 +08:00
|
|
|
Default: 0
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-05-09 01:36:44 +08:00
|
|
|
bridge-nf-pass-vlan-input-dev - BOOLEAN
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: if bridge-nf-filter-vlan-tagged is enabled, try to find a vlan
|
|
|
|
interface on the bridge and set the netfilter input device to the
|
|
|
|
vlan. This allows use of e.g. "iptables -i br0.1" and makes the
|
|
|
|
REDIRECT target work with vlan-on-top-of-bridge interfaces. When no
|
|
|
|
matching vlan interface is found, or this switch is off, the input
|
|
|
|
device is set to the bridge interface.
|
|
|
|
|
|
|
|
- 0: disable bridge netfilter vlan interface lookup.
|
|
|
|
|
2012-05-09 01:36:44 +08:00
|
|
|
Default: 0
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``proc/sys/net/sctp/*`` Variables:
|
|
|
|
==================================
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
addip_enable - BOOLEAN
|
|
|
|
Enable or disable extension of Dynamic Address Reconfiguration
|
|
|
|
(ADD-IP) functionality specified in RFC5061. This extension provides
|
|
|
|
the ability to dynamically add and remove new addresses for the SCTP
|
|
|
|
associations.
|
|
|
|
|
|
|
|
1: Enable extension.
|
|
|
|
|
|
|
|
0: Disable extension.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2015-12-16 13:55:04 +08:00
|
|
|
pf_enable - INTEGER
|
|
|
|
Enable or disable pf (pf is short for potentially failed) state. A value
|
|
|
|
of pf_retrans > path_max_retrans also disables pf state. That is, one of
|
|
|
|
both pf_enable and pf_retrans > path_max_retrans can disable pf state.
|
|
|
|
Since pf_retrans and path_max_retrans can be changed by userspace
|
|
|
|
application, sometimes user expects to disable pf state by the value of
|
|
|
|
pf_retrans > path_max_retrans, but occasionally the value of pf_retrans
|
|
|
|
or path_max_retrans is changed by the user application, this pf state is
|
|
|
|
enabled. As such, it is necessary to add this to dynamically enable
|
|
|
|
and disable pf state. See:
|
|
|
|
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover for
|
|
|
|
details.
|
|
|
|
|
|
|
|
1: Enable pf.
|
|
|
|
|
|
|
|
0: Disable pf.
|
|
|
|
|
|
|
|
Default: 1
|
|
|
|
|
sctp: add pf_expose per netns and sock and asoc
As said in rfc7829, section 3, point 12:
The SCTP stack SHOULD expose the PF state of its destination
addresses to the ULP as well as provide the means to notify the
ULP of state transitions of its destination addresses from
active to PF, and vice versa. However, it is recommended that
an SCTP stack implementing SCTP-PF also allows for the ULP to be
kept ignorant of the PF state of its destinations and the
associated state transitions, thus allowing for retention of the
simpler state transition model of [RFC4960] in the ULP.
Not only does it allow to expose the PF state to ULP, but also
allow to ignore sctp-pf to ULP.
So this patch is to add pf_expose per netns, sock and asoc. And in
sctp_assoc_control_transport(), ulp_notify will be set to false if
asoc->expose is not 'enabled' in next patch.
It also allows a user to change pf_expose per netns by sysctl, and
pf_expose per sock and asoc will be initialized with it.
Note that pf_expose also works for SCTP_GET_PEER_ADDR_INFO sockopt,
to not allow a user to query the state of a sctp-pf peer address
when pf_expose is 'disabled', as said in section 7.3.
v1->v2:
- Fix a build warning noticed by Nathan Chancellor.
v2->v3:
- set pf_expose to UNUSED by default to keep compatible with old
applications.
v3->v4:
- add a new entry for pf_expose on ip-sysctl.txt, as Marcelo suggested.
- change this patch to 1/5, and move sctp_assoc_control_transport
change into 2/5, as Marcelo suggested.
- use SCTP_PF_EXPOSE_UNSET instead of SCTP_PF_EXPOSE_UNUSED, and
set SCTP_PF_EXPOSE_UNSET to 0 in enum, as Marcelo suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 13:20:32 +08:00
|
|
|
pf_expose - INTEGER
|
|
|
|
Unset or enable/disable pf (pf is short for potentially failed) state
|
|
|
|
exposure. Applications can control the exposure of the PF path state
|
|
|
|
in the SCTP_PEER_ADDR_CHANGE event and the SCTP_GET_PEER_ADDR_INFO
|
|
|
|
sockopt. When it's unset, no SCTP_PEER_ADDR_CHANGE event with
|
|
|
|
SCTP_ADDR_PF state will be sent and a SCTP_PF-state transport info
|
|
|
|
can be got via SCTP_GET_PEER_ADDR_INFO sockopt; When it's enabled,
|
|
|
|
a SCTP_PEER_ADDR_CHANGE event will be sent for a transport becoming
|
|
|
|
SCTP_PF state and a SCTP_PF-state transport info can be got via
|
2023-01-30 07:10:48 +08:00
|
|
|
SCTP_GET_PEER_ADDR_INFO sockopt; When it's disabled, no
|
sctp: add pf_expose per netns and sock and asoc
As said in rfc7829, section 3, point 12:
The SCTP stack SHOULD expose the PF state of its destination
addresses to the ULP as well as provide the means to notify the
ULP of state transitions of its destination addresses from
active to PF, and vice versa. However, it is recommended that
an SCTP stack implementing SCTP-PF also allows for the ULP to be
kept ignorant of the PF state of its destinations and the
associated state transitions, thus allowing for retention of the
simpler state transition model of [RFC4960] in the ULP.
Not only does it allow to expose the PF state to ULP, but also
allow to ignore sctp-pf to ULP.
So this patch is to add pf_expose per netns, sock and asoc. And in
sctp_assoc_control_transport(), ulp_notify will be set to false if
asoc->expose is not 'enabled' in next patch.
It also allows a user to change pf_expose per netns by sysctl, and
pf_expose per sock and asoc will be initialized with it.
Note that pf_expose also works for SCTP_GET_PEER_ADDR_INFO sockopt,
to not allow a user to query the state of a sctp-pf peer address
when pf_expose is 'disabled', as said in section 7.3.
v1->v2:
- Fix a build warning noticed by Nathan Chancellor.
v2->v3:
- set pf_expose to UNUSED by default to keep compatible with old
applications.
v3->v4:
- add a new entry for pf_expose on ip-sysctl.txt, as Marcelo suggested.
- change this patch to 1/5, and move sctp_assoc_control_transport
change into 2/5, as Marcelo suggested.
- use SCTP_PF_EXPOSE_UNSET instead of SCTP_PF_EXPOSE_UNUSED, and
set SCTP_PF_EXPOSE_UNSET to 0 in enum, as Marcelo suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 13:20:32 +08:00
|
|
|
SCTP_PEER_ADDR_CHANGE event will be sent and it returns -EACCES when
|
|
|
|
trying to get a SCTP_PF-state transport info via SCTP_GET_PEER_ADDR_INFO
|
|
|
|
sockopt.
|
|
|
|
|
|
|
|
0: Unset pf state exposure, Compatible with old applications.
|
|
|
|
|
|
|
|
1: Disable pf state exposure.
|
|
|
|
|
|
|
|
2: Enable pf state exposure.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2008-07-09 07:43:29 +08:00
|
|
|
addip_noauth_enable - BOOLEAN
|
|
|
|
Dynamic Address Reconfiguration (ADD-IP) requires the use of
|
|
|
|
authentication to protect the operations of adding or removing new
|
|
|
|
addresses. This requirement is mandated so that unauthorized hosts
|
|
|
|
would not be able to hijack associations. However, older
|
|
|
|
implementations may not have implemented this requirement while
|
|
|
|
allowing the ADD-IP extension. For reasons of interoperability,
|
|
|
|
we provide this variable to control the enforcement of the
|
|
|
|
authentication requirement.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
== ===============================================================
|
|
|
|
1 Allow ADD-IP extension to be used without authentication. This
|
2008-07-09 07:43:29 +08:00
|
|
|
should only be set in a closed environment for interoperability
|
|
|
|
with older implementations.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
0 Enforce the authentication requirement
|
|
|
|
== ===============================================================
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
|
|
|
auth_enable - BOOLEAN
|
|
|
|
Enable or disable Authenticated Chunks extension. This extension
|
|
|
|
provides the ability to send and receive authenticated chunks and is
|
|
|
|
required for secure operation of Dynamic Address Reconfiguration
|
|
|
|
(ADD-IP) extension.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: Enable this extension.
|
|
|
|
- 0: Disable this extension.
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
|
|
|
prsctp_enable - BOOLEAN
|
|
|
|
Enable or disable the Partial Reliability extension (RFC3758) which
|
|
|
|
is used to notify peers that a given DATA should no longer be expected.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: Enable extension
|
|
|
|
- 0: Disable
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
Default: 1
|
|
|
|
|
|
|
|
max_burst - INTEGER
|
|
|
|
The limit of the number of new packets that can be initially sent. It
|
|
|
|
controls how bursty the generated traffic can be.
|
|
|
|
|
|
|
|
Default: 4
|
|
|
|
|
|
|
|
association_max_retrans - INTEGER
|
|
|
|
Set the maximum number for retransmissions that an association can
|
|
|
|
attempt deciding that the remote end is unreachable. If this value
|
|
|
|
is exceeded, the association is terminated.
|
|
|
|
|
|
|
|
Default: 10
|
|
|
|
|
|
|
|
max_init_retransmits - INTEGER
|
|
|
|
The maximum number of retransmissions of INIT and COOKIE-ECHO chunks
|
|
|
|
that an association will attempt before declaring the destination
|
|
|
|
unreachable and terminating.
|
|
|
|
|
|
|
|
Default: 8
|
|
|
|
|
|
|
|
path_max_retrans - INTEGER
|
|
|
|
The maximum number of retransmissions that will be attempted on a given
|
|
|
|
path. Once this threshold is exceeded, the path is considered
|
|
|
|
unreachable, and new traffic will use a different path when the
|
|
|
|
association is multihomed.
|
|
|
|
|
|
|
|
Default: 5
|
|
|
|
|
2012-07-21 15:56:07 +08:00
|
|
|
pf_retrans - INTEGER
|
|
|
|
The number of retransmissions that will be attempted on a given path
|
|
|
|
before traffic is redirected to an alternate transport (should one
|
|
|
|
exist). Note this is distinct from path_max_retrans, as a path that
|
|
|
|
passes the pf_retrans threshold can still be used. Its only
|
|
|
|
deprioritized when a transmission path is selected by the stack. This
|
|
|
|
setting is primarily used to enable fast failover mechanisms without
|
|
|
|
having to reduce path_max_retrans to a very low value. See:
|
|
|
|
http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-05.txt
|
|
|
|
for details. Note also that a value of pf_retrans > path_max_retrans
|
2015-12-16 13:55:04 +08:00
|
|
|
disables this feature. Since both pf_retrans and path_max_retrans can
|
|
|
|
be changed by userspace application, a variable pf_enable is used to
|
|
|
|
disable pf state.
|
2012-07-21 15:56:07 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2019-11-08 13:20:35 +08:00
|
|
|
ps_retrans - INTEGER
|
|
|
|
Primary.Switchover.Max.Retrans (PSMR), it's a tunable parameter coming
|
|
|
|
from section-5 "Primary Path Switchover" in rfc7829. The primary path
|
|
|
|
will be changed to another active path when the path error counter on
|
|
|
|
the old primary path exceeds PSMR, so that "the SCTP sender is allowed
|
|
|
|
to continue data transmission on a new working path even when the old
|
|
|
|
primary destination address becomes active again". Note this feature
|
|
|
|
is disabled by initializing 'ps_retrans' per netns as 0xffff by default,
|
|
|
|
and its value can't be less than 'pf_retrans' when changing by sysctl.
|
|
|
|
|
|
|
|
Default: 0xffff
|
|
|
|
|
2008-07-09 07:43:29 +08:00
|
|
|
rto_initial - INTEGER
|
|
|
|
The initial round trip timeout value in milliseconds that will be used
|
|
|
|
in calculating round trip times. This is the initial time interval
|
|
|
|
for retransmissions.
|
|
|
|
|
|
|
|
Default: 3000
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-07-09 07:43:29 +08:00
|
|
|
rto_max - INTEGER
|
|
|
|
The maximum value (in milliseconds) of the round trip timeout. This
|
|
|
|
is the largest time interval that can elapse between retransmissions.
|
|
|
|
|
|
|
|
Default: 60000
|
|
|
|
|
|
|
|
rto_min - INTEGER
|
|
|
|
The minimum value (in milliseconds) of the round trip timeout. This
|
|
|
|
is the smallest time interval the can elapse between retransmissions.
|
|
|
|
|
|
|
|
Default: 1000
|
|
|
|
|
|
|
|
hb_interval - INTEGER
|
|
|
|
The interval (in milliseconds) between HEARTBEAT chunks. These chunks
|
|
|
|
are sent at the specified interval on idle paths to probe the state of
|
|
|
|
a given path between 2 associations.
|
|
|
|
|
|
|
|
Default: 30000
|
|
|
|
|
|
|
|
sack_timeout - INTEGER
|
|
|
|
The amount of time (in milliseconds) that the implementation will wait
|
|
|
|
to send a SACK.
|
|
|
|
|
|
|
|
Default: 200
|
|
|
|
|
|
|
|
valid_cookie_life - INTEGER
|
|
|
|
The default lifetime of the SCTP cookie (in milliseconds). The cookie
|
|
|
|
is used during association establishment.
|
|
|
|
|
|
|
|
Default: 60000
|
|
|
|
|
|
|
|
cookie_preserve_enable - BOOLEAN
|
|
|
|
Enable or disable the ability to extend the lifetime of the SCTP cookie
|
|
|
|
that is used during the establishment phase of SCTP association
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: Enable cookie lifetime extension.
|
|
|
|
- 0: Disable
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
Default: 1
|
|
|
|
|
2012-10-24 17:20:03 +08:00
|
|
|
cookie_hmac_alg - STRING
|
|
|
|
Select the hmac algorithm used when generating the cookie value sent by
|
|
|
|
a listening sctp socket to a connecting client in the INIT-ACK chunk.
|
|
|
|
Valid values are:
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-10-24 17:20:03 +08:00
|
|
|
* md5
|
|
|
|
* sha1
|
|
|
|
* none
|
2020-04-28 06:01:49 +08:00
|
|
|
|
2012-10-24 17:20:03 +08:00
|
|
|
Ability to assign md5 or sha1 as the selected alg is predicated on the
|
2013-01-03 15:50:29 +08:00
|
|
|
configuration of those algorithms at build time (CONFIG_CRYPTO_MD5 and
|
2012-10-24 17:20:03 +08:00
|
|
|
CONFIG_CRYPTO_SHA1).
|
|
|
|
|
|
|
|
Default: Dependent on configuration. MD5 if available, else SHA1 if
|
|
|
|
available, else none.
|
|
|
|
|
2008-07-09 07:43:29 +08:00
|
|
|
rcvbuf_policy - INTEGER
|
|
|
|
Determines if the receive buffer is attributed to the socket or to
|
|
|
|
association. SCTP supports the capability to create multiple
|
|
|
|
associations on a single socket. When using this capability, it is
|
|
|
|
possible that a single stalled association that's buffering a lot
|
|
|
|
of data may block other associations from delivering their data by
|
|
|
|
consuming all of the receive buffer space. To work around this,
|
|
|
|
the rcvbuf_policy could be set to attribute the receiver buffer space
|
|
|
|
to each association instead of the socket. This prevents the described
|
|
|
|
blocking.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: rcvbuf space is per association
|
|
|
|
- 0: rcvbuf space is per socket
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
|
|
|
sndbuf_policy - INTEGER
|
|
|
|
Similar to rcvbuf_policy above, this applies to send buffer space.
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 1: Send buffer is tracked per association
|
|
|
|
- 0: Send buffer is tracked per socket.
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
|
|
|
sctp_mem - vector of 3 INTEGERs: min, pressure, max
|
|
|
|
Number of pages allowed for queueing by all SCTP sockets.
|
|
|
|
|
|
|
|
min: Below this number of pages SCTP is not bothered about its
|
|
|
|
memory appetite. When amount of memory allocated by SCTP exceeds
|
|
|
|
this number, SCTP starts to moderate memory usage.
|
|
|
|
|
|
|
|
pressure: This value was introduced to follow format of tcp_mem.
|
|
|
|
|
|
|
|
max: Number of pages allowed for queueing by all SCTP sockets.
|
|
|
|
|
|
|
|
Default is calculated at boot time from amount of available memory.
|
|
|
|
|
|
|
|
sctp_rmem - vector of 3 INTEGERs: min, default, max
|
2011-06-20 06:08:10 +08:00
|
|
|
Only the first value ("min") is used, "default" and "max" are
|
|
|
|
ignored.
|
|
|
|
|
|
|
|
min: Minimal size of receive buffer used by SCTP socket.
|
|
|
|
It is guaranteed to each SCTP socket (but not association) even
|
|
|
|
under moderate memory pressure.
|
|
|
|
|
2018-03-14 12:57:17 +08:00
|
|
|
Default: 4K
|
2008-07-09 07:43:29 +08:00
|
|
|
|
|
|
|
sctp_wmem - vector of 3 INTEGERs: min, default, max
|
2022-07-21 22:35:46 +08:00
|
|
|
Only the first value ("min") is used, "default" and "max" are
|
|
|
|
ignored.
|
|
|
|
|
|
|
|
min: Minimum size of send buffer that can be used by SCTP sockets.
|
|
|
|
It is guaranteed to each SCTP socket (but not association) even
|
|
|
|
under moderate memory pressure.
|
|
|
|
|
|
|
|
Default: 4K
|
2008-07-09 07:43:29 +08:00
|
|
|
|
2009-09-03 19:55:47 +08:00
|
|
|
addr_scope_policy - INTEGER
|
|
|
|
Control IPv4 address scoping - draft-stewart-tsvwg-sctp-ipv4-00
|
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
- 0 - Disable IPv4 address scoping
|
|
|
|
- 1 - Enable IPv4 address scoping
|
|
|
|
- 2 - Follow draft but allow IPv4 private addresses
|
|
|
|
- 3 - Follow draft but allow IPv4 link local addresses
|
2009-09-03 19:55:47 +08:00
|
|
|
|
|
|
|
Default: 1
|
|
|
|
|
2020-10-29 15:05:10 +08:00
|
|
|
udp_port - INTEGER
|
|
|
|
The listening port for the local UDP tunneling sock. Normally it's
|
|
|
|
using the IANA-assigned UDP port number 9899 (sctp-tunneling).
|
|
|
|
|
|
|
|
This UDP sock is used for processing the incoming UDP-encapsulated
|
|
|
|
SCTP packets (from RFC6951), and shared by all applications in the
|
|
|
|
same net namespace. This UDP sock will be closed when the value is
|
|
|
|
set to 0.
|
|
|
|
|
|
|
|
The value will also be used to set the src port of the UDP header
|
|
|
|
for the outgoing UDP-encapsulated SCTP packets. For the dest port,
|
|
|
|
please refer to 'encap_port' below.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2020-10-29 15:05:01 +08:00
|
|
|
encap_port - INTEGER
|
|
|
|
The default remote UDP encapsulation port.
|
|
|
|
|
|
|
|
This value is used to set the dest port of the UDP header for the
|
|
|
|
outgoing UDP-encapsulated SCTP packets by default. Users can also
|
|
|
|
change the value for each sock/asoc/transport by using setsockopt.
|
|
|
|
For further information, please refer to RFC6951.
|
|
|
|
|
|
|
|
Note that when connecting to a remote server, the client should set
|
|
|
|
this to the port that the UDP tunneling sock on the peer server is
|
|
|
|
listening to and the local UDP tunneling sock on the client also
|
|
|
|
must be started. On the server, it would get the encap_port from
|
|
|
|
the incoming packet's source port.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2021-06-23 02:04:48 +08:00
|
|
|
plpmtud_probe_interval - INTEGER
|
2021-06-24 23:48:09 +08:00
|
|
|
The time interval (in milliseconds) for the PLPMTUD probe timer,
|
|
|
|
which is configured to expire after this period to receive an
|
|
|
|
acknowledgment to a probe packet. This is also the time interval
|
|
|
|
between the probes for the current pmtu when the probe search
|
|
|
|
is done.
|
|
|
|
|
|
|
|
PLPMTUD will be disabled when 0 is set, and other values for it
|
|
|
|
must be >= 5000.
|
2021-06-23 02:04:48 +08:00
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2022-06-09 23:17:13 +08:00
|
|
|
reconf_enable - BOOLEAN
|
|
|
|
Enable or disable extension of Stream Reconfiguration functionality
|
|
|
|
specified in RFC6525. This extension provides the ability to "reset"
|
|
|
|
a stream, and it includes the Parameters of "Outgoing/Incoming SSN
|
|
|
|
Reset", "SSN/TSN Reset" and "Add Outgoing/Incoming Streams".
|
|
|
|
|
|
|
|
- 1: Enable extension.
|
|
|
|
- 0: Disable extension.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2022-06-09 23:17:14 +08:00
|
|
|
intl_enable - BOOLEAN
|
|
|
|
Enable or disable extension of User Message Interleaving functionality
|
|
|
|
specified in RFC8260. This extension allows the interleaving of user
|
|
|
|
messages sent on different streams. With this feature enabled, I-DATA
|
|
|
|
chunk will replace DATA chunk to carry user messages if also supported
|
|
|
|
by the peer. Note that to use this feature, one needs to set this option
|
|
|
|
to 1 and also needs to set socket options SCTP_FRAGMENT_INTERLEAVE to 2
|
|
|
|
and SCTP_INTERLEAVING_SUPPORTED to 1.
|
|
|
|
|
|
|
|
- 1: Enable extension.
|
|
|
|
- 0: Disable extension.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
2022-06-09 23:17:15 +08:00
|
|
|
ecn_enable - BOOLEAN
|
|
|
|
Control use of Explicit Congestion Notification (ECN) by SCTP.
|
|
|
|
Like in TCP, ECN is used only when both ends of the SCTP connection
|
|
|
|
indicate support for it. This feature is useful in avoiding losses
|
|
|
|
due to congestion by allowing supporting routers to signal congestion
|
|
|
|
before having to drop packets.
|
|
|
|
|
|
|
|
1: Enable ecn.
|
|
|
|
0: Disable ecn.
|
|
|
|
|
|
|
|
Default: 1
|
|
|
|
|
2022-11-17 04:01:21 +08:00
|
|
|
l3mdev_accept - BOOLEAN
|
|
|
|
Enabling this option allows a "global" bound socket to work
|
|
|
|
across L3 master domains (e.g., VRFs) with packets capable of
|
|
|
|
being received regardless of the L3 domain in which they
|
|
|
|
originated. Only valid when the kernel was compiled with
|
|
|
|
CONFIG_NET_L3_MASTER_DEV.
|
|
|
|
|
|
|
|
Default: 1 (enabled)
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``/proc/sys/net/core/*``
|
|
|
|
========================
|
|
|
|
|
2019-04-23 03:48:00 +08:00
|
|
|
Please see: Documentation/admin-guide/sysctl/net.rst for descriptions of these entries.
|
2009-05-15 06:49:36 +08:00
|
|
|
|
2008-07-11 07:50:26 +08:00
|
|
|
|
2020-04-28 06:01:49 +08:00
|
|
|
``/proc/sys/net/unix/*``
|
|
|
|
========================
|
|
|
|
|
2009-05-15 06:49:36 +08:00
|
|
|
max_dgram_qlen - INTEGER
|
|
|
|
The maximum length of dgram socket receive queue
|
|
|
|
|
|
|
|
Default: 10
|
|
|
|
|