--- layout: docs page_title: Gossip Protocol | Serf description: >- Consul agents manage membership and broadcast messages using the Serf protocol. Learn about the differences between LAN and WAN gossip pools and how `serfHealth` affects health checks. --- # Gossip Protocol Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) to manage membership and broadcast messages to the cluster. The protocol, membership management, and message broadcasting is provided through the [Serf library](https://www.serf.io/). The gossip protocol used by Serf is based on a modified version of the [SWIM (Scalable Weakly-consistent Infection-style Process Group Membership)](https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/SWIM.pdf) protocol. Refer to the [Serf documentation](https://www.serf.io/docs/internals/gossip.html) for additional information about the gossip protocol. ## Gossip in Consul Consul uses a LAN gossip pool and a WAN gossip pool to perform different functions. The pools are able to perform their functions by leveraging an embedded [Serf](https://www.serf.io/) library. The library is abstracted and masked by Consul to simplify the user experience, but developers may find it useful to understand how the library is leveraged. ### LAN Gossip Pool Each datacenter that Consul operates in has a LAN gossip pool containing all members of the datacenter (clients _and_ servers). Membership information provided by the LAN pool allows clients to automatically discover servers, reducing the amount of configuration needed. Failure detection is also distributed and shared by the entire cluster, instead of concentrated on a few servers. Lastly, the gossip pool allows for fast and reliable event broadcasts. ### WAN Gossip Pool The WAN pool is globally unique. All servers should participate in the WAN pool, regardless of datacenter. Membership information provided by the WAN pool allows servers to perform cross-datacenter requests. The integrated failure detection allows Consul to gracefully handle loss of connectivity--whether the loss is for an entire datacenter, or a single server in a remote datacenter. ## Lifeguard Enhancements ((#lifeguard)) SWIM assumes that the local node is healthy, meaning that soft real-time packet processing is possible. The assumption may be violated, however, if the local node experiences CPU or network exhaustion. In these cases, the `serfHealth` check status can flap. This can result in false monitoring alarms, additional telemetry noise, and CPU and network resources being wasted as they attempt to diagnose non-existent failures. Lifeguard completely resolves this issue with novel enhancements to SWIM. For more details about Lifeguard, please see the [Making Gossip More Robust with Lifeguard](https://www.hashicorp.com/blog/making-gossip-more-robust-with-lifeguard/) blog post, which provides a high level overview of the HashiCorp Research paper [Lifeguard : SWIM-ing with Situational Awareness](https://arxiv.org/abs/1707.00788). The [Serf gossip protocol guide](https://www.serf.io/docs/internals/gossip.html#lifeguard) also provides some lower-level details about the gossip protocol and Lifeguard.