consul/website/content/docs/troubleshoot/faq.mdx

---
layout: docs
page_title: Frequently Asked Questions
sidebar_title: FAQ
---

# Frequently Asked Questions

## Consul on Kubernetes

### Q: Can I upgrade directly to a specific Helm chart version or should I upgrade one patch release at a time?

It is safe to upgrade directly to a specific version. Be sure to read the release notes for all versions you're upgrading
through and look for any breaking changes.

### Q: Can I upgrade in place or should I spin up a new Kubernetes cluster?

It is always safer to spin up a new Kubernetes cluster but that is not an
option for most teams. Consul supports [upgrading in place](/docs/k8s/upgrade).

Non-production environments should be upgraded first. If upgrading
a Consul version, Consul data should be [backed up](https://learn.hashicorp.com/tutorials/consul/kubernetes-disaster-recovery).

## Generic Consul Questions

### Q: What is Checkpoint? / Does Consul call home?

Consul makes use of a HashiCorp service called [Checkpoint](http://checkpoint.hashicorp.com)
which is used to check for updates and critical security bulletins.
Only anonymous information, which cannot be used to identify the user or host,
is sent to Checkpoint. An anonymous ID is sent which helps de-duplicate warning
messages.
This anonymous ID can be disabled. In fact, using the Checkpoint service is
optional and can be disabled.

See [`disable_anonymous_signature`](/docs/agent/options#disable_anonymous_signature)
and [`disable_update_check`](/docs/agent/options#disable_update_check).

### Q: Does Consul rely on UDP Broadcast or Multicast?

Consul uses the [Serf](https://www.serf.io) gossip protocol which relies on
TCP and UDP unicast. Broadcast and Multicast are rarely available in a
multi-tenant or cloud network environment. For that reason, Consul and Serf
were both designed to avoid any dependence on those capabilities.

### Q: Is Consul eventually or strongly consistent?

Consul has two important subsystems, the service catalog and the gossip
protocol.
The service catalog stores all the nodes, service instances, health check data,
ACLs, and KV information. It is strongly consistent, and replicated
using the [consensus protocol](/docs/internals/consensus).

The [gossip protocol](/docs/internals/gossip) is used to track which
nodes are part of the cluster and to detect a node or agent failure. This
information is eventually consistent by nature. When the servers detects a
change in membership, or receive a health update, they update the service
catalog appropriately.

Because of this split, the answer to the question is subtle. Almost all client
APIs interact with the service catalog and are strongly consistent. Updates to
the catalog may come via the gossip protocol which is eventually consistent
meaning the current state of the catalog can lag behind until the state is
reconciled.

### Q: Are _failed_ or _left_ nodes ever removed?

To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_
states), Consul will automatically remove dead nodes out of the catalog. This
process is called _reaping_. This is currently done on a configurable
interval of 72 hours. Reaping is similar to leaving, causing all associated
services to be deregistered. Changing the reap interval for aesthetic
reasons to trim the number of _failed_ or _left_ nodes is not advised (nodes
in the _failed_ or _left_ state do not cause any additional burden on
Consul).

### Q: Does Consul support delta updates for watchers or blocking queries?

Consul does not currently support sending a delta or a change only response
to a watcher or a blocking query. The API simply allows for an edge-trigger
return with the full result. A client should keep the results of their last
read and compute the delta client side.

By design, Consul offloads this to clients instead of attempting to support
the delta calculation. This avoids expensive state maintenance on the servers
as well as race conditions between data updates and watch registrations.

### Q: What network ports does Consul use?

The [Ports Used](/docs/agent/options#ports) section of the Configuration
documentation lists all ports that Consul uses.

### Q: Does Consul require certain user process resource limits?

There should be only a small number of open file descriptors required for a
Consul client agent. The gossip layers perform transient connections with
other nodes, each connection to the client agent (such as for a blocking
query) will open a connection, and there will typically be connections to one
of the Consul servers. A small number of file descriptors are also required
for watch handlers, health checks, log files, and so on.

For a Consul server agent, you should plan on the above requirements and
an additional incoming connection from each of the nodes in the cluster. This
should not be the common case, but in the worst case if there is a problem
with the other servers you would expect the other client agents to all
connect to a single server and so preparation for this possibility is helpful.

The default ulimits are usually sufficient for Consul, but you should closely
scrutinize your own environment's specific needs and identify the root cause
of any excessive resource utilization before arbitrarily increasing the limits.

### Q: What is the per-key value size limitation for Consul's key/value store?

The limit on a key's value size is 512KB. This is strictly enforced and an
HTTP 413 status will be returned to any client that attempts to store more
than that limit in a value. It should be noted that the Consul key/value store
is not designed to be used as a general purpose database. See
[Server Performance](/docs/install/performance) for more details.

### Q: What data is replicated between Consul datacenters?

In general, data is not replicated between different Consul datacenters. When a
request is made for a resource in another datacenter, the local Consul servers
forward an RPC request to the remote Consul servers for that resource and
return the results.
If the remote datacenter is not available, then those resources will also not be
available from that datacenter. That will not affect the requests to the local
datacenter. There are some special situations where a limited subset of data
can be replicated, such as with Consul's built-in
[ACL replication](https://learn.hashicorp.com/tutorials/consul/access-control-replication-multiple-datacenters)
capability, or external tools like
[consul-replicate](https://github.com/hashicorp/consul-replicate).

### Q: Can Consul natively handle protecting against other processes accessing Consul's memory state?

Consul does not provide built-in memory access protections, and doesn't
interact with the host system to change or manipulate
viewing and doesn't interact with the host system to change or manipulate
application security.

We recommend taking any precautions or remediation steps that you would
normally do for individual processes, based on your operating system.

Please see our
[Security Model](/docs/internals/security) for more information.

### Q: Are the Consul Docker Images OCI Compliant?

The official [Consul Docker image](https://hub.docker.com/_/consul/) uses
[Docker image schema](https://docs.docker.com/registry/spec/manifest-v2-2/) V2,
which is OCI Compliant. To check the docker images on Docker Hub, use the
command `docker manifest inspect consul` to inspect the manifest payload. The
`docker manifest inspect` may require you to enable experimental features to
use.

### Q: What browsers are supported by the Consul UI?

Consul currently supports all 'evergreen' browsers, as they are generally on
up-to-date versions. This means we support:

- Chrome
- Firefox
- Safari
- Microsoft Edge

We do not support Internet Explorer 11 (IE 11). Consul follows a similar
alignment with Microsoft's own stance on IE 11, found on their
[support website](https://support.microsoft.com/en-us/help/17454/lifecycle-faq-internet-explorer-and-edge).