]>
Commit | Line | Data |
---|---|---|
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 | |
16 | @value{PACKAGE_NAME} nhrpd 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 | address-family ipv4 unicast | |
68 | network 172.16.0.0/16 | |
69 | redistribute nhrp | |
70 | exit-address-family | |
71 | @end group | |
72 | @end example | |
73 | ||
74 | ||
75 | @node Configuring NHRP | |
76 | @section Configuring NHRP | |
77 | ||
78 | FIXME | |
79 | ||
80 | @node Hub Functionality | |
81 | @section Hub Functionality | |
82 | ||
83 | In addition to routing nhrp redistributed host prefixes, the hub nodes | |
84 | are also responsible to send NHRP Traffic Indication messages that | |
85 | trigger creation of the shortcut tunnels. | |
86 | ||
87 | nhrpd sends Traffic Indication messages based on network traffic captured | |
88 | using NFLOG. Typically you want to send Traffic Indications for network | |
89 | traffic that is routed from gre1 back to gre1 in rate limited manner. | |
90 | This can be achieved with the following iptables rule. | |
91 | ||
92 | @example | |
93 | @group | |
94 | iptables -A FORWARD -i gre1 -o gre1 \ | |
95 | -m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \ | |
96 | --hashlimit-mode srcip,dstip --hashlimit-srcmask 24 --hashlimit-dstmask 24 \ | |
97 | --hashlimit-name loglimit-0 -j NFLOG --nflog-group 1 --nflog-range 128 | |
98 | @end group | |
99 | @end example | |
100 | ||
101 | You can fine tune the src/dstmask according to the prefix lengths you | |
102 | announce internal, add additional IP range matches, or rate limitation | |
103 | if needed. However, the above should be good in most cases. | |
104 | ||
105 | This kernel NFLOG target's nflog-group is configured in global nhrp config | |
106 | with: | |
107 | @example | |
108 | @group | |
109 | nhrp nflog-group 1 | |
110 | @end group | |
111 | @end example | |
112 | ||
113 | To start sending these traffic notices out from hubs, use the nhrp | |
114 | per-interface directive: | |
115 | @example | |
116 | @group | |
117 | interface gre1 | |
118 | ip nhrp redirect | |
119 | @end group | |
120 | @end example | |
121 | ||
122 | @node Integration with IKE | |
123 | @section Integration with IKE | |
124 | ||
125 | nhrpd needs tight integration with IKE daemon for various reasons. | |
126 | Currently only strongSwan is supported as IKE daemon. | |
127 | ||
128 | nhrpd connects to strongSwan using VICI protocol based on UNIX socket | |
129 | (hardcoded now as /var/run/charon.vici). | |
130 | ||
131 | strongSwan currently needs few patches applied. Please check out the | |
132 | @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release,release} | |
133 | and | |
134 | @uref{http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras,working tree} | |
135 | git repositories for the patches. | |
136 | ||
137 | @node NHRP Events | |
138 | @section NHRP Events | |
139 | ||
140 | FIXME | |
141 | ||
142 | @node Configuration Example | |
143 | @section Configuration Example | |
144 | ||
145 | FIXME |