Tired of buzzword bingo and terms like EVPN, VXLAN, Software Defined XX, Cloud-Native, XX-AS-code and more without having to earn a PhD because “I thought I knew how it worked?”
Extending the Enterprise toThe Cloud at Cloud Scale or becoming more Cloud-Centric or Cloud-Native has become the new mantra for adapting to a new Work-From-Anywhere workforce.
Taking your Enterprise “to the Cloud” or simplifying your Enterprise “hybrid-cloud” shouldn’t require writing a thesis on how to yet again “tunnel something inside of something else.”
Until recently joining Pica8, I thought Tunneling Acronym-a-Pooloza already had more-than-its-fair-share of technology acronyms dedicated to the topic:
- 31 Flavors of MPLS
- DNS (Tunneling)
- “Micro-Segmentation” (we’ll save this one for a future Pica8 Blog post)
- And now EVPN- <fill-in-blank-here>
- Followed by a few more I’m sure I’ve missed
Leading to the convergence (how we doin’ on buzzword bingo?) of Dev/Net/SecOPs, Automation, Containerization and Everything-as- a-Service-virtualization in the VXLAN Tunnel of (Virtualized) Love…
(Editor’s note: I got BINGO.)
Is it the tunnel to end-all-tunnels? Will it make you fall in “love” with Enterprise networking all over again?
Pica8 just might.
Having focused in other areas such as Cyber, BlockChain, and Artificial Intelligence for the last several years of my career, it has given me some unique insight since my days in the classic “access-distribution-core” Enterprise Network model.
The CLOS (what’s old is new again: invented in 1938, and formalized in 1952 by Charles Clos) architecture that was once only implemented INSIDE big iron networking gear…..is now the backbone, or rather, the Spine(-Leaf) architecture-of-choice that is quickly sweeping the Enterprise.
That same CLOS architecture has driven innovations like Multi-Chassis Link Aggregation (MLAG) that enables All-Links-Active scenarios (bye-bye Spanning-Tree, hello to all my missing uplink ports!) and makes the idea of bringing “everything closer to the application-level network-edge” a reality.
And by reality…well, let’s explore what the “reality” of the buzzword EVPN-VXLAN really means.
EVPN-VXLAN stands for Ethernet VPN (EVPN) Virtual EXtensible LAN (VXLAN). By itself, VXLAN is the protocol that is used to create a tunneled “Overlay” network on-top of an existing (physical) Layer-3 “Underlay” network.
Sound familiar? Yet another way to “tunnel something inside of something else”, except THIS time, we add the theoretical limit of a possible 16-million VLANs in our “better-then-your-original” Layer-2 (measly 4096 VLANs).
What can we do and how far can we go with all these VLANs, you may ask?
If the promise of the Spine-Leaf CLOS architecture, “All-Links-Active”, and VXLAN’s 16 million VLANs holds true… VXLAN certainly holds the “Cloud Scale” Data Center potential…to, yes, fall in love all over again…
This promise however, begs a few questions…
- Will EVPN-VXLAN simplify the design and management of your Enterprise and shift “to the Cloud”?
- Is EVPN-VXLAN the network fabric of our lives…or is that Cotton?
(PUBLIC SERVICE MESSAGE: This blog series vows NOT to continue the abuse of the word fabric. We encourage the industry to please take our pledge to stop abusing the word fabric.)
Can one implement a VXLAN-enabled, hybrid-cloud powered network, without spending tens or hundreds of thousands of dollars for a fabric manager?
(With respect to our prior pledge, I’m pretty sure fabric managers should sell clothes or work in High Fashion.)
Or do we have to spend millions of dollars on something that will completely change the DNA of one’s Enterprise network?
What if I told you, and could PROVE to you, that it doesn’t take a complex configuration to deploy an EVPN-VXLAN powered network, or the budget of a small or medium-sized country to do it?
As part of this blog series, what if we could SHOW how you could leverage some simple Ansible integrated with a light-weight UI in Pica8’s Amplified Network Control Platform (AmpCon) to automate and simplify configuration management on your network, and make push-button VXLAN deployment a reality today with the simple purchase of an AmpCon instance to deploy and automate the management of the white box hardware of your choice — no restrictions.
Can’t Wait? Don’t believe us? Contact us for an advanced preview.
Upcoming: In part 2 of this Blog series we’re going compare what actual EVPN-VXLAN configurations look like across vendors. Here’s a preview:
Pica8’s EVPN-VXLAN recipe in 25 lines or less of code: A few lines of BGP, a dash of MLAG, a pinch of OSPF, and super-simplified VXLAN VNI mapping to traditional VLANs and….
set protocols bgp local-as 65001
set protocols bgp router-id 10.1.1.202
set protocols bgp peer-group RR remote-as “internal”
set protocols bgp peer-group RR update-source “10.1.1.202”
set protocols bgp peer-group RR evpn activate true
set protocols bgp neighbor 10.1.1.203 peer-group “RR”
set protocols bgp neighbor 10.1.1.204 peer-group “RR”
set protocols mlag domain 1 node 1
set protocols mlag domain 1 peer-ip 172.16.1.1 peer-link “ae1”
set protocols mlag domain 1 peer-ip 172.16.1.1 peer-vlan 4094
set protocols mlag domain 1 interface ae11 link 1
set protocols mlag domain 1 interface ae12 link 2
set protocols ospf router-id 10.1.1.202
set protocols ospf auto-cost reference-bandwidth 200000
set protocols ospf network 10.1.1.0/24 area “0”
set protocols ospf vrf pica8 router-id 10.2.100.2
set protocols ospf vrf pica8 auto-cost reference-bandwidth 200000
set protocols ospf vrf pica8network 10.2.0.0/24 area “0”
set vxlans vni 10010 decapsulation mode “service-vlan-per-port”
set vxlans vni 10010 vlan 10
set vxlans vni 10020 decapsulation mode “service-vlan-per-port”
set vxlans vni 10020 vlan 20
set vxlans vni 10030 decapsulation mode “service-vlan-per-port”
set vxlans vni 10030 vlan 30
Stay tuned for our next post on the VXLAN…Tunnel of Love…Part 2
- “The Fabric of Our Lives” – Trademark, Cotton – https://thefabricofourlives.com/
Neal Trieber is a Senior Sales Engineer for Pica8