Showing 0 products

Frequently Asked Questions

Router or Layer 3 switch - what separates them?

A Layer 3 switch routes between internal networks very fast and does little else. A router connects to the outside world and does a great deal else, more slowly.

The switch is built around forwarding silicon: many ports, all the same media, routing at wire speed between internal subnets, and a limited set of wide-area features.

The router is built around interface variety and services: fibre and copper circuits, cellular modems, serial connections, and the processing to run encryption, network address translation, quality of service, deep packet inspection and complex policy. Its per-port throughput is lower because the work per packet is greater.

Most networks need both, and putting the work in the right place is the point. Inter-VLAN traffic belongs in the Layer 3 switch, where it is essentially free. Traffic leaving the site belongs in the router, where it can be encrypted, inspected and policed.

Using a router for internal routing is a classic cause of an unexplained bottleneck.

Why is quoted router throughput often unachievable?

Because the headline figure is measured with large packets and no features enabled, and neither condition resembles a live circuit.

Throughput tests typically use large frames, which is the most favourable case: a router does roughly the same work per packet regardless of size, so performance in packets per second is the real limit and small packets consume it far faster. Voice traffic is almost entirely small packets.

Features cost more still. Encryption, address translation, deep inspection, application recognition, quality of service and per-flow logging each add work. Turning on a full inspection profile can reduce throughput by most of its headline figure.

So read the data sheet for the figure that matches the intended configuration - manufacturers increasingly publish separate numbers for encrypted and inspected throughput - and size against that.

A useful rule is to size for the circuit you expect in three years with all intended features enabled, not the one you have today with none.

How many WAN connections should a site have?

Two wherever the site cannot tolerate an outage, and they should differ in more than the account name.

A second circuit from the same provider over the same physical route protects against equipment failure and nothing else. The failures that actually take sites off are cable damage and provider incidents, both of which affect every circuit sharing that path.

So diversity means a different provider where possible, a different physical entry to the building, and ideally a different technology - fibre primary with cellular backup is genuinely diverse and increasingly affordable.

Having two circuits is not the same as using them. The router must be configured to detect failure quickly and fail over, and that needs active probing rather than watching link state, since a circuit can be up and not passing traffic.

Test the failover deliberately and periodically. Untested failover fails about as often as it works, and the discovery is always at the worst moment.

What is SD-WAN in practical terms?

Central policy plus an overlay, so a site can use several ordinary internet circuits as if they were one managed network.

Traditionally a branch had a private circuit and a router configured by hand. SD-WAN replaces both. Each site builds encrypted tunnels over whatever transport it has, and a controller distributes the policy that decides which application uses which path.

The benefits are practical rather than theoretical: cheaper transport, because ordinary broadband can be used with the tunnel providing the privacy; per-application steering, so voice takes the low-latency path while backups take the cheap one; automatic failover between paths in sub-second time; and configuration from one console instead of one router at a time.

The costs are dependence on the controller, a subscription, and a troubleshooting model that requires the controller's own tooling.

It makes most sense above roughly ten sites. Below that the licensing often outweighs the saving.

What does NAT do and when is it a problem?

It translates private internal addresses to public ones so many devices can share few addresses - and it becomes a problem whenever something needs to be reached from outside, or when two networks overlap.

Outbound it is invisible: the router rewrites the source address and tracks the session so replies find their way back.

Inbound is where it bites. A server that must be reachable needs an explicit port forward or a static translation, and protocols that carry addresses inside the payload - some voice and video signalling in particular - break unless the router understands them.

Double NAT, where a router sits behind another router that is also translating, makes this worse and is common when a customer router is added behind an ISP-supplied gateway.

The other case is overlapping address ranges, which appears constantly when connecting two organisations or many identical machine networks. The usual answer is to translate one or both sides onto a neutral range at the tunnel, which works but must be documented or it becomes unmaintainable.

Which routing protocol should a site use?

Static routes for a single circuit, OSPF within an estate you control, BGP where you peer with someone else.

A site with one way out needs one default route. Adding a protocol adds nothing but complexity.

OSPF suits a multi-site estate over private links or tunnels, where routes should be learned rather than configured and failures should reroute automatically. It converges quickly and needs a straightforward area and addressing design.

BGP is the protocol for relationships across an administrative boundary: multiple internet providers with your own address space, a carrier's managed network, or a cloud interconnect. It is also increasingly used inside data centre fabrics for its scale and policy control.

Where tunnels are involved, check the router runs the protocol over them properly - some SD-WAN implementations use their own control plane instead and expect routes to be redistributed, which is a design decision rather than an afterthought.

What deserves a look before a router goes into service?

Interfaces and licences, failover, remote access, configuration backup and time synchronisation - in that order.

Confirm the physical interfaces match the circuits actually ordered, including the optics, and that any licence required for throughput or features is applied. Feature licensing on routers is a common cause of a device that cannot do what it was bought for.

Test failover by disconnecting the primary circuit, not by reading the configuration.

Ensure there is a path to manage the router when the primary circuit is down - a cellular interface, a console server, or an out-of-band connection. A router reachable only through the link it is meant to be restoring is a design fault.

Back up the configuration off the device and confirm it restores.

Set NTP. Without correct time, logs from the router cannot be correlated with anything else, and certificate-based tunnels fail in ways that are hard to diagnose.