OCF_HEARTBEAT_ETHMON(7)

🌸 OCF_HEARTBEAT_ETHMON(7) 🌸

okay so bestie, you're reading the OCF_HEARTBEAT_ETHMON(7) page from the OCF resource agents manual, and honestly? it's giving network-vibes-check energy. let's get into it 💅

---

✨ NAME ✨

ocf_heartbeat_ethmonitor — literally just monitors network interfaces, no cap 🫶

---

✨ SYNOPSIS ✨

ethmonitor [start | stop | status | monitor | meta-data | validate-all]

---

✨ DESCRIPTION ✨

So the whole point is monitoring the vitality of a local network interface. Like, is this nic thriving or is it not okay 😭

You can set this RA up as a clone resource to monitor the network interfaces on different nodes — with the same interface name across all of them. And no, this is not related to the IP address or the network that a interface is configured on, so don't @ me about that 🙈

What you can do with it: use this RA to move resources away from a node that has a faulty interface, or to prevent resources from moving to such a node. That gives you independent control of the resources, without involving cluster intercommunication. But — and this is the catch — it requires your nodes to have more than one network interface. periodt 💀

⚠️ Your resource configuration requires a monitor operation, because the monitor is the one doing the main part of the work. No monitor, no vibes.

On top of the resource config, you also need to configure some location constraints, based on a CIB attribute value. The name of that attribute value is configured in the name option of this RA. iykyk ✨

Example constraint configuration using crmsh:

location loc_connected_node my_resource_grp rule ="rule_loc_connected_node" -INF: ethmonitor eq 0

Example constraint configuration using pcs. Only allow my_resource to run on nodes where the eth0 ethernet device is available:

pcs constraint location my_resource rule score=-INFINITY ethmonitor-eth0 ne 1

The ethmonitor works in 3 different modes to test the interface vitality — but like, there are four things listed, we don't make the rules 🧚

1. call ip to see if the link status is up (if link is down -> error)
2. call ip and watch the RX counter (if packages come around in a certain time -> success)
3. call arping to check whether any of the IPs found in the local ARP cache answers an ARP REQUEST (one answer -> success)
4. return error

---

✨ SUPPORTED PARAMETERS ✨

• interface — the name of the network interface that should be monitored (e.g. eth0). (unique, required, string, no default) 👑
• name — the name of the CIB attribute to set. This is the name to be used in the constraints. Defaults to "ethmonitor-'interface_name'". (unique, optional, string, no default)
• multiplier — multiplier for the value of the CIB attriobute specified in parameter name (yes that's the manpage's spelling, not mine, I would never 😭). (optional, integer, default 1)
• repeat_count — specify how often the interface will be monitored, before the status is set to failed. You need to set the timeout of the monitoring operation to at least repeat_count * repeat_interval. (optional, integer, default 5)
• repeat_interval — specify how long to wait in seconds between the repeat_counts. (optional, integer, default 10)
• pktcnt_timeout — timeout for the RX packet counter. Stop listening for packet counter changes after the given number of seconds. (optional, integer, default 5)
• arping_count — number of ARP REQUEST packets to send for every IP. Usually one ARP REQUEST (arping) is send 🦋 (optional, integer, default 1)
• arping_timeout — time in seconds to wait for ARP REQUESTs (all packets of arping_count). This is to limit the time for arp requests, so you can send requests to more than one node without running in the monitor operation timeout. (optional, integer, default 1)
• arping_cache_entries — maximum number of IPs from the ARP cache list to check for ARP REQUEST (arping) answers. Newest entries are tried first. (optional, integer, default 5)
• infiniband_device — for interfaces that are infiniband devices. (optional, string, no default)
• infiniband_port — for infiniband devices, this is the port to monitor. (optional, integer, no default)
• link_status_only — only report success based on link status. Do not perform RX counter or arping related connectivity tests. (optional, boolean, default false)

---

✨ SUPPORTED ACTIONS ✨

This resource agent supports the following actions (operations) — here's the whole lineup bestie 💖

• start — starts the resource. Suggested minimum timeout: 60s.
• stop — stops the resource. Suggested minimum timeout: 20s.
• status — performs a status check. Suggested minimum timeout: 60s. Suggested interval: 10s.
• monitor — performs a detailed status check. Suggested minimum timeout: 60s. Suggested interval: 10s. (this is the main character, remember? 👑)
• meta-data — retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.
• validate-all — performs a validation of the resource configuration. Suggested minimum timeout: 20s.

---

✨ EXAMPLE CRM SHELL ✨

The following is an example configuration for a ethmonitor resource using the crm(8) shell:

primitive p_ethmonitor ocf:heartbeat:ethmonitor \
  params \
    interface=string \
  op monitor depth="0" timeout="60s" interval="10s"

---

✨ EXAMPLE PCS ✨

The following is an example configuration for a ethmonitor resource using pcs(8):

pcs resource create p_ethmonitor ocf:heartbeat:ethmonitor \
  interface=string \
  op monitor OCF_CHECK_LEVEL="0" timeout="60s" interval="10s"

---

✨ SEE ALSO ✨

• http://clusterlabs.org/ 🌈

---

✨ AUTHOR ✨

ClusterLabs contributors (see the resource agent source for information about individual authors) 🫶

---

anyway that's the whole page, ily, go monitor some interfaces and slay 💜✨

resource-agents version UNKNOWN, dated 10/01/2026 — that's the sign-off bestie, we're done here 🎀🦋