5 @command{nhrpd} is a daemon to support Next Hop Routing Protocol (NHRP).
6 NHRP is described in RFC2332.
8 NHRP is used to improve the efficiency of routing computer network
9 traffic over Non-Broadcast, Multiple Access (NBMA) Networks. NHRP provides
10 an ARP-like solution that allows a system to dynamically learn the NBMA
11 address of the other systems that are part of that network, allowing
12 these systems to directly communicate without requiring traffic to use
15 Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and Quagga nrhpd
16 implements this scenario.
22 * Integration with IKE::
24 * Configuration Example::
28 @section Routing Design
30 nhrpd never handles routing of prefixes itself. You need to run some
31 real routing protocol (e.g. BGP) to advertise routes over the tunnels.
32 What nhrpd does it establishes 'shortcut routes' that optimizes the
33 routing protocol to avoid going through extra nodes in NBMA GRE mesh.
35 nhrpd does route NHRP domain addresses individually using per-host prefixes.
36 This is similar to Cisco FlexVPN; but in contrast to opennhrp which uses
37 a generic subnet route.
39 To create NBMA GRE tunnel you might use the following (linux terminal
43 ip tunnel add gre1 mode gre key 42 ttl 64
44 ip addr add 10.255.255.2/32 dev gre1
49 Note that the IP-address is assigned as host prefix to gre1. nhrpd will
50 automatically create additional host routes pointing to gre1 when
51 a connection with these hosts is established.
53 The gre1 subnet prefix should be announced by routing protocol from the
54 hub nodes (e.g. BGP 'network' announce). This allows the routing protocol
55 to decide which is the closest hub and determine the relay hub on prefix
56 basis when direct tunnel is not established.
58 nhrpd will redistribute directly connected neighbors to zebra. Within
59 hub nodes, these routes should be internally redistributed using some
60 routing protocol (e.g. iBGP) to allow hubs to be able to relay all traffic.
62 This can be achieved in hubs with the following bgp configuration (network
63 command defines the GRE subnet):
73 @node Configuring NHRP
74 @section Configuring NHRP
78 @node Hub Functionality
79 @section Hub Functionality
81 In addition to routing nhrp redistributed host prefixes, the hub nodes
82 are also responsible to send NHRP Traffic Indication messages that
83 trigger creation of the shortcut tunnels.
85 nhrpd sends Traffic Indication messages based on network traffic captured
86 using NFLOG. Typically you want to send Traffic Indications for network
87 traffic that is routed from gre1 back to gre1 in rate limited manner.
88 This can be achieved with the following iptables rule.
92 iptables -A FORWARD -i gre1 -o gre1 \
93 -m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \
94 --hashlimit-mode srcip,dstip --hashlimit-srcmask 24 \
95 --hashlimit-dstmask 24 --hashlimit-name loglimit-0 \
96 -j NFLOG --nflog-group 1 --nflog-range 128
100 You can fine tune the src/dstmask according to the prefix lengths you
101 announce internal, add additional IP range matches, or rate limitation
102 if needed. However, the above should be good in most cases.
104 This kernel NFLOG target's nflog-group is configured in global nhrp config
112 To start sending these traffic notices out from hubs, use the nhrp
113 per-interface directive:
121 @node Integration with IKE
122 @section Integration with IKE
124 nhrpd needs tight integration with IKE daemon for various reasons.
125 Currently only strongSwan is supported as IKE daemon.
127 nhrpd connects to strongSwan using VICI protocol based on UNIX socket
128 (hardcoded now as /var/run/charon.vici).
130 strongSwan currently needs few patches applied. Please check out the
131 @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release,release}
133 @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras,working tree}
134 git repositories for the patches.
141 @node Configuration Example
142 @section Configuration Example