Mesh gateway, or multi-cluster gateways, is the Consul primitive that allows you to bridge traffic between two or more completely separate Consul service meshes securely and transparently across different network environments. The configuration for the service mesh needs to be written only in one location, and it gets federated and copied automatically to the other locations.

The gateway acts as a bridge between two locations: if one service wants to communicate to another service in another location, it does so through lightweight Envoy proxies. These proxies have no way of decrypting traffic, so the traffic between the services in two locations is done through the mTLS flowing through two gateways. Consul uses SNI headers inside HTTPS requests so the gateway can determine where to send the traffic. 

To enable a service so that it can use the mesh gateway, the service-defaults primitive uses a stanza called meshgateway to define the gateway, as shown in the following code:

kind = "service-defaults"
name = "web"
protocol = "http"
meshgateway = {
  mode = "local"
}

The mode has three values: local, remote, and none. Let's go over these now:

• With local mode, the service will communicate with the local gateway first, and the local gateway communicates with other cluster gateways, which then communicates to the upstream service.
• In remote mode, the local gateway is bypassed. It is like Egress, where we are able to communicate directly to the remote cluster gateways and then forward traffic to the destination service.

• In none mode, no gateway is used, and the outbound connection is made directly to the destination service.

In this chapter, we used the Consul web and api services to show you how traffic splitting and routing works. Let's assume that the Consul service web is running in one data center, dc1, and that the api service is running in another data center, dc2. We can use the Consul service-resolver primitive to route traffic between web and api through a virtual resolver, as shown here:

kind = "service-resolver"
name = "api"

redirect {
  service = "api"
  datacenter = "dc2"
}

Once we have defined this, the traffic will flow through the gateway between two data centers.

With the use of the Consul service-resolver primitive, it is possible to perform a service failover from one data center to another seamlessly. A mesh gateway provides a flat network without users having to worry about network routing rules. The Envoy proxy acts as a gateway so that it can route Consul Connect traffic across data centers using SNI headers. 

As an example, let's assume the dc1 data center has web and api services but that data center dc2 has only the api service. Cross-cluster and cross-cloud service failover can be provided through service-resolver. If the api service is not available in dc1, the failover will happen seamlessly and automatically in the api service in the dc2 data center: 

kind = "service-resolver"
name = "api"

failover = {
  "*"= {
    datacenter = ["dc2"]
  }
}

It should be noted that multiple data centers can also be defined in the datacenter field of the failover stanza in order to provide a robust high availability for the desired services in the service-resolver for the api service.