doc/user/nhrpd.rst

   1 .. _NHRP:
   2
   3 ****
   4 NHRP
   5 ****
   6
   7 *nhrpd* is an implementation of the :abbr:NHRP `(Next Hop Routing Protocol)`.
   8 NHRP is described in :rfc`2332`.
   9
  10 NHRP is used to improve the efficiency of routing computer network traffic over
  11 :abbr:`NBMA (Non-Broadcast, Multiple Access)` networks. NHRP provides an
  12 ARP-like solution that allows a system to dynamically learn the NBMA address of
  13 the other systems that are part of that network, allowing these systems to
  14 directly communicate without requiring traffic to use an intermediate hop.
  15
  16 Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and |PACKAGE_NAME| nhrpd
  17 implements this scenario.
  18
  19 .. _Routing_Design:
  20
  21 Routing Design
  22 ==============
  23
  24 nhrpd never handles routing of prefixes itself. You need to run some
  25 real routing protocol (e.g. BGP) to advertise routes over the tunnels.
  26 What nhrpd does it establishes 'shortcut routes' that optimizes the
  27 routing protocol to avoid going through extra nodes in NBMA GRE mesh.
  28
  29 nhrpd does route NHRP domain addresses individually using per-host prefixes.
  30 This is similar to Cisco FlexVPN; but in contrast to opennhrp which uses
  31 a generic subnet route.
  32
  33 To create NBMA GRE tunnel you might use the following (Linux terminal
  34 commands):::
  35
  36    ip tunnel add gre1 mode gre key 42 ttl 64
  37    ip addr add 10.255.255.2/32 dev gre1
  38    ip link set gre1 up
  39
  40
  41 Note that the IP-address is assigned as host prefix to gre1. nhrpd will
  42 automatically create additional host routes pointing to gre1 when
  43 a connection with these hosts is established.
  44
  45 The gre1 subnet prefix should be announced by routing protocol from the
  46 hub nodes (e.g. BGP 'network' announce). This allows the routing protocol
  47 to decide which is the closest hub and determine the relay hub on prefix
  48 basis when direct tunnel is not established.
  49
  50 nhrpd will redistribute directly connected neighbors to zebra. Within
  51 hub nodes, these routes should be internally redistributed using some
  52 routing protocol (e.g. iBGP) to allow hubs to be able to relay all traffic.
  53
  54 This can be achieved in hubs with the following bgp configuration (network
  55 command defines the GRE subnet):::
  56
  57   router bgp 65555
  58    address-family ipv4 unicast
  59      network 172.16.0.0/16
  60      redistribute nhrp
  61    exit-address-family
  62
  63
  64 .. _Configuring_NHRP:
  65
  66 Configuring NHRP
  67 ================
  68
  69 FIXME
  70
  71 .. _Hub_Functionality:
  72
  73 Hub Functionality
  74 =================
  75
  76 In addition to routing nhrp redistributed host prefixes, the hub nodes
  77 are also responsible to send NHRP Traffic Indication messages that
  78 trigger creation of the shortcut tunnels.
  79
  80 nhrpd sends Traffic Indication messages based on network traffic captured
  81 using NFLOG. Typically you want to send Traffic Indications for network
  82 traffic that is routed from gre1 back to gre1 in rate limited manner.
  83 This can be achieved with the following iptables rule.
  84
  85 ::
  86
  87   iptables -A FORWARD -i gre1 -o gre1 \\
  88         -m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \\
  89         --hashlimit-mode srcip,dstip --hashlimit-srcmask 24 --hashlimit-dstmask 24 \\
  90         --hashlimit-name loglimit-0 -j NFLOG --nflog-group 1 --nflog-range 128
  91
  92
  93 You can fine tune the src/dstmask according to the prefix lengths you
  94 announce internal, add additional IP range matches, or rate limitation
  95 if needed. However, the above should be good in most cases.
  96
  97 This kernel NFLOG target's nflog-group is configured in global nhrp config
  98 with:::
  99
 100   nhrp nflog-group 1
 101
 102 To start sending these traffic notices out from hubs, use the nhrp
 103 per-interface directive:::
 104
 105   interface gre1
 106    ip nhrp redirect
 107
 108 .. _Integration_with_IKE:
 109
 110 Integration with IKE
 111 ====================
 112
 113 nhrpd needs tight integration with IKE daemon for various reasons.
 114 Currently only strongSwan is supported as IKE daemon.
 115
 116 nhrpd connects to strongSwan using VICI protocol based on UNIX socket
 117 (hardcoded now as /var/run/charon.vici).
 118
 119 strongSwan currently needs few patches applied. Please check out the
 120 `http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release,release <http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release,release>`_
 121 and
 122 `http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras,working tree <http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras,working tree>`_
 123 git repositories for the patches.
 124
 125 .. _NHRP_Events:
 126
 127 NHRP Events
 128 ===========
 129
 130 FIXME
 131
 132 Configuration Example
 133 =====================
 134
 135 FIXME
 136