2017-11-01 14:08:43 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
|
2006-08-08 00:57:44 +00:00
|
|
|
#ifndef __LINUX_NEIGHBOUR_H
|
|
|
|
#define __LINUX_NEIGHBOUR_H
|
|
|
|
|
2009-01-30 16:28:19 +00:00
|
|
|
#include <linux/types.h>
|
2006-08-08 00:57:44 +00:00
|
|
|
#include <linux/netlink.h>
|
|
|
|
|
2009-11-04 17:50:58 +00:00
|
|
|
struct ndmsg {
|
2006-08-08 00:57:44 +00:00
|
|
|
__u8 ndm_family;
|
|
|
|
__u8 ndm_pad1;
|
|
|
|
__u16 ndm_pad2;
|
|
|
|
__s32 ndm_ifindex;
|
|
|
|
__u16 ndm_state;
|
|
|
|
__u8 ndm_flags;
|
|
|
|
__u8 ndm_type;
|
|
|
|
};
|
|
|
|
|
2009-11-04 17:50:58 +00:00
|
|
|
enum {
|
2006-08-08 00:57:44 +00:00
|
|
|
NDA_UNSPEC,
|
|
|
|
NDA_DST,
|
|
|
|
NDA_LLADDR,
|
|
|
|
NDA_CACHEINFO,
|
|
|
|
NDA_PROBES,
|
2013-02-13 12:00:18 +00:00
|
|
|
NDA_VLAN,
|
2013-03-15 04:35:51 +00:00
|
|
|
NDA_PORT,
|
|
|
|
NDA_VNI,
|
|
|
|
NDA_IFINDEX,
|
2014-05-28 05:39:37 +00:00
|
|
|
NDA_MASTER,
|
2015-01-26 13:10:53 +00:00
|
|
|
NDA_LINK_NETNSID,
|
2017-02-01 06:59:52 +00:00
|
|
|
NDA_SRC_VNI,
|
2018-12-15 22:09:06 +00:00
|
|
|
NDA_PROTOCOL, /* Originator of entry */
|
2020-05-22 05:26:14 +00:00
|
|
|
NDA_NH_ID,
|
2020-06-23 20:47:16 +00:00
|
|
|
NDA_FDB_EXT_ATTRS,
|
2021-10-11 12:12:37 +00:00
|
|
|
NDA_FLAGS_EXT,
|
2022-04-13 10:52:00 +00:00
|
|
|
NDA_NDM_STATE_MASK,
|
|
|
|
NDA_NDM_FLAGS_MASK,
|
2006-08-08 00:57:44 +00:00
|
|
|
__NDA_MAX
|
|
|
|
};
|
|
|
|
|
|
|
|
#define NDA_MAX (__NDA_MAX - 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Neighbor Cache Entry Flags
|
|
|
|
*/
|
|
|
|
|
2021-10-11 12:12:38 +00:00
|
|
|
#define NTF_USE (1 << 0)
|
|
|
|
#define NTF_SELF (1 << 1)
|
|
|
|
#define NTF_MASTER (1 << 2)
|
|
|
|
#define NTF_PROXY (1 << 3) /* == ATF_PUBL */
|
|
|
|
#define NTF_EXT_LEARNED (1 << 4)
|
|
|
|
#define NTF_OFFLOADED (1 << 5)
|
|
|
|
#define NTF_STICKY (1 << 6)
|
|
|
|
#define NTF_ROUTER (1 << 7)
|
|
|
|
/* Extended flags under NDA_FLAGS_EXT: */
|
bridge: Add MAC Authentication Bypass (MAB) support
Hosts that support 802.1X authentication are able to authenticate
themselves by exchanging EAPOL frames with an authenticator (Ethernet
bridge, in this case) and an authentication server. Access to the
network is only granted by the authenticator to successfully
authenticated hosts.
The above is implemented in the bridge using the "locked" bridge port
option. When enabled, link-local frames (e.g., EAPOL) can be locally
received by the bridge, but all other frames are dropped unless the host
is authenticated. That is, unless the user space control plane installed
an FDB entry according to which the source address of the frame is
located behind the locked ingress port. The entry can be dynamic, in
which case learning needs to be enabled so that the entry will be
refreshed by incoming traffic.
There are deployments in which not all the devices connected to the
authenticator (the bridge) support 802.1X. Such devices can include
printers and cameras. One option to support such deployments is to
unlock the bridge ports connecting these devices, but a slightly more
secure option is to use MAB. When MAB is enabled, the MAC address of the
connected device is used as the user name and password for the
authentication.
For MAB to work, the user space control plane needs to be notified about
MAC addresses that are trying to gain access so that they will be
compared against an allow list. This can be implemented via the regular
learning process with the sole difference that learned FDB entries are
installed with a new "locked" flag indicating that the entry cannot be
used to authenticate the device. The flag cannot be set by user space,
but user space can clear the flag by replacing the entry, thereby
authenticating the device.
Locked FDB entries implement the following semantics with regards to
roaming, aging and forwarding:
1. Roaming: Locked FDB entries can roam to unlocked (authorized) ports,
in which case the "locked" flag is cleared. FDB entries cannot roam
to locked ports regardless of MAB being enabled or not. Therefore,
locked FDB entries are only created if an FDB entry with the given {MAC,
VID} does not already exist. This behavior prevents unauthenticated
devices from disrupting traffic destined to already authenticated
devices.
2. Aging: Locked FDB entries age and refresh by incoming traffic like
regular entries.
3. Forwarding: Locked FDB entries forward traffic like regular entries.
If user space detects an unauthorized MAC behind a locked port and
wishes to prevent traffic with this MAC DA from reaching the host, it
can do so using tc or a different mechanism.
Enable the above behavior using a new bridge port option called "mab".
It can only be enabled on a bridge port that is both locked and has
learning enabled. Locked FDB entries are flushed from the port once MAB
is disabled. A new option is added because there are pure 802.1X
deployments that are not interested in notifications about locked FDB
entries.
Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-01 19:39:21 +00:00
|
|
|
#define NTF_EXT_MANAGED (1 << 0)
|
|
|
|
#define NTF_EXT_LOCKED (1 << 1)
|
2012-04-15 06:43:56 +00:00
|
|
|
|
2006-08-08 00:57:44 +00:00
|
|
|
/*
|
|
|
|
* Neighbor Cache Entry States.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define NUD_INCOMPLETE 0x01
|
|
|
|
#define NUD_REACHABLE 0x02
|
|
|
|
#define NUD_STALE 0x04
|
|
|
|
#define NUD_DELAY 0x08
|
|
|
|
#define NUD_PROBE 0x10
|
|
|
|
#define NUD_FAILED 0x20
|
|
|
|
|
|
|
|
/* Dummy states */
|
|
|
|
#define NUD_NOARP 0x40
|
|
|
|
#define NUD_PERMANENT 0x80
|
|
|
|
#define NUD_NONE 0x00
|
|
|
|
|
2021-10-11 12:12:38 +00:00
|
|
|
/* NUD_NOARP & NUD_PERMANENT are pseudostates, they never change and make no
|
|
|
|
* address resolution or NUD.
|
|
|
|
*
|
|
|
|
* NUD_PERMANENT also cannot be deleted by garbage collectors. This holds true
|
|
|
|
* for dynamic entries with NTF_EXT_LEARNED flag as well. However, upon carrier
|
|
|
|
* down event, NUD_PERMANENT entries are not flushed whereas NTF_EXT_LEARNED
|
|
|
|
* flagged entries explicitly are (which is also consistent with the routing
|
|
|
|
* subsystem).
|
|
|
|
*
|
2021-08-10 11:00:10 +00:00
|
|
|
* When NTF_EXT_LEARNED is set for a bridge fdb entry the different cache entry
|
|
|
|
* states don't make sense and thus are ignored. Such entries don't age and
|
|
|
|
* can roam.
|
2021-10-11 12:12:38 +00:00
|
|
|
*
|
|
|
|
* NTF_EXT_MANAGED flagged neigbor entries are managed by the kernel on behalf
|
|
|
|
* of a user space control plane, and automatically refreshed so that (if
|
|
|
|
* possible) they remain in NUD_REACHABLE state.
|
bridge: Add MAC Authentication Bypass (MAB) support
Hosts that support 802.1X authentication are able to authenticate
themselves by exchanging EAPOL frames with an authenticator (Ethernet
bridge, in this case) and an authentication server. Access to the
network is only granted by the authenticator to successfully
authenticated hosts.
The above is implemented in the bridge using the "locked" bridge port
option. When enabled, link-local frames (e.g., EAPOL) can be locally
received by the bridge, but all other frames are dropped unless the host
is authenticated. That is, unless the user space control plane installed
an FDB entry according to which the source address of the frame is
located behind the locked ingress port. The entry can be dynamic, in
which case learning needs to be enabled so that the entry will be
refreshed by incoming traffic.
There are deployments in which not all the devices connected to the
authenticator (the bridge) support 802.1X. Such devices can include
printers and cameras. One option to support such deployments is to
unlock the bridge ports connecting these devices, but a slightly more
secure option is to use MAB. When MAB is enabled, the MAC address of the
connected device is used as the user name and password for the
authentication.
For MAB to work, the user space control plane needs to be notified about
MAC addresses that are trying to gain access so that they will be
compared against an allow list. This can be implemented via the regular
learning process with the sole difference that learned FDB entries are
installed with a new "locked" flag indicating that the entry cannot be
used to authenticate the device. The flag cannot be set by user space,
but user space can clear the flag by replacing the entry, thereby
authenticating the device.
Locked FDB entries implement the following semantics with regards to
roaming, aging and forwarding:
1. Roaming: Locked FDB entries can roam to unlocked (authorized) ports,
in which case the "locked" flag is cleared. FDB entries cannot roam
to locked ports regardless of MAB being enabled or not. Therefore,
locked FDB entries are only created if an FDB entry with the given {MAC,
VID} does not already exist. This behavior prevents unauthenticated
devices from disrupting traffic destined to already authenticated
devices.
2. Aging: Locked FDB entries age and refresh by incoming traffic like
regular entries.
3. Forwarding: Locked FDB entries forward traffic like regular entries.
If user space detects an unauthorized MAC behind a locked port and
wishes to prevent traffic with this MAC DA from reaching the host, it
can do so using tc or a different mechanism.
Enable the above behavior using a new bridge port option called "mab".
It can only be enabled on a bridge port that is both locked and has
learning enabled. Locked FDB entries are flushed from the port once MAB
is disabled. A new option is added because there are pure 802.1X
deployments that are not interested in notifications about locked FDB
entries.
Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-01 19:39:21 +00:00
|
|
|
*
|
|
|
|
* NTF_EXT_LOCKED flagged bridge FDB entries are entries generated by the
|
|
|
|
* bridge in response to a host trying to communicate via a locked bridge port
|
|
|
|
* with MAB enabled. Their purpose is to notify user space that a host requires
|
|
|
|
* authentication.
|
2006-08-08 00:57:44 +00:00
|
|
|
*/
|
|
|
|
|
2009-11-04 17:50:58 +00:00
|
|
|
struct nda_cacheinfo {
|
2006-08-08 00:57:44 +00:00
|
|
|
__u32 ndm_confirmed;
|
|
|
|
__u32 ndm_used;
|
|
|
|
__u32 ndm_updated;
|
|
|
|
__u32 ndm_refcnt;
|
|
|
|
};
|
|
|
|
|
2006-08-08 01:00:57 +00:00
|
|
|
/*****************************************************************
|
|
|
|
* Neighbour tables specific messages.
|
|
|
|
*
|
|
|
|
* To retrieve the neighbour tables send RTM_GETNEIGHTBL with the
|
|
|
|
* NLM_F_DUMP flag set. Every neighbour table configuration is
|
|
|
|
* spread over multiple messages to avoid running into message
|
|
|
|
* size limits on systems with many interfaces. The first message
|
|
|
|
* in the sequence transports all not device specific data such as
|
|
|
|
* statistics, configuration, and the default parameter set.
|
|
|
|
* This message is followed by 0..n messages carrying device
|
|
|
|
* specific parameter sets.
|
|
|
|
* Although the ordering should be sufficient, NDTA_NAME can be
|
|
|
|
* used to identify sequences. The initial message can be identified
|
|
|
|
* by checking for NDTA_CONFIG. The device specific messages do
|
|
|
|
* not contain this TLV but have NDTPA_IFINDEX set to the
|
|
|
|
* corresponding interface index.
|
|
|
|
*
|
|
|
|
* To change neighbour table attributes, send RTM_SETNEIGHTBL
|
|
|
|
* with NDTA_NAME set. Changeable attribute include NDTA_THRESH[1-3],
|
|
|
|
* NDTA_GC_INTERVAL, and all TLVs in NDTA_PARMS unless marked
|
|
|
|
* otherwise. Device specific parameter sets can be changed by
|
|
|
|
* setting NDTPA_IFINDEX to the interface index of the corresponding
|
|
|
|
* device.
|
|
|
|
****/
|
|
|
|
|
2009-11-04 17:50:58 +00:00
|
|
|
struct ndt_stats {
|
2006-08-08 01:00:57 +00:00
|
|
|
__u64 ndts_allocs;
|
|
|
|
__u64 ndts_destroys;
|
|
|
|
__u64 ndts_hash_grows;
|
|
|
|
__u64 ndts_res_failed;
|
|
|
|
__u64 ndts_lookups;
|
|
|
|
__u64 ndts_hits;
|
|
|
|
__u64 ndts_rcv_probes_mcast;
|
|
|
|
__u64 ndts_rcv_probes_ucast;
|
|
|
|
__u64 ndts_periodic_gc_runs;
|
|
|
|
__u64 ndts_forced_gc_runs;
|
2015-08-07 18:10:37 +00:00
|
|
|
__u64 ndts_table_fulls;
|
2006-08-08 01:00:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
NDTPA_UNSPEC,
|
|
|
|
NDTPA_IFINDEX, /* u32, unchangeable */
|
|
|
|
NDTPA_REFCNT, /* u32, read-only */
|
|
|
|
NDTPA_REACHABLE_TIME, /* u64, read-only, msecs */
|
|
|
|
NDTPA_BASE_REACHABLE_TIME, /* u64, msecs */
|
|
|
|
NDTPA_RETRANS_TIME, /* u64, msecs */
|
|
|
|
NDTPA_GC_STALETIME, /* u64, msecs */
|
|
|
|
NDTPA_DELAY_PROBE_TIME, /* u64, msecs */
|
|
|
|
NDTPA_QUEUE_LEN, /* u32 */
|
|
|
|
NDTPA_APP_PROBES, /* u32 */
|
|
|
|
NDTPA_UCAST_PROBES, /* u32 */
|
|
|
|
NDTPA_MCAST_PROBES, /* u32 */
|
|
|
|
NDTPA_ANYCAST_DELAY, /* u64, msecs */
|
|
|
|
NDTPA_PROXY_DELAY, /* u64, msecs */
|
|
|
|
NDTPA_PROXY_QLEN, /* u32 */
|
|
|
|
NDTPA_LOCKTIME, /* u64, msecs */
|
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 12:07:14 +00:00
|
|
|
NDTPA_QUEUE_LENBYTES, /* u32 */
|
2015-03-19 13:41:46 +00:00
|
|
|
NDTPA_MCAST_REPROBES, /* u32 */
|
2016-04-22 15:31:21 +00:00
|
|
|
NDTPA_PAD,
|
2022-06-29 08:48:32 +00:00
|
|
|
NDTPA_INTERVAL_PROBE_TIME_MS, /* u64, msecs */
|
2006-08-08 01:00:57 +00:00
|
|
|
__NDTPA_MAX
|
|
|
|
};
|
|
|
|
#define NDTPA_MAX (__NDTPA_MAX - 1)
|
|
|
|
|
2009-11-04 17:50:58 +00:00
|
|
|
struct ndtmsg {
|
2006-08-08 01:00:57 +00:00
|
|
|
__u8 ndtm_family;
|
|
|
|
__u8 ndtm_pad1;
|
|
|
|
__u16 ndtm_pad2;
|
|
|
|
};
|
|
|
|
|
2009-11-04 17:50:58 +00:00
|
|
|
struct ndt_config {
|
2006-08-08 01:00:57 +00:00
|
|
|
__u16 ndtc_key_len;
|
|
|
|
__u16 ndtc_entry_size;
|
|
|
|
__u32 ndtc_entries;
|
|
|
|
__u32 ndtc_last_flush; /* delta to now in msecs */
|
|
|
|
__u32 ndtc_last_rand; /* delta to now in msecs */
|
|
|
|
__u32 ndtc_hash_rnd;
|
|
|
|
__u32 ndtc_hash_mask;
|
|
|
|
__u32 ndtc_hash_chain_gc;
|
|
|
|
__u32 ndtc_proxy_qlen;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
NDTA_UNSPEC,
|
|
|
|
NDTA_NAME, /* char *, unchangeable */
|
|
|
|
NDTA_THRESH1, /* u32 */
|
|
|
|
NDTA_THRESH2, /* u32 */
|
|
|
|
NDTA_THRESH3, /* u32 */
|
|
|
|
NDTA_CONFIG, /* struct ndt_config, read-only */
|
|
|
|
NDTA_PARMS, /* nested TLV NDTPA_* */
|
|
|
|
NDTA_STATS, /* struct ndt_stats, read-only */
|
|
|
|
NDTA_GC_INTERVAL, /* u64, msecs */
|
2016-04-22 15:31:21 +00:00
|
|
|
NDTA_PAD,
|
2006-08-08 01:00:57 +00:00
|
|
|
__NDTA_MAX
|
|
|
|
};
|
|
|
|
#define NDTA_MAX (__NDTA_MAX - 1)
|
|
|
|
|
2020-06-23 20:47:17 +00:00
|
|
|
/* FDB activity notification bits used in NFEA_ACTIVITY_NOTIFY:
|
|
|
|
* - FDB_NOTIFY_BIT - notify on activity/expire for any entry
|
|
|
|
* - FDB_NOTIFY_INACTIVE_BIT - mark as inactive to avoid multiple notifications
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
FDB_NOTIFY_BIT = (1 << 0),
|
|
|
|
FDB_NOTIFY_INACTIVE_BIT = (1 << 1)
|
|
|
|
};
|
|
|
|
|
2020-06-23 20:47:16 +00:00
|
|
|
/* embedded into NDA_FDB_EXT_ATTRS:
|
|
|
|
* [NDA_FDB_EXT_ATTRS] = {
|
2020-06-23 20:47:17 +00:00
|
|
|
* [NFEA_ACTIVITY_NOTIFY]
|
2020-06-23 20:47:16 +00:00
|
|
|
* ...
|
|
|
|
* }
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
NFEA_UNSPEC,
|
2020-06-23 20:47:17 +00:00
|
|
|
NFEA_ACTIVITY_NOTIFY,
|
2020-06-23 20:47:18 +00:00
|
|
|
NFEA_DONT_REFRESH,
|
2020-06-23 20:47:16 +00:00
|
|
|
__NFEA_MAX
|
|
|
|
};
|
|
|
|
#define NFEA_MAX (__NFEA_MAX - 1)
|
|
|
|
|
2006-08-08 00:57:44 +00:00
|
|
|
#endif
|