Tomislav Kranjec Technology Leadership & Architecture
EVPN

EVPN Part 6: Production Lessons and Design Mistakes

Published Reading time 11 min Focus EVPN
EVPN Part 6: Production Lessons and Design Mistakes

If you’ve made it this far, you now understand:

  • Why EVPN exists
  • The problems it solves
  • EVPN route types
  • Multi-homing
  • VXLAN integration
  • Anycast gateways
  • ARP suppression
  • Fabric architecture
  • Troubleshooting methodology

At this stage, many engineers feel they understand EVPN.

In reality, this is where the most important lessons begin.

Production EVPN deployments are rarely limited by protocol knowledge.

They are limited by engineering judgment.

Most major EVPN problems are not caused by EVPN itself.

They are caused by:

  • Poor design assumptions
  • Operational shortcuts
  • Incomplete testing
  • Lack of scale planning
  • Misunderstanding what EVPN is actually solving

This final section focuses on the lessons architects learn after operating EVPN in production.

These are the mistakes that don’t usually appear in certification guides, vendor workshops, or proof-of-concept labs.

Common EVPN Design Mistakes

Mistake #1 — Treating EVPN as “Just VXLAN”

This is the most common misunderstanding.

Engineers hear:

EVPN-VXLAN

and assume EVPN is simply a VXLAN feature.

It is not.

Remember:

VXLAN = Data Plane

EVPN = Control Plane

When engineers think only about encapsulation and ignore route distribution, they often miss critical design considerations.

Impact

  • Poor route scaling
  • Incorrect route target design
  • Inadequate route reflector planning
  • Troubleshooting difficulties

Always design:

  1. Underlay
  2. Control Plane
  3. Data Plane

in that order.

Mistake #2 — Ignoring Route Target Planning

Many deployments start with:

No RT Plan

Everything works.

Initially.

Three years later:

Nobody understands:

Who imports what?

Impact

  • Route leaks
  • Tenant confusion
  • Operational complexity

Create a documented RT strategy before deployment.

Mistake #3 — Poor VNI Allocation Strategy

I’ve seen environments where VNIs were assigned randomly.

Example:

Tenant A
VNI 5021

Tenant B
VNI 8197

Tenant C
VNI 14322

Technically valid.

Operationally painful.

Impact

  • Difficult troubleshooting
  • Documentation drift
  • Operational errors

Use structured VNI allocation.

Mistake #4 — Underestimating Route Scale

Most proofs of concept have:

20 Hosts

Production environments may have:

50,000+
Endpoints

The control plane changes dramatically.

Impact

  • Route reflector overload
  • Memory exhaustion
  • Slow convergence
  • Hardware table exhaustion

Calculate:

  • Endpoint count
  • MAC scale
  • Type 2 scale
  • VRF scale
  • VNI scale
  • Route Reflector prefix capacity

before deployment.

Mistake #5 — Treating Route Reflectors as an Afterthought

Many engineers focus heavily on leafs and spines.

Then place route reflectors wherever convenient.

This is dangerous.

In iBGP overlays, route reflectors are often the most important control-plane components.

Impact

  • Convergence delays
  • Route propagation issues
  • Control-plane bottlenecks

Design route reflectors deliberately.

Mistake #6 — Incorrect Multi-Homing Design

Many engineers assume:

EVPN Multi-Homing
=
MLAG

This leads to operational confusion.

Impact

  • MAC flapping
  • DF election issues
  • Blackholing

Understand:

  • ESI configuration and the 10-octet format
  • Type 1 routes (per-ES and per-EVI subtypes)
  • Type 2 routes carrying the ESI value
  • Type 4 routes and DF election algorithm

before production deployment.

Mistake #7 — Misunderstanding Type 5 Routes

This appears frequently.

Many engineers assume:

Type 5 replaces Type 2

It does not.

Type 2

Represents:

Endpoints

Type 5

Represents:

Prefixes

Both remain important.

