Guides
Two Internet Links: Check Shared Dependencies Before Buying Backup
Compare the failure scenarios a second internet link could address, identify shared site and provider dependencies, and request evidence for failover.
DETIAN ICT · Tanzania & East Africa
Discuss your ICT project with DETIAN.
DETIAN ICT supports audiovisual, security, network and smart-building projects in Tanzania and East Africa, with design, equipment supply, installation and maintenance services.
Share your site location, required systems and available drawings or equipment list. Start a discussion about the work scope and the information still needed.
Name the interruption the second link should address
Before buying a second internet link, define which interruption it is meant to address and trace the dependencies of both proposed paths. A second service contract may leave the building entry, customer gateway, power supply or local network unchanged. The useful buying decision is whether the proposal addresses the required failure scenario, with evidence for the remaining path and the way traffic will use it.
Start with a business task: for example, allowing authorised staff to reach a specified hosted application when the primary access service is unavailable. Record the users, operating period, acceptable disruption and any reduced service the owner can accept. Keep those requirements separate from a general request for “backup internet”.
DETIAN’s network solutions and project services provide a route for discussing the customer-side network and its dependencies. Internet service, route information and provider commitments must come from the relevant service providers. This guide does not claim that DETIAN supplies a circuit or guarantees continuous connectivity.
Distinguish provider names from the actual paths
Ask each provider which parts of the proposed access route and termination arrangement it can confirm for the named site. Identify the service reference, scope of the confirmation, date and unresolved dependencies. Where detailed routing information is sensitive, request an appropriate written statement of separation and its limits through the agreed channel.
Lumen’s network-resiliency guidance explains that circuits sold by different carriers can share physical infrastructure, including a conduit. Carrier diversity and route diversity therefore answer different questions. This is a reason to request evidence for the actual services; it is not evidence that any particular East African provider shares, or separates, a route.
Record confirmed shared elements explicitly. Mark other elements “unverified” rather than treating a missing drawing as proof of independence. Different delivery technologies also need this review: they may change the access path while retaining site power, local equipment or an upstream dependency.
Use the circuit-handover guide to identify the provider/customer boundary and equipment ownership. The dependency comparison then follows the complete task through the customer network and both access options. A correct handover boundary is one input to that comparison.
Make a dependency row that can be checked
Create one row per relevant dependency: reference | role | primary path | proposed second path | evidence and date | status | unresolved owner. Useful statuses are confirmed shared, confirmed separate within the stated scope, and unverified. Keep the scope qualifier beside any claim of separation.
Include the approved user-to-network path, customer gateway or firewall, termination devices, building entry and on-site cable route, power arrangements, and the provider-side facts available to the project. Use stable identifiers so that two descriptions of the same cabinet or gateway are not mistaken for separate resources.
Add a separate row for the application or remote service that the task needs. If the destination service itself is unavailable, a second access link does not by itself resolve that condition. Ask the application owner about requirements that may differ between paths, such as approved source addresses or remote-access arrangements, without putting private configuration into the general worksheet.
The row describes dependencies, not a count of how reliable a system is. Four common elements are not a failure probability, and removing one shared element does not yield a percentage improvement. A technical assessment must consider the actual arrangement and the failures the owner wants to address.
Work through a fictional two-link proposal
Consider an invented office planning access to an approved hosted application. The following identifiers and route statements are assumptions for this exercise, not a real site survey or a DETIAN project. User devices, the destination application and dependencies outside the stated model are held unchanged and still require their own assessment.
Existing path A uses the site access switch S1, customer gateway G1, power arrangement P1, entry duct D1 and provider access segment A1. Proposed path B uses S1, G1, P1, D1 and provider access segment B1. Assume the project has evidence that A1 and B1 are separate within the specifically reviewed external segment; no broader upstream independence has been established.
The common set for A and B is S1, G1, P1 and D1: four modelled dependencies. The paperwork now names two providers, while the entry duct and the customer-side dependencies are still common. The proposal may address a failure confined to A1, subject to the remaining assumptions and traffic-switching capability; it does not remove D1 or G1 from the task.
Now consider alternative C. Its documented on-site path uses entry D2 and access segment C1, while retaining S1, G1 and P1. The common set for A and C is three modelled dependencies: S1, G1 and P1. D1 has been removed from that intersection. Provider-side independence outside the reviewed segments remains unverified.
That change gives the buyer a precise follow-up: if the requirement includes loss of D1, request evidence for the separate D2 path and its complete applicable scope. If the requirement includes loss of G1, both alternatives still leave that gap. Ask the designer for a proposal addressing the gateway dependency instead of treating the second circuit as the complete answer.
Review the proposal against specific failure scenarios
Scenario 1 — A failure confined to A1. In the fictional model, neither B nor C contains A1. A potential alternate path remains on paper, provided its own dependencies work. Record the separate question of whether the proposed equipment and policies will detect that failure and carry the required task over the alternate path.
Scenario 2 — D1 becomes unavailable. Both A and B include D1, so that pair provides no alternate path around the modelled duct failure. A plus C avoids this particular common element only if the claimed D2 arrangement is supported. This conclusion says nothing about unexamined shared routes elsewhere.
Scenario 3 — G1 becomes unavailable. All three paths include G1. Selecting B or C alone does not address that scenario. The same reasoning applies to S1 or P1 within this model. Record the gap and the owner’s decision about whether it must be addressed in the project.
Copyable comparison row: failure scenario | affected dependencies | remaining proposed path | evidence supporting that path | switching and application questions | accept, revise or unresolved. Keep the scenarios separate; passing the reasoning for one does not demonstrate the others.
This is a document-based exercise. It is not an instruction to interrupt a circuit, remove power or change routing. Any later demonstration needs an authorised method, suitable conditions and a recovery arrangement agreed by the responsible teams.
Ask how traffic and the business task will recover
Physical separation and traffic failover require separate evidence. Ask the designer how the proposed system recognises loss of service, selects the alternate path, treats existing sessions and returns traffic when the preferred service is available again. Identify the exact hardware, software and intended policy in the technical response.
Cisco Meraki’s connection-monitoring documentation illustrates why those questions matter: it distinguishes physical-link loss from loss of internet reachability, and describes different handling of existing and new traffic under different failover and failback modes. Those are product-specific behaviours. They do not establish the behaviour or switching time of an unspecified proposal.
Have the service owner define what counts as useful recovery. A new browser request, an existing remote session and an ongoing meeting are different task observations. Record the allowable interruption and what the user may need to do, based on the actual application and agreed design. A device status change alone does not show that the required task recovered.
Ask which activities must fit on the alternate service and which can be deferred. Request supported capacity, usage conditions and application-access assumptions for that requirement. A second link with unknown capacity or restrictions remains an unresolved proposal item even when its physical path is separate.
Request an evidence package that supports the purchase decision
Ask each supplier to answer the same dependency rows and failure scenarios. The response should state the confirmed scope, assumptions, excluded failures, customer work, proposed equipment and service responsibilities. Keep provider route statements separate from the integrator’s customer-network design and the application owner’s requirements.
For an agreed demonstration, retain the scenario, approved method reference, actual conditions, observers, task results and unresolved items. Distinguish design reasoning, supplier commitments and observed behaviour. If no demonstration has occurred, keep the outcome as proposed or unverified rather than calling failover successful.
Use the existing changeover process for any work affecting an operating site, including permission to interrupt service and the agreed recovery decision. Review the dependency record after a circuit migration, gateway replacement or route change, because earlier evidence may no longer describe the current arrangement.
If backup power is part of the proposed response, connect it to the specific devices and duration requirement. The separate UPS guide helps define that load and runtime discussion; having a UPS listed in an equipment schedule does not resolve every power dependency.
Bring DETIAN the task, paths and remaining gaps
Prepare the country and town, facility type, business task, existing service boundaries and a non-sensitive dependency sketch. Include the proposed second service, provider statements, required failure scenarios, acceptable disruption and the questions still awaiting an owner. Use the official contact route to agree how any detailed project records should be shared.
Contact DETIAN at [email protected] or +255 723 666 959 to discuss customer-network design, equipment, installation and support scope. Ask which dependencies and verification work can be assessed for the actual site. Provider availability, route separation, equipment compatibility, costs, delivery and recovery behaviour require project-specific confirmation.
