On the topic of measuring WAN metrics, most engineers think to look at the standard statistics of loss, latency, jitter, and reachability for determining path quality. This is good information for a routing protocol that is making decisions for packet flow at layer 3 of the OSI model. However, it is incomplete information when looking at it from the perspective of the overall user experience.  In order for an SD-WAN solution to provide materially better value than a typical packet router, it must look beyond the metrics considered by the router.    

SD-WAN devices shouldn’t be considered routers in the conventional sense. Routers use local tables and algorithms such as Dijkstra to determine the shortest path to a destination for a packet. The term packet is important here. It is all that the router cares about. If you look up the definition of a router, it is a device that functions at layer 3 to deliver packets to their destination network. When there is a problem the router will process the topology change and compute new routing table entries that are a point in time decision of the available paths. These topology changes take time to process. This can cause packet loss, latency, and jitter for anything traversing that segment. Hence why we use those measurements to determine the health of our legacy networks.

To read this article in full, please click here

The fundamental shift of the enterprise toward the cloud has posed a conundrum for many. The largest issue is the state of most enterprise networks. These networks were designed for an era gone by. Their original designs could not foresee the coming of technologies such as SDN, SDWAN, Segment Routing, the Cloud and an exponential increase in bandwidth that have all happened over the past 10 years.

The IPv4 Internet BGP routing table alone has experienced a 10% year over year growth between 2009 and 2017 along. In 2009 the table eclipsed 286,000 routes. Here in 2017 we are at approximately 650,000. These figures only account for IPv4 routes, and not the full IPv4 and IPv6 tables. During that same period we have gone from token ring and 10Base-T to 100GbE.

To read this article in full, please click here

During the past three decades, we have seen a monumental growth in networking technology. From RFC-1163, which describes the beginnings of BGP in 1989 to the cloud and software defined networks of today, our voracious appetite for bandwidth and services have begun to outpace the networking industry’s ability to deliver.

I remember when I had my first “broadband” – and I use that term loosely – circuit installed at my house. It was a 128kbps ISDN line from my local telco. Since it was 1996, I was riding high compared to everyone else using 28.8 kpbs modems to access the internet. Today I have a 1Gbps connection that allows me to stream 4k video from multiple providers. In roughly 20 years, my consumption of bandwidth has increased 8000%!

To read this article in full, please click here

SD-WAN is the hottest topic in networking today. On the one hand, analyst reports state that this industry is in its infancy with less than 5% adoption through 2017. On the other hand, the same analysts project over 50% customer adoption in the next 36 months. Why has adoption been modest to-date, and why is 10X acceleration expected now? The answer lies in understanding the differences between the first generation of SD-WAN (Gen1) and the second generation of SD-WAN (Gen2).

In the old days, WAN routers were focused on providing connectivity using MPLS. The goal of Gen1 SD-WAN was to enable usage of broadband for connectivity. So Gen1 SD-WAN provided better VPN manageability and improved the delivery of voice traffic over broadband connections. However, like many first-generation products, Gen1 SD-WAN has serious limitations, three of which I examine below.

To read this article in full, please click here

This blog post is going a bit outside my usual “make sense to the C-Level” slant. I wanted to get in the weeds about reviewing SD-WAN products. We all know that’s where the fun really is!

I have been doing a bit of evaluation on SD-WAN products and their configurations from the network engineer’s perspective. I have looked at numerous vendors’ products, poured over install guides, and dusted off the CLI.

Everyone who knows me can tell you I am a Cisco fanatic. Hands down, I would rather implement a Cisco technology rather than any other vendor by a 1000:1 ratio. I have spent a majority of my career as a network engineer, and the best network devices to configure and troubleshoot have been Cisco.

To read this article in full, please click here

If you ask a group of 10 people what SD-WAN is, there’s a good chance you will get 10 different answers. So, which one is right?

Well, that depends on your perspective. If you take all the marketing and jargon out of the equation it will be something like the following.

Let’s start off with what the acronym stands for. SD-WAN is a Software Defined Wide Area Network. It is a fresh new approach to how you build your WAN to accomplish the following objectives:

1. Move from legacy packet networking that frequently holds the business back, to an application-policy based approach to build your WAN infrastructure. This is a fundamental shift that is an essential prerequisite for the modern remote office.
2. Eliminate dependencies on your network service provider. Gain the freedom to utilize disparate and sometimes cheaper forms of connectivity to deliver data reliably to remote offices.
3. Make your enterprise and WAN truly cloud-ready. Decouple policy and infrastructure so your applications be delivered to the remote office from the cloud/SaaS/data center in a consistent manner.
4. Eliminate dependencies on proprietary hardware. Gain cost savings and a rapid innovation cycle aligned to business needs.
5. Deliver a great user experience with native application and network analytics that are automatically applied to the network in a self-healing manner.

In addition to business and architectural transformation, SD-WAN delivers hard cost savings. This technology can reduce both OPEX and CAPEX expenditures depending on the solution deployed. The OPEX expenditures are significantly reduced not only through the deployment stage, but throughout the ongoing life cycle of the network.

To read this article in full, please click here