Hi Eyal,

Some background info on routes, domains, the system domain, and apps
domains.

Cloud Foundry deployments include a component called the gorouter. It
essentially holds a routing table (actually a trie) in memory that maps
routes to IPs and ports. So "foo.mysystemdomain.com" might map to some
collection of IPs and ports, and "bar.myappsdomain.com" can map to other
IPs and ports. All publicly routable things in cloud foundry typically
have a route registered on their behalf with the gorouter. This includes
system components, like cloud controller, as well as all (routable) apps
pushed to the CF platform by developers.

The gorouter doesn't have a notion of domain ownership, but a platform
operator might want to make sure that an app developer doesn't try to claim
the same route as the Cloud Controller. And since CF is designed for
multitenancy, one organization might have their own custom app domain, and
may want to make sure other organizations can't use the same app domain for
their application routes.

A typical pattern to deal with this is to have all system components (CC,
UAA, etc.) that need to register routes to do so using routes that use a
special "system domain" that will not be accessible to user applications.
"domains" are owned by "organizations" in the cloud controller view of the
world, so typically a "dummy" system organization is created to own the
system domain, and this prevents it from being used by any other orgs that
users create. In practice, this "dummy" org is not a dummy, and actually
used for applications, e.g. if your Cloud Foundry installation has a custom
user portal, e.g. https://console.run.pivotal.io.

Separate from system components, users' applications also need routes. By
default, they will be given a route of the form
${app_name}.${default_shared_app_domain}. While it's technically possible
to use the same domain for the apps domain and system domain, it's not
recommended, because then random users could push an app called "api" for
example, and the gorouter would balance traffic intended for the CC between
the CC and this random app.

If you search http://docs.cloudfoundry.org/deploying/aws/cf-stub.html for
"system_domain" you can see editing instructions that recommend how to set
system domain and apps domains. In your case, I would recommend:

system_domain: sys.10.60.18.186.xip.io
app_domains:
- apps.10.60.18.186.xip.io

If you update your stub thusly, you then need to regenerate your manifest
and redeploy to make sure this has all been updated across the board. The
fact that your output shows "login.sysdomain.10.60.18.186.xip.io" and "
api.10.60.18.186.xip.io" suggest there's something inconsistent about how
the system domain is being used throughout your manifest. If you follow
the above recommendations, you would use

cf api api.sys.api.10.60.18.186.xip.io --skip-ssl-validation

Best,
Amit
<http://docs.cloudfoundry.org/deploying/aws/cf-stub.html>