Back to Envoy

Original destination cluster configuration and testing

configs/original-dst-cluster/README.md

1.38.02.5 KB
Original Source

Original destination cluster configuration and testing

An original destination cluster forwards requests to the same destination the request was going to before being redirected to Envoy using an iptables REDIRECT rule. proxy_config.yaml contains an example Envoy configuration demonstrating the use of an original destination cluster. netns_setup.sh and netns_cleanup.sh are provided as examples for setting up and cleaning up, respectively, a network namespace and the required iptables rule to redirect traffic to Envoy.

Setting up

netns_setup.sh takes two arguments: the name of the new network namespace and the prefix that is to be redirected. Envoy listener port is set to 10000, which matches the configuration in proxy_config.yaml.

This creates a network namespace ns1 and redirects traffic from there to Envoy listening on port 10000 if the destination address of the traffic matches 173.194.222.0/24 :

sudo ./configs/original-dst-cluster/netns_setup.sh ns1 173.194.222.0/24

Building and running Envoy

Build Envoy with debug options, so that the behavior can be better observed from the logs:

bazel build //source/exe:envoy-static -c dbg

Then you should run Envoy with the provided example configuration:

bazel-out/local-dbg/bin/source/exe/envoy-static -c configs/original-dst-cluster/proxy_config.yaml -l debug

When running you should see periodical messages like Cleaning up stale original dst hosts.

Generating traffic

Next we generate traffic from the new network namespace hitting the redirect rule. Run this from another terminal:

sudo ip netns exec ns1 curl -v 173.194.222.106:80

Most likely you'll see 301 Moved in the curl response. In the rare case of upstream connection timeout you'll see 503 Service Unavailable instead. The connection timeout setting on the proxy_config.yaml is set to 6 seconds to make this less likely, but if no host with the destination address exist then you will get this response no matter how long the timeout setting.

You should see lines with Adding host 173.194.222.106:80 being logged by each Envoy thread, followed by Keeping active host 173.194.222.106:80 and eventually Removing stale host 173.194.222.106:80, again multiple times, once from each Envoy thread.

Cleaning up

To properly remove the added network namespace and the iptables configuration run netns_cleanup.sh with the same arguments as the setup before:

sudo ./configs/original-dst-cluster/netns_cleanup.sh ns1 173.194.222.0/24

Finally, stop Envoy with ^C.