Put both paths to work.

Start with the work both paths do

Two working connections can support the operation every day. Where the network design and workload support load sharing, both paths contribute capacity. The team needs to understand how that capacity is used and whether the distribution meets the service requirement.

Existing configuration, utilisation records and service knowledge provide a starting point. Check which traffic can use each path, what limits its performance and how demand changes through the operating day. A configured path may carry little traffic; a busy one may have too little headroom for a change in demand.

That gives the team a practical basis for optimisation: improve how the available paths support the service, then verify the effect.

Check the capacity left during failure

Load sharing does not remove the need to examine failure. In the illustrative example, two paths each offer 100 units of usable capacity. They share 120 units of demand, carrying 60 units each.

If one path becomes unavailable, the other still offers 100 units. Twenty units of demand exceed that capacity. Successful switching to the remaining path would not, on its own, establish that the full service can continue.

Agree which workloads must keep running, what performance the operation needs and whether any reduction in service is acceptable. Then check the usable capacity, configuration and behaviour against those requirements.

Peak demand, application constraints and operating conditions belong in that assessment. Nominal link speed alone is insufficient evidence of the capacity available to the service.

Follow the paths into the physical environment

Both paths may carry traffic while still sharing a trench, power supply, site entry or intermediate facility. A failure at that dependency can affect both.

Bring provider records, drawings, site inspections and operating knowledge into the same assessment as configuration and utilisation. Keep the source and date of each contribution. Where the route or shared dependency remains uncertain, name the gap.

The service owner can then consider capacity, physical dependencies and operating requirements together. Load sharing explains how the service uses the paths; physical evidence helps establish which failures they could withstand.

Verify the benefit and keep it under review

Before changing the design, agree what should improve: the distribution of demand, available headroom, service performance or capacity during a defined failure. Include the operating window, fallback and authority to proceed.

After authorised work, collect fresh evidence. Check normal operation and the agreed failure conditions. Retain the measured result, the conditions of the test and what remains unresolved.

SignalFront draws value from the data your organisation already holds by connecting these views. Your team can see how the environment supports the service, where an improvement would help and whether the change achieved its purpose.

Revisit the conclusion when demand, routing, capacity or physical dependencies change. An ongoing understanding is useful only while its evidence still describes the operation.