VXLAN and why you should care as a service provider

As some of you may have heard Mikrotik has added in some VXLAN support in the latest RouterOS7 beta.  What is VXLAN and how would service providers use it? Let’s start out with some broad information about VXLAN

Where does TRILL and VXLAN fit in to your network strategy?

The always interesting RFC read
https://tools.ietf.org/html/rfc7348

This document describes Virtual eXtensible Local Area Network
   (VXLAN), which is used to address the need for overlay networks
   within virtualized data centers accommodating multiple tenants.  The
   scheme and the related protocols can be used in networks for cloud
   service providers and enterprise data centers

Boil it down for me. What is vxlan?
In short, VXLAN allows you to create a layer2 network on top of a layer3 network. It allows you to bind separate layer2 domains and make them look like one. If you are thinking this looks like a GRE tunnel, you are correct except the layer2 domains are still separate with tunnels. VXLAN is mainly touted as a way to interconnect data centers. If you are having to use spanning-tree then VLXLAN is an answer.

Okay, but why not use tunnels or MPLS?
VXLAN allows you to accomplish what GRE does without having to change the network design. By using VXLAN you are also able to have standalone layer2 domains that talk to each other. With the tunnel approach, you have to do a lot of manual configuration.

Is this just a data center thing?
VXLAN was designed to solve many of the edge computing and hyper-scale computing issues. Imagine having compute nodes in different parts of a data center or even in different data centers.  You want all of those nodes on the same VLAN.  With GRE you could extend that VLAN, but with VXLAN you can have two standalone layer2 VLANs that are merged together. VXLAN also solves the 4096 VLAN issue.  This is important in hyper-scale cloud computing.

VXLAN benefits in a nutshell

  • increases layer2 segments to 16 million
  • Centralize control
  • Standards-based
  • Scalable

VXLAN downsides in a nutshell

  • Multicast must be available
  • more overhead to layer2 packet
  • no built-in encryption
  • Slow adoption of ipv6 support by open source

What about the service provider? How can I use this?
In a service-provider network, you have things like broadcast issues. Basically, bridging is bad. Your layer2 networks need to be contained. Imagine you are a service provider who is providing LTE services. You may have an LTE VLAN on your network.  Historically you would have to extend your VLAN across the network in order to do management and access your LTE core. Now you have this large broadcast domain across your entire network.  Or worse yet, you have tunnels to other cities or locations you don’t have physically connected to your network.  Now you have tunnels a part of your LTE VLAN.  MTU issues and other things are now a part of your life.

With VXLAN each LTE node can have its own layer2 VLAN but still talk to the others. This prevents the broadcast storms which can occur.

Another use for VXLAN is a way to allow managed service providers to deploy large scale networks over the 4000 limits of VLANs.  You could literally deploy thousands of layer2 segments to tenants

Why I should or should not care about VXLAN as a service provider?
If you just have a couple of layer2 networks to extend across your network VXLAN is not for you. However, VXLAN does allow for multipath routing and other protocols to be extended to remote networks.

VXLAN adds 50+ bytes of overhead to the layer2 frame. In many service provider networks, this is not an issue due to MTU being raised for MPLS, etc.   IP multicast must be extended across the entire network. Mac addresses are used in creating a distribution network across all of the routed layer2 domains.

Large service providers have started looking at segment routing to solve many of the issues I talk about. This causing them to gravitate toward EVPN. EVPN allows for BGP for the control plane and MPLS for the data plane. More on this coming soon.

In closing, VXLAN is an ultra-cool technology and has use cases for service providers.  Other methods also exist to solve these issues in the service provider world. For those of you looking to learn all you can, I will be posting a list of links for my Patreon folks.

Interesting Network Monitoring tool

https://nav.uninett.no/

From their Web-site

NAV (Network Administration Visualized) is a free software program to monitor networks, developed by Uninett and used by universities and corporations around the world.

 Customizable dashboard
 Extensive statistical overviews
 Configuration on the fly
 Full traceability of users and equipment
 Device and vendor agnostic

A little reboot now and then..

Just a reminder that rebooting does help. My home network was experiencing slowness and lag.  Xbox games were having issues, etc.  Started pings to various sites and they all looked this way. Even to the provider’s DNS.  I rebooted the CPE and all is well.  Sometimes it’s the simple things.

Before the reboot

After the reboot

Management Networks in the xISP field and Enterprises

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.

