Starlink: First Impressions

Starlink

So my Starlink kit is finally here! A number of folks have asked for first impressions so I’m going to break it down. Long story short, it’s a breeze to setup but operationally, definitely a beta service. Let’s explore.

The Unboxing

What first struck me was how efficiently everything is packaged. The first thing you see is the 3 panel pictogram of how to set this all up right on top and you know what, it pretty much was this easy. When you lift this page and the top molded plastic panel that holds everything in place up, you get to the goods. The form fitting molded plastic on the top and bottom holds the kit in super snug, it’s really well executed. In the box:

  • Starlink Dish with attached mast
  • Ground base to attached to dish mast
  • Starlink Power over Ethernet (PoE) Injector – Model UTP-201S – Output towards dish maxes out at 90W (x2), output towards router maxes out at 17W. Total wattage this guy can produce is 180W.
  • Starlink Router – Model UTR-201 – PoE input 10W – Has built in 802.11a/b/c/g/ac Wifi over 2.4Ghz & 5Ghz and “AUX” 10/100/1000 Ethernet port.
  • Pre-connected cables, 100 foot black cable for dish to PoE injector, 6 foot white for PoE injector to router. I did not plug these in, they were packaged plugged in.

The Setup

Everything is pre-cabled so assembly really comes down to:

  • Snap the dish and it’s attached mast into the base
  • Plug PoE brick into the wall
  • Plug the pre-terminated and weather proofed black cable from the dish into it’s black color coded port on the PoE brick
  • Plug the white cable already hanging off the included router into it’s color coded port on the PoE brick.

From a physical standpoint, that’s all you really have to do! A lot of focus was obviously spent on making this very easy to deploy and I have to say, mission accomplished. I literally got everything up and running within 10 minutes. After you plug the dish in, it points straight up at the sky and starts to tune it self to receive the strongest signal possible with it’s built in motors. If you want to see these motors and the guts of the dish, check out engineer Ken Keiter’s tear down. It’s quite impressive, I highly recommend checking it out. The dish iterated through a few positions and I wish I would have gotten video (might try again soon) but it eventually settled on a position somewhere in the sky NNE of my house.

First thing to do after plugging everything in is to get the Starlink app on iOS or Android. All configuration, control and documentation is really within this app so it’s definitely a requirement. This process is relatively straightforward and is a lot like any other consumer IoT devices you may have picked up recently.

The Starlink UTR-201 router comes with a default SSID which is printed right on it by the “AUX” port on the back of the unit.

The iOS/Android app connects to it over Wifi and adopts the router so now you can adjust some basic settings via the app. Not really much you can configure there other than the wireless SSID, more on that later.

The Operation

Here are some notes on what things look like after we get it all plugged in and up and running. I have to say it’s definitely “better than nothing” as they state. That said, there is room for improvement.

  • Once connecting to the Starlink router via Wifi or wired via the AUX port, you will be DHCP’d a 192.168.1.x/24 address. This is not optional and there is no way to reconfigure different addressing or other DHCP options that I can find.
  • There is no management interface to the router and the options are very limited. There is a rather nice statistics dashboard you can see through the app or surfing in your browser to 192.168.100.1 when connected to it.
  • Your DNS server will be the router at 192.168.1.1 and the search domain is just “lan”.
  • There is no configuring port translations but the router is running Universal Plug n Play (UPnP, see below in the next section) so maybe there will be plans for that later?
  • The WAN interface on the router is behind Carrier Grade Network Address Translation (CG-NAT). More on this later, but this will make port forwarding impossible and having a public IP address for specific applications (things like old school IPSEC VPNs or accessing your own server directly) is not currently possible.

How’s the latency? Pretty good actually.

jg-mbp:~ jason$ ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2): 56 data bytes
64 bytes from 4.2.2.2: icmp_seq=0 ttl=58 time=37.909 ms
64 bytes from 4.2.2.2: icmp_seq=1 ttl=58 time=43.383 ms
64 bytes from 4.2.2.2: icmp_seq=2 ttl=58 time=40.946 ms
64 bytes from 4.2.2.2: icmp_seq=3 ttl=58 time=39.343 ms
64 bytes from 4.2.2.2: icmp_seq=4 ttl=58 time=37.811 ms
^C
--- 4.2.2.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 37.811/39.878/43.383/2.091 ms

