Routing Protocols Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

What a route is

A route is a prefix, a next hop or an exit, and a reason to trust it. Connected routes come from interfaces. Static routes come from a person. Dynamic routes come from a protocol. The forwarding decision for a single packet is the longest matching prefix. If two routes have the same prefix, the platform's preference, often called administrative distance, picks the source, and the metric picks among equals inside that source.

This guide uses documentation addresses. 192.0.2.0/24 stands in for the transit network where next hops live. 198.51.100.0/24 and 203.0.113.0/24 are destinations in the example, not networks you should advertise. 10.0.0.0/8 is private space in the example aggregate.

OSPF and BGP are not interchangeable decorations. OSPF is usually your interior link-state protocol. A cost is a statement about a path inside your network. BGP is how you express policy between autonomous systems, and often between sites when you have chosen it for that. A default route from the provider is not a full table, and a full table is not a requirement for an office. Take the route you can operate.

The simulators linked from this page walk longest match in the browser. They do not form an adjacency with your routers. Use them to explain a table, then confirm the real table on the device with the platform's show command during the window.

A lab table and the destinations it forwards

A packet to 198.51.100.10 matches 198.51.100.0/24 and follows 192.0.2.2. The /25 does not contain .10, so the /24 wins over the default. Longest prefix is the whole decision in this lab table. Administrative distance and metrics matter when two routes for the same prefix compete, not when one prefix is longer. If you add a static route for the same prefix as a dynamic route, know which one the platform prefers before the window. A more specific static route will hide a wider dynamic route even when the dynamic route is healthy. That is useful for a blackhole or a repair, and it is a surprise when you meant to override only one host and you typed a /16.

A packet to 198.51.100.200 matches 198.51.100.128/25 and follows 192.0.2.3. Both the /24 and the /25 contain .200. The /25 is longer, so it wins. Longest prefix is the whole decision in this lab table. Administrative distance and metrics matter when two routes for the same prefix compete, not when one prefix is longer. If you add a static route for the same prefix as a dynamic route, know which one the platform prefers before the window. A more specific static route will hide a wider dynamic route even when the dynamic route is healthy. That is useful for a blackhole or a repair, and it is a surprise when you meant to override only one host and you typed a /16.

A packet to 10.1.8.4 matches 10.1.0.0/16 and follows 192.0.2.6. The /8 also contains it. The /16 is longer and wins. The default does not get a vote. Longest prefix is the whole decision in this lab table. Administrative distance and metrics matter when two routes for the same prefix compete, not when one prefix is longer. If you add a static route for the same prefix as a dynamic route, know which one the platform prefers before the window. A more specific static route will hide a wider dynamic route even when the dynamic route is healthy. That is useful for a blackhole or a repair, and it is a surprise when you meant to override only one host and you typed a /16.

A packet to 10.2.2.2 matches 10.0.0.0/8 and follows 192.0.2.5. Nothing longer than the /8 matches. The /16 was only 10.1.0.0/16. Longest prefix is the whole decision in this lab table. Administrative distance and metrics matter when two routes for the same prefix compete, not when one prefix is longer. If you add a static route for the same prefix as a dynamic route, know which one the platform prefers before the window. A more specific static route will hide a wider dynamic route even when the dynamic route is healthy. That is useful for a blackhole or a repair, and it is a surprise when you meant to override only one host and you typed a /16.

A packet to 203.0.113.50 matches 203.0.113.0/24 and follows 192.0.2.4. This is a specific prefix, not a reason to edit the default route. Longest prefix is the whole decision in this lab table. Administrative distance and metrics matter when two routes for the same prefix compete, not when one prefix is longer. If you add a static route for the same prefix as a dynamic route, know which one the platform prefers before the window. A more specific static route will hide a wider dynamic route even when the dynamic route is healthy. That is useful for a blackhole or a repair, and it is a surprise when you meant to override only one host and you typed a /16.

A packet to 192.0.2.20 matches 0.0.0.0/0 and follows 192.0.2.1. No specific route in this table contains 192.0.2.20, so the default is the match. On a real router a connected route might win instead. Connected routes are longer and local. Do not forget them when you read a table. Longest prefix is the whole decision in this lab table. Administrative distance and metrics matter when two routes for the same prefix compete, not when one prefix is longer. If you add a static route for the same prefix as a dynamic route, know which one the platform prefers before the window. A more specific static route will hide a wider dynamic route even when the dynamic route is healthy. That is useful for a blackhole or a repair, and it is a surprise when you meant to override only one host and you typed a /16.

Prefix	Next hop	Role
0.0.0.0/0	192.0.2.1	the default, used when nothing longer matches
10.0.0.0/8	192.0.2.5	a wide private aggregate
10.1.0.0/16	192.0.2.6	a site inside that aggregate
198.51.100.0/24	192.0.2.2	a server network
198.51.100.128/25	192.0.2.3	a longer prefix inside that server network
203.0.113.0/24	192.0.2.4	a partner or a documentation block used here as a lab destination

A cost you can explain

If the reference bandwidth is 100000 megabits per second, a 100 gigabit link has cost 1, a 10 gigabit link has cost 10, a 1 gigabit link has cost 100, and a 100 megabit link has cost 1000. Those are the integer costs of reference divided by bandwidth, with a floor of 1. Two equal-cost paths can share traffic. A path that is one gigabit plus one gigabit is cost 200, which loses to a direct 10 gigabit path of cost 10. You do not need a novel metric to see that.

The failure is an old reference bandwidth. If the reference is still 100 megabits, then 1 gigabit, 10 gigabit, and 100 gigabit all collapse toward the same cost and the protocol cannot tell them apart. Set the reference on every router in the area before you rely on cost to prefer the fast core. Mismatched references make two routers disagree about the best path.

Areas, authentication, and passive interfaces are part of the design and not part of this arithmetic. A passive interface toward users stops you forming an adjacency with a laptop. Authentication stops you forming an adjacency with a stranger. Neither one changes the longest-prefix rule for a static route you add later.

Policy without a full Internet

A default route from one provider, or defaults from two providers with a local preference you understand, is a complete design for many sites. Accepting a full table because a blog recommended it adds memory, convergence, and a need to filter. If you accept anything beyond a default, filter it. Your own prefixes should be the ones you originate, with a prefix limit you chose, not whatever a neighbour sends.

Private AS numbers and documentation prefixes do not belong in a public advertisement. 203.0.113.0/24 in this guide is an example destination, not a prefix to originate. Before a BGP change, write the prefixes you announce, the neighbour address, the remote AS, and the filter. Then have someone else read that list against the ticket.

iBGP and OSPF solve different problems. OSPF can carry the next hop reachability that BGP assumes. If the BGP next hop is not reachable in your interior, the BGP route does not forward traffic even though the session is up. Check the next hop as its own route. A session that is established is not a path that works.

A branch with two ways out

A branch has 198.51.100.0/24 on its LAN and two routers. The primary next hop toward the core is 192.0.2.2. The backup is 192.0.2.3. You want the primary used while it is alive, and the backup used when the primary path is dead. A static default with a worse administrative distance on the backup can do that on a platform that withdraws a static route when the next hop is unreachable. If the platform keeps the static route while the next hop is dead, you have written a blackhole. Know which behaviour you have before you depend on it. A tracking object or a protocol is the honest fix when a static route does not withdraw.

OSPF between the branch and the core will withdraw a dead neighbour. Give the primary link a better cost. Using the reference of 100000 megabits, a 1 gigabit primary is cost 100 and a 100 megabit backup is cost 1000. The branch prefers the primary. When the primary neighbour drops, the backup remains. Do not also leave a static default that is preferred over OSPF, or the static route will hide the failure and keep sending traffic into the dead link. Read the administrative distance. A static route that the platform prefers to OSPF will win even when OSPF is telling the truth.

The return path matters as much as the path out. If the branch sends traffic via the primary and the core replies via the backup, a stateful firewall in only one of those paths will drop the reply. Draw both arrows. If both paths are meant to be live, the firewalls on both paths need the same policy, or you pin both directions to one path. Asymmetric routing is not a moral failure. It is a failure only when a device on the path keeps state and sees one direction.

A more specific route can repair one server without touching the default. If 203.0.113.10 must use the backup today, add 203.0.113.10/32 via 192.0.2.3 and leave the default on the primary. Longest match sends that host to the backup and everything else to the primary. Write an expiry on the /32. A repair that outlives the incident becomes the design, and the next person will not know why one server takes the slow path.

Summaries save the core from a pile of /24s and they hide the /24 you are trying to debug. If the branch advertises only 198.51.100.0/16 while the dead VLAN is 198.51.100.40/24, the core still has a route. Traffic arrives at the branch and dies there. The core table looking healthy does not prove the VLAN is up. Check the route at the branch for the longer prefix, on the branch, before you tell the core team the WAN is down.

Redistribution is how a static route becomes an OSPF route or a BGP route. It is also how a default you accepted from a provider becomes an interior default you did not mean to send to every branch. Redistribute a named prefix list, not an entire protocol, until you can point at every prefix that crossed. Mutual redistribution between two protocols without a filter is a loop you get to explain during the window. If you do not have a prefix list in the ticket, you are not ready to redistribute.

Failover deserves a test that is not a real outage for the whole site. Shut the primary link while a single test host pings a named address, watch the route withdraw, watch the backup take over, then restore the primary and watch the preferred path return. If the preferred path does not return, a distance or a cost is wrong, or a static route is stuck. Fix that before you call the design highly available. A backup you have never seen win is a drawing.

Document the branch in six lines. LAN prefix. Primary next hop and how it is learned. Backup next hop and how it is learned. What makes the primary win. What withdraws a dead path. Where the return path is pinned. A routing protocol page that does not contain those six lines is a protocol page, not a design. The calculator and the longest-match simulator help you teach the six lines. They do not push the config.

Connected routes outrank the story people tell about protocols. If the branch router's LAN interface is 198.51.100.1/24, the router already has 198.51.100.0/24 connected. You do not add a static route for that prefix toward somebody else. If a traceroute from the core reaches the branch and then stops, look at the connected route and the ARP or neighbour table on the branch, not at BGP. The packet arrived. The last hop is local. A missing connected route means the interface is down or the address is not the one in the ticket.

Null routes are a tool and a foot-gun. A route for 198.51.100.128/25 to discard or to null0 will blackhole that half on purpose, which is what you want for a prefix you must not forward, and what you do not want for a VLAN you merely forgot to build. Name the null route in the ticket as a blackhole. Give it an owner and an expiry. A blackhole without an expiry becomes the mysterious loss that survives three routing migrations.

Default routes need an owner. Someone accepted it from a provider, or someone typed it. If both happen, write which one wins and why. Two defaults with the same preference will either share or flap in the way the platform defines, and that way should be in the ticket before users notice. If you have no default, then destinations you did not explicitly route are unreachable, which is a fine security posture and a surprising one for an office that expected the Internet. Say which posture you are in.

When you read a live table, filter it. Ask the router for the match for one address, not for the entire BGP table. The match for one address is the decision. The full table is the haystack. The simulators on this site exist so you can practise that question with the lab prefixes above. On the day, use the platform command that answers the same question for the real address, and paste the one matching line into the ticket. If that line is a default and you expected a /24, the /24 is missing or you are on the wrong router. If that line is a /32 and you expected the VLAN route, someone left a host route behind. The one line is the incident. The rest of the table can wait until that line is the one you meant to install. After the window, compare the ticket's prefix to the running configuration, not to your memory of what you typed. Then delete the lab route if you used 203.0.113.0/24 or 192.0.2.0/24 as a stand-in. Those documentation prefixes must not remain as production routes and must not be advertised. A successful test that leaves a documentation prefix in the table is not a successful test. Replace it with the real prefix in the same change, or remove it before you close the window. The longest-match rule will honour whatever you left behind, including a prefix that was only ever an example. Search the running configuration for 192.0.2. and 203.0.113. and 198.51.100. before you leave, and keep only the prefixes the ticket named as real. Say the winning prefix aloud and compare it to the ticket before you save.

Changing a route

Add the more specific route you need, with a next hop you can ping, and a prefix that is not wider than the outage. A host route is /32. A user VLAN is whatever you allocated, not a /8 you typed because it was easy. Confirm the longest match on the router after the change, from the router, not only from a laptop that might be using a cached path or a different VPN.

Rollback is removing that route or restoring the previous next hop. Know which one before you start. A route that points at a next hop which is down will blackhole. A route that points at the wrong next hop will deliver traffic to the wrong place, which can be worse. Test with one address you named in the ticket.

Write the destination prefix and the next hop.
Prove the next hop is reachable without the route you are adding.
Check whether a longer or equal prefix already exists.
Add the route and display the match for one test address.
Test forward and return. A reply that takes another firewall is still part of the path.
Keep the rollback as a single command you already wrote down.

Mistakes that look like a protocol bug

Editing the default route to fix one server. Add a longer prefix.

Forgetting the connected route and wondering why the table does not match the whiteboard.

Setting two OSPF routers to different reference bandwidths.

Accepting a full BGP table you cannot filter.

Advertising a documentation prefix or a private prefix to a provider.

Pointing a static route at a next hop that is not directly reachable and that the platform will not recurse.

Testing only the session state and not an actual forward.

Leaving a temporary more-specific route in place after the outage so it hides next quarter's IGP.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.