|
|
@@ -0,0 +1,143 @@
|
|
|
+@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
|
Timo Teräs