Impact

  • Broken tenant routing
  • Route advertisement confusion

Understand endpoint routing and prefix routing separately.

Mistake #8 — Excessive Layer 2 Stretching

EVPN makes Layer 2 extension more controlled and scalable than traditional flood-and-learn designs.

That does not mean it should be done everywhere.

A dangerous mindset is:

“Because we can stretch VLANs, we should.”

Impact

  • Large failure domains
  • Increased mobility complexity
  • Operational risk

Prefer Layer 3 boundaries whenever possible.

Mistake #9 — Poor Tenant Design

Many environments begin with:

Everything in one VRF

This usually becomes problematic.

Impact

  • Security challenges
  • Route complexity
  • Difficult policy management

Use logical tenant boundaries from day one.

Mistake #10 — Inadequate Failure Testing

One of the most expensive mistakes.

The deployment works.

The project closes.

No one tests failures.

Months later:

Leaf Failure

reveals hidden issues.

Test:

  • Leaf failure
  • Spine failure
  • Route reflector failure
  • Link failure
  • ESI failure
  • BFD session failure
  • MTU change impact

before production.

Mistake #11 — Assuming EVPN Eliminates All Flooding

Another common misconception.

EVPN significantly reduces flooding.

It does not eliminate it.

BUM traffic still exists.

Impact

  • Unrealistic expectations
  • Troubleshooting confusion

Understand how Type 3 routes build the BUM flooding list (ingress replication or multicast).

Mistake #12 — Neglecting MTU Design

One of the most painful production issues.

Everything appears healthy.

Traffic still fails.

The root cause:

Underlay MTU Too Small

VXLAN adds 50 bytes of encapsulation overhead.

The underlay needs at least 1600 bytes, or jumbo frames end-to-end.

If hosts use jumbo frames, the underlay needs even more (commonly 9216).

Impact

  • Intermittent packet loss
  • Application instability
  • Difficult troubleshooting

Validate MTU end-to-end.

Every time.

Mistake #13 — Designing for Day 1 Instead of Day 1000

Many designs focus on deployment.

Few focus on operations.

Impact

Three years later:

  • Nobody understands RT assignments
  • VNIs lack consistency
  • Documentation is outdated

Design for future operators.

Not just initial deployment.

Mistake #14 — Lack of Operational Visibility

Some teams deploy EVPN but fail to build operational dashboards.

Impact

Troubleshooting becomes reactive.

Monitor:

  • EVPN peers
  • Route counts
  • MAC counts
  • Type 2 growth
  • VTEP reachability

continuously.

Mistake #15 — Copying Reference Architectures Blindly

Perhaps the most dangerous mistake.

A design that works for:

  • Cloud providers
  • Large enterprises
  • Service providers

may not fit your environment.

Understand:

Why

before implementing:

How

When NOT to Deploy EVPN

One of the most important architectural questions:

Should we deploy EVPN at all?

The answer is not always yes.

Scenario 1 — Small Environments

Example:

2 Switches

20 Servers

Do you need:

  • EVPN
  • VXLAN
  • Route reflectors
  • Multi-homing

Probably not.

A simple routed design may be superior.

Scenario 2 — Pure Layer 3 Fabrics

If applications do not require Layer 2 extension:

EVPN may provide little benefit.

Unless you need tenant separation (VRFs) across the fabric.

EVPN Type 5 routes provide that without any Layer 2.

Example

Traditional routed leaf-spine:

L3 Everywhere

may be entirely sufficient.

Scenario 3 — Limited Operational Maturity

This is rarely discussed.

EVPN requires:

  • BGP knowledge
  • Overlay understanding
  • Route analysis skills

If the operations team lacks these skills:

The design may become difficult to support.

Recommendation

Invest in operational readiness first.

Scenario 4 — Very Stable Workloads

If workloads never move, and there are:

  • No mobility requirements
  • No tenant scaling challenges
  • No overlay needs

EVPN may not justify its complexity.

