Timo Teräs | b1887c8 | 2017-01-24 16:42:19 +0200 | [diff] [blame] | 1 | @cindex NHRP |
| 2 | @node NHRP |
| 3 | @chapter NHRP |
| 4 | |
| 5 | @command{nhrpd} is a daemon to support Next Hop Routing Protocol (NHRP). |
| 6 | NHRP is described in RFC2332. |
| 7 | |
| 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 |
| 13 | an intermediate hop. |
| 14 | |
| 15 | Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and Quagga nrhpd |
| 16 | implements this scenario. |
| 17 | |
| 18 | @menu |
| 19 | * Routing Design:: |
| 20 | * Configuring NHRP:: |
| 21 | * Hub Functionality:: |
| 22 | * Integration with IKE:: |
| 23 | * NHRP Events:: |
| 24 | * Configuration Example:: |
| 25 | @end menu |
| 26 | |
| 27 | @node Routing Design |
| 28 | @section Routing Design |
| 29 | |
| 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. |
| 34 | |
| 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. |
| 38 | |
| 39 | To create NBMA GRE tunnel you might use the following (linux terminal |
| 40 | commands): |
| 41 | @example |
| 42 | @group |
| 43 | ip tunnel add gre1 mode gre key 42 ttl 64 |
| 44 | ip addr add 10.255.255.2/32 dev gre1 |
| 45 | ip link set gre1 up |
| 46 | @end group |
| 47 | @end example |
| 48 | |
| 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. |
| 52 | |
| 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. |
| 57 | |
| 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. |
| 61 | |
| 62 | This can be achieved in hubs with the following bgp configuration (network |
| 63 | command defines the GRE subnet): |
| 64 | @example |
| 65 | @group |
| 66 | router bgp 65555 |
| 67 | network 172.16.0.0/16 |
| 68 | redistribute nhrp |
| 69 | @end group |
| 70 | @end example |
| 71 | |
| 72 | |
| 73 | @node Configuring NHRP |
| 74 | @section Configuring NHRP |
| 75 | |
| 76 | FIXME |
| 77 | |
| 78 | @node Hub Functionality |
| 79 | @section Hub Functionality |
| 80 | |
| 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. |
| 84 | |
| 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. |
| 89 | |
| 90 | @example |
| 91 | @group |
| 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 --hashlimit-dstmask 24 \ |
| 95 | --hashlimit-name loglimit-0 -j NFLOG --nflog-group 1 --nflog-range 128 |
| 96 | @end group |
| 97 | @end example |
| 98 | |
| 99 | You can fine tune the src/dstmask according to the prefix lengths you |
| 100 | announce internal, add additional IP range matches, or rate limitation |
| 101 | if needed. However, the above should be good in most cases. |
| 102 | |
| 103 | This kernel NFLOG target's nflog-group is configured in global nhrp config |
| 104 | with: |
| 105 | @example |
| 106 | @group |
| 107 | nhrp nflog-group 1 |
| 108 | @end group |
| 109 | @end example |
| 110 | |
| 111 | To start sending these traffic notices out from hubs, use the nhrp |
| 112 | per-interface directive: |
| 113 | @example |
| 114 | @group |
| 115 | interface gre1 |
| 116 | ip nhrp redirect |
| 117 | @end group |
| 118 | @end example |
| 119 | |
| 120 | @node Integration with IKE |
| 121 | @section Integration with IKE |
| 122 | |
| 123 | nhrpd needs tight integration with IKE daemon for various reasons. |
| 124 | Currently only strongSwan is supported as IKE daemon. |
| 125 | |
| 126 | nhrpd connects to strongSwan using VICI protocol based on UNIX socket |
| 127 | (hardcoded now as /var/run/charon.vici). |
| 128 | |
| 129 | strongSwan currently needs few patches applied. Please check out the |
| 130 | @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release,release} |
| 131 | and |
| 132 | @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras,working tree} |
| 133 | git repositories for the patches. |
| 134 | |
| 135 | @node NHRP Events |
| 136 | @section NHRP Events |
| 137 | |
| 138 | FIXME |
| 139 | |
| 140 | @node Configuration Example |
| 141 | @section Configuration Example |
| 142 | |
| 143 | FIXME |