This in the same neighborhood as RTTs over my Spectrum connection which is impressive! This is my Spectrum RTT to the same address.

jason@rtr01-jghome:~$ ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_req=1 ttl=53 time=34.4 ms
64 bytes from 4.2.2.2: icmp_req=2 ttl=53 time=32.2 ms
64 bytes from 4.2.2.2: icmp_req=3 ttl=53 time=31.0 ms
64 bytes from 4.2.2.2: icmp_req=4 ttl=53 time=29.5 ms
64 bytes from 4.2.2.2: icmp_req=5 ttl=53 time=34.3 ms
^C
--- 4.2.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 29.513/32.314/34.454/1.910 ms

Next question, how much bandwidth are we getting? This is typically in the neighborhood of around 70Mbps down / 10Mbps up. It’s good, but not great. I was most surprised at the upload bandwidth, I wasn’t expecting to get this much.

Now as far as stability goes, that’s all over the board. Here’s a My Traceroute (MTR) which trace routes the path then pings the hops repeatedly. I let it cycle through 100 times here.

Oof. That’s not pretty. Standard deviation is up there and we are getting upwards of 300ms RTTs right out of the gate. More detail will be below in the next section after I plug it into my VMware SD-WAN appliance.

The Geekier Stuff

The previous sections were the basics that most people want to see. This section will be more of the fun details I observed while playing around.

One thing that I thought was interesting was the router’s hostname resolved via DNS off itself.

jg-mbp:~ jason$ host 192.168.1.1
1.1.168.192.in-addr.arpa domain name pointer OpenWrt.lan.

So it looks like it’s based on OpenWRT. To be honest, this is not uncommon and I know of many other commercial products based on this as well.

