Why This Topic Matters
Network redundancy should be designed across multiple layers so a single switch, uplink, gateway or WAN failure does not cause a full outage.
Key Decision Points
Evaluate gateway redundancy with access/core design.
Verify redundant links do not share the same physical path.
Compare failover time with application tolerance.
Validate redundancy with regular outage tests.
Architecture and operating model
Network resilience starts with shared failures, not port count. Assess gateways, switches, uplinks, carriers, power and physical routes together. Convergence must fit application timeout and session behavior. An unused alternate path is not proof of its health.
- 1Shared-failure map
- 2Independent paths
- 3Detection/convergence
- 4Application continuity
Design parameters
- Shared-route risk
- Map devices, power, carrier and routes separately; two ports may share one failure.
- Convergence and transaction
- Time detection, routing changes and application retries separately.
- Addressing and routing
- Show subnet, gateway, routes and NAT scope separately. Validate DNS results alongside the actual path to the target IP.
- Redundant path
- Check that alternate paths do not share device, power or carrier failures. Measure transition time through the application.
- Transport capacity
- Evaluate port speed, uplink utilization, packet loss and queues together. One test flow may not represent total capacity.
- Operational visibility
- Monitor interface counters, adjacencies, error records and time synchronization. Maintain a normal-operation baseline.
Worked example
Two branch links entering through one conduit may both fail after a cable cut. Test gateway, uplink and carrier loss separately. Measure time to the first completed user operation after the alarm.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Ping returns but applications disconnect | Session state or connection targets may have changed. | Validate existing sessions and new transactions in the same failure test. |
| Local VLAN works, remote network fails | Gateway, routing, ACL or return-path issues may be involved. | Compare addressing, routes and policy records at both ends. |
| Small requests work, large transfers stall | MTU, packet loss and destination storage waits are possible distinctions. | Measure packet sizes and retransmissions; distinguish networking from storage waits. |
| Backup path exists but interruption is long | Detection, convergence, DNS or session renewal can extend interruption. | Record failure time and the first successful application operation using synchronized clocks. |
Acceptance checks
- Exercise alternate paths regularly to verify actual capacity and reachability.
- Test an access matrix covering allowed and denied network pairs.
- Exercise individual link and device failures separately.
- Record loss, latency and queue counters under peak load.
- Retain pre-change configuration and rollback steps.
- Verify appropriate separation of management access from user networks.
Related concepts
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
MTU along the path
MTU concerns packet size on a link; tunnelling and encapsulation headers can reduce space available for useful payload. Small requests working while large transfers stall may suggest an MTU issue, but this is not proof. TCP MSS and interface MTU are distinct. Compare both endpoints and tunnel interfaces. Identify the affected segment with controlled tests instead of changing every device, and remember that blocked ICMP error messages can complicate path-MTU discovery.
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
Latency distribution
Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.
Bandwidth and useful throughput
Link capacity differs from useful application throughput. Protocol headers, encryption, retransmissions, small files and storage waits reduce net transfer speed. Keep bits and bytes distinct: 1 Gbit/s corresponds to a theoretical 125 MB/s, not an application performance guarantee. Estimate transfer time as data size divided by measured useful throughput. Observe the network, source reads and destination writes together to locate the bottleneck. Consider temporary slowdowns and competing workloads as well as average speed.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Primary documentation
How This Content Was Prepared
Doz Teknoloji Technical Team
This content is based on the technical evaluation approach used across Doz Teknoloji's enterprise IT practice areas.
Technical criteria + primary sources
The topic was cross-checked against vendor documentation, publications from standards bodies and other relevant official technical sources.
Improve decision quality
This guide explains the technical term and the criteria to consider when making purchasing, architecture or operational decisions.
Related Services and Guides
Related Enterprise Solutions
Explore the related service and solution pages to plan implementation.
Let's Evaluate Your Technical Requirement
Share your current infrastructure, user count or technical objective and we can help clarify product, licensing or project scope.
Send a Technical Request