My mission is simple: Establish an SSH connection to a device and run some commands in as few lines as possible. The contenders? Paramiko, Spur and Fabric.
My mission is simple: Establish an SSH connection to a device and run some commands in as few lines as possible. The contenders? Paramiko, Spur and Fabric.
I've had some great discussion with the OpenDaylight OVSDB team around NETCONF, YANG, RESTCONF and what network operations will look like in an SDN world. This post summarizes where my head is at on this subject.
NETCONF is defined in RFC 6241 which describes it as follows:
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).
It's not a new technology, as work started on this approximately 10 years ago, but what it gives us is an extensible and robust mechanism for managing network devices.
NETCONF understands the difference between configuration data and state data. As somebody who has been bitten by trying to perform a create operation and faced validation issues as I've mistakenly sent (or worse, edited) a read-only field in a request, I feel this is really valuable.
Another great thing from an operations perspective is the ability to test/validate configuration before it's applied to the device. NETCONF allows you Continue reading
I've had some great discussion with the OpenDaylight OVSDB team around NETCONF, YANG, RESTCONF and what network operations will look like in an SDN world. This post summarizes where my head is at on this subject.
I've had some great discussion with the OpenDaylight OVSDB team around NETCONF, YANG, RESTCONF and what network operations will look like in an SDN world. This post summarizes where my head is at on this subject.
In my NetOps to DevOps Training Plan I mentioned installing KVM, Libvirt and Open vSwitch. I did this a few weeks ago and documented it to produce this tutorial. My motivation was to replace my VMware environment at home with something Open Source. I am also a strong believer in "eat your own dog food" and as a lot of the work I am doing in the Open Source community centers around these 3 technologies, I should get used to using them every day...
Before we get started, I'll assume that you already have a Fedora Minimal Installation that you are ready to work on...
sudo yum install -y @standard @virtualization openvswitch
That was easy wasn't it!
@standard installs some useful utilities and @virtualization installs libvirt + KVM
I'm sure you can guess what openvswitch does.
Now here comes the fun part!
# Disable NetworkManager
sudo systemctl stop NetworkManager.service
sudo systemctl disable NetworkManager.service
# Enable "Proper" Networking
sudo systemctl enable network.service
sudo systemctl start network.service
# Enable the Open vSwitch service
sudo systemctl enable openvswitch.service
sudo systemctl start openvswitch.service
Our Continue reading
In my NetOps to DevOps Training Plan I mentioned installing KVM, Libvirt and Open vSwitch. I did this a few weeks ago and documented it to produce this tutorial. My motivation was to replace my VMware environment at home with something Open Source. I am also a strong believer in "eat your own dog food" and as a lot of the work I am doing in the Open Source community centers around these 3 technologies, I should get used to using them every day...
In my NetOps to DevOps Training Plan I mentioned installing KVM, Libvirt and Open vSwitch. I did this a few weeks ago and documented it to produce this tutorial. My motivation was to replace my VMware environment at home with something Open Source. I am also a strong believer in "eat your own dog food" and as a lot of the work I am doing in the Open Source community centers around these 3 technologies, I should get used to using them every day...
OpenStack uses the concept of flavors to define compute/storage configurations that vary in terms of resource consumption. When we start to consume the network as a resource pool, we need a similar concept. This post explains how this is achieved in the context of the Flavors application in the OpenDaylight project
If you haven't read the Fallacies of Distributed Computing you should. Specifically points 2 and 3.
2) Latency is Zero 3) Bandwidth is Infinite
The truth is that not all networks are created equally. We may have some pools of 2:1, 4:1, 8:1 oversubscribed fabric. We may links between data centers at varying bandwidths and costs to the business.
In a cloud network, we can increase our ROI by charging out portions of the network based on their actual cost to the business, but to do this we need to model the network appropriately. Applications also need to consume networking in an abstract way, and the concept of using Flavors as this abstraction is an interesting prospect.
The problem is that todays cloud networking solutions (OpenDaylight included) are based on "Overlay Networks". The Overlay Network solution only assumes L3 reachability between tunnel endpoints Continue reading
OpenStack uses the concept of flavors to define compute/storage configurations that vary in terms of resource consumption. When we start to consume the network as a resource pool, we need a similar concept. This post explains how this is achieved in the context of the Flavors application in the OpenDaylight project
OpenStack uses the concept of flavors to define compute/storage configurations that vary in terms of resource consumption. When we start to consume the network as a resource pool, we need a similar concept. This post explains how this is achieved in the context of the Flavors application in the OpenDaylight project
Dotfiles are all those . files that sit in your ~ and customize your system. Here are mine.
Until a few weeks ago I had no idea that people hosted their dotfiles on GitHub, and now I am one of them... There are two reasons for this:
To point 2, I've gone one step further than just including my dotfiles. I've also included all of my system customizations and installers for the packages I use most. Why a new repository and not a fork you might ask? The honest answer is that there wasn't one repo that fit my tastes well enough so I ended up taking what I considered to be the "best" elements from a number of other repos. This is still a work-in-progress and I am comitting changes every time I find somehting new and exciting, or tire of a specific setting.
.symlink are symlinked to the home folderDotfiles are all those . files that sit in your ~ and customize your system. Here are mine.
In one of my rants, I asked people to kindly stop with the "All Network Guys will Need to be Programmers" FUD. My recommendation was basically for Networkers to be open to change, and to start broadening their horizons. DevOps is coming to networking and that is a FACT. You might be wondering what skills a Network DevOps Engineer needs and here I attempt to answer that.
I'm going to state this upfront here. You need to be good at Networking for any of the other skills here to be useful. Continue along vendor certification tracks, follow the IETF, join NANOG, experiment with new technologies. This is all invaluable.
A lot of the DevOps skills have roots in Software Engineering. Being a Network Guy ™ this may seem like a little bit of a paradigm shift but here's something cool. Would you believe that some of these software engineering concepts have more to do with engineering best practice than with software, and are in fact relevant to the work you are doing today? Also, your SysAdmin buddies already know this and started their DevOps pilgrimage a while ago.
Unit/Functional/Integration Testing, Version Control, Agile, Continue reading
In one of my rants, I asked people to kindly stop with the "All Network Guys will Need to be Programmers" FUD. My recommendation was basically for Networkers to be open to change, and to start broadening their horizons. DevOps is coming to networking and that is a FACT. You might be wondering what skills a Network DevOps Engineer needs and here I attempt to answer that.
The final installment in this three part series. This covers installing Dokku and publishing your pelican blog to you new Docker-powere mini-Heroku.
If you haven't read Part 1 or Part 2 yet, this should give you some background as to what I'm doing, why I'm doing it and how I built it. In this installment I'll focuse on the publishing side of things.
My former blog was hosted on a Linode 1024 VPS, which had a healthy 1GB RAM. I've been very happy with Linode and would recommend them to anybody who needs hosting, but for the convenience of having prebuild Ubuntu images with Dokku installed, I opted to host my blog with DigitalOcean. They have a full tutorial on their website that makes this very easy to set up.
One of the big benefits of using a static site generator is that the memory requirement is a lot less than Apache+PHP or Nginx+PHP. I'm hosting my site now on a $5/month VM from DigitalOcean which is a $15/month saving on my Wordpress site.
Once you have your Dokku installation set up, you can push your application to Continue reading
The final installment in this three part series. This covers installing Dokku and publishing your pelican blog to you new Docker-powere mini-Heroku.
Dotfiles are all those . files that sit in your ~ and customize your system. Here are mine.
In one of my rants, I asked people to kindly stop with the "All Network Guys will Need to be Programmers" FUD. My recommendation was basically for Networkers to be open to change, and to start broadening their horizons. DevOps is coming to networking and that is a FACT. You might be wondering what skills a Network DevOps Engineer needs and here I attempt to answer that.
For the last 9 months, I've been silently working on a little pet project. It's finally ready to be released in to the wild and to be used by one and all for creating Python-based SDN Applications for the HP VAN SDN Controller.
When I started working with the HP VAN SDN Controller (while it still had a cool code name) it became immediately apparent to me that extending the controller with Java applications is not for everyone. There's lots of heavy lifting to be done with things like Maven, OSGi and Remote Debugging. Not only that, but I am not a "Java guy" (or was not until recently to be more exact) and being able to rapidly prototype applications in Python appealed to me.
The HP VAN SDN Controller's REST API exposes a large amount of the functionality available to the Java API with the exception of handling OpenFlow Packet-In, Packet-Out events. For a large number of applications this is absolutely fine, and this is where I hope this library will be useful.
The library is licensed under the Apache 2.0 license so it's free for all to use. The source is hosted on GitHub Continue reading