API Does Not SDN Make
Vendors that slapped API on top of their CLI are quick to claim that they SDN-enabled their boxes.
Not so fast. As I explained in SDN 101 webinar, programmable access to network devices is nice (less so when you're forced to use a vendor-specific API), but it's not SDN.
Openstack SDN – L2 Population and ARP Proxy
In the previous post we’ve had a look at how native OpenStack SDN works and what are some of its limitations. In this post we’ll tackle the first one of them - overhead created by multicast source replication.
Continue readingSD-WAN Market Consolidation? Don’t Hold Your Breath
The torrid growth projected for the SD-WAN market means that a ridiculous number of competitors will be able to sustain themselves for a long time.
The post SD-WAN Market Consolidation? Don’t Hold Your Breath appeared first on Packet Pushers.
SD-WAN Market Consolidation? Don’t Hold Your Breath
The torrid growth projected for the SD-WAN market means that a ridiculous number of competitors will be able to sustain themselves for a long time.
The post SD-WAN Market Consolidation? Don’t Hold Your Breath appeared first on Packet Pushers.
Overheard At Interop, Day 4
Get the inside scoop on Interop Las Vegas.
The Changing Role Of The Network Engineer
Interop puts spotlight on how the job of a networking pro is evolving as software takes center stage.
Setting Up DC Fabric Simulation With OpenSwitch and GNS3
Note: This article was originally published here.
In the previous post I covered the basics about setting up the OpenSwitch Appliance using GNS3. The setup was fairly simple: two switches connected to each other and exchanging LLDP packets. In this post we will setup a more elaborate network to simulate a DC fabric (although it may be a bit overkill of a setup). The setup will be the basis for the next posts about configuring this fabric using Ansible.
One of the first questions when setting up a complex topology with GNS3 that most people will do is: how do I connect it to the external world outside of the simulation? For VirtualBox machines that we are using, the options are limited. The one I found to work reliably across platforms was to use a NAT connection. This has the disadvantage that we have limited connectivity from the external world toward the internal network, but this could be also a security advantage to prevent accidental propagation of control protocols from our simulated environment.
Since the purpose of this lab is going to be to play with Ansible, we are going to need a Linux machine to run it. So, we will setup the following Continue reading
Open Source SDN: The Enterprise Impact
Interop keynote panelists advocate corporate commitment to a major IT culture shift.
Using Terraform to Build an etcd2 Cluster on OpenStack
In this post I’ll build on my earlier introduction to Terraform to show a practical example of using Terraform to build a CoreOS-based etcd2 cluster on OpenStack. This information is based upon a demo that I created for a session at the Austin OpenStack Summit in late April, so all the files I reference in this post are available in the GitHub repo for that session.
You may recall that Terraform is a platform-independent orchestration tool that allows you to create configurations (in either Terraform format or JSON format) specifying resources to be created/modified/deleted. This allows users to take an “infrastructure as code” approach where infrastructure configuration can be declaratively defined and managed via well-known version control mechanisms. In my previous post, I used JSON for the Terraform configurations; in this post, I’ll use the “standard” Terraform format.
As in the intro to Terraform post, I’ll use three different files:
- The
vars.tffile, which contains variables we’ll reference later - The
main.tffile, which has the actual resource definitions - The
output.tffile, which will provide some feedback to the user on the resources being created by Terraform (in this case, IP addresses)
Note that there’s no Continue reading
Cloud Foundry Is Crossing The Chasm
IT managers at the world’s largest organizations have a lot of reasons to envy hyperscalers, including the fact that they seem to be flush with cash and it looks like they can buy or build just about anything their hearts desire.
While hyperscalers have to cope with scale issues, they do not have as much complexity, so they can pick a technology and run with it. Enterprises, on the other hand, are merging and acquiring all the time and have lots of silos of existing applications that cannot be thrown away.
The need to support existing as well as new …
Cloud Foundry Is Crossing The Chasm was written by Timothy Prickett Morgan at The Next Platform.
Arista Will Ramp Manufacturing in the U.S.
Cisco's patent lawsuits played a role in the decision.