Last week Greg Ferro (@etherealmind) wrote this article about his experience
with scripting as a method for network automation, with the ultimate
conclusion that scripting does not scale.
Early in my career I managed a small network that grew to be a IP over X.25
hub of Europe for a few years providing many countries with their first
Internet connectivity. Scripts were everywhere, small ones to grab stats and
create pretty graphs, others that continuously checked the status of links
and would send emails when things went wrong.
While it is hard to argue with Greg’s complaints per se, I believe the key
point is missing. And it has nothing to do with scripting. In a reply,
Ivan’s last comment touches on the real issue.
We have been scripting our networks against CLIs forever and I will bet you
most folks will consider it successful, even though it may be a pain. The ... (more)
A while ago I wrote a few articles describing the various tunnel protocols
used for network virtualization between vSwitches on servers, and between
vSwitches and physical network gateways. These are the mechanisms that
construct overlay networks on top of a physical network. VMWare uses STT as
the tunneling mechanism between vSwitches on servers and VXLAN to communicate
with gateways to the non virtualized world. NVGRE is used mostly by
Microsoft, and is an extension to GRE tunneling that has been around for a
Each one of these mechanisms have their pros and cons. They ... (more)
Perhaps not as popular as its brothers and sisters I, P and S,
Network-As-A-Service or NaaS has slowly started to appear in industry press,
articles and presentations. While sometimes associated with a hypervisor
based overlay solution, its definition is not very clear, which is not at all
surprising. Our industry does not do too well in defining new terms. I ran
across this presentation from Usenix 2012 that details a NaaS solution that
adds a software forwarding engine to switches and routers that provide
specific services for some well known cloud computing workloads.
I have ... (more)
In reviewing some opportunities for Plexxi this week, I was reminded that we
have made things very hard on ourselves. Through no one’s fault but our own
we have created monsters of networks that are impossible to maintain, debug,
diagnose and understand.
I have been lucky in my career. Most of it has been in an R&D organization
for a large network vendor, but always in positions where I was close to
customers, close to customer networks, and of course with that comes the
“close to customer networks that are not working well”. And while there
are always exceptions, in most of the... (more)
IP Multicast is one of those technologies that most everyone loves to hate.
It’s almost the perfect example of how complicated we have made networking.
Getting IP Multicast to run depends on several protocols that are all
somewhat intertwined or dependent on each, their relationship sometimes
explicit, sometimes implicit.
Even trying to describe the basic operation is complicated.
When an application or service provides information using IP multicast, it
simply starts sending it onto a specific multicast group. The multicast
router for the subnet of the sender sees the incoming m... (more)