September 02, 2015

Networking Now (Juniper Blog)

Ready to go virtual? We have what you’re looking for….

If you're like most organizations, a virtual firewall is on your list.  What should you be looking for in a virtual firewall?  read the infographic to learn what experts say should be top considerations. 

vSRX infographic.PNG

by rajoon at September 02, 2015 09:20 PM

Mobile is Here....Are you Ready?

infographic.PNGMobile data traffic is expected to grow at a CAGR of around 45 percent between 2013 and 2019, resulting in a 10-fold increase over that time span...learn more about how mobile traffic will impact your network in this new infographic.

by rajoon at September 02, 2015 07:00 AM

The Data Center Overlords

Traditional versus Cloud Native Web Applications

Here’s a quick whiteboard session of the differences between traditional and cloud native web applications.

by tonybourke at September 02, 2015 01:40 AM

September 01, 2015


Centralized vs. Distributed SD-WAN Functions

In the world of idealistic fantasy, an software defined network of whatever kind would centralize all functions. Pesky reality gets in the way of idealism, and so it is that we find full centralization to be an impractical idea.

by Ethan Banks at September 01, 2015 07:56 PM

My Etherealmind
Potaroo blog

The Global Village Idiot

I recall from some years back, when we were debating in Australia some national Internet censorship proposal de jour, that if the Internet represented a new Global Village then Australia was trying very hard to position itself as the Global Village Idiot. And the current situation with Australia’s new Data Retention laws may well support a case for reviving that sentiment.

September 01, 2015 04:30 AM

XKCD Comics

August 31, 2015

The Networking Nerd

The Blame Pipeline

wc_pipeline sketch

Talk to any modern IT person about shifting the landscape of how teams work and I can guarantee you that you’ll hear a bit about DevOps as well as “siloed” organizational structures. Fingers get pointed in all directions as to the real culprit behind dysfunctional architecture. Perhaps changing the silo term to something more appropriate will help organizations sort out where the real issues lie.

You Dropped A Bomb On Me

Silos, or stovepipes, are an artifact of reporting structures of days gone by. Greg Ferro (@EtherealMind) has a great piece on the evils of ITIL. In it, he talks about how the silo structure creates blame passing issues and lack of responsibility for problem determination and solving.

I think Greg is spot on here. But I also think that the love of blame extends in the other direction too. It is one thing to have the storage team telling everyone that the arrays are working so it’s not their problem. It’s another issue entirely when the CxO-level folks come down from the High Holy Boardroom to hunt for heads when something goes wrong. They aren’t looking to root out the cause of the issue. They want someone to blame.

That’s where the silo comes in. The vertical integration and focus on team disciplines means the CTO/CIO/CFOO get to find out which particular technology was responsible for the issue and blame those people. Modern IT organizations revel in blame assignment. What they want more than anything is to find out who is responsible and berate them until they feel vindicated.

Silos aren’t organizational structures. They are pipelines that allow management to find “responsible” parties and get their retribution for any problems that happen. The focus lies solely on punishing the guilty rather than correcting the problem. Which leads to people not wanting to be challenged outside of their team environment for fear that they’ll get double the blame when something goes wrong.

Trans-Organizational Pipeline

How can we fix this issue with silos and stovepipes? Think for a moment about the physical structures that we use to model them. Silos and stovepipes are all vertical. They might as well be using sewer pipes for a visual representation. After all, the crap does flow downhill.

A better model for the modern IT environment should be the horizontal pipeline. These would be more like oil transport pipelines or other precious materials. Rather than focus on storing things vertically, horizontal pipelines are all about getting raw materials to a processing facility. There isn’t time to waste along the way. Product moves from one location to the next rapidly.

That’s how teams should function. Resources should be allocated and processed. Equipment should be installed and configured. Applications should be installed and be operational. No time to waste. But who should do it? Which team gets the vote?

The reality of the world is that this kind of implementation style needs a cross-sectional horizontal team. Think about the old episodes of Mission: Impossible. The IMF didn’t pick the disguise team to infiltrate or the computer team to hack door locks. They found one or two people with the unique skills to get the job done and focused them on their task. And when the impossible mission was completed everyone went on their merry way back to real life.

In the case of IT teams, new technology products like hyperconvergence and programmable networking require the inputs of many different disciplines. Creating ad-hoc teams like the IMF can go a long way to helping stagnant IT departments rapidly embrace new technology. The rapid implementation approach leads to great things.

