README.nhrpd 5.0 KB

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