How is the Apigee X /28 "Troubleshooting" IP Range used?

[rcooper3]

Step 4.3 of the Command line provisioning document states: 'Create a network IP range with a CIDR length of /28. This range is required and is used by Apigee for troubleshooting purposes and cannot be customized or changed.'

Is this range used for troubleshooting I would be performing myself? Or is it used by Google support?

Is it one /28 per Apigee Org or per Apigee Instance? 

I can specify a /22 for a new Apigee Instance but I cannot specify the /28. How does a new Apigee Instance identify the /28 to be used? 

[iambaskar · Accepted solution]

Recently (Jan, 2022), Apigee introduced a change in the network configuration to reduce the number of IPs required from the customer to manage the runtime instances. As part of that, customer can specify /22 range explicitly while creating an instance. However, we are still allocating an additional /28 range implicitly from any unassigned customer ranges for our internal usage, during the creation of every Apigee instance. 

Due to multiple requests, we are exploring ways for the customer to pass /28 range along with /22, so that all IP ranges will be explicit. (No external ETA on this  feature yet)

It is to be noted that even before this change (pre Jan, 2022), Apigee was using a /28 range from the larger block (like /16 to /20) customers were allocating to Apigee. 

Show More

Quoting from Public Document 

Note: In addition to the /22 range that is created, Apigee requires a non-overlapping, available /28 CIDR range. You created this /28 range in the previous step, Configure service networking. This /28 range is used by Apigee to access the instance for troubleshooting purposes and cannot be customized or changed. See also Creating instances.

[rcooper3]

May I confirm we would not expect to see network traffic to or from the /28 range in normal operation? 
i.e. Typical northbound/southbound traffic will utilize IPs within the /22 range

[strebel]

That is true for (PAID) Apigee instances you should see the northbound endpoint and the southbound source IP for internal traffic coming out of the /22 CIDR block you specified.

[rcooper3]

Should we expect to see a /28 under VPC network peering/Peering connection details/Imported Routes?

[strebel]

With an instance in a PAID organization you should see a /22 and for an EVAL you see a /28 being imported from the peering connection.

[iambaskar]

No. As we mentioned, the "/28" range for the paid orgs will be used for internal usage. So, they won't show up in the imported routes. As @strebel mentioned, only "/22" will be seen in the imported routes.

[rcooper3]

So if I create two /22 IP ranges and two /28 ranges associated with one peering network and then create two (paid) Apigee X Organisations pointing to the same peering network I can specify a /22 for the runtime instance in each org but I'll never know which /28 is used by which org. Would I only need one /28 in this scenario as both orgs may be able to use the same one without conflict? 

[iambaskar]

Yes, that is the problem we are trying to solve internally. Sooner (by Q2 approx), we will be able to provide an option for the customers to pass both /22 & /28 while creating the instances, so that it will be clear. 

You cannot share /28 with multiple instances / orgs. 

[rcooper3]

You cannot share /28 with multiple instances / orgs. 

- What stops this? Is there a VPC Peering or Apigee X process that understands when the IP range is already in use?