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