Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

BGP in EVPN-Based Data Center Fabrics – Take 2

My BGP in EVPN-Based Data Center Fabrics blog post generated numerous comments from engineers disagreeing with my views on using IBGP-over-EBGP.

As usual, there were three kinds of comments:

  • People like Alexander Grigorenko arguing with the technical merits of what I wrote (Alex published a blog post describing his perspective). They were right – I should have spent more time on the details;
  • People like Paul saying “while I understand your discussion, nothing else would work for my fabric”. Fair point – if you have to carry 1M prefixes around you cannot use generic design guidelines found on the Internet;
  • Anonymous commenters being annoyed because I called their baby ugly (more about this in another blog post).

Anyway, Alex’ comments triggered a major rewrite of the BGP in EVPN-Based Data Center Fabrics section of Using BGP in Data Center Leaf-and-Spine Fabrics article. It took me a long time to figure out how to structure it, and then more than a week ironing out the kinks based on feedback from people way closer to actual BGP source code than I ever was.

The new version of the document is online. There are still a few missing bits and pieces, like route target implications of using numerous AS numbers in a single EVPN fabric, or performance differences between IBGP and EBGP-based EVPN designs.

For even more details, watch EVPN Technical Deep Dive and Leaf and Spine Architectures webinars (both part of ipSpace.net subscription).

1 comment:

  1. May it be BGP EVPN or a directory service with reachability infromation (kept on hypervisors) and a custom encapsulation, in the end they all are trying to solve the same underlying problem. They all have to use those 40 years old protocols like Ethernet and IP. In my opinion those approaches aren't an evolution. They are just continuous product improvements for capex and opex reduction. And they keep the consultants employed and the vendors also hugely benefit from that.

    ReplyDelete

Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.

Sidebar