1--- 2layout: "docs" 3page_title: "Frequently Asked Questions" 4sidebar_current: "docs-faq" 5--- 6 7# Frequently Asked Questions 8 9## Q: What is Checkpoint? / Does Consul call home? 10 11Consul makes use of a HashiCorp service called [Checkpoint](http://checkpoint.hashicorp.com) 12which is used to check for updates and critical security bulletins. 13Only anonymous information, which cannot be used to identify the user or host, is 14sent to Checkpoint . An anonymous ID is sent which helps de-duplicate warning messages. 15This anonymous ID can be disabled. In fact, using the Checkpoint service is optional 16and can be disabled. 17 18See [`disable_anonymous_signature`](/docs/agent/options.html#disable_anonymous_signature) 19and [`disable_update_check`](/docs/agent/options.html#disable_update_check). 20 21## Q: Does Consul rely on UDP Broadcast or Multicast? 22 23Consul uses the [Serf](https://www.serf.io) gossip protocol which relies on 24TCP and UDP unicast. Broadcast and Multicast are rarely available in a multi-tenant 25or cloud network environment. For that reason, Consul and Serf were both 26designed to avoid any dependence on those capabilities. 27 28## Q: Is Consul eventually or strongly consistent? 29 30Consul has two important subsystems, the service catalog and the gossip protocol. 31The service catalog stores all the nodes, service instances, health check data, 32ACLs, and KV information. It is strongly consistent, and replicated 33using the [consensus protocol](/docs/internals/consensus.html). 34 35The [gossip protocol](/docs/internals/gossip.html) is used to track which 36nodes are part of the cluster and to detect a node or agent failure. This information 37is eventually consistent by nature. When the servers detects a change in membership, 38or receive a health update, they update the service catalog appropriately. 39 40Because of this split, the answer to the question is subtle. Almost all client APIs 41interact with the service catalog and are strongly consistent. Updates to the 42catalog may come via the gossip protocol which is eventually consistent, meaning 43the current state of the catalog can lag behind until the state is reconciled. 44 45## Q: Are _failed_ or _left_ nodes ever removed? 46 47To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_ 48states), Consul will automatically remove dead nodes out of the catalog. This 49process is called _reaping_. This is currently done on a configurable 50interval of 72 hours. Reaping is similar to leaving, causing all associated 51services to be deregistered. Changing the reap interval for aesthetic 52reasons to trim the number of _failed_ or _left_ nodes is not advised (nodes 53in the _failed_ or _left_ state do not cause any additional burden on 54Consul). 55 56## Q: Does Consul support delta updates for watchers or blocking queries? 57 58Consul does not currently support sending a delta or a change only response 59to a watcher or a blocking query. The API simply allows for an edge-trigger 60return with the full result. A client should keep the results of their last 61read and compute the delta client side. 62 63By design, Consul offloads this to clients instead of attempting to support 64the delta calculation. This avoids expensive state maintenance on the servers 65as well as race conditions between data updates and watch registrations. 66 67## Q: What network ports does Consul use? 68 69The [Ports Used](https://www.consul.io/docs/agent/options.html#ports) section of the Configuration documentation lists all ports that Consul uses. 70 71## Q: Does Consul require certain user process resource limits? 72 73There should be only a small number of open file descriptors required for a 74Consul client agent. The gossip layers perform transient connections with 75other nodes, each connection to the client agent (such as for a blocking 76query) will open a connection, and there will typically be connections to one 77of the Consul servers. A small number of file descriptors are also required 78for watch handlers, health checks, log files, and so on. 79 80For a Consul server agent, you should plan on the above requirements and 81an additional incoming connection from each of the nodes in the cluster. This 82should not be the common case, but in the worst case if there is a problem 83with the other servers you would expect the other client agents to all 84connect to a single server and so preparation for this possibility is helpful. 85 86The default ulimits are usually sufficient for Consul, but you should closely 87scrutinize your own environment's specific needs and identify the root cause 88of any excessive resource utilization before arbitrarily increasing the limits. 89 90## Q: What is the per-key value size limitation for Consul's key/value store? 91 92The limit on a key's value size is 512KB. This is strictly enforced and an 93HTTP 413 status will be returned to any client that attempts to store more 94than that limit in a value. It should be noted that the Consul key/value store 95is not designed to be used as a general purpose database. See 96[Server Performance](/docs/guides/performance.html) for more details. 97 98## Q: What data is replicated between Consul datacenters? 99 100In general, data is not replicated between different Consul datacenters. When a 101request is made for a resource in another datacenter, the local Consul servers forward 102an RPC request to the remote Consul servers for that resource and return the results. 103If the remote datacenter is not available, then those resources will also not be 104available, but that won't otherwise affect the local datacenter. There are some special 105situations where a limited subset of data can be replicated, such as with Consul's built-in 106[ACL replication](/docs/guides/acl.html#outages-and-acl-replication) capability, or 107external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate). 108