But what about the blame? After all, CxOs love to point fingers when things go wrong? How does a horizontal team help? The best way to treat this kind of issue is to remember that these new, smaller cross-functional teams have a much larger atomic unit than traditional silos. A CTO can blame an individual on the storage team for a failure. But in a cross-discipline team, it is the team that is responsible for success or failure. Blame, if any, resides with the team itself and not the people that comprise it. That kind of insulation helps individuals rise above the fear of committing egregious errors and instead embrace the kinds of thinking needed to make new IT happen.

Tom’s Take

The best teams don’t happen by accident. It takes effort to make a group of people across disciplines work together to make amazing things happen. The best way to make this happen is to form the team and get out of the way. No blame shifting. No segregation of skills. Just putting awesome people together and seeing what happens.

The sooner we stop putting silos around teams for ease of management the sooner we will find that people are capable of amazing feats of technology. Let’s turn those blame pipelines into something infinitely more useful.


by networkingnerd at August 31, 2015 07:31 PM


How to Bring SDN/NFV into Reality

Unless you've been living inside a cave, or on top of a mountain without any Internet connection, you must have heard or read the news about Software-Defined Networking (SDN). In fact, SDN news pops up too often these days it makes some skeptics start thinking whether it is really real or just another hype in networking industry.

The challenge is it seems like everybody comes with their own definition of SDN. Each networking vendor displays its solution based on each own interpretation of SDN implementation. IETF group called the Interface to the Routing System (I2RS) is still trying to standardize southbound programming protocols and network-wide, multilayer topologies that include both virtual and real elements, network overlays and underlays. Open Networking Foundation (ONF), as a user-driven organization dedicated to the promotion and adoption of SDN, until today is mainly focusing on standardization of OpenFlow protocol. And the rise of new SDN startups, no doubt have created lots of excitement with many innovations within SDN spaces, contributes to the confusion at the same time.

The questions from today's business leaders in companies that consume networking technologies: if we want to embrace SDN, are we on the right track? Which way to go? For some, the question is even more basic: What to do to get to SDN? How to start?

To try to find the answers to those questions, perhaps we should refresh our memory how it was all started. Everybody has heard the story how some smart people at Stanford University initiated Project Clean Slate, to explore what kind of Internet we would design if we were to start with a clean slate and 20-30 years of hindsight. Project Clean Slate led the development of OpenFlow.

According to Wikipedia, OpenFlow is a Layer 2 communication protocol that gives access to the forwarding plane of a network switch or router over the network. In "traditional" network paradigm, control and data (forwarding) plane reside within the physical device such as router or switch. In SDN paradigm, not all processing happens inside the same device. Control plane is separated from the physical device that will run only as forwarding plane.

OpenFlow has four parts:

Controller - resides on a server and provides control plane function for the network
OpenFlow Agent - resides on a network devices and fulfill requests from the Controller
Northbound APIs - enable applications to interface with the Controller
OpenFlow Protocol - the Layer 2 protocol that the Controller and Agents use to communicate

Open Networking Foundation (ONF) was formed to accelerate the delivery and use of SDN by standardizing OpenFlow. Deutsche Telekom, Facebook, Goldman Sachs, Yahoo, Google, Microsoft, NTT, Verizon are the board members, while almost all known vendors in networking industry like Cisco, HP, Juniper, Intel etc. sit as ONF members. That shows how important OpenFlow is.

However, the important point to keep in mind that OpenFlow does not equal to SDN. OpenFlow is just one protocol within SDN paradigm. Cisco once shared sample of new protocols for SDN along with their place in multiple layers: from device API layer, to forwarding, control plane, network services, orchestration and management.

Now, you have read this far and may have the One Most Important Question in mind: who cares? What should I care with all this? Who cares about new protocols in the network? How can it help me with my business? Exactly.

Let's first quickly review who were the first ones making noise about SDN in real network: James Hamilton from Amazon released a famous white paper in 2010 saying "Datacenter Networks Are In My Way". As network engineers we have to admit that auto provisioning technique in networking space is way behind the server space. Automation and orchestration in provisioning new Virtual Machine in Data Center can take only minutes to build, to configure the system and even to install service packages (e.g. Apache, DNS etc) in order to make it ready to provide services to the users. While to provision the new VLANs and subnets, to inject the new prefix into Routing Protocol, to create or re-configure Security policy and QoS... well, most networks today are still using manual provisioning method that require at least days or even weeks to complete those tasks.

