1--- 2layout: "docs" 3page_title: "Gossip Protocol" 4sidebar_current: "docs-internals-gossip" 5description: |- 6 Consul uses a gossip protocol to manage membership and broadcast messages to the cluster. All of this is provided through the use of the Serf library. The gossip protocol used by Serf is based on SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol, with a few minor adaptations. 7--- 8 9# Gossip Protocol 10 11Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) 12to manage membership and broadcast messages to the cluster. All of this is provided 13through the use of the [Serf library](https://www.serf.io/). The gossip protocol 14used by Serf is based on 15["SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol"](http://www.cs.cornell.edu/info/projects/spinglass/public_pdfs/swim.pdf), 16with a few minor adaptations. There are more details about [Serf's protocol here](https://www.serf.io/docs/internals/gossip.html). 17 18## Gossip in Consul 19 20Consul makes use of two different gossip pools. We refer to each pool as the 21LAN or WAN pool respectively. Each datacenter Consul operates in has a LAN gossip pool 22containing all members of the datacenter, both clients and servers. The LAN pool is 23used for a few purposes. Membership information allows clients to automatically discover 24servers, reducing the amount of configuration needed. The distributed failure detection 25allows the work of failure detection to be shared by the entire cluster instead of 26concentrated on a few servers. Lastly, the gossip pool allows for reliable and fast 27event broadcasts. 28 29The WAN pool is globally unique, as all servers should participate in the WAN pool 30regardless of datacenter. Membership information provided by the WAN pool allows 31servers to perform cross datacenter requests. The integrated failure detection 32allows Consul to gracefully handle an entire datacenter losing connectivity, or just 33a single server in a remote datacenter. 34 35All of these features are provided by leveraging [Serf](https://www.serf.io/). It 36is used as an embedded library to provide these features. From a user perspective, 37this is not important, since the abstraction should be masked by Consul. It can be useful 38however as a developer to understand how this library is leveraged. 39 40<a name="lifeguard"></a> 41## Lifeguard Enhancements 42 43SWIM makes the assumption that the local node is healthy in the sense 44that soft real-time processing of packets is possible. However, in cases 45where the local node is experiencing CPU or network exhaustion this assumption 46can be violated. The result is that the `serfHealth` check status can 47occasionally flap, resulting in false monitoring alarms, adding noise to 48telemetry, and simply causing the overall cluster to waste CPU and network 49resources diagnosing a failure that may not truly exist. 50 51Lifeguard completely resolves this issue with novel enhancements to SWIM. 52 53For more details about Lifeguard, please see the 54[Making Gossip More Robust with Lifeguard](https://www.hashicorp.com/blog/making-gossip-more-robust-with-lifeguard/) 55blog post, which provides a high level overview of the HashiCorp Research paper 56[Lifeguard : SWIM-ing with Situational Awareness](https://arxiv.org/abs/1707.00788). The 57[Serf gossip protocol guide](https://www.serf.io/docs/internals/gossip.html#lifeguard) 58also provides some lower-level details about the gossip protocol and Lifeguard. 59