Automated DataCenter Core Switching: VxLAN Tunnel End Point (VTEP)

A couple months ago I was in a Briefing with Kenneth DuDa, CTO at Arista Networks, And I just brought to the table a short simple question: What is next in datacenter core switching design? And he started to whiteboard a little diagram with three layers of switches. In the middle we found the spine boxes which are in charge of supporting the core of the communications using routing protocols. Below the previous ones, he drew a couple of boxes more (which could be the Top of Rack or ToR switches), and finally above the spine switches, there were the edge or VTEP switches (VXLAN Tunnel End Point). At first I didn’t understand what he was trying to show us, then I asked him how could we be able to communicate different hosts in the datacenter connected to different ToR switches?. Then, he added to the diagram some servers that belong to the same network segment connected directly to different ToR switches. He wrote some IP addresses as an example in every server. Then, he started to show us how to create a tunnel across the Layer 3 comprised of spine boxes… at last, I could understand how the magic really works.

core switch datacenter

After that discussion, we could see more scenarios where the edge switches from the top of his diagram can manage the communications between the ToR and the outside world. The beauty of this is that by using Open tools and protocols, there is no need to touch any of the spine boxes at all. We don’t have to worry about how to maintain spine’s settings synchronize between its different boxes. We don’t need to manage them or see how to balance their resources to avoid bottlenecks. This is a highly automated core datacenter switching design, that could not only help us to save a lot of time creating and provisioning new segments for network clients, but also to save a lot of electric power, minimize risks and maintenance time. It’s what make a leader like us to encourage other DCs to use open platforms and protocols in the region.

It’s also possible to connect virtual instances through VTEPs from/to VMware ESX to physical servers. We can map VXLAN to VLAN across different ToR switches. I don’t know exactly how this configuration could affect response time between ends. Maybe there could be a bit overhead. Nevertheless it’s worth to see how it works.

Evidently Open Standards are making a difference. It’s curious how our perception of a robust high performance network design stays locked at the perspective of just one vendor like Cisco. Thinking about it like “the” standard for any of these cases. I don’t have nothing against Cisco. We all recognize and feel safe around their standards. However, it is a must to have at least two options if you want get competitive costs from vendors.

Finally, nowadays VXLAN has a wide influence on big vendors despite its “draft” state. It will be strongly used by the time it goes to a full standard option.

Special thanks to Erick Maqueda, Network Tech Leader at Swat Team, who help me to write this note.

4 replies »

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: