| @cindex NHRP |
| @node NHRP |
| @chapter NHRP |
| |
| @command{nhrpd} is a daemon to support Next Hop Routing Protocol (NHRP). |
| NHRP is described in RFC2332. |
| |
| NHRP is used to improve the efficiency of routing computer network |
| traffic over Non-Broadcast, Multiple Access (NBMA) Networks. NHRP provides |
| an ARP-like solution that allows a system to dynamically learn the NBMA |
| address of the other systems that are part of that network, allowing |
| these systems to directly communicate without requiring traffic to use |
| an intermediate hop. |
| |
| Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and Quagga nrhpd |
| implements this scenario. |
| |
| @menu |
| * Routing Design:: |
| * Configuring NHRP:: |
| * Hub Functionality:: |
| * Integration with IKE:: |
| * NHRP Events:: |
| * Configuration Example:: |
| @end menu |
| |
| @node Routing Design |
| @section Routing Design |
| |
| nhrpd never handles routing of prefixes itself. You need to run some |
| real routing protocol (e.g. BGP) to advertise routes over the tunnels. |
| What nhrpd does it establishes 'shortcut routes' that optimizes the |
| routing protocol to avoid going through extra nodes in NBMA GRE mesh. |
| |
| nhrpd does route NHRP domain addresses individually using per-host prefixes. |
| This is similar to Cisco FlexVPN; but in contrast to opennhrp which uses |
| a generic subnet route. |
| |
| To create NBMA GRE tunnel you might use the following (linux terminal |
| commands): |
| @example |
| @group |
| ip tunnel add gre1 mode gre key 42 ttl 64 |
| ip addr add 10.255.255.2/32 dev gre1 |
| ip link set gre1 up |
| @end group |
| @end example |
| |
| Note that the IP-address is assigned as host prefix to gre1. nhrpd will |
| automatically create additional host routes pointing to gre1 when |
| a connection with these hosts is established. |
| |
| The gre1 subnet prefix should be announced by routing protocol from the |
| hub nodes (e.g. BGP 'network' announce). This allows the routing protocol |
| to decide which is the closest hub and determine the relay hub on prefix |
| basis when direct tunnel is not established. |
| |
| nhrpd will redistribute directly connected neighbors to zebra. Within |
| hub nodes, these routes should be internally redistributed using some |
| routing protocol (e.g. iBGP) to allow hubs to be able to relay all traffic. |
| |
| This can be achieved in hubs with the following bgp configuration (network |
| command defines the GRE subnet): |
| @example |
| @group |
| router bgp 65555 |
| network 172.16.0.0/16 |
| redistribute nhrp |
| @end group |
| @end example |
| |
| |
| @node Configuring NHRP |
| @section Configuring NHRP |
| |
| FIXME |
| |
| @node Hub Functionality |
| @section Hub Functionality |
| |
| In addition to routing nhrp redistributed host prefixes, the hub nodes |
| are also responsible to send NHRP Traffic Indication messages that |
| trigger creation of the shortcut tunnels. |
| |
| nhrpd sends Traffic Indication messages based on network traffic captured |
| using NFLOG. Typically you want to send Traffic Indications for network |
| traffic that is routed from gre1 back to gre1 in rate limited manner. |
| This can be achieved with the following iptables rule. |
| |
| @example |
| @group |
| iptables -A FORWARD -i gre1 -o gre1 \ |
| -m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \ |
| --hashlimit-mode srcip,dstip --hashlimit-srcmask 24 --hashlimit-dstmask 24 \ |
| --hashlimit-name loglimit-0 -j NFLOG --nflog-group 1 --nflog-range 128 |
| @end group |
| @end example |
| |
| You can fine tune the src/dstmask according to the prefix lengths you |
| announce internal, add additional IP range matches, or rate limitation |
| if needed. However, the above should be good in most cases. |
| |
| This kernel NFLOG target's nflog-group is configured in global nhrp config |
| with: |
| @example |
| @group |
| nhrp nflog-group 1 |
| @end group |
| @end example |
| |
| To start sending these traffic notices out from hubs, use the nhrp |
| per-interface directive: |
| @example |
| @group |
| interface gre1 |
| ip nhrp redirect |
| @end group |
| @end example |
| |
| @node Integration with IKE |
| @section Integration with IKE |
| |
| nhrpd needs tight integration with IKE daemon for various reasons. |
| Currently only strongSwan is supported as IKE daemon. |
| |
| nhrpd connects to strongSwan using VICI protocol based on UNIX socket |
| (hardcoded now as /var/run/charon.vici). |
| |
| strongSwan currently needs few patches applied. Please check out the |
| @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release,release} |
| and |
| @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras,working tree} |
| git repositories for the patches. |
| |
| @node NHRP Events |
| @section NHRP Events |
| |
| FIXME |
| |
| @node Configuration Example |
| @section Configuration Example |
| |
| FIXME |