Frequent Asked Questions (FAQ)
Q: IS THERE REDUNDANCY BUILT INTO THE OPEN CLOUD EXCHANGE® NETWORK?
A: Yes. The Open Cloud Exchange is a dual-edge and dual-core configuration for all sites, which ensures full redundancy in the network and maximizes uptime. This includes our campus and national architecture where we always have at least two diverse routes between data centers. Note: when customers order two ports in the same market, which we strongly recommend, we will provision the ports on separate switches to ensure full diversity.
Q: DOES THE OPEN CLOUD EXCHANGE SUPPORT 802.1AD (AKA QINQ) ENCAPSULATION OR STACKED TAGS?
A: No. The Open Cloud Exchange only supports 802.1Q (aka dot1q).
Q: AFTER PROVISIONING MY EVC IN THE CORESITE SERVICE DELIVERY PLATFORM, WHICH VLAN SHOULD I USE WHEN CONFIGURING MY ROUTER?
A: Once an EVC has been provisioned, the buyer and target VLAN IDs will be provided. When setting up your own router, you will use the Buyer (your) VLAN ID. Note – when finalizing your peering sessions with some cloud providers, you will also need to know the Target (CSP) VLAN ID, which can be found in a confirmation email when your EVC is ordered and can also be found in the MyCoreSite customer service delivery platform on The Open Cloud Exchange Dashboard.
Q: DO YOU SUPPORT CONNECTIVITY BETWEEN OTHER CORESITE LOCATIONS AND MARKETS THROUGH THE OPEN CLOUD EXCHANGE?
A: Yes. Once connected to The Open Cloud Exchange, the buyer can provision EVCs to all CoreSite locations through our inter-market connectivity. This provides a convenient option to connect your deployments with CoreSite across the county, connect to diverse cloud regions / zones and gain access to CoreSite’s nationwide ecosystem.
Q: WHAT IF I WANT TO CONNECT TO A DIFFERENT OR DIVERSE CLOUD REGION?
A: Once connected to The Open Cloud Exchange you will have access to all CoreSite locations through our inter-market connectivity, which will allow you to connect to multiple cloud regions / locations. See tables below showing cloud regions by location.
Q: IS A BGP (BORDER GATEWAY PROTOCOL) SESSION ESTABLISHED WITH CORESITE?
A: No. A BGP session is stood up between the buyer and the target customers.
Q: IS THE OPEN CLOUD EXCHANGE MEF (METRO ETHERNET FORUM) COMPLIANT?
A: Yes. It is MEF 10.2 compliant using the UNI-to-UNI model.
Q: DOES THE OPEN CLOUD EXCHANGE SUPPORT PROTECTED PORTS (LAG / LACP)?
A: Yes. The Open Cloud Exchange supports dynamic LACP with the maximum of two ports in the LAG. LAG ports are set up as active / active.
Q: DO YOU SUPPORT JUMBO FRAMES? WHAT IS THE MAX MTU (MAXIMUM TRANSMISSION UNIT) SIZE?
A: Yes; the max MTU is 9100 bytes.
Q: DOES THE OPEN CLOUD EXCHANGE PROVIDE ANY SERVICE LEVEL GUARANTEES?
A: Yes. Services on the Open Cloud Exchange are backed by a 100% availability Service Level Guarantee. For other metrics such as frame loss and delay, CoreSite provides a target SLA.
Q: WHAT ARE THE SERVICE LEVEL TARGETS FOR THE OPEN CLOUD EXCHANGE?
A: The Open Cloud Exchange targets the below Service Level Targets. Please note: Service Level Agreements applicable to your use of OCX is governed by your MSA.
Metric | Target |
Frame Loss Ratio (FLR) | 0.01% |
Frame Delay (FD) | <2 ms |
Inter Frame Delay Variation (IFDV) | <0.5 ms |
Mean Time to Repair (MTTR) | 4 hours |
Q: WHAT CLOUD PROVIDERS AND AVAILABILITY ZONES CAN BE CONNECTED THROUGH THE OPEN CLOUD EXCHANGE AND INTER-MARKET CONNECTIVITY?
MICROSOFT EXPRESSROUTE | ||
CoreSite Locations | Azure Location | Local Azure Region |
CH1, CH2 | Chicago | North Central US |
DE1, DE2 | Denver | West Central US |
LA1, LA2, LA3 | Los Angeles | N/A |
NY1, NY2, BO1 | New York | N/A |
SV1, SV2, SV3, SV4, SV7, SV8 | Silicon Valley2 | West US |
VA1, VA2, VA3, DC1, DC2 | Washington DC2 | East US, East US2 |
AWS DIRECT CONNECT (HOSTED CONNECTIONS) | |
CoreSite Locations | Direct Connect Region |
NY1, NY2, BO1, VA1, VA2, VA3, DC1, DC2, MI | US East (N. Virginia) |
CH1, CH2 | US East (Ohio) |
LA1, LA2, LA3, SV1, SV2, SV3, SV4, SV7, SV8 | US West (N. California) |
DE1, DE2 | US West (Oregon |
GOOGLE CLOUD PLATFORM | |
CoreSite Locations | Cloud Interconnect Region |
LA1, LA2, LA3 | us-west2 (Los Angeles) |
DE1, DE2 | us-west4 (Las Vegas) |
VA1, VA2, VA3, DC1, DC2 | us-east4 (Virginia) |
SV1, SV2, SV3, SV4, SV7, SV8, SV9 | us-west1 (Oregon) |
CH1, CH2 | us-central1 (Iowa) |
ORACLE FAST CONNECT | |
CoreSite Locations | Cloud Interconnect Region |
LA1, LA2, LA3 | Phoenix, AZ |
VA1, VA2, VA3, DC1, DC2 | Ashburn, VA |
CH1, CH2 | Ashburn, VA |
RESTRICTED IP RANGES
When setting up dynamic routing, it is important to be aware of the restricted IP ranges that are not available for use. There are two IP address blocks that are restricted:
172.31.0.0 / 16 | This block is reserved for Virtual Router Loopback IP addresses. |
169.254.0.0 / 16 | This block is reserved for use of link-local IPv4 address space for BGP peering between virtual routers and the cloud provider infrastructure(s). |
