A Point Of Presence (POP) refers to the networking equipment responsible for handling traffic from The Internet and customer Direct Links. Each POP is connected to at least two others on our backend network
A Point of Delivery (POD) is a segmentation of our physical datacenters. Each POP will service several POD, although some POPs are standalone. These PODs are generally recognizable by their router in the datacenter.
SoftLayer_Location_Datacenter::getDatacenters will return a list of all Datacenters and with an objectMask, can return each datacenter’s routers.
Here, we have to force the API to use the SoftlLayer_Location_Datacenter objectMask instead of the default return type of SoftLayer_Location. That is why the objectMask is like mask(SoftLayer_Location_Datacenter)[
.
slcli -vvv call-api SoftLayer_Location_Datacenter getDatacenters --mask="mask(SoftLayer_Location_Datacenter)[backendHardwareRouters[id,hostname]]"
curl -u $SL_USER:$SL_APIKEY 'https://api.softlayer.com/rest/v3.1/SoftLayer_Location_Datacenter/getDatacenters.json?objectMask=mask%28SoftLayer_Location_Datacenter%29%5BbackendHardwareRouters%5Bid%2Chostname%5D%5D'
:............................:.........:..............:.......:..........:
: backendHardwareRouters : id : longName : name : statusId :
:............................:.........:..............:.......:..........:
: :..............:........: : 265592 : Amsterdam 1 : ams01 : 2 :
: : hostname : id : : : : : :
: :..............:........: : : : : :
: : bcr01a.ams01 : 117917 : : : : : :
: : bcr02a.ams01 : 190854 : : : : : :
: :..............:........: : : : : :
:............................:.........:..............:.......:..........:
bcr01a is Backend Customer Router 01a, so POD 1. bcr02a is Backend Customer Router 02a, so Pod 2.
Each router will also have a b
pair, but usually the API will only return the a
of the pair, which is what we need for ordering purposes.
Selecting the correct POD at order time is important if you need all of your servers in the same datacenter to be on the same vlan or IP subnet.
VLANs are a way to isolate network traffic between servers. Each network capable resource provisioned will have at least one VLAN per network (Public/Private). This is done automatically and in general, doesn’t need to be changed by the end user.
By default this feature is disabled, preventing servers in your account from communicating with each other over the private network if they are on different VLANs. However this can be enabled quite easily either in the portal, or with SoftLayer_Account::setVlanSpan
VLan Trunking (or tagging) allows a server’s network component to exist on multiple VLANs at the same time. This can only be done through the API.
Subnets exist on VLANs, and provide compute resources IP addresses to access the network. There are several different types of subnets to be concerned about.
These are used by our provisoining system to automatically give an IP address to a compute resource. NEVER manually distribute IP space from these subnets, it disrupt provisioning on your account since our system will not know if you are using an IP out of this subnet.
These subnets are routed to a specific IP address, and allow the server associated with the static IP to use all the ips in this subnet.
These subnets are routed to a VLAN, and allows any server on that vlan access to IP space here. You lose 3 IPs for the Network IP, Gateway Ip, and Broadcast Ip.