Routing & Routing Protocols

Part Fourteen: Layer 3 and Routing Fundamentals

The topic

Layer 3 is where traffic moves between different networks. A switch connects devices within a network; a router connects networks to each other and decides, for every packet, the best path toward its destination. Routing decisions are made using a routing table, a list of known destination networks and the next hop to reach each one.

Routes get into that table in two ways. Static routes are configured by hand, simple, predictable, and unmanageable at scale. Dynamic routing uses a protocol so that routers discover networks and share reachability information automatically, adapting when links change. The dynamic protocols differ in how they learn, how fast they react, and how big a network they suit.

How it is generally implemented

A small network may need only a default route (“send anything you don’t recognize to the internet”) and a couple of static routes. As a network grows, or has redundant paths, or spans many sites, a dynamic routing protocol becomes necessary so the network can heal itself when a link fails without someone editing routes by hand.

Why it matters

Routing is what makes internetworking possible, it is the function that turns a pile of separate networks into the internet. The choice of how routing is done determines how quickly a network recovers from a failure and how well it scales. Get it right and the network reroutes around problems invisibly; get it wrong and a single failure becomes an outage.

In an SD-WAN world

Traditional routing chooses paths based on topology, the shortest number of hops, the configured cost, not on how well a path is actually performing right now. A link can be technically “up” and routing traffic while being congested, lossy, or high-latency. SD-WAN’s defining improvement is performance-based path selection: it continuously measures latency, loss, and jitter on every link and steers each kind of traffic onto the path that is genuinely best at that moment. It is routing that responds to reality, not just to the map.

Part Fifteen: The Routing Protocols, RIP, EIGRP, OSPF, BGP

The topic

Four routing protocols cover almost everything you will encounter:

• RIP (Routing Information Protocol) is the oldest and simplest. It picks paths purely by hop count and maxes out at 15 hops. It is easy to understand and almost never the right choice today, useful mainly as a teaching tool and in tiny or legacy networks.
• OSPF (Open Shortest Path First) is the workhorse interior protocol. It is a link-state protocol: every router builds a complete map of the network and calculates the shortest path using link cost (related to bandwidth). It is standards-based, fast to converge, scales well with proper area design, and works across any vendor’s equipment.
• EIGRP is Cisco’s advanced distance-vector protocol. It converges very fast and is simpler to configure than OSPF, but it was historically Cisco-proprietary, which limits it in mixed-vendor environments.
• BGP (Border Gateway Protocol) is the protocol that runs the internet itself. It is a path-vector protocol designed to exchange routing information between different autonomous systems (different organizations). It scales to the entire global routing table, hundreds of thousands of routes, and it chooses paths based on policy and attributes, not just speed. BGP is how your network announces “you can reach me here” to the world.

Routing protocols compared

eBGP vs. iBGP

BGP comes in two flavors depending on whether the two routers talking are in the same autonomous system or different ones:

• eBGP (external BGP) runs between routers in different ASNs, your edge router peering with your ISP, for example. This is the classic “announce my address space to the world” use. eBGP peers are normally directly connected, and a route learned via eBGP is passed on freely.
• iBGP (internal BGP) runs between routers within the same ASN. Large organizations use it to carry full internet routing information consistently across their own multiple edge routers and data centers. iBGP has a famous catch: to prevent loops, a router will not re-advertise an iBGP-learned route to another iBGP peer, which means iBGP traditionally requires a full mesh of peerings (or a shortcut called a route reflector to avoid that).

The practical distinction: eBGP is how you talk to the outside world; iBGP is how a big network keeps its own routers in agreement about what the outside world looks like.

BGP ASN ranges, including the private ones

An Autonomous System Number identifies a network. Like IP addresses, some ranges are public (globally assigned) and some are private (for internal use), exactly analogous to RFC 1918:

Common internal use cases for private ASNs. Private ASNs (64,512–65,534, and the larger 32-bit private block) are used wherever you need BGP’s mechanics without needing the world to see you: a data-center fabric where each rack or switch runs BGP (the modern leaf-spine design leans heavily on private ASNs per device), an SD-WAN or MPLS setup where a customer site peers with a provider edge using a private ASN, multi-tenant environments, and lab or staging networks. The idea mirrors private IP addressing: use a private ASN internally, and translate or strip it at the boundary (ISPs remove private ASNs from the path before announcing your routes to the global table).

How you actually get a public ASN

If you need to multi-home (connect to two or more ISPs with your own address space and your own identity on the internet), you need a real, globally unique ASN. You get one from a Regional Internet Registry, the RIR for your part of the world:

The process: you (or your ISP/sponsor) apply to the RIR, demonstrate the need (typically that you will multi-home, or otherwise require a unique routing policy), pay a fee, and receive your ASN, usually a 32-bit number these days since the 16-bit pool is effectively exhausted. Many organizations pair the ASN request with a request for their own portable IP address block (a provider-independent allocation) so they can announce their own space across multiple carriers. West Networks holds its own ASN and address space this way, which is what lets it run its backbone as a true autonomous system on the internet rather than living inside an ISP’s space.

How it is generally implemented

OSPF and EIGRP are interior gateway protocols, used inside one organization to route between its own sites and segments. BGP is the exterior protocol, used at the boundary to exchange routes with ISPs and other organizations, and increasingly inside very large networks too. A typical business with redundant internet and its own address space runs eBGP at the edge (to its ISPs) and may run OSPF internally; a very large one adds iBGP to keep its edge routers in sync. RIP you will mostly meet in textbooks and old gear.

Why it matters

The choice shapes the network’s resilience and scale. OSPF and BGP in particular are foundational professional skills, OSPF for building self-healing internal networks, BGP for controlling how your organization is reached from the internet and for multi-homing across several ISPs without depending on any one of them.

