Providing good test commands for cloud provisioning requests

When requesting a TIP, additional region or other major change to your existing Apigee Cloud organization(s), you may be requested to provide test curl commands. This article is intended to explain why these are necessary, what they are used for, and how to pick good test commands.

When a new TIP or region is set up, this requires configuration of new infrastructure within the Apigee Cloud. Until the new infrastructure is fully ready to take new traffic, API clients are blocked from sending traffic to it. In order to ensure the new infrastructure is ready to take traffic, Apigee needs to perform a range of tests to assess it's readiness.

In many cases, Target Servers used by existing API clients and proxies will have IP address allowlists and block unknown IPs. This new infrastructure will likely have new fixed southbound IP addresses and in the case of additional regions, potentially very different network routes to the Target Servers. For this reason it's important for Apigee to verify that network connectivity from your new infrastructure to your Target Servers (the dotted lines in the diagram below) is working before allowing API Clients to access the new infrastructure.

10036-infraoverview.png

The test curl commands that we request are used on the new Apigee infrastructure, before API clients are allowed to access it, to verify this network connectivity.

Now you understand the purpose of these commands, let's review the implications for choosing good test curl commands:

1) If you have multiple targets which are behind different firewalls or have significantly different routing (eg, different data centers) it's worth testing both because the network paths are independent.

2) Conversely, testing both /api/example/a and /api/example/b on the same target server adds no value as the network path will be the same.

3) Your test curls must access your target servers directly. If your test curl simply points at Apigee (ie, (org)-(env).apigee.net or a CNAME) then the test will jump from the new infrastructure to the old infrastructure and will not test the required network paths because the new infrastructure is not serving API clients yet:

10037-loopbackcurl.png

4) As the curl command is only intended to test network connectivity, curl commands which return an error (eg, 401 Unauthorized) are fine as long as you tell us the error is expected. This can be simpler than generating valid tokens for testing.

5) When requiring mTLS southbound, consider providing an openssl s_client command and the expected output instead of curl.

Version history
Last update:
‎06-21-2020 11:38 PM
Updated by: