Applied blindly, these routing protocol “truths” lead to outages, brittle networks, and unnecessary complexity.
Most routing myths do not survive because engineers are careless. They survive because they sound correct, worked once, or were taught by someone senior.
Over time, these ideas turn into rules. They get repeated in design reviews, baked into standards, and defended long after their original context disappears.
The problem is not that these beliefs are subtle. It is that they feel settled. And that is precisely why they keep breaking networks.
Myth 1. Route redistribution is fundamentally unsafe
This belief kills more sane designs than almost any other.
Route redistribution is not inherently dangerous. Uncontrolled, bidirectional redistribution without filtering is dangerous. One-way redistribution with explicit policy, metrics, and defaults is often clean and stable.
Most fear around redistribution comes from unmanaged administrative distance and feedback loops, not from redistribution itself. When those are handled deliberately, redistribution becomes boring in the best possible way.
Entire networks have been over-engineered to avoid redistribution when a single controlled handoff would have simplified operations and reduced failure domains.
If you believe redistribution is always bad, you are probably compensating with unnecessary protocol sprawl.
Myth 2. You cannot run OSPF and EIGRP in the same AS
This myth survives because it sounds authoritative and just technical enough to avoid challenge.
Engineers conflate BGP autonomous systems with OSPF process IDs or EIGRP AS numbers. They are not the same thing, and they never were.
You can run OSPF and EIGRP in the same network. You can redistribute between them. What usually stops people is the fear of vendor lock-in or multi-vendor scrutiny, not a protocol limitation.
Avoiding this blocks migrations, forces parallel designs, and creates brittle transitional states for no technical reason.
This is not a design constraint. It is institutional anxiety.
Myth 3. You need multiple OSPF areas to scale
This is 1990s cargo cult engineering.
Modern hardware can run single-area OSPF with thousands of routes without stress. Multi-area designs introduce complexity, failure modes, and operational friction that often outweigh their theoretical benefits.
Many networks use multiple areas not because they need them, but because someone was taught that “area 0 cannot be large.”
If you cannot explain why each area exists without saying “best practice,” you do not need them.
Myth 4. BGP communities are too advanced for most networks
This belief keeps BGP fragile and opaque.
Communities are not an advanced feature. They are a clarity feature. Avoiding them forces engineers to encode intent into route maps, prefix lists, and naming conventions that do not scale.
If your team debates a route-map change for 30 minutes because no one can predict the side effects, that is the cost of avoiding communities.
BGP does not cause complex policy. It is caused by hiding intent.
Myth 5. Static routes are always a band-aid
Static routes are not the opposite of “real” networking.
Static routes are often more stable than dynamic routing protocols for default routes, management traffic, and tightly scoped paths. They fail predictably and do not depend on control-plane convergence.
Treating statics as shameful leads to unnecessary protocol complexity when a simpler approach would be safer.
Not everything needs to converge dynamically to be correct.
Myth 6. Equal-cost paths mean equal traffic
One circuit runs at 80%, while three others are at 15%, yet monitoring indicates traffic is evenly balanced.
ECMP relies on hashing, not fairness. Flow size, entropy, and hardware behavior matter more than route tables. Large flows pin to single paths, microbursts amplify imbalance, and the network claims everything is fine.
This is how performance problems quietly turn into outages when a single hot path tips over under load.
If you trust ECMP without validating flow behavior, you are planning capacity on paper.
Myth 7. Routing problems live in the control plane
This assumption misleads engineers during incidents.
Many routing instabilities originate in the data plane. Microbursts, buffer exhaustion, oversubscription, and hardware limits destabilize routing even when protocol configurations are clean.
Chasing timers and neighbors without examining forwarding behavior leads to fixes that never stick.
If a routing issue keeps coming back, it is probably not a routing issue.
Why these myths survive in production
Each myth here originated as a reasonable idea within a specific context. Over time, the context disappeared, and the rule remained.
Networks fail when engineers keep following rules without questioning why they exist. Just because something is accepted as best practice does not mean it still is.
If even one of these made you want to check a config, the article did its job.
About NetworkTigers
NetworkTigers is the leader in the secondary market for Grade A, seller-refurbished networking equipment. Founded in January 1996 as Andover Consulting Group, which built and re-architected data centers for Fortune 500 firms, NetworkTigers provides consulting and network equipment to global governmental agencies, Fortune 2000, and healthcare companies. www.networktigers.com.