Why would anyone still use RIP in 2026? Almost nobody should, and that is the honest answer, but it survives in a few places: very small or very old networks where it was set up decades ago and never causes enough pain to justify a change, some simple embedded or consumer-grade gear that only speaks RIP, and as a teaching tool because its hop-count logic is easy to understand. If you encounter RIP in the field, it is usually a sign of a legacy network overdue for modernization, not a deliberate modern choice. You learn it so you recognize it, not so you deploy it.

OSPF vs. EIGRP in a mixed-vendor shop (Peplink plus some Cisco). Choose OSPF. EIGRP was historically Cisco-proprietary (Cisco later published it, but support outside Cisco remains thin and inconsistent), so in any environment that mixes vendors, OSPF is the safe, universal choice that every vendor’s gear speaks fluently. The rule of thumb: EIGRP only when the network is all-Cisco and you specifically want its fast, simple configuration; OSPF anywhere else, and certainly anywhere Peplink and Cisco have to share a routing domain. Picking OSPF in a mixed shop avoids the interoperability headaches before they start.

In an SD-WAN world

Here is where West Networks does something distinctive. We run our own infrastructure on BGP, so we hold a stable, consistent identity on the internet, but instead of letting BGP’s traditional path attributes alone decide where traffic goes, we layer SpeedFusion’s real-time, performance-based path selection on top. We get BGP’s stable, advertised identity and SD-WAN’s intelligent, self-healing path choice at the same time. For client deployments, SD-WAN can also integrate cleanly with a site’s existing OSPF or BGP, as we have done when replacing an incumbent system without touching the customer’s firewall or core switch, changing only the wide-area layer underneath.

Do we configure BGP on customer sites, or only on our backbone? Both happen, but they are different in scope. The deep BGP, our own ASN, announcing address space to the internet, multi-homing the backbone, lives with us and is genuinely a senior-level task. On customer sites, the common case is lighter: SpeedFusion handles the wide-area intelligence, so many sites need no dynamic routing at all beyond what the edge does automatically. Where a customer already runs BGP or OSPF (often to integrate with an existing firewall or core, like the incumbent-replacement example), we peer the Peplink edge with it rather than ripping it out. So a newer tech will mostly see SD-WAN doing the heavy lifting and the occasional OSPF/BGP integration with existing gear; the full “stand up BGP from scratch” work is concentrated on our backbone and a minority of large client designs. BGP is less scary than it sounds once you see that, in most deployments, you are integrating with it, not building it.

What you’ll actually notice between eBGP and iBGP in the dashboard. In day-to-day Peplink work you will rarely stare at raw BGP, but when you do, the practical difference is who the peer is: an eBGP session is with a different organization’s ASN (your ISP, or our backbone from the customer’s view), and an iBGP session is with another router inside the same ASN. On a dashboard that means an eBGP peer shows a different AS number than yours and is usually your path to the outside, while an iBGP peer shows your own AS number on both ends and is about staying consistent internally. For most site techs, you will see eBGP-style peering (to an ISP or to our backbone) far more often than iBGP, which mainly appears inside larger multi-router networks.

If SD-WAN does performance-based routing, do we still need OSPF or BGP in the customer LAN? Often not, and that is part of the appeal, but it depends on the LAN’s size. SpeedFusion handles path selection across the WAN, that is the wide-area job done. Inside a small or mid-size site, the edge device routes between VLANs directly and there is simply no need for a dynamic interior protocol; static routing plus the SD-WAN edge covers it. You reach for OSPF inside the LAN only when the site is large enough to have multiple internal routers or Layer 3 switches that need to learn each other’s networks automatically, or when you must integrate with a customer’s existing OSPF/BGP domain. So the rule: SD-WAN replaces the need for dynamic routing across the WAN almost always, and replaces the need for it inside the LAN at most small and mid-size sites, while large multi-router LANs still benefit from OSPF underneath. Performance-based path selection and a traditional interior routing protocol are not in conflict; SD-WAN decides which WAN path, and an IGP, where present, decides internal reachability.

Part Sixteen: Routers, Switches, Firewalls, and Gateways, What Each Actually Is

The topic

These four terms get used loosely, but each names a specific function:

• A switch connects devices within a network and forwards based on MAC addresses (Layer 2). Its job is local connectivity.
• A router connects different networks and forwards based on IP addresses (Layer 3). Its job is to move traffic between networks and toward the internet.
• A firewall inspects and controls traffic according to security policy. It can operate from Layer 3 up to Layer 7, deciding what is allowed to pass based on addresses, ports, and increasingly the actual application and content.
• A gateway is a role, not usually a separate box: it is whatever device serves as the doorway from one network to another. Your “default gateway” is simply the router your devices send traffic to when the destination is somewhere else.

How it is generally implemented

In a large network these are often distinct devices. In modern smaller and mid-sized deployments they increasingly converge: a single edge appliance routes, firewalls, and serves as the gateway, and often does WAN bonding and Wi-Fi control too. The trend is consolidation of these functions into fewer, smarter boxes.

Why it matters

Knowing which function you actually need keeps you from over- or under-buying. Many networks have an expensive dedicated device doing a job a converged appliance could handle, and others try to make a simple router do a firewall’s job and end up exposed. Matching function to requirement is basic competence and a constant real-world judgment call.

In an SD-WAN world

The Peplink edge is the clearest example of this convergence done well: it is router, firewall, gateway, WAN-bonding device, and wireless controller in one, managed centrally. That consolidation is a large part of why the modern edge can be simpler and cheaper than the traditional stack of separate boxes, while being more capable, because the functions cooperate instead of being bolted together from different vendors.