/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ #ifndef __LINUX_NEIGHBOUR_H #define __LINUX_NEIGHBOUR_H #include <linux/types.h> #include <linux/netlink.h> struct ndmsg { … }; enum { … }; #define NDA_MAX … /* * Neighbor Cache Entry Flags */ #define NTF_USE … #define NTF_SELF … #define NTF_MASTER … #define NTF_PROXY … #define NTF_EXT_LEARNED … #define NTF_OFFLOADED … #define NTF_STICKY … #define NTF_ROUTER … /* Extended flags under NDA_FLAGS_EXT: */ #define NTF_EXT_MANAGED … #define NTF_EXT_LOCKED … /* * Neighbor Cache Entry States. */ #define NUD_INCOMPLETE … #define NUD_REACHABLE … #define NUD_STALE … #define NUD_DELAY … #define NUD_PROBE … #define NUD_FAILED … /* Dummy states */ #define NUD_NOARP … #define NUD_PERMANENT … #define NUD_NONE … /* 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). * * 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. * * 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. * * 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. */ struct nda_cacheinfo { … }; /***************************************************************** * 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. ****/ struct ndt_stats { … }; enum { … }; #define NDTPA_MAX … struct ndtmsg { … }; struct ndt_config { … }; enum { … }; #define NDTA_MAX … /* 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 { … }; /* embedded into NDA_FDB_EXT_ATTRS: * [NDA_FDB_EXT_ATTRS] = { * [NFEA_ACTIVITY_NOTIFY] * ... * } */ enum { … }; #define NFEA_MAX … #endif
Codebase Browser
linux