Edited Grade: 6 Verifying That NS1 Redistributes Traffic In this section, we describe how to verify that NS1 correctly redistributes traffic to an alternate PoP when the PoP nearest to the client is not operational. Note: In the setup in this guide, each of the three NGINX Plus instances corresponds to a PoP. There are three ways to indicate to NS1 that a PoP is down: Change the status of the NGINX Plus instance to Down in the NS1 A record Take down the servers in the proxied upstream group Cause traffic to exceed a configured threshold Verifying Traffic Redistribution When an NGINX Plus Instance Is Marked Down Here we verify that NS1 switches over to the next‑nearest NGINX Plus instance when we change the metadata on the nearest NGINX Plus instance to Down. On a host located in the US, run the following command to determine which site NS1 is returning as nearest. Correctly, it’s returning 10.10.10.1, the IP address of the NGINX Plus instance in the US. Copy $ nslookup nginxgslb.cf Server: 10.10.100.102 Address: 10.10.100.102#53 Non-authoritative answer: Name: nginxgslb.cf Address: 10.10.10.1 Change the Up/Down answer metadata on the US instance to Down (see Step 8 in Setting Up NS1). Wait one hour – because we didn’t change the default time-to-live (TTL) of 3600 seconds on the A record for nginxgslb.cf – and issue the nslookup command again. NS1 returns 10.10.10.2, the IP address of the NGINX Plus instance in Germany, which is now the nearest. Copy $ nslookup nginxgslb.cf Server: 10.10.100.102 Address: 10.10.100.102#53 Non-authoritative answer: Name: nginxgslb.cf Address: 10.10.10.2 Verifying Traffic Redistribution When an Upstream Group Is Down With our NGINX Plus instances (answers) connected to NS1 data feeds (see Step 2 in Installing the NS1 Agent), we can verify that NS1 redistributes traffic correctly when it receives data from the agent indicating that an upstream group is down. In the following example, it’s the my_backend group that goes down, as reported in the us-nginxgslb-datafeed feed. We run the following commands on a host located in the US. Query the NGINX Plus API to verify that the current status is up for the my_backend upstream group being proxied by the NGINX Plus instance in the US: Copy $ curl -X GET "127.0.0.1:8000/api//http/upstreams/my_backend/" -H "accept: application/json" | python -m json.tool | grep state "state": "up", Query the NS1 API to verify that NS1 also sees the US my_backend upstream group as up. (For details about this API call, see the NS1 documentation. If the page doesn’t scroll automatically to the relevant section, search for “Get active data feeds for a source”.) On the command line, and are the same values we included in the YAML file in Step 4 of Installing the NS1 Agent. The output includes a destinations entry for each data feed. Search for the one where the label field says us-nginxgslb-datafeed and verify that the up field in that entry says true. Copy $ curl -X GET -H 'X-NSONE-Key: ' https://api.nsone.net/v1/data/feeds/ | python -m json.tool [ ... { "destinations": [ { "destid": "", "desttype": "answer", "record": "" } ], "id": "", "data": { "up": "true" }, "config": { "label": "us-nginxgslb-datafeed" }, "name": "us-nginxgslb-datafeed" }, ... ] Determine which site NS1 is returning for hosts in the US. Correctly, it’s 10.10.10.1, the IP address of the US‑based NGINX Plus instance. Copy $ nslookup nginxgslb.cf Server: 10.10.100.102 Address: 10.10.100.102#53 Non-authoritative answer: Name: nginxgslb.cf Address: 10.10.10.1 Take down the servers in the my_backend upstream group. There are several ways to do this: Turn off the actual app on each server. On the NGINX Plus instance either change the app’s port number in the NGINX Plus configuration file to the wrong value, or use the server directive or the NGINX Plus API to set each server’s state to down. Repeat Step 1. The NGINX Plus API now reports the status as unhealthy. Copy $ curl -X GET "127.0.0.1:8000/api//http/upstreams/my_backend/" -H "accept: application/json" | python -m json.tool | grep state "state": "unhealthy", Repeat Step 2. The NS1 API now returns false in the up field. Copy $ curl -X GET -H 'X-NSONE-Key: ' https://api.nsone.net/v1/data/feeds/ | python -m json.tool [ ... { "destinations": [ { "destid": "", "desttype": "answer", "record": "" } ], "id": "", "data": { "up": "false" }, "config": { "label": "us-nginxgslb-datafeed" }, "name": "us-nginxgslb-datafeed" }, ... ] Wait an hour – because we didn’t change the default TTL of 3600 seconds on the A record for nginxgslb.cf – and repeat Step 3. NS1 returns 10.10.10.2, the IP address of the NGINX Plus instance in Germany, which is now the nearest to US‑based hosts. Copy $ nslookup nginxgslb.cf Server: 10.10.100.102 Address: 10.10.100.102#53 Non-authoritative answer: Name: nginxgslb.cf Address: 10.10.10.2