Building network automation solutions

9 module online course

Start now!

Pragmatic EVPN Designs

While running the Using VXLAN And EVPN To Build Active-Active Data Centers workshop in early December 2019 I got the usual set of questions about using BGP as the underlay routing protocol in EVPN fabrics, and the various convoluted designs like IBGP-over-EBGP or EBGP-between-loopbacks over directly-connected-EBGP that some vendors love so much.

I got a question along the same lines from one of the readers of my latest EPVN rant who described how convoluted it is to implement the design he’d like to use with the gear he has (I won’t name any vendor because hazardous chemical substances get mentioned when I do).

Here’s what you have to keep in mind when considering what design to use in your network (and it applies to everything, not just EVPN): while I love to fight the windmills of overly-complex designs, and annoy the vendors by pointing out weaknesses in their arguments, you have a network to run, so be pragmatic.

Do whatever your vendor describes as the reference design… and if you have multiple reference designs to choose from, choose the simplest one that meets your scalability requirements.

You might not like the design your vendor loves, and you might find it too complex. Guess what, there are multiple vendors out there, and they are all keen to take your money. Vote with your wallet - that’s the only way to bring some common sense to this industry.

In Case You’re Not Persuaded (Yet)

While every vendor (marketing department) claims they support whatever you’d like to do, or as Aldrin said in his comment to my EVPN Dilemma blog post…

Pretty much all EVPN implementations support multiple routing protocols. Including IS-IS, OSPF and EBGP as IGP. There’s a difference between a reference design and feature support.

.. there truly is a difference between the two: reference design is tested much better than all other combinations of supposedly-supported features. If you don’t fancy providing free QA/troubleshooting resources to your $vendor (and arguing with their level-1 TAC that reloading the box really doesn’t help while doing that), stick with whatever the vendor is recommending.

As always, there will be consequences. In this particular case:

  • As no two vendors use the same preferred reference design, forget about multi-vendor EVPN fabrics (which is probably a good idea anyway);
  • Some reference designs tend to be overly complex. Someone will have to troubleshoot them at 2AM on a Sunday morning (hint: that might be you, or they might call you after the get hopelessly lost). All other things being comparable, choose the vendor with the simplest reference design.
  • Some reference design configurations read like a Tolstoy novel. Prefer vendors that can implement your needs with minimum configuration hassle (example)

You can always generate device configurations with templates, and the vendors with overly-verbose configurations will be quick to point out the powers of automation. However, someone has to design those templates, and someone might have to troubleshoot them (or the actual device configurations)… yet again most probably at 2AM on a Sunday morning when the automation system breaks down. Regardless of what the thought leaders love to tell you, if you want to have a stable solution, hidden complexity tends to be worse than explicit complexity.

Notes:

2 comments:

  1. Is a multi-vendor EVPN a good idea? I keep hearing EVPN is a standard but yet every vendor when applying into their implementation use different features!
  2. When I was a consultant I was making a good living using your principles. :-) Just configure back everything to the vendor reference design, since that was the best tested configuration. :-) That is so true...
    I always had an explanation. In California, you want to deliver quick and dirty, since the girls are waiting for you at the beach... :-) So testing is limited to the very minimum... Never forget this... :-) :-) :-)

Add comment
Sidebar