1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Quagga / NHRP Design and Configuration Notes
============================================
Quagga/NHRP is an NHRP (RFC2332) implementation for Linux. The primary
use case is to implement DMVPN. The aim is thus to be compatible with
Cisco DMVPN (and potentially with FlexVPN in the future).
Current Status
--------------
- IPsec integration with strongSwan (requires patched strongSwan)
- IPv4 over IPv4 NBMA GRE
- IPv6 over IPv4 NBMA GRE -- majority of code exist; but is not tested
- Spoke (NHC) functionality complete
- Hub (NHS) functionality complete
- Multicast support is not done yet
(so OSPF will not work, use BGP for now)
The code is not (yet) compatible with Cisco FlexVPN style DMVPN. It
would require relaying IKEv2 routing messages from strongSwan to nhrpd
and parsing that. It is doable, but not implemented for the time being.
Routing Design
--------------
In contrast to opennhrp routing design, Quagga/NHRP routes each NHRP
domain address individually (similar to Cisco FlexVPN).
To create NBMA GRE tunnel you might use following:
ip tunnel add gre1 mode gre key 42 ttl 64 dev eth0
ip addr add 10.255.255.2/32 dev gre1
ip link set gre1 up
This has two important differences compared to opennhrp setup:
1. The 'tunnel add' now specifies physical device binding. Quagga/NHRP
wants to know stable protocol address to NBMA address mapping. Thus,
add 'dev <physdev>' binding, or specify 'local <nbma-address>'. If
neither of this is specified, NHRP will not be enabled on the interface.
Alternatively you can skip 'dev' binding on tunnel if you allow
nhrpd to manage it using 'tunnel source' command (see below).
2. The 'addr add' now has host prefix. In opennhrp you would have used
the GRE subnet prefix length here instead, e.g. /24.
Quagga/NHRP will automatically create additional host routes pointing to
gre1 when a connection with these hosts is established. The gre1 subnet
should be announced by routing protocol. This allows routing protocol
to decide which is the closest hub and get the gre addresses' traffic.
The second benefit is that hubs can then easily exchange host prefixes
of directly connected gre addresses. And thus routing of gre addresses
inside hubs is based on routing protocol's shortest path choice -- not
on random choice from next hop server list.
Configuring nhrpd
-----------------
The configuration is done using vtysh, and most commands do what they
do in Cisco. As minimal configuration example one can do:
configure terminal
interface gre1
tunnel protection vici profile dmvpn
tunnel source eth0
ip nhrp network-id 1
ip nhrp shortcut
ip nhrp registration no-unique
ip nhrp nhs dynamic nbma hubs.example.com
There's important notes about the "ip nhrp nhs" command:
1. The 'dynamic' works only against Cisco (or nhrpd), but is not
compatible with opennhrp. To use dynamic detection of opennhrp hub's
protocol address use the GRE broadcast address there. For the above
example of 10.255.255.0/24 the configuration should read instead:
ip nhrp nhs 10.255.255.255 nbma hubs.example.com
2. nbma <FQDN> works like opennhrp dynamic-map. That is, all of the
A-records are configured as NBMA addresses of different hubs, and
each hub protocol address will be dynamically detected.
Hub functionality
-----------------
Sending Traffic Indication (redirect) notifications is now accomplished
using NFLOG.
Use:
iptables -A FORWARD -i gre1 -o gre1 \
-m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \
--hashlimit-mode srcip,dstip --hashlimit-srcmask 16 --hashlimit-dstmask 16 \
--hashlimit-name loglimit-0 -j NFLOG --nflog-group 1 --nflog-range 128
or similar to get rate-limited samples of the packets that match traffic
flow needing redirection. This kernel NFLOG target's nflog-group is configured
in global nhrp config with:
nhrp nflog-group 1
To start sending these traffic notices out from hubs, use the nhrp per-interface
directive:
ip nhrp redirect
opennhrp used PF_PACKET and tried to create packet filter to get only
the packets of interest. Though, this was bad if shortcut fails to
establish (remote policy, or both are behind NAT or restrictive
firewalls), all of the relayaed traffic would match always.
Getting information via vtysh
-----------------------------
Some commands of interest:
- show dmvpn
- show ip nhrp cache
- show ip nhrp shortcut
- show ip route nhrp
- clear ip nhrp cache
- clear ip nhrp shortcut
Integration with strongSwan
---------------------------
Contrary to opennhrp, Quagga/NHRP has tight integration with IKE daemon.
Currently strongSwan is supported using the VICI protocol. strongSwan
is connected using UNIX socket (default /var/run/charon.vici use configure
argument --with-vici-socket= to change).
Thus nhrpd needs to be run as user that can open that file.
Currently, you will need patched strongSwan. The working tree is at:
http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras
And the branch with patches against latest release are:
http://git.alpinelinux.org/cgit/user/tteras/strongswan/log/?h=tteras-release
|
