README.nhrpd 4.9 KB

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