docs/gettingstarted/developers/fib20/neighbors.rst

   1 .. _neighbors:
   2
   3 Neighbours
   4 ^^^^^^^^^^^
   5
   6 .. figure:: /_images/ip-neighbor.png
   7
   8 Figure 1: Neighbour data model
   9
  10 Figure 1 shows the data model for IP neighbours. An IP neighbour contains the mapping
  11 between a peer, identified by an IPv4 or IPv6 address, and its MAC address on a given
  12 interface. An IP-table (VRF) is not part of the neighbour's
  13 data/identity. This is because the virtualisation of a router into
  14 different tables (VRFs) is performed at the interface level, i.e. an
  15 IP-table is bound to a particular interface. A neighbour, which is
  16 attached to an interface, is thus implicitly in that table, and
  17 only in that table. It is also worth noting that IP neighbours
  18 contribute forwarding for the egress direction, whereas an IP-table
  19 is an ingress only function.
  20
  21 The *ip_neighbor_t* represents the control-plane addition of the
  22 neighbour. The *ip_adjacency_t* contains the data derived from the *ip_neighbor_t* that is needed to
  23 forward packets to the peer. The additional data in the adjacency are the *rewrite*
  24 and the *link_type*. The *link_type* is a description of the protocol of the packets
  25 that will be forwarded with this adjacency; e.g. IPv4, IPv6 or MPLS. The *link_type*
  26 maps directly to the ether-type in an Ethernet header, or the protocol filed in a
  27 GRE header. The rewrite is a byte string representation of the header that will be
  28 prepended to the packet when it is sent to that peer. For Ethernet interfaces this
  29 is be the src,dst MAC and the ether-type. For LISP tunnels, the IP src,dst pair
  30 and the LISP header.
  31
  32 The *ip_neighbor_t* for an IPv4 peer (learned e.g. over ARP) will
  33 install a *link_type=IPv4* when the entry is created and a
  34 link_type=MPLS on demand (i.e. when a route with output labels resolves via the peer).
  35
  36 Adjacency
  37 ---------
  38
  39 There are three sub-types of adjacencies. Purists would argue that some
  40 of these sub-types are not really adjacencies but are instead other
  41 forms of DPOs, and it would be hard to argue against that, but
  42 historically (not just in VPP, but in the FIB implementations from
  43 which VPP draws on for some of its concepts), these have been modelled
  44 as adjacency types, the one thing they have in common is that they
  45 have an associated interface and are terminal. The [sub] sub-types are:
  46
  47 * A Neighbour Adjacency (key={interface, next-hop, link-type}). A
  48   representation of a peer on a link (as described above). A neighbour adjacency itself has
  49   two sub-types; terminal and mid-chain. When one speak of 'an
  50   adjacency' one is usually referring to a terminal neighbour
  51   sub-type. A mid-chain adjacency represents a neighbor on a virtual
  52   interface which relies on the FIB to perform further forwarding. This
  53   adjacency is thus not terminal for the FIB object graph but instead
  54   appears in the 'middle' (the term chain is a synonym for graph in
  55   some contexts).
  56   A neighbour adjacency can be in one of two states; complete and
  57   incomplete. A complete adjacency knows the rewrite string that
  58   should be used to reach the peer, an incomplete adjacency does
  59   not. If the adjacency was added as a result of the addition of an
  60   *ip_neighbor_t* then the adjacency will be complete (because the
  61   *ip_neighbor_t* knows the peer's MAC address). An incomplete
  62   adjacency is created on demand by the FIB when a route's path
  63   requires to resolve through such an adjacency. It is thus created in
  64   order to resolve the missing dependency, it will become complete
  65   once the *ip_neighbor_t* is discovered.
  66   In the forwarding path a complete adjacency will prepend the rewrite
  67   string and transmit on the egress interface, an incomplete adjacency
  68   will construct a ARP/ND request to resolve the peer's IP address.
  69
  70 * A Glean Adjacency (key={interface}). This is a representation of the need to discover
  71   a peer on the given interface. It is used when it is known that the
  72   packet is destined to an undiscoverd peer on that interface. The
  73   difference between the glean adjacency and an
  74   incomplete neighbour adjacency is that in the forwarding path the
  75   glean adjacency will construct an ARP/ND request for the peer as
  76   determined from the packet's destination address. The glean
  77   adjacency is used to resolve connected prefixes on multi-access
  78   interfaces.
  79
  80 * A Multicast Adjacency (key={interface}). This represents the need to send an IP
  81   multicast packet out of the adjacency's associated interface. Since
  82   IP multicast constructs the destination MAC address from the IP
  83   packet's destination/group address, the rewrite is always known and
  84   hence the adjacency is always complete.
  85
  86
  87 All adjacency types can be shared between routes, hence each type is
  88 stored in a DB whose key is appropriate for the type.