MacOS Catalina RIP 32-bit programs

As many of you, Mac users may know the new Mac OS version, codenamed “Catalina” has dropped support for 32-bit programs.  Some of the programs I use on a regular basis are listed below.  If they have an update I will note it, and if they do not I list an alternative.

Zterm – Terminal Emulator.  I now use Serial https://www.decisivetactics.com/products/serial/.
TFTP – https://www.decisivetactics.com/products/trivial/
Textwrangler – BBedit https://www.barebones.com/products/bbedit/index.html
Dragthing – Icollections https://naarakstudio.com/icollections/

ISP vs Enterprise networks

I recently was hanging out with an ISP admin who moved over from the Enterprise world. After a few days with him, it rekindled the interest in writing this article. From a high level, a network is a network. Its job is to move bits to and fro. The goals of the network are where we start to see networks separate themselves. Let’s start with some simple goals of each system.

An enterprise network’s goal is to protect the end-users from outside threats and themselves while giving access to the things they need for their job. An enterprise admin deals with things like firewalls, file servers, software, and Domain controllers. Switches and routers are backend systems for the enterprise. A means to deliver the software to the end-user.

An ISP network’s goal is to give access to the Internet as a whole to its customers while protecting its infrastructure.  Access points, fiber ONTS, and backhauls are the things routinely dealt with by ISP admins. Servers and things are backend systems for the ISP. The servers become the support systems to deliver access to the customers.

The most significant difference between the two networks above is the Enterprise customers are given access to what they need for their job. If they need the Internet, it is routinely filtered for content, and non-work related sites are blocked. Admins of the Enterprise network follow the “block all and allow what is needed” approach. Sure, the Enterprise admin deals with things like WAN connections, switching, and sometimes even BGP but not in the same ways a Service provider does.

Typical corporate or enterprise network

In contrast, Service Provider networks should give unfettered access to the Internet and leave it up to the customer to decide what they should and should not restrict access. With ISP customers you are only dealing with Internet access and don’t necessarily know what the users are doing with the Internet “pipe”. You don’t have to worry about content filtering (unless that is an add-on or your business model), file shares (handled by corporate VPNs) and restricting access to things.

Typical ISP network

My oversimplified view is most ISPs mainly deal with layers 1-3 of the OSI model for their access networks, while Enterprise networks deal a lot with layers 4-7.  The software takes focus, and layers 1-3 are just necessary to make the software work.   In other words, the corporate network deals with the LAN more than the WAN and the ISP network deals with the WAN more than the LAN. As corporate networks grow these lines tend to blur a little.

If you are an ISP admin, your goal should not be blocking what users are doing. Your goal should be to give the user fast speed and the lowest latency possible while protecting your infrastructure from them and the outside world. I mentioned latency because of gaming and streaming. Every device the customer goes through it adds latency. Sometimes its fractions of a millisecond, but there is no free lunch. This speed hit is why firewalls have limited uses in the ISP world for access customers. Firewall options give you a myriad of choices when it comes to throughput and latency. These licensing options for things such as the number of concurrent connections, latency level pricing, and the sheer number of users supported. You pay for the more connections you need to run through the firewalls. What may be useful for a corporation of 500 users probably won’t support a 500 user ISP if everyone is routed through a firewall.

So what is someone to do with all this information? If you are an ISP, you should adopt and adapt the following guidelines for your business.

1. Don’t firewall your customers on your access network. Let them be responsible for that. If you are a managed service provider (MSP) then you have firewall services at the desktop and router level you can sell. If you are just an ISP you can sell a managed router service to help protect the customers and your infrastructure. However, don’t be heavy-handed as it will create more problems than it solves (see #2)

2. Things change so much in terms of how programs and apps utilize networks. Customer demand routinely drives service providers to adapt and change with the times. An ISP who restricts what their customers do gets left behind pretty quickly. In some instances, you even have laws about limiting access to content.

3. As technology evolves so does the use of your network.  Restricting customer access to the Internet via firewalls creates more support because you are routinely editing rules, troubleshooting, and upgrading firewall software.

I want to close with a little philosophy.  It’s not that firewalling an ISP network is a bad thing, it’s just not very efficient and cost-effective.  You need to keep buying more and more firewalls to keep up with demand.  Firewalls have their place in corporate environments. In my next article, I talk about how ISPs should be running both types of networks. Look for this coming soon.

Udemy Course of the week

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.