Urs Holzle, Senior Vice President of Technology Infrastructure at Google, gave keynote speech at the
second annual Open Networking Summit (April 2012) and mentioned that Google has been using OpenFlow as the protocol for their WAN. That was a pretty big statement and somewhat validated OpenFlow as a viable technology in the SDN space.

You may argue that you are not Amazon nor Google. You don't run Massive Scale Data Center that requires multi-tenancy and very fast auto provisioning for services. And you are still happy with your current WAN since the traditional networking protocols that you use can provide predictable behavior, "self healing" the network will find alternate path when the primary path is down, and your network can provide sub-second convergence time during failure. You don't want to even consider new protocol, or new paradigm, that is not proven yet to replace the current one you've been using for years.

And you are absolutely right. For us mere mortals, nothing has changed in networking since Cisco built their first router about 30 years ago. The "traditional" network paradigm has remained mostly intact, until mid-2012. That was the time when VMWare bought a startup company called Nicira, that created Network Virtualization Platform as overlay network, for around $1.2 billion in total. Rumor has it that Cisco was trying to acquire Nicira too, but outbid by VMWare at that time.

What does it mean?

When major networking players such as VMWare and Cisco are willing to spend more than a billion dollar to acquire a startup in SDN, that's a market validation. That gives a strong signal to confirm that SDN business is real. And obviously that acquisition was able to boost lots of investors to started investing in many other SDN startups.

Software defined networking (SDN), as per Wikipedia, is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. To understand this abstraction concept, let's see the different types of Network Programmability.

The traditional network device we know, shown as the most left in the picture, can be managed by the applications using well known protocol from device CLI to SNMP or Netflow. Picture (1) shows how several network vendors have created vendor specific API to access their devices to allow some degree of programmability by the applications, even though we have to follow what is defined in the API. When SDN with OpenFlow comes to the picture (2a) it separates the control plane and data/forwarding plane. This "Pure SDN" approach lets the controller to provide Northbound API for the applications, and to use Southbound API to communicate with network device. Northbound API can be open/standard based or vendor specific, and the Southbound API can be OpenFlow, PCEP, I2RS and other types of open API, or vendor specific API. The result is an abstraction where the application does not need to deal directly with lower level functionality within network device.

Some people argue that all networking technologies that have been built for the past three decades can't be thrown away and replaced by new SDN protocols. Hence they say it's better to keep the network as it is, but have the controller ready to program the network when it's required. "Preserve what works, program when needed". This is the idea behind Hybrid SDN (2b) approach, where the network can continue with its predictable behavior, self healing, and fast convergence, but can be re-program based on the input from the applications. Just like pure SDN, controller can sit between applications and network device to provide the abstraction.

What is overlay networks (3)? When we have physical network built using physical devices and links, called the underlay, then on top of it we create new virtual network topology that can be different with the physical network, then we get an overlay network. It is not a new concept in networking. GRE tunnels or MPLS VPN are some example of overlay network we've been using for years. That idea is being sold by the vendors who sell overlay networks as SDN solution: leave the underlay network as it is, and build completely new virtual network on top of it.

Before we start looking for the answer of which network programmability is the best, let's discuss NFV quickly. Network Functions Virtualization (NFV) is a network architecture concept that proposes using IT virtualization related technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services. So instead of having dedicated hardware for router, switch, firewall, cache engine, DPI, BRAS, NAT etc. we can run those network functions as software on top of common x86 hardware.

That's not a new idea either, is it? Before network devices use dedicated hardware with either "merchant silicon" off-the-shelf chip or vendor's designed-specific ASIC, we used to have Linux firewall or Linux router. So we used to have network functions running as software on x86. What's new? NFV brings the idea to not only virtualized the network functions but to connect them as well, known as "Service Chaining", in order to provide benefits to the business such as time reduction for service provisioning, and dynamic and elastic scale for network services.

