0

Connect a VXLAN-EVPN DC to the Public Cloud the right way

In my latest blog post i was ranting on how you should not do cloud connectivity, and specifically how you should stay miles away from whoever suggests the use of vxlan to “extend layer 2”.
Today i wanted to show you instead how you could actually extend your network into the cloud to allow workload mobility. It’s assumed that your application is “cloud ready” and won’t require a layer 2 adjacency with other components.

As part of a customer project i was supposed to design a cloud connectivity solution that would allow to extend several VRFs into AWS. The requirements were very clear, so let’s list them:

1. It is required to extend around 15 VRFs into AWS to allow application migrations into the cloud.
2. The solution needs to be ready for other clouds like Azure or IBM Cloud
3. The solution needs to be scalable and be able to ensure support to additional VRFs without network redesign

The high level solution

Simply put, what we did was to extend VXLAN-EVPN Overlay into AWS, specifically by making the CSR 1000v a vtep.
In my specific use case, the customer is running a dual site VXLAN-EVPN DC with EVPN Multi-Site for the DCI Continue reading

0

Public Cloud connectivity done wrong

If your idea for interconnection and migration to the private cloud involves using NSX and L2VPN so that you can “stretch the vlan” between your NSX private farm and the one into the Cloud you are doing it wrong.

No matter if you are using VXLAN as a transport or any other technology, if your plan involves layer 2 extension you are doing it wrong.

Not every application should be migrated to the public cloud, and most definitely you should not migrate something that relies on a layer 2 adjacency to work.

If layer 2 extension is a way to allow ip mobility, then again, it’s just a lazy design. There are better ways to provide same-subnet IP mobility that doesn’t require layer 2 (see LISP or BGP-EVPN Type 5 routing for example).

Even if it works on Power Point or on a small demo, you really should NOT.

0

Scaling EVPN Multi-Site Overlays using Route-Servers

Cisco’s EVPN Multi-Site it’s a great technology that allows us to achieve massive scale of an EVPN network. With the latest release, the official scalability numbers give us something in the realm of over 12000 VTEPs (512 VTEPs per site x 25 sites).
I’m in no way suggesting that you would need such a big topology and you definitely should segment way sooner you reach the limit, but still…

The main configuration requirement for the Multi-Site overlay is to have a full mesh of eBGP peering between all border gateways.

This has scalability drawbacks as usual. Not only each leaf will have ever growing number of peers which will soon grow out of control, but maybe, worse is the fact that after one site is added, every other site must be touched too.

To avoid a full mesh, for iBGP topologies we would be using a Route Reflector, but with eBGP that’s obviously not an option. So, instead of a RR they way to scale eBGP peerings is to leverage a Route-Server.

A Route-Server provides route reflection capabilities and as such it must ensure that NLRIs attributes like the Next Hop and route-targets aren’t changed.
In Cisco’s EVPN implementation, the Continue reading

0

SONiC and White Box switches in the Enterprise DC! – Part 3

After discussing the architecture of our design during part 1, and the underlay configuration during part 2, today i’ll show how the overlay it’s configured and hopefully we will be able to draw our conclusions to the question: Are SONiC and White Box switches ready to be used in the enterprise DC?

Our two servers will be connected with LACP and trunk interfaces. 1 VLAN will be bridged (no SVI) and both servers will have an interface into such vlan so that layer 2 can be tested.
Other 2 vlans instead will each be configured on a different pair of switches together with an SVI so that Layer 3 symmetric IRB can be tested.

VRF Configuration

First of all, let’s create a VRF. This vrf requires an VLAN and a Layer 3 VNI for symmetric IRB to function. Configuration is really simple, but a small caveat must be overlooked, specifically every vrf must contain the prefix Vrf- in the name.

From a configuration point of view, we have to follow the usual steps:

1. Create a VRF
2. Create a Vlan and allow it to the peer-link port channel
3. Create a SVI interface and assign it to the VRF itself
4. Continue reading

0

SONiC and White Box switches in the Enterprise DC! – Part 2

As discussed during our part 1, we are trying to configure a VXLAN-EVPN fabric using SONiC on white box switches in order to determine if Open Networking is ready to be deployed in most enterprise DCs.

As a small Recap, below is the topology we are trying to bring online:

Familiarise with the OS

The most interesting thing of SONiC is its architecture!
I’ll write a blog just about it because it’s a fascinating topic, but in short, every single process is living inside a dedicated container.

Linux SONIC-Leaf301 4.9.0-11-2-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64
You are on
  ____   ___  _   _ _  ____
 / ___| / _ \| \ | (_)/ ___|
 \___ \| | | |  \| | | |
  ___) |  | |\  | | |___
 |____/ \___/|_| \_|_|\____|

-- Software for Open Networking in the Cloud --

Unauthorized access and/or use are prohibited.
All access and/or use are subject to monitoring.

Help:    http://azure.github.io/SONiC/

Last login: Thu Apr 20 12:52:21 2017 from 192.168.0.31
admin@SONIC-Leaf301:~$ show version 

SONiC Software Version: SONiC-OS-3.0.1-Enterprise_Advanced
Product: Enterprise Advanced SONiC OS - Powered by Broadcom
Distribution: Debian 9.12
Kernel:  Continue reading

0

SONiC and White Box switches in the Enterprise DC! – Part 1

In recent years two buzz words began to arise: open-networking and white box switches. Those two words go often hand-in-hand with each other. They are often promoted by big names like Facebook or Microsoft.
From the software side, SONiC is maybe the biggest player out there as it powers Microsoft Azure’s cloud, while from the hardware side, Accton has arguably been one of the most important vendors.

The truth though, at least in my opinion, is that while this innovation is great it is not ready to be embraced by everyone yet. Only companies willing to make this “leap of faith” can take advantage of all of this, but what about us poor mortals? Are SONiC and white boxes ready to be widely deployed? Well let’s give it a look!

We will be deploying a simple VXLAN-EVPN Fabric like in the picture below and we will be checking how difficult is to configure and troubleshoot the fabric, but also and most importantly if this common Enterprise design actually works.

The Hardware

For our spines we’ll be using Edge-Core’s AS7816-64X, powered by Broadcom’s Tomahawk II chipset. This switch is a 2RU lean spine providing 64x 40/100 Gbps QSF28 ports.

For Continue reading