The state of Data Centers and Co-Location in Indianapolis

We like to refer to Indianapolis, Indiana as an “NFL  City” when explaining the connectivity and peering landscape.  It is not a large network presence like Chicago or Ashburn but has enough networks to make it a place for great interconnects.

At the heart of Indianapolis is the Indy Telcom complex.  www.indytelcom.com (currently down as of this writing).  This is also referred to as the “Henry Street” complex because West Henry Street runs past several of the buildings.   This is a large complex with many buildings on it.

One of the things many of our clients ask about is getting connectivity from building to building on the Indy Telcom campus. Lifeline Data Centers ( www.lifelinedatacenters.com ) operates a carrier hotel at 733 Henry. With at least 30 on-net carriers and access to many more 733 is the place to go for cross-connect connectivity in Indianapolis.   We have been told by Indy Telcom the conduits between the buildings on the campus are 100% full. This makes connectivity challenging at best when going between buildings. The campus has lots of space, but the buildings are on islands if you wish to establish dark fiber cross-connects between buildings. Many carriers have lit services, but due to the ways many carriers provision things getting a strand, or even a wave is not possible.  We do have some options from companies like Zayo or Lightedge for getting connectivity between buildings, but it is not like Chicago or other big Date centers.  However, there is a solution for those looking for to establish interconnections.   Lifeline also operates a facility at 401 North Shadeland, which is referred to as the EastGate facility. This facility is built on 41 acres, is FEDRAMP certified, and has a bunch of features.  There is a dark fiber ring going between 733 and 401.  This is ideal for folks looking for both co-location and connectivity.  Servers and other infrastructure can be housed at Eastgate and connectivity can be pulled from 733.  This solves the 100% full conduit issue with Indy Telcom. MidWest Internet Exchange ( www.midwest-ix.com ) is also on-net at both 401 and 733.