Obviously not all network functions make sense to be virtualized. For Network Forwarding function with high throughput, high bandwidth, stateless and predictable, using designated hardware or custom Network Processing Unit (NPU) is a better way. But for many Network Services function with low to medium throughput, stateful and unpredictable, this is the area where virtualization on x86 can shine. In short, when you need more muscle functions, it's better to use special designed hardware. When you need more brain functions, it's better to virtualized the functions.

Now we reach the $1 million question:
How to bring SDN, NFV, Overlay, Programmability etc into reality?

Based on my experience working in this space the past few years, to make any SDN/NFV solutions successful in real world:

1. It must solve Real business problem

Different customers have different business problem to solve. Separation of control plane and data plane as offered by OpenFlow may not be interesting to others outside research or academic institution.

For Massive Scaled Data Center or SP Data Center or Cloud provider, what matter is the automation of new services to scale the multi-tenancy environment. Deep programmability or network overlay may be interesting to support application mobility. For Service Providers that have invested heavily on the WAN infrastructure, what important is to have deep network programmability to monetize the current infrastructure. WAN optimization is another requirement, as well as providing SLAs to their customers. For Enterprise customers, especially the ones that only use network infrastructure to support their core business, the requirement is to have auto provisioning and device config management to provide services.

2. It should be orchestrated to deliver business outcome

SDN to separate the control plane and data plane, and NFV to have network functions and software running on any open standards-based hardware, mean nothing if they don't deliver business outcome. A new component called Services Orchestration should be used to provide automation, provisioning and interworking of physical and virtual resources in order to enable new service offering.

The industry agrees that the combination of these capabilities offer business a path to agility and dynamic networks. To optimally benefit from virtualization, the intersection of all three must be addressed – and on a carrier grade level which means services can be scaled up as well as down easily with complete reliability and security. The confluence of SDN, NFV, and orchestration takes advantage of cloud economics and provides service automation so we can nimbly address new market opportunities and dynamically modify existing services to best benefit the business. With this approach service innovation dramatically changes from weeks and months to minutes and days.

3. It has to follow industry standard and open architecture reference

We don't have industry standard yet for SDN architecture reference. However, ETSI - European Telecommunications Standards Institute has already published NFV Reference Architectural Framework as shown below.

The three main components of the reference architecture:

- VNF is the actual Network Function application, for example virtual router, virtual switch, virtual firewall, virtual load balancer, virtual web filter and so on, along with the Element Management System (EMS)
- NVF Infrastructure consists of virtualization layer that provides abstraction between the physical resources (compute, storage, network hardware) and virtual resources, where we can run the VNFs
- NVF MANO includes Virtualized Infrastructure Manager as resource manager to manage NFVI, VNF Manager to manage the life cycle of the VNFs, and the Orchestrator manager to orchestrate the overall solution

ETSI even defines formalized NFV use cases with potentially virtualized functions.

4. It should be modular, loosely coupled and extensible

Any SDN/NFV solutions will be built using various components. Modular architecture provides benefits since it can be scaled and extended when it's needed. One important note here is: every component should be connected as loosely coupled, and not "locked". It means the solution is expected to run in multi-vendor environment and will have lots of integration to build the whole system.

The picture above shows an example of SDN solution architecture. All physical and virtual resources are managed by Management and Orchestration box, that consists of network control, compute and storage control and service control, with cross-domain orchestration to manage all of them. Customer facing service portal is common to provide self service to the users. Management and Orchestration box provides northbound API for the application, and use various southbound API from all the control layer to the resources. Many other boxes like billing system, trouble management, inventory and service assurance can be attached to have the end-to-end solution.

5. It has to use Open API

In order to make sure all components can interconnect without any vendor locked-in, the solution must use Open API between each component. The Northbound API between Management/Orchestration and Applications, for example, can use REST API, NetConf, SOAP or even XML RPC with standard data format like XML and JSON. The Southbound API from Management/Orchestration toward compute, network and storage resources can use NetConf, OpenFlow, SNMP, Telnet/SSH or even device specific API as long as it is open.

6. It must have continuous development and support, and embrace FOSS

There are many components from SDN solution that can embrace Free and Open Source Software (FOSS). The operating system for the Compute resource, for example, can use Linux. Virtual Infrastructure Manager can use OpenStack. Network controller can use OpenDaylight. All programming languages used like Python or Java are free to use. The main benefit to embrace FOSS components in the solution is we can get continuous development and support from the community, and we don't need to create all the components in the solution only some focused components that we think matter the most.

Do you think there is SDN/NFV solution today following the points above?

I can give you one example of SDN/NFV solution that complies with all the six points above. And you may be surprised when I tell you that kind of solution comes from a network vendor that is known to be closed source: Cisco. Yes, Cisco with its Virtualized Managed Services (VMS) actually follow all the points in the list as explained below:

1. VMS solves SP's real business problem in managed services

SPs that offer VPN solution have seen the strong adoption by large and medium enterprises, however the aggregate growth rate is pretty much stable (around 5-7% in many countries). This requires them to find the blue ocean, a new market with expansion opportunity such as Small and Medium Business. However, SMB is very price sensitive and has adopted public cloud services to shift the workload. Huge number of SMBs provides indeed big opportunity, however the solution must be attractive from pricing perspective, time to market/provision the service, and integrated or bundled with other service offering.

2. VMS is orchestrated to cut down time to provision

VMS uses the idea of cloud-based managed service by moving the network functions from CPE to SP cloud.

The CPE is moving to be less and less intelligent, to a point where it becomes L2 network insertion device only. Virtualized Network Functions in SP Cloud are service chained to provide new service offering to the customer. All initiation and configuration of the VNFs and CPE are done automatically to provide agile service provisioning to the end customer. The CPE even uses zero touch deployment mechanism to reduce the requirements to have a technician sent to the location only to fix the device. Once the CPE is powered up, it will call home to register itself to the system and start building encrypted tunnel to its assigned service chained VNFs.

3. VMS follows ETSI architecture reference

I can only provide the following diagram to show Cisco VMS architecture.

However, I can mention that Cisco VMS follows ETSI architecture reference:

- Cisco has extensive list of VNFs from virtual router to virtual web filter, and there is nothing can stop the solution to use third party VNFs
- NVF Infrastructure uses Linux KVM as virtualization layer, running on top of physical hardware resources for compute, network and storage. Again, even though the solution is built using Cisco UCS and networking products, it can accommodate third party hardware as well
- NVF MANO includes OpenStack as Virtualized Infrastructure Manager, Cisco ESC as VNF life cycle manager, and Cisco NSO (previously known as Tail-f NCS) as the Cross Domain Orchestrator

4. VMS is modular, loosely coupled between components, extensible

VMS solution uses modular architecture. There is no locked-in between components. The solution can be integrated with customer existing setup. It can also be extended beyond the main functionality when needed.

5. Yes, all APIs between VMS components are open

The self-service portal can send the service request to orchestrator using Netconf. NSO as orchestrator can use NetConf or REST API to instruct Cisco ESC to initiate the VNFs, which requires ESC to tell OpenStack either with REST or Nova Client API to spin up the VMs. Cisco NSO can provision the configuration of network devices either using NetConf, SSH, REST or device specific API.

6. VMS embraces FOSS

As you can see above, Cisco VMS embraces FOSS like OpenStack, Linux, KVM along with open API to connect them to Cisco specific components. By doing that, Cisco can focus on the component that matters the most like the orchestrator. And innovation with life cycle manager or end-to-end system integration is the competitive advantage from Cisco compare to the other vendors.

Before you accuse me as Cisco fanboy, let me make a statement first: I'm not trying to sell Cisco solution here. Cisco has the best sales force in the market to do that. I just want to give example that even a market leader like Cisco is willing to adapt; to change from closed source to be more open as shown in its VMS solution. This is a big shift in networking industry. And I believe we will see more and more solutions that are inline with the six points above.

And if you are in a company that consumes networking technology, next time any networking vendor comes to offer their SDN solution, you can ask them questions if the solution offered really solves your business problem, how the solution is orchestrated to deliver business outcome, whether the solution follow industry standard and open architecture reference, ask if the solution is modular so can be extended easily without any locked-in to specific vendor, check if it supports open API, and if they have plan to embrace FOSS to ensure continuous development and support.

That, I believe, is the only way to bring SDN/NFV into reality.

by (Himawan Nugroho) at August 31, 2015 09:11 AM

XKCD Comics

August 30, 2015

Peter's CCIE Musings and Rants

CCIERants Phone Control Beta 0.5 (Public Beta) Available now. Control your phone remotely!

Hi Guys

I am excited to announce some new software I have been working on is in public beta. The software allows you to control a Cisco IP Handset remotely, including retrieving a screenshot, sending it a msg as well as listening in on the phone.

