nhrpd/README.nhrpd

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