> For the complete documentation index, see [llms.txt](https://docs.colt.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.colt.net/on-demand/user-guides/resilience.md). # RESILIENCE At locations that are on-net for Colt (i.e. connected directly to the Colt fibre network), diversity between a pair of On Demand ports can be provided as an optional feature. Diversity is available in all Colt countries in Europe and North America. ### DIVERSITY On Demand ports can be provided with or without physical diversity – customers have the option to add the diversity feature when a new On Demand access port is requested. Where diversity is requested, the two ports in the diverse pair are provided across two separate fibre paths and equipment as a minimum. To provide additional resilience, the ports can also be provided in two physically separate PoP locations within the same building or two physically separate buildings. Diversity is a premium feature which attracts a higher charge on the 2nd port in the dual port pair, and any Ethernet, Internet or Cloud connections that are then attached to that port. Customers can build their own topologies as required. For example, a pair of diverse access ports at an A end enterprise building, virtual cloud ports in physically separate cloud on-ramp locations and a pair of circuit connections between the access ports and cloud ports. Port diversity is requested when a new access port is ordered. Customers are presented with three diversity options: | Option | Port ordering | Building | PoP | Interface | | ---------------------------- | ------------------- | ----------------- | ----------------- | ----------------- | | Diverse from existing | Two separate orders | Same or different | Same or different | Same or different | | Diverse from new (duplicate) | Single order | Same | Same | Same | | Diverse from new (custom) | Single order | Same or different | Same or different | Same or different | #### NO DIVERSITY Where a single port without diversity is required. #### DIVERSE FROM EXISTING PORT Where a new port is required that is diverse from an existing (live) port. Customers can use this option to request diversity from a port that is already live, or to place two port orders in quick succession and request diversity on the 2nd port (the “existing” port being the first request placed minutes earlier) #### DIVERSE FROM NEW PORT (DUPLICATE) Where two new ports are required, with identical settings (same location, same interface type). This option provides the same functionality as the “Diverse from existing” option, but via a simplified order journey (the location/interface details are only entered once) #### DIVERSE FROM NEW PORT (CUSTOM) Where two new ports are required via a single order, with different settings (e.g. a different location or interface type). Please note that diversity is not available on ports at offnet or hybrid on-net locations. #### Dual fibre routes Where dual fibre is already available at a building, the two fibre paths (one fibre path for port 1, the other for and port 2) will utilise the dual fibre routes into the building – customers do not need to specifically request it. Where dual fibre is not available, customers have two options – proceed without dual fibre or request a price for the dual fibre build. Where a price for dual fibre is requested, customers will receive an email with a link to the price details. The dual fibre request can then either be accepted (to initiate the order for two diverse ports with dual fibre routes enabled) or rejected. ### ETHERNET SERVICES To enable diversity on Ethernet point-to-point services, port diversity is required at both the A and B end locations (i.e. two "diverse pairs" of ports). Circuit connections requested between the diverse ports are delivered across Colt's mesh protected core network - so end-to-end diversity (via the access ports) & resilience (via the mesh protected core) is ultimately achieved. ### CLOUD ON DEMAND (MICROSOFT AZURE) Under the Azure ExpressRoute hosted model, a single ExpressRoute Service Key enables dual/resilient connectivity into Microsoft Azure via Handover into Microsoft Azure dual interconnects (NNIs) at a single data centre PoP. Customers can then choose to request dual On Demand connections from Colt (and benefit from the default resilience offered by Microsoft) or request a single connection. Where dual circuit connections are required, they can be presented on On Demand access ports with physical diversity. This provides a high level of end-to-end resilience (diverse access ports, mesh protected circuits across the Colt core, dual NNIs into Microsoft). Please note that a single On Demand Azure hosted cloud port supports either one or two circuit connections. A similar configuration can be supported for dedicated ports, based on two separate Azure dedicated cloud ports. The ExpressRoute Metro feature, which ensures the Microsoft NNIs used for handover are located in two physically separate data centres is also supported via On Demand. ### CLOUD ON DEMAND (AMAZON WEB SERVICES) Hosted connectivity into Amazon Web Services is based on a single circuit connection by default. Customers who want to achieve maximum resilience can request two separate hosted OD cloud ports (at different AWS PoP locations), access ports with diversity and two separate circuit connections. The concept is similar to the Ethernet scenario described above, but here the two AWS PoPs replace the diverse OD access ports at the B end location. ### CLOUD ON DEMAND (GOOGLE PARTNER INTERCONNECT) Connections into Google are based on a single circuit connection, provided with protection across the Colt core network and an unprotected access tail. Under the On Demand offering, there are three resilience options for Google: * Standard single circuit configuration * Dual circuit configuration (99.9% Google SLA) * 2 x dual circuit configuration (99.99% Google SLA) The options for the dual circuit configuration (equating to Google’s 99.9% SLA) are illustrated below. Both circuits need to connect to Google Cloud PoPs in the same city (e.g. London). ![](https://content.gitbook.com/content/VLSaOIDXVwkVeVU0OgDq/blobs/sMfVhy02jOpNKUVL7B5j/resiliance3.jpg) Note that the VLAN attachment (“pairing key”) should be assigned to Google Cloud PoPs in different zones (e.g. one VLAN attachment assigned to zone 1, the other in zone two). The quad circuit configuration (equating to Google’s 99.99% SLA) is achieved by duplicating the dual circuit configuration. ### IBM & ORACLE CLOUDS Coming soon! ### DEDICATED INTERNET ACCESS (DIA) SERVICES Dedicated Internet Access (DIA) connections are based on a single circuit connection by default, which is protected across the Colt core network. Similar to Ethernet On Demand services, DIA connections are delivered via an unprotected access tail in enterprise buildings and standard data centres and across a fully protected mesh into key data centres. At the A end customer premises (data centre or enterprise office), DIA connections can be terminated on On Demand access ports which have diversity enabled - giving a high level of end-to-end resilience (the only common point of failure is the SAR router providing access to the internet). SAR router diversity is planned as a future feature. ## QUESTIONS? WE'RE HERE TO HELP. Speak with one of our specialists today. We’re here to offer advice, provide further information and to answer any queries you may have. [Check your connectivity](https://www.colt.net/connect/) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.colt.net/on-demand/user-guides/resilience.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.