I tried to see if there is a web management interface on the router but no such luck. Here’s what a port scan looks like.

Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-28 11:33 EST
Nmap scan report for 192.168.1.1
Host is up (0.24s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
80/tcp   open  http
5000/tcp open  upnp
9000/tcp open  cslistener
9001/tcp open  tor-orport

When you go to port 80 on it, it just redirects you to https://www.starlink.com. Boring!

The router is listening for DNS queries on port 53 and answering them pretty quickly. It appears to be proxying and caching DNS entries which certainly helps speed things up. It’s all about optimizing performance where you can when delivering internet from space and I think this was a smart way to go. Here’s a dig query against the router for a cached entry vs against an internet name server. 2ms vs 63ms is a big improvement!

jg-mbp:~ jason$ dig google.com @192.168.1.1

; <<>> DiG 9.10.6 <<>> google.com @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		212	IN	A	142.250.64.110

;; Query time: 2 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Mar 01 20:40:03 EST 2021
;; MSG SIZE  rcvd: 55

jg-mbp:~ jason$ dig google.com @8.8.8.8

; <<>> DiG 9.10.6 <<>> google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41035
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		117	IN	A	142.250.64.110

;; Query time: 63 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 01 20:40:10 EST 2021
;; MSG SIZE  rcvd: 55

TCP/22 aka SSH is open! But good luck getting in there. Their SSH server uses key based instead of user based authentication which I have to say is refreshing! Definitely a step in the right direction when it comes to IoT device security.

jg-mbp:~ jason$ ssh admin@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is SHA256:owxzwYXb/xsrqqDmR1YkIaAIR6AS1t+iwE0mMvoymYM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
admin@192.168.1.1: Permission denied (publickey).

Universal Plug n Play (UPnP) is running on TCP/5000. Perhaps this is for future application? If you think you know what this is for outside of the standard UPnP application, let me know. Seems weird to have it when there’s another layer of CG-NAT beyond it. Also curious about TCP/9000 and TCP/9001. The most common uses for these are PHP-FPM and The Onion Router (ToR) but I doubt that’s what they’re for. If anyone has ideas I’m all ears.

I wanted to see what happens when you bypass the Starlink router and plug the dish right into a different device instead. It turns out, this works! You get an RFC6598 IP address which is what you do for CG-NAT. Makes sense when you are working with very little IPv4 space and you need to conserve as much as you can.

While in the SD-WAN Platform, let’s check out how well it things Starlink would do for real time applications like voice compared to my Spectrum circuit.

Hmmm… have a little ways to go there it seems. There are a lot of instances of packet loss, jitter, high latency and just plain no connection.

How about IPv6? Turns out, not ready yet.

One thing I really love is the support section. It has some really great insights and commonly asked questions like this one in it.

So that’s it for now! As mentioned before, what a setup experience and it really is a remarkable offering considering they are blazing new territory here. I think the services will only improve over time and you will see greater stability and performance with each software update/improvement SpaceX makes. That said, this is perfectly usable and much better than many of the alternatives those in the boonies suffer today.

I’m going to write a follow up but wanted to get something out for folks to check out. Please do contact me for things you would like for me to try or tell you about! I would absolutely love to share my experiences and learn more by answering your questions.

What do YOU want from SD-WAN?

There have been a lot of discussions lately about the maturation of the SD-WAN market. Much of what I’ve read and heard is that SD-WAN has met its initial promise:

  • Improve performance over the WAN
  • Make better use of bandwidth across disparate circuits
  • Give us a central controller for management/visibility
  • In some cases, save a little money.

So is that it? Are we done? The Network Collective podcast had a great conversation about the Future of SD-WAN. There have been some really great Packet Pushers podcast episodes on this topic lately too. These really got me thinking about what else we can really ask for from SD-WAN and here are some thoughts.

My Wish List

  • Deeper Security Integrations – There’s no doubt security considerations are top of mind right now. With how rapidly remote work was foisted upon all of us with COVID-19, many needed to figure things out fast. Gartner coined the term Secure Access Service Edge (SASE) for the amalgamation of network technologies that make for secure, borderless network access. The current state of the world will certainly make the adoption of SASE much more rapid. I would like to see many of the “pure play” SD-WAN providers adapt and add more native security features to their products. Another option is to create some tight partnerships with security vendors via “service chaining”. Also great would be Zero Trust Network Access (ZTNA) remote access features baked right into SD-WAN solutions. This means the SD-WAN controller should have visibility and policy control over remote access users.
  • Adaptive Multi-Cloud Topologies – COVID-19 has also emphasized the importance of the cloud in order to make sure remote users still have access to the applications and resources they need. A lot of organizations are finding their cloud providers are not “one size fits all” when it comes to certain applications. This makes for some complex network designs and integrations to make it all work together. Optimizing performance across clouds natively will need to be a part of the SD-WAN story moving forward. You are seeing these problems solved today some interesting multi-cloud solutions like Alkira and Aviatrix. I firmly believe SD-WAN vendors are going to need to start building some of this to deal with it.
  • Application Performance VisibilityAIOps is helping IT operations keep up with the rapid pace of change but we’ll start to need this level of smarts in the network to the user and application level. This will help network operators quickly identify network related application performance issues using ML and AI to break down in simple terms. With the introduction of these features, network engineers will be able to quickly see what is going on and more rapidly remediate said issues.

If you were an SD-WAN Product Manager…

These are a few of my ideas but I would like to hear from you. What do you want to see from SD-WAN? Let’s say you are the product manager, it’s up to you to add features that everybody needs but do not have today. Please comment or reply to the post on social to share your thoughts!

Making the Business Case for SD-WAN

There are many things to consider for businesses to adopt a new technology into their environment. SD-WAN has emerged as a better way to build the WAN for organizations as it improves performance, adds greater redundancy and many times can reduce cost. I was fortunate to work with the Packet Pushers to create a white paper on making the Business Case for SD-WAN. Full disclosure, you do need a Packet Pushers Ignition account which is a bargain at a mere $99/yr for resources like this and access to their Slack channel in which you can find some pretty awesome networking conversations! If you want to check out the mini version for free, WAN Dynamics has a brief posted on our site here: http://www.wandynamics.com/sd-wan-building-the-business-case

I hope you find value in it and if you need to follow up, reach out to me on Twitter or LinkedIn!

Connecting the Cloud: SDN, SD-WAN and Multicloud

On the tail of a new report that details how SDN & SD-WAN are becoming a mainstream consideration within many organizations, we have been pondering on why SD-WAN and cloud based network solutions have struck such a chord. 2017 was an incredible year of transformation in the network industry and 2018 is shaping up to be even bigger. The following are some thoughts on what is going on with SDN, SD-WAN and the modern cloud connected network this year.

Last year saw a massive uptick in public cloud adoption within companies and the technological disruption of many traditional, established businesses. We see clients every day overcome by regulatory compliance considerations, security concerns, stacked up operational and technical debt not to mention countless other complex IT challenges. This is forcing many to rapidly move out of traditional models of maintaining their own private IT infrastructure and applications internally to finding cloud based alternatives in order to gain efficiency needed to keep up. Organizations are more frequently than ever looking at their business problems through the lens of the cloud and are beginning to understand the promise and accompanying value, finally prepared to accept change. From where we sit, adoption is widespread and it’s across the board in every vertical and every size of customer. What we see time and again is that as attempts are made to transition to cloud services, legacy infrastructure pieces which are key to supporting cloud efforts like connectivity and security are neglected. With comprehensively managed network services like those that WAN Dynamics provides (SD-WAN, firewall, etc), we were able to assist many to get back on track to accomplish what started their cloud ambitions in the first place: Providing greater agility and value to their core business by enabling cloud adoption. We are firm believers in the cloud but in order to host services there, the infrastructure needs to be ready for it. It was a great year of discovery, education and growth along side our clients helping them solve so many of these new challenges as we go.

The pent up demand to solve problems of leveraging hybrid WAN connectivity options coupled with SD-WAN has been akin to a tidal wave. Most businesses are facing the same issues around intelligently using available connectivity in an active and dynamic capacity, addressing bandwidth quality problems over paths on the fly, seamless failover and truly uniform, holistic visibility and management of the network. Customers we meet with have heard of SD-WAN, understand the key value proposition and know that it is something requiring further exploration. As it becomes mainstream and starts to replace older WANs, we seeing a bit of backlash from the legacy vendors and service providers unable to adapt or find ways to replace shrinking revenue streams from selling and supporting legacy WANs. SD-WAN works in conjunction with a multitude of connectivity options, even L3 VPN/MPLS so for those that wish to hang onto their traditional L3VPN WAN to use with SD-WAN, they can. That said, we find most SD-WAN deployments will take advantage of the direct connectivity over Dedicated Internet Access (DIA) and Broadband and will displace MPLS connections. This will aid in better management of cloud connectivity for the organization with local Internet breakout at locations which require it.

Also of significance is the emerging trends around managing unified network policy within datacenter, cloud and WAN. Networking vendors across the board are working out “Multi-Cloud” strategies to cohesively stitch together all of these environments. Doing so will be key to scale as fragmentation of point solutions become exacerbated by maintaining many different types of infrastructure.

Let’s also not discount security’s role. With so many emerging threats coming at us daily and regulations such as General Data Protection Regulation (GDPR), security is top of mind for many in IT so watch for the cloud and premises based security integrations with the network to mount. There will be many new offerings deployed with “service chaining” which can make tie network elements together in different places be it onsite, potentially as a virtual network function (VNF) or virtual machine running on a general purpose x86 network appliance or even tunneled to a cloud service, making things dynamic and scalable. Most security offerings are pivoting to accommodate cloud, so if a company has a centralized or already well defined security posture which they would like to maintain, vendors are making it easier to do so and easily integrate.

2018 will mark a year of growth in the networking industry that has not been seen in some time. Rapid mainstream adoption of SD-WAN and cloud connectivity options will continue and it will become a core element for network designs from here on out. Those exploring a network refresh without considering the impact of the cloud are doing themselves and their business a disservice. We are looking forward to all of the new applications and opportunities we expect to be a part of!

How Software Defined Wide Area Networking (SD-WAN) Provides Reliable Voice and Video Services Over the Internet

For as long as organizations have tried to make real-time services like voice or video work over Internet Protocol (IP) network pipes, there have been very basic requirements in order to make said services operate effectively. The first requirement for these sensitive applications was a dedicated, business class network line to carry this traffic. A business class circuit was paramount to reliability and uptime required for crucial services like voice or video. This type of network access has low latency characteristics which keeps the amount of time it takes to forward the voice traffic low so that conversations are not made off kilter by long delays.

Also absolutely critical to voice or video over network pipes is an additional layer over these high quality dedicated connections, something called quality of service or QoS. QoS is a suite of bandwidth prioritization and reservation techniques that give select services fast lane access to bypass lesser classifications of traffic and also reserves bandwidth preventing exhaustion of available throughput. Most commonly, QoS is used in tandem with carrier services like an IP VPN or Multi-Protocol Label Switching (MPLS) and have been assumed by many to be the only way to reliably deliver voice services for an organization. I can affirm as a network engineer for the past few decades, this has been the case for most of my career. In order for voice to perform adequately, specific care was required to specify dedicated pipes with prioritization and if you did not perform technical due diligence, you were asking for trouble in the way of poor quality, session disconnections and general voice issues.

Then something called Software Defined Wide Area Networks or SD-WAN came along. This nascent technology space is drastically changing the way we do a lot of things on the wide area network, including managing sensitive real-time protocols that typically require QoS. Read more on what SD-WAN is here.

Let’s take a look at some of the mechanisms that make SD-WAN different versus how we’ve implemented voice over traditional networks up until now. Though many of these techniques may not qualify specifically as QoS, they mimic the capabilities and allow for more reliable Internet based infrastructure to support real-time protocols. The combination of these techniques that have been used individually for decades, create a service greater than the sum of its parts. Features now considered fundamental aspects of most SD-WAN platforms are differentiators from the means we have used in the past to run network traffic over networks.

  1. Multi-Path Steering – SD-WAN can actively forward over multiple paths and is constantly measuring the performance characteristics and properties of each path available. Because it can very rapidly identify issues like high latency, packet loss and jitter, there are software mechanisms to quickly bypass these issues by utilizing an alternate, better performing path on the fly.
  2. Forward Error Correction/Packet Duplication – When issues like data loss from dropped packets arise, if there is only one path available or all paths are experiencing loss, that can be a serious issue with traditional networks with little means to remediate. SD-WAN employs features such as Forward Error Correction (FEC) or packet duplication, which becomes enabled once packet loss is identified on a path.  This technique will send duplicates of each packet in the flow over a single path or over multiple paths to have greater assurance that critical data like voice or video will make it to the destination. At the other side of the session for that voice or video stream, the first packet received will be forwarded to the destination and the duplicates packets will be dropped but if packets are dropped, the duplicated packet will be used in its place.
  3. Jitter Buffering – Voice and video quality can suffer from a network condition called “jitter” which is when the information sent over the network is spaced inconsistently leading to a variable tempo for the stream. The result is audio or video that can have gaps in timing and become impaired. SD-WAN measures the gaps between the packets and can evenly space these packets on the other side providing what is called a “jitter buffer” to realign the timing of these packets to keep the video or audio stream cadence intact.  Jitter buffering has been performed before but traditionally at the application servers and endpoints (i.e. IP phones or IP video appliances).  The unique differentiator for SD-WAN  is performing this inline on the network versus relying on the end points and application servers to supply the jitter buffering.
  4. Prioritization and Queuing over Multiple Tunneled Paths – Because SD-WAN performs it’s queuing and packet forwarding over something called an “overlay”, the forwarding decisions for information that has the highest priority and reservation of bandwidth for applications is performed at a layer above the traditional IP interface. With this, a priority “fast pass” can be given to crucial data like voice, video or other business essential apps bi-directionally and this can be done over all paths available. These overlays are typically facilitated with tunnels over top of existing infrastructure versus on the actual underlay interfaces.  This allows user defined packet queuing and service prioritization configuration overtop of service provider links.

So as you can see, there are many pieces that come together to make IP based voice over broadband and Dedicated Internet Access (DIA) now possible. Our organization has played a part in designing many SD-WAN based solutions for customers and have seen it perform in the “real world” so can attest first hand, it works.  We are beginning a new era of intelligent, self-healing networks which Software Defined Networking (SDN) applications like SD-WAN will be leveraged to usher in.  Though many of the technologies leveraged by SD-WAN are not new, the way they are put together and managed by an SDN controller is and it is this combination that makes it truly powerful. It is with great confidence that I can state, SD-WAN is not a fad and it will be a fundamental piece of how organizations will build out their connectivity moving forward.

Five Use Cases for SD-WAN

A lot of folks I speak with about Software Defined Wide Area Networking (SD-WAN) are trying hard to understand how this rapidly emerging technology works and the places where it can fit with their clients or within their own network. As we acquire more experience with deployments inside many different business and network environments, the results that we discover are quite surprising. There are many applications where SD-WAN is an obvious fit but in some cases, the true value is not exactly what we were expecting. The following are some of the more prominent examples of reasons for SD-WAN we’ve been able to assist with to date:

  1. Voice Services Over the Internet – A lot of small to medium sized businesses have started utilizing voice services over commodity broadband connections with no Quality of Service (QoS) in place. Though most of the time this works adequately, there will be many instances of degradation in quality or dropped calls that can be frustrating. This has just been the reality of utilizing the public Internet for voice services… up until now. With SD-WAN, we’re able to prioritize voice traffic both inbound and outbound while leveraging multi-path technologies to “route around” carrier backbone problems. We’re able to do this with single, stand alone sites in addition to multiple locations.
  2. WAN Visibility and Management – Setting aside the benefits of multi-path link steering, bandwidth aggregation and QoS for a bit, many organizations have no usage breakdowns or application performance visibility in their network today. As a byproduct of the application steering and prioritization baked into most SD-WAN solutions, there is a great deal of reporting functionality available. So now when stakeholders of IT want to know what is happening at their remote locations, they have a graphical interface to see exactly what is happening.
  3. Configuration Uniformity and Standardization – Large organizations which have many sites or will soon have many sites at the hands of rapid growth can have a lot of hands in the IT group working on things. With this, lack of standardization becomes an issue as sites are configured and turned up if there is not a uniform configuration policy. With SD-WAN, attaining a high level of uniformity is simple using features like Zero Touch provisioning and Configuration Profiles to make sure that all sites are configured identically. This also helps greatly for change management if you want to make a configuration update to all of your locations. With this approach, you can update a configuration in one place and push it to all sites, instantaneously. This frees up engineers to solve larger problems facing the business rather than making a minor configuration change on dozens or hundreds of sites.
  4. Remote Diagnostics Capabilities – When there are issues at a remote location, it can often times be difficult to walk users through providing troubleshooting assistance or getting the right software and hardware onsite. With the built in tools into many SD-WAN solutions, the ability to perform packet captures, see network state and what the users see on the network, so that the time vetting issues on the network can be greatly reduced.
  5. MPLS / IP VPN Replacement – MPLS and other dedicated private network infrastructures have begun to outlive their usefulness with many organizations as critical workloads are moved to the cloud. Further, there is growing demand by companies to reduce cost of their expensive WANs that typically have no redundancy or application smarts built in. SD-WAN can easily leverage existing dedicated internet access (DIA) links and even inexpensive broadband connections to build an application aware, private network overlay that provides more applications control, redundancy and critical business application prioritization than traditional network designs.

These are just five examples of things we have been able to help with. We’re happily conducting Proof of Concept deployments for businesses to show the value of SD-WAN and finding new use cases all the time. We find ourselves working on long standing problems that have been occurring for years in traditional networks and within just a few hours of having SD-WAN appliances in the network, fixing them. Using this technology is some of the most rewarding work I’ve ever done as a network engineer. SD-WAN really is a game changer!

Should your telecom provider manage your SD-WAN strategy?

As interest in software defined wide area networking (SD-WAN) grows, many traditional telecommunications providers are jumping on the bandwagon to bundle their data and voice service offerings.  I would caution those exploring their options with SD-WAN as a potential technology solution for their business to think carefully about going this route.  I’ll detail some key reasons why one may want to steer clear of bundled offerings from telecommunications carriers:

  1. A key benefit of SD-WAN is the freedom from carrier lock in and the ability to select the best access provider(s) a particular region has to offer. Bundling with your telecom provider can hamper flexibility to pick and choose the circuits you want.
  2. When bundling with circuits, pricing may prove unpredictable when the packaged offering is pulled apart.  If it’s determined later to choose another SD-WAN solution, to take circuits to other providers or to change the arrangement in any way, it could adversely affect the bottom line and there may even be penalties.
  3. Carriers will represent one, maybe two SD-WAN solutions at most with which vendor partnerships are secured.  Because there is no “one size fits all” model with any vendor currently in the SD-WAN space, Managed Services Providers (MSPs) and Value Added Resellers (VARs) have a compelling story with more choice and a better technological fit as they can represent many different best of breed solutions.
  4. A Managed Service Provider offering provides more of a customized and “boutique” solution which can be tailored to the customer needs.  Service provider offerings are typically standardized and very rigid leaving little room to get “out of the box” to provide advanced integration options.
  5. Telecommunications carriers have a vested interest in maintaining the high margins of services like MPLS.  With that, SD-WAN service offerings will likely be created to augment MPLS services, not replace them whether or not that is the right solution for the customer.

From a technology standpoint, SD-WAN will no doubt create a great deal of value, agility and savings for those running large wide area networks, no matter who it is procured from.  That said, I would advise not locking into a solution that reduces choice and the ability to realize SD-WAN’s fullest potential.

Why I left my job to co-found a managed SD-WAN services company

I left my job of 13 years to found a new company.  It’s the end of an era for me and it was not an easy decision to make.   The reason?  I believe a new technology space known as Software Defined Wide Area Networking (SD-WAN) is one of the most significant advancements we’ve seen in decades as to how we build wide area networks and I want to be a part of it.  I’ll explain.

I’ve worked for one service provider or another for the past 17 years.  I joined Stratos Internet Group, a regional dial-up ISP, on the same day that Naptser debuted on June 1st, 1999.  From dial-up to Carrier Ethernet, frame relay to MPLS, e-mail and website hosting to cloud, there has never been a shortage of new services emerging and exciting technologies to learn about.  In particular, since 2003 I’ve enjoyed helping build a regional business class ISP called Fidelity Access Networks into Fidelity Voice and Data, a boutique telecommunications powerhouse in Ohio.  We married a carrier grade network with out-of-the-box thinking and an unparalleled support experience to offer what I feel were the best products in the business.  Fidelity was a large and very important part of my life for the last 13 years.   As many of you who have worked with us know, Fidelity was acquired by Fusion (FSNN on Nasdaq – http://www.fusionconnect.com/) back in December of 2015.  Fusion is a good fit from a product and services perspective plus fills in the gaps with many services that Fidelity lacked.  Even though all of this was lining up to be an interesting next chapter for me, there was something on my mind.  I felt myself drawn in a different direction.

Enter my interest in this thing called Software Defined Wide Area Networking or SD-WAN.  If you’re in the field of telecommunications or in IT and this is the first you’ve heard of SD-WAN, I assure you, it will not be the last.  I first discovered it in 2012 while I was working on an MPLS deal with an agent partner and one of our sales folks at Fidelity.  We were up against a company that was a very early entrant in the SD-WAN market.  I’d never come across anything like it before but after learning more about their solution, I was impressed.  To be honest, after understanding what they were doing, I found our MPLS solution inferior.   The SD-WAN service was able to tunnel private traffic over commodity public broadband links, aggregate the total throughput of available links so there was never one sitting idle, it achieved redundancy across the connections without a complicated dynamic routing protocol, provided centralized policy and control with application based QoS for a fraction of the price of our offering.  That was just incredible to me.  What a fascinating concept and an absolutely disruptive technology.

After giving all of this more thought, I came to a realization.  Though some minor features and functionality have changed over the years, we have fundamentally been building the same networks since my career began in 1999.  Static, complex and closed.  That said, the advent of cloud services is changing the way we work and is forcing the network to change with it.  Business critical services like ERP and CRM applications, unified communications, hosted voice and video conferencing are moving off of the traditional private corporate network and onto the public, virtual infrastructure we call “the cloud”.   Added to that, the economics of commodity broadband (Cable Internet, DSL, 3G/4G, etc) are beginning to overshadow the value of the symmetrical bandwidth, SLAs and perceived reliability of dedicated links.  The proposition of finding smarter ways to use these commodity connections to provide reliable, high performance connectivity to cloud resources is an undeniable driver so will no doubt continue.  But how do you make these services work over the public internet without tools like QoS or the visibility and control of dedicated links?  It is my belief these objectives will be achieved with SD-WAN.  This new approach to networking will give organizations the ability to put their mission critical apps on commodity cable modem or DSL services to realize performance expectations traditionally found on services like MPLS or dedicated lines.   That is why we at WAN Dynamics will be helping organizations build value driven SD-WAN networks from now on.  There’s no doubt in my mind that in 5 years, organizations who are NOT managing their sites with SD-WAN will be the outliers.