Please remember this is a BETA, there is likely quite a few bugs and its best to try and use this software on 7941 - 7945 and 7961 to 7965 phones if possible. It seems to work OK with 8945's etc. but I can't vouch for it 100 percent.

Here are some screenshots of the various features:

Main Phone Screen and viewing log messages from the phone:

Send simple text messages to a collection of phones and listen in remotely to a phone, you can even listen in on an existing call! (So long as you start the listen session AFTER they have joined the call.)


Setup a connection to multiple phones, send bulk commands to multiple phones at once: (Great for doing CTL File deletion!)

You can find the file here:

(Alternative mirror:

Please report any bugs to and be sure to include the text file it SHOULD generate in the directory.

Setup Tips

- You have to have web access enabled for the phone, this is found in the phones device settings, you can also make it part of the Common phone profile

- you must have a user configured on CUCM who has this phone associated as well as CCM End User Privileges

- If you have Informacast or any other application that changes the Authentication URL, you may have some difficulties if you have not configured Informacast to pass through the Auth Requests.

- If you can't get a phone to add and are sure that you have configured it correctly, try browsing to http:///CGI/Screenshot and enter your username/password your putting into the application. If you see the phones screen, your doing it right!

Any feedback or bug reports greatly appreciated please paste them below or email me :).