Another location where MidWest-IX is at is  365 Data Centers (http://www.365datacenters.com ) at 701 West Henry.  365 has a national footprint and thus draws some different clients than some of the other facilities.  365 operates Data centers in Tennessee, Michigan, New York, and others. MidWest has dark fiber over to 365 in order to bring them on their Indy fabric.

Another large presence at Henry Street is Lightbound ( www.lightbound.com ).  They have a couple of large facilities. According to PeeringDB, only three carriers are in their 731 facility.   However, their web-site lists 18+ carriers in their facilities. The web-site does not list these carriers.

I am a big fan of peeringdb for knowing who is at what facilities, where peering points are, and other geeky information.  Many of the facilities in Indianapolis are not listed on peering DB.  Some other Data Centers which we know about:

Zayo (www.zayo.com)
LightTower ( www.lightower.com )
Indiana Fiber Network (IFN) (https://ifncom.co/)
Online Tech ( www.onlinetech.com )

On the north side of Indianapolis, you have Expedient ( www.expedient.com ) in Carmel. Expedient says they have “dozens of on net carriers among all markets”.  There are some other data centers in the Indianapolis Metro area. Data Cave in Columbus is within decent driving distance.

Where does Trill and VXLAN fit in your strategy?

As networking trends yo-yo between layer-3 and layer-2,  different protocols have emerged to address issues with large layer-2 networks. Protocols such as Transparent Interconnection of Lots of Links (TRILL), Shortest Path Bridging (SPB), and Virtual Extensible LAN (VXLAN) have emerged to address the need for scalability at Layer2.   Cloud scalability, spanning tree bridging issues, and big broadcast networks start to become a problem in a large data center or cloud environment.

To figure out if things like TRILL is a solution for you, you must understand the problem that is being addressed by TRILL. The same goes for the rest of the mentioned protocols. When it boils down to it the reason for looking at such protocols is you want high switching capacity, low latency, and redundancy.  The current de facto standard of Spanning Tree Protocol (STP) simply is unable to meet the needs of modern layer2 networks.  TRILL addresses the problem of STP’s ability to only allow one network path between switches or ports.  STP prevents loops by managing active layer -2 paths.   TRILL applies Intermediate System-to-Intermediate System protocol (IS-IS), which is a layer3 routing protocol translated to Layer 2 devices.

For those who say TRILL is not the answer things like SPB also known as 802.1aq, and VXLAN are the alternatives. A presentation at NANOG 50 in 2010 addressed some of the SPB vs TRILL debate. This presentation goes into great detail on the differences between the two.

The problem, which is one most folks overlook, is that you can only make a layer 2 network so flat.  The trend for a while, especially in data centers, is to flatten out the network. Is TRILL better? Is SPB better? The problem isn’t what is the better solution to use.  What needs to be addressed is the design philosophy behind why you need to use such things.   Having large Layer2 networks is generally a bad idea. Scaling issues can almost always be solved by Layer-3.

So, and this is where the philosophy starts, is TRILL, SPB, or even VXLAN for you? Yes, but with a very big asterisk. TRILL is one of those stop-gap measures or one of those targeted things to use in specific instances. TRILL reduces complexity and makes layer-2 more robust when compared to MLAG. Where would you use such things? One common decision of whether to use TRILL or not comes in a virtualized environment such as VSPHERE.

Many vendors such as Juniper, have developed their own solutions to such things.  Juniper and their Virtual Chassis solution do away with spanning tree issues, which is what TRILL addresses.   Cisco has FabricPath, which is Cisco’s proprietary TRILL-based solution. Keep in mind, this is still TRILL.   If you want to learn some more about Fabric Path this article by Joel Knight gets to the heart of Fabric path.

Many networks see VXLAN as their upgrade path.  VXLAN allows layer 2 to be stretched across layer 3 boundaries. If you are a “Microsoft person” you probably hear an awful lot about Network Virtualization using Generic Routing Encapsulation (NVGRE) which can encapsulate a layer two frame into IP.

The last thing to consider in this entire debate is how does Software Defined Networking (SDN) play into this. Many folks think controllers will make ECMP and MLAG easy to create and maintain. If centralized controllers have a complete view of the network there is no longer a need to run protocols such as TRILL.   The individual switch no longer makes the decision, the controller does.

Should you use Trill, VXLAN, or any of the others mentioned? If you have a large Layer-2 virtualized environment it might be something to consider.  Are you an ISP, there is a very small case for running TRILL in anything other than your data center. Things such as Carrier Ethernet and MPLS are the way to go.

Netflix, IPv6, and queing

While trying to get my Playstation to download the latest “No Man’s Sky” download quicker I figured I would share a little torch action.  This is showing my wife’s Ipad talking to Netflix while she is watching a streaming TV show. Keep in mind this is just an Ipad, not some 4k TV.

Some things to note as you watch this (no sound).

1.Uncapped the connection bursts to 50-60+ megs.
2.The slower your que the connection the more time it spends downloading data.  At slower ques the bursts last longer.
3.If you are handing out IPv6 to customers you should be queing them as well.

Just something to quick and dirty to keep in mind.

ethernet MTU and overhead

One of the most common questions is how much overhead do I need to account for on my transport network? I have put together a quick list to help when you are calculating your overhead.

-GRE (IP Protocol 47) (RFC 2784): 24 bytes (20 byte IPv4 header, 4 byte GRE header)
-6in4 encapsulation (IP Protocol 41, RFC 4213): 20 bytes
-4in6 encapsulation (e.g. DS-Lite RFC 6333): 40 bytes
Addition IPv4 header:20 bytes
-IPsec encryption:
73 bytes for ESP-AES-256 and ESP-SHA-HMAC overhead (overhead depends on transport or tunnel mode and the encryption/authentication algorithm and HMAC)
-MPLS: 4 bytes for each label in the stack
-802.1Q tag: 4 bytes
Q-in-Q: 8 bytes
-VXLAN: 50 bytes
-OTV: 42 bytes

Some rules of thumb when setting MTUs. You won’t get fragmentation if your L2 MTU is higher than your L3 MTU. This is just not the setting, but the actual overhead in use. Just setting it to a number doesn’t necessarily make it right. The above list will help you calculate the minimum MTU you may need. I try to get gear that supports a 1548 MTU and set everything to that. Makes it simple. I still want to know how much MTU I am utilizing because it helps me validate my designs.
The most important rule of thumb is you won’t get fragmentation if your l3 MTU is less than your L2 MTU.

BGP local Pref and you

One of the bgp topics that comes up from time to time is what does “bgp local-pref” do for me? The short answer is it allows you to prefer which direction a traffic will flow to a given destination. How can this help you? Well before we start, remember the high number wins in local-pref.
Let’s assume you are an ISP. You have the following connections:
-You supply a BGP connection to a downstream client.
-You have a private peer setup with the local college
-You are hooked into a local internet exchange
-You have transport to another internet exchange in the next state over
-and you have some transit connections where you buy internet.

So how do we use BGP preference to help us out? We might apply the following rules to routes received from our various peers
Our downstream client we might set their local pref to 150
The college we may set them to 140
Preferred internet exchange peering: 130
Next state IX: 120
Transit ISPs: 100

Now these don’t make much sense by themselves, but they do when you take into account how BGP would make a decision if it has to choose between multiple paths. If it only has one path to a certain route then local-pref is not relevant.

Let’s say you have a customer on your ISP that is sending traffic to a server at a local college. Maybe they are a professor who is remoting into a server at the college to run experiments. There are probably multiple ways for that traffic to go. If the college is on the local Internet exchange you are a member of, that is one route, the next route would be your transit ISPs, and obviously your private peer with the college. So, in our example above the college, with a local pref of 140 wins out over the local exchange, wins out over the next state IX, and wins out over the Transit ISPs. We want it to go direct over the direct peer with the college. Mission accomplished.

local-pref is just one way to engineer your traffic to go out certain links. Keep in mind two things:
1.Higher number wins
2.local-pref only matters if there are multiple paths to the same destination.
3.Local-pref has to do with outbound path selection

Networking foundations

In an article earlier today, I wrote about certifications and the ISP.  The biggest area I see folks go wrong when it comes to networking is having a good understanding of design. One of the analogies I like to use is building a house.   You have several key roles when you build a house.  These can be directly applied to the networking world.

The first is the Architect. Everything starts with this person or team’s vision. The Architect lays out the design and how the network will function. This person needs a wide variety of skills.  They know the product lines they are supporting, they know how these products fit into the overall vision of the network, and they know the limitations of what they are working with, to name just a few of their many skills. These are your CCIE and higher level CCNP folks in certification terms.  They have enough breadth of knowledge to see the entire picture.  Not just what the device in front of them can do. A network architect would know that a certain wireless CPE does not fully support a VPLS tunnel, and would either recommend not using that equipment or come up with a workaround to implement it into the network, if in fact, they were using VPLS.  Many large companies have Architects who implement and validate network designs. These are then pushed to the next group of folks to implement.

The “tradesmen” or “tradeswomen” are the ones who actually implement the designs around the Architects blueprints for the network.  Just like a house who has carpenters, brick layers, and roofers, so do you have folks who know wireless, routing, security, and other disciplines.  These are the folks who can make the machines do what they want them to do. They work off the blueprints to actually make the network talk and function according to the Architects design. these are your CCNA and CCNP level folks. These folks know the equipment configuration in and out.  They are the most responsible for making things work, and knowing how to make it work. The more experienced of these folks typically collaborate with the Architects to provide expert opinions on the latest features of the equipment they are implementing or any limitations of the equipment.

Many folks working in the ISP world wear multiple hats at the same time.   There is nothing whatsoever wrong with this.  You just have to know the limitations of yourself and the things you have to work with. I see multiple illustrations of this on a daily basis. Clients take a router and make it do BGP, OSPF, PPPoE termination, firewall rules, and other things.  Sometimes this is a budgetary thing, maybe just a lack of understanding, or it can even be a sales hype thing. however, not having an understanding of the design and architecture of a network can be costly.

Anyone can build a house. Go to the lumberyard and get some materials, some tools, and watch a few YouTube videos. Bam you are set.  That will probably work until the first time it rains, or it gets cold. Then you are wondering where your design went wrong.  Using plastic on your roof sounded like a good idea until the wind ripped it.  Same can be said in networks.  Start and always have design considerations in mind.  Not just design, but how individual components are best used in that design. Then rely on the tradesmen  to implement them.  You might be one and the same, but don’t wing it as you go.

Learning, certifications and the xISP

One of the most asked questions which comes up in the xISP world is “How do I learn this stuff?”.   Depending on who you ask this could be a lengthy answer or a simple one sentence answer.  Before we answer the question, let’s dive into why the answer is complicated.

In many enterprise environments, there is usually pretty standard deployment of networking hardware.  Typically this is from a certain vendor.  There are many factors involved. in why this is.  The first is total Cost of Ownership (TCO).  It almost always costs less to support one product than to support multiples.  Things like staff training are usually a big factor.  If you are running Cisco it’s cheaper to train and keep updated on just Cisco rather than Cisco and another vendor.

Another factor involved is economies of scale.  Buying all your gear from a certain vendor allows you to leverage buying power. Quantity discounts in other words.  You can commit to buying product over time or all at once.

So, to answer this question in simple terms.  If your network runs Mikrotik, go to a Mikrotik training course.  If you run Ubiquiti go to a Ubiquiti training class.

Now that the simple question has been answered, let’s move on to the complicated, and typically the real world answer and scenario.  Many of our xISP clients have gear from several vendors deployed.  They may have several different kinds of Wireless systems, a switch solution, a router solution, and different pieces in-between.  So where does a person start?

We recommend the following path. You can tweak this a little based on your learning style, skill level, and the gear you want to learn.

1.Start with the Cisco Certified Network Associate (CCNA) certification in Routing and Switching (R&S).  There are a ton of ways to study for this certification.   There are Bootcamps (not a huge fan of these for learning), iPhone and Android Apps (again these are more focused on getting the cert), online, books, and even youtube videos. Through the process of studying for this certification, you will learn many things which will carry over to any vendor.  Things like subnetting, differences between broadcast and collision domains, and even some IPV6 in the newest tracks.  During the course of studying you will learn, and then reinforce that through practice tests and such.  Don’t necessarily focus on the goal of passing the test, focus on the content of the material.  I used to work with a guy who went into every test with the goal of passing at 100%.  This meant he had to know the material. CompTIA is a side path to the Cisco CCNA.  For reasons explained later, COMPTIA Network+ doesn’t necessarily work into my plan, especially when it comes to #3. I would recommend COMPTIA if you have never taken a certification test before.

2.Once you have the CCNA under your belt, take a course in a vendor you will be working the most with.  At the end of this article, I am going to add links to some of the popular vendor certifications and then 3rd party folks who teach classes. One of the advantages of a 3rd party teacher is they are able to apply this to your real world needs. If you are running Mikrotik, take a class in that. Let the certification be a by-product of that class.

3.Once you have completed #1 and #2 under your belt go back to Cisco for their Cisco Certifed Design Associate (CCDA). This is a very crucial step those on a learning path overlook.  Think of your networking knowledge as your end goal is to be able to build a house.  Steps one and two have given you general knowledge, you can now use tools, do some basic configuration.  But you can’t build a house without knowing what is involved in designing foundations,  what materials you need to use, how to compact the soil, etc.  Network design is no different. These are not things you can read in a manual on how to use the tool.  They also are not tool specific.   Some of the things in the Cisco CCDA will be specific to Cisco, but overall it is a general learning track.  Just follow my philosophy in relationship to #1. Focus on the material.

Once you have all of this under your belt look into pulling in pieces of other knowledge. Understanding what is going on is a key to your success.  If you understand what goes on with an IP packet, learning tools like Wireshark will be easier.  As you progress let things grow organically from this point.  Adding equipment in from a Vendor? Update your knowledge or press the new vendor for training options.  Branch out into some other areas ,such as security, to add to your overall understanding.

Never stop learning! Visit our online store for links to recommend books and products.

WISP Based Traning Folks.
These companies and individuals provide WISP based training. Some of it is vendor focused. Some are not.  My advice is to ask questions. See if they are a fit for what your goals are.
-Connectivity Engineer
Butch Evans
Dennis Burgess
Rickey Frey
Steve Discher
Baltic Networks

Vendor Certification Pages
Ubiquiti
Mikrotik
Cisco
Juniper
CWNA
CompTIA

If you provide training let me know and I will add you to this list.

Metro Ethernet Terms

As some of you reading this dive into metro ethernet you should know some terminology

• User-Network Interface (UNI): The UNI is a physical Ethernet port on the service provider side of the network along with a predefined set of parameters to provide data, control and management traffic exchange with the end-customer CPE device. The customer CPE device can be a Layer 2 Ethernet switch, Layer 3 routing node or some of LTE nodes.

• Network-to-Network Interface (NNI):  NNI is represented by the physical Ethernet port on the service provider access node that is used to interconnect two Ethernet MANs of two different service providers. We are also using E-NNI as a reference point for the interconnection of Layer 2 MAN service with Layer 3 service nodes—the provider edge router (PE), a broadband network gateway (BNG), vertical handover (VHO), etc—in the provider network.

• Ethernet Virtual Connection (EVC) is the architecture construct that supports the association of UNI reference points for the purpose of delivering an Ethernet flow between subscriber sites across the MAN.