Scenario 5 — No Clear Business Driver

Never deploy EVPN because:

Everyone Else Is Doing It

Deploy it because it solves a problem.

Examples:

  • Scale
  • Mobility
  • Tenant isolation
  • Operational simplification

Real-World Deployment Lessons

After multiple EVPN deployments, several lessons appear repeatedly.

Lesson #1

In many production incidents, the root cause is underlay reachability, MTU, routing instability, or operational design — not EVPN route processing itself.

Most overlay issues begin below the overlay.

Lesson #2

Type 2 routes solve more troubleshooting cases than any other route type.

Master Type 2 routes.

Lesson #3

Good route-target planning prevents years of operational pain.

Lesson #4

Failure testing reveals more design flaws than documentation reviews.

Lesson #5

The simplest EVPN design is usually the best EVPN design.

Lesson #6

Operational consistency matters more than architectural cleverness.

Lesson #7

Most EVPN problems are human problems.

Not protocol problems.

The EVPN Mental Model Every Engineer Should Use

If I had to teach EVPN in one diagram, it would be this:

Underlay
Provides Reachability

↓

EVPN
Provides Knowledge

↓

VXLAN
Provides Transport

↓

Tenants
Provide Services

↓

Endpoints
Provide Applications

This model explains almost every EVPN deployment.

Another Mental Model

When troubleshooting:

Ask four questions.

Question 1

Can I reach the VTEP?

If not:

Underlay problem.

Question 2

Does EVPN know the endpoint?

If not:

Control-plane problem.

Question 3

Can VXLAN transport traffic?

If not:

Overlay problem.

Question 4

Can the tenant import the route?

If not:

Policy problem.

This framework helps solve an enormous number of incidents.

Final Thoughts

EVPN is not simply a modern replacement for VLANs.

It is a fundamentally different approach to building scalable Layer 2 and Layer 3 services.

The real innovation is not VXLAN.

The real innovation is replacing decades of flood-and-learn behavior with a distributed control plane.

That shift changes everything:

  • Convergence
  • Scale
  • Visibility
  • Multi-homing
  • Mobility
  • Troubleshooting

Engineers who understand only the configuration often struggle when things go wrong.

Engineers who understand the control plane can usually explain exactly why something is happening.

That should be your goal.

Not memorizing commands.

Not memorizing route types.

Understanding the system.

Because once you understand the system, the configuration becomes the easy part.

10 EVPN Principles Every Engineer Should Memorize

  1. EVPN is a control plane, not a data plane.
  2. VXLAN transports traffic; EVPN distributes knowledge.
  3. The underlay must be stable before the overlay can be stable.
  4. Type 2 routes are the foundation of endpoint reachability.
  5. Route Targets determine which VRFs import which routes.
  6. Anycast Gateway supports workload mobility by keeping the default gateway consistent across participating VTEPs.
  7. Multi-homing depends on ESI, Type 1 routes, and Type 4 routes.
  8. Most ARP suppression problems are actually endpoint advertisement problems.
  9. Good EVPN designs scale operationally, not just technically.
  10. When troubleshooting EVPN, always identify which layer is broken before attempting a fix.

After mastering these fundamentals, I recommend studying the following topics in order:

  1. EVPN Route Types Deep Dive (RFC 7432, RFC 9136)
  2. VXLAN EVPN Packet Walk Analysis (RFC 8365)
  3. EVPN Multi-Homing and All-Active Designs
  4. Distributed Anycast Gateway Architectures
  5. EVPN Type 5 Route Design
  6. EVPN Route Target and Tenant Architecture
  7. EVPN in Service Provider Networks
  8. EVPN MPLS vs EVPN VXLAN
  9. EVPN over SR-MPLS and SRv6
  10. Large-Scale EVPN Fabric Operations and Troubleshooting

Master these topics, and you’ll be able to participate confidently in architecture reviews, migration projects, design workshops, and production troubleshooting discussions involving modern EVPN fabrics.