by peter_revill ( at August 30, 2015 06:04 PM

August 28, 2015

My Etherealmind

Response: Nerd Knobs Are Symptom, Not Cause.

Nerd knobs are treating the symptom but not the cause of bad networking.

The post Response: Nerd Knobs Are Symptom, Not Cause. appeared first on EtherealMind.

by Greg Ferro at August 28, 2015 11:45 AM

XKCD Comics

August 26, 2015

My Etherealmind

Why I Hate ITIL So Much

In the middle of 2014, Justin Warren  sent me a series of interview questions on the topic of why I hate ITIL so much. The process of writing a response got me … um, motivated and spat a substantial amount of bile. Here it is.  Why do you hate ITIL so much? How did you […]

The post Why I Hate ITIL So Much appeared first on EtherealMind.

by Greg Ferro at August 26, 2015 05:37 PM

XKCD Comics

August 25, 2015

My Etherealmind

Five Action Items For IT Infrastructure Architects If the Global Economic Slowdown Starts To Bite

There are signs that the global economy is slowing down. Is It Time To Delay Your Projects To Get Better Pricing and what does this means for IT Infrastructure ?

The post Five Action Items For IT Infrastructure Architects If the Global Economic Slowdown Starts To Bite appeared first on EtherealMind.

by Greg Ferro at August 25, 2015 10:57 AM

August 24, 2015

The Networking Nerd

This WAN Is Your WAN, This WAN Is My WAN

Straw Bales on Hill Landscape, Tuscany, Italy

Straw Bales on Hill Landscape, Tuscany, Italy

Ideas coalesce all the time in every vertical. You don’t really notice it until you wake up one day and suddenly everything around you looks identical. Wireless becoming the new access layer. Flash storage taking hold of the high end performance crown. And in networking we have the dominance of all things software defined. One recent development has coming along much faster than anyone could have predicted: Software Defined Wide Area Networking (SD-WAN).

Automatic For The People

SD-WAN is a force in modern networking because people want simplicity. While Ivan does a great job of decoupling marketing from reality, people still believe that SD-WAN is the silver bullet that will fix all of their WAN woes. Even during the original discussions of SD-WAN technology at conferences like ONUG, the overriding idea wasn’t around tying sites together or driving down costs to the point of feasibility. It was all about making life easier.

How does SD-WAN manage to accomplish this? It’s all black box networking. Just like the fuel injector in your car. There’s no crying about interoperability or standards-based protocols. You just plug things in and it all works, even if you can’t exactly plug one vendor solution into a competitor. Lock in wins again.

The ideas behind SD-WAN aren’t exactly new. Cisco talked about SD-WAN quite a bit at Networking Field Day 10. Here’s Jeff Reed on it:

The rest of the two hour session details how Cisco is using their Intelligent WAN (IWAN) product to drive SD-WAN. The names of the components all sound very familiar to networkers: DMVPN, NBAR, PfR, and so on. That’s because SD-WAN uses a lot of tried-and-true techniques to tie the concept together. There’s nothing earth-shattering about SD-WAN under the hood. In fact, a fair number of people that work at the “pioneering” SD-WAN startups all seem to have their roots in one or more traditional networking companies.

Fables of Reconstruction

Look at the other presenters at Networking Field Day 10. Two of them announced SD-WAN solutions even though they aren’t really known for expertise in SD-WAN. One of them wasn’t even known as a branch office acceleration solution. So why the SD-WAN land rush all of the sudden? What’s behind the need to have a solution?

You probably wouldn’t be surprised to learn that a lot of investors are backing expansion into SD-WAN technologies. It’s a hot property. But why? As above, customers aren’t interested in the technical wizardry that goes into SD-WAN. They aren’t clamoring for it to supplant their current WAN solution and offer a Rosetta Stone of inter-vendor WAN cooperation. What’s behind the push?

It probably goes something like this:

  1. Technologist needs to implement WAN architecture. Is dismayed that things are so difficult.
  2. Technologist starts searching for solutions about WAN. They probably start asking friends about it.
  3. Analyst firm hears that technologists are asking about WAN solutions. Releases a questionnaire asking which technologies you’d like to learn more about.
  4. Responses to questionnaires are loaded into a graph or report that people buy because they don’t know who to talk to.
  5. Companies realize customers want WAN solutions. They break their necks to offer those solutions to keep up with demand.
  6. Investors see companies beginning to offer WAN solutions and think there’s a huge untapped market. They start funding anyone that mentions WAN in a meeting.

By the way, you can replace “WAN” with any technology above and it still works.

Thanks to customers needing a solution for something they can’t configure easily they are going to be inundated with SD-WAN options by the time they turn around. And the biggest concern no long becomes “Who has the easiest solution?” but instead, “Who is still going to be here in six months?”

Collapse Into Now

The reckoning is coming in the SD-WAN market. If a company doesn’t already have an SD-WAN solution in development or if their solution won’t see daylight for another nine months, they are going to exercise the second “B” of innovation and buy it. And they have a lot of prime targets to choose from.

Investors get cagey without an exit strategy. How are they going to win at this game? They either have to get paid with an IPO, with a later round of funding, or by having someone buy out the investment. If an investor thinks they can get their money back (plus a bit of interest) by having this little startup bought by a traditional networking vendor you can better believe they will be advising the startup to sell.

The customers are the real losers in the case of a buyout, or worse a bankruptcy. Those highly proprietary solutions become dead weight if there isn’t any support for them any longer. Black box networking falls apart when the little magical creatures inside the box go away. Which means customers will be skittish of supporting a solution that is likely to go away any time soon.

Who will you support? An established vendor slow to roll out a solution? Or an up-and-coming company with new ideas but at risk of being snapped up by a big bank account?

Tom’s Take

I loved seeing all the SD-WAN discussion at Networking Field Day 10. SD-WAN is no longer magic sauce that aggregates DSL and MPLS circuits with encryption. Nuage Networks showed off deploying Docker apps to remote sites. Riverbed talked about using their WAN optimization experience to deploy SaaS solutions through SD-WAN.

We’ve heard from SD-WAN companies in the past at Networking Field Day. It’s interesting to hear the comparisons between the upstarts and the old geezers. It’s clear there is a ton of money that is being invested in SD-WAN. The trick is to find out your needs and pick the best solution for you. Otherwise you may find yourself losing your SD-WAN religion.


by networkingnerd at August 24, 2015 09:51 PM

My Etherealmind

Response: Snappy for Whitebox Switches | Ubuntu Insights

Ubuntu announces a version for devices, Penguin Computing uses it for network operating systems

The post Response: Snappy for Whitebox Switches | Ubuntu Insights appeared first on EtherealMind.

by Greg Ferro at August 24, 2015 01:00 PM

Response: Arista EOS & Quality

This video from Ken Duda at Arista is, perhaps, the best explanation of Arista’s success with customers. As an engineer, I found this talk inspirational. No bonuses for hitting ship dates. This avoids “good enough” code getting shipped. Sure there are money problems associated with this but Arista believes quality is better. You write the […]

The post Response: Arista EOS & Quality appeared first on EtherealMind.

by Greg Ferro at August 24, 2015 10:48 AM

XKCD Comics