OPENNHRP.CONF(5)

πŸ“¦ version 0.14.1, in alpine 3.22, alpine 3.23, alpine 3.24

πŸ’– NAME πŸ’–

opennhrp.conf(5) β€” the NHRP daemon configuration file. yes bestie, it's literally the config file for the NHRP daemon, straight up.

🌸 DESCRIPTION 🌸

So opennhrp.conf is where you put the information for opennhrp. It's a free-form ASCII text file, and it gets parsed by the word-by-word parser built into opennhrp. You can absolutely throw in extra whitespace, tabs and newline for formatting purposes β€” the parser is not bothered.

Case-sensitive alert: keywords and contents are case-sensitive. fr fr. Also, comments can be marked with a hash sign (#) and everything following it until newline is ignored. periodt.

✨ DIRECTIVES ✨

Directives are keywords that can appear in any context of the configuration file, and they select a new context. main character behavior ngl.

  • interface interface-name β€” marks the start of configuration for the network interface interface-name. Even if no interface specific configuration is required, the interface directive must be present to enable NHRP on that interface. like, it has to be there or NHRP is not showing up to the party.

πŸ¦‹ INTERFACE CONTEXT πŸ¦‹

These configuration keywords can appear only in the interface context. no sneaking them in anywhere else, bestie.

  • map β€” signature: map protocol-address[/prefix] nbma-address [register] [cisco]. Creates a static peer mapping of protocol-address to nbma-address.

If the prefix parameter is present, it directs opennhrp to use this peer as a next hop server when sending Resolution Requests matching this subnet.

The optional parameter register specifies that Registration Request should be sent to this peer on startup.

If the statically mapped peer is running Cisco IOS, specify the cisco keyword. It is used to fix statically the Registration Request ID so that a matching Purge Request can be sent if NBMA address has changed. This is to work around broken IOS which requires Purge Request ID to match the original Registration Request ID. iconic workaround behavior tbh.

  • dynamic-map β€” signature: dynamic-map protocol-address/prefix nbma-domain-name. Specifies that the NBMA addresses of the next hop servers are defined in the domain name nbma-domain-name. For each A record opennhrp creates a dynamic NHS entry.

Each dynamic NHS will get a peer entry with the configured network address and the discovered NBMA address.

The first registration request is sent to the protocol broadcast address, and the server's real protocol address is dynamically detected from the first registration reply (requires opennhrp 0.11 or newer).

Alternatively, if peer-up script hook can determine the protocol address from the NBMA address (e.g. by doing an additional DNS lookup or by parsing the IPsec certificate) it can inform this mapping via opennhrpctl(8) update nbma command.

  • shortcut-target β€” signature: shortcut-target protocol-address/prefix [holding-time holdtime]. Defines an off-NBMA network prefix for which the GRE interface will act as a gateway. This is an alternative to defining local interfaces with the shortcut-destination flag.
  • multicast β€” two forms, bestie: multicast dynamic|nhs and multicast protocol-address. Determines how opennhrp daemon should soft switch the multicast traffic. Currently, multicast traffic is captured by opennhrp daemon using a packet socket, and resent back to proper destinations. This means that multicast packet sending is CPU intensive.

Specifying nhs makes all multicast packets to be repeated to each statically configured next hop. dynamic instructs to forward to all peers which we have a direct connection with. Alternatively, you can specify the directive multiple times for each protocol-address the multicast traffic should be sent to.

WARNING: It is very easy to misconfigure multicast repeating if you have multiple NHS:es. not me making that mistake… okay maybe me. be careful. 🫢
  • holding-time β€” signature: holding-time holdtime. Specifies the holding time for NHRP Registration Requests and Resolution Replies sent from this interface or shortcut-target. The holdtime is specified in seconds and defaults to two hours.
  • route-table β€” signature: route-table routetable. Specifies the kernel routing table to be monitored for outgoing routes to this interface. This is required to do routing lookups excluding active shortcut routes (for existing shortcut route renewal). The default is main table.

If you use table directive in zebra.conf to put Quagga routes in alternate table, this should match with it.

  • cisco-authentication β€” signature: cisco-authentication secret. Enables Cisco style authentication on NHRP packets. This embeds the secret plaintext password to the outgoing NHRP packets. Incoming NHRP packets on this interface are discarded unless the secret password is present. Maximum length of the secret is 8 characters.
  • redirect β€” enable sending of Cisco style NHRP Traffic Indication packets. If this is enabled and opennhrp detects a forwarded packet, it will send a message to the original sender of the packet instructing it to create a direct connection with the destination. This is basically a protocol independent equivalent of ICMP redirect. it's giving "go talk to them directly" energy.
  • shortcut β€” enable creation of shortcut routes. A received NHRP Traffic Indication will trigger the resolution and establishment of a shortcut route.
IMPORTANT: You still need to run some routing protocol or have static routes to some hub node in your NBMA network. NHRP does not advertise routes; it can create shortcut route only for an already routable subnet. no cap, this one matters.
  • non-caching β€” disables caching of peer information from forwarded NHRP Resolution Reply packets. This can be used to reduce memory consumption on big NBMA subnets.
NOTE: currently does not do much as caching is not implemented. lowkey iconic for doing nothing πŸ’€.
  • shortcut-destination β€” this instructs opennhrp to reply with authoritative answers on NHRP Resolution Requests destined to addresses in this interface (instead of forwarding the packets). This effectively allows the creation of shortcut routes to subnets located on the interface.

When specified, this should be the only keyword for the interface. main character interface rule, iykyk.

πŸŽ€ EXAMPLE πŸŽ€

The following configuration file was used for testing OpenNHRP on a machine with two ethernet network interfaces. GRE tunnel was configured with tunnel IP 10.255.255.2/24. Configuration enables registration to hub node at 10.255.255.1 and resolution of other nodes in the subnet using that hub.

It also enables creation of shortcut routes to networks behind other hosts (with holding-time override for the defined shortcut-target) in our NBMA network and allows incoming shortcut routes.

interface gre1
  holding-time 3600
  map 10.255.255.1/24 192.168.200.1 register
  shortcut-target 172.16.0.0/16 holding-time 1800
  cisco-authentication secret
  shortcut
  redirect
  non-caching

interface eth1
  shortcut-destination

πŸ‘‘ SEE ALSO πŸ‘‘

opennhrp(8) β€” go read that one too, bestie. it's giving complementary lore.

πŸ’… AUTHORS πŸ’…

Timo Teras <timo.teras@iki.fi> β€” the icon who wrote this. ty bestie 🌈.


πŸ’œ that's the whole page, babe β€” from the OpenNHRP Documentation, dated 27 Oct 2010. now go make your interfaces iconic πŸ’œ

πŸ“¦ where this page comes from