Archive

Category Archives for "Keeping It Classless"

Using Vagrant with CumulusVX

Cumulus recently announced their CumulusVX platform, which is a virtualized instance of their operating system typically found on network switches. They’ve provided a few options to run this, and in this blog post, I’ll be exploring the use of Vagrant to set up a topology with Cumulus virtual devices.

Brief Review of Vagrant

In software development, there is a very crucial need to consistently and repeatably set up development and test environments. We’ve had the “but it worked on my laptop” problem for a while, and anything to simplify the environment set up and ensure that everyone is on the same page will help prevent it.

Vagrant is a tool aimed at doing exactly this. By providing a simple CLI interface on top of your favorite hypervisor (i.e. Virtualbox) you can distribute Vagrantfiles, which are essentially smally Ruby scripts, and they provide the logic needed to set up the environment the way you want it. In addition, it can call external automation tools like Ansible and Puppet to go one step further, and actually interact with the operating system itself to perform tasks like installing and configuring software.

What we get out of a tool like Vagrant is a Continue reading

Using Vagrant with CumulusVX

Cumulus recently announced their CumulusVX platform, which is a virtualized instance of their operating system typically found on network switches. They’ve provided a few options to run this, and in this blog post, I’ll be exploring the use of Vagrant to set up a topology with Cumulus virtual devices. Brief Review of Vagrant In software development, there is a very crucial need to consistently and repeatably set up development and test environments.

Using Vagrant with CumulusVX

Cumulus recently announced their CumulusVX platform, which is a virtualized instance of their operating system typically found on network switches. They’ve provided a few options to run this, and in this blog post, I’ll be exploring the use of Vagrant to set up a topology with Cumulus virtual devices. Brief Review of Vagrant In software development, there is a very crucial need to consistently and repeatably set up development and test environments.

Big Flowering Thing

This is a rant. It borrows emotional (and some verbal) inspiration from Lewis Black’s “Big F**king Thing” bit. However, in order to keep things light and professional, I will be using the term “flower” in lieu of the four-letter word that I am using in my head.

It’s not unreasonable that ongoing operations for existing applications, and as a result, remaining profitable, have been and always will be the priority. It’s easy to sit atop an ivory tower and critique all of the shortcomings of the industry (applies anywhere, not even just IT), but the reality is, IT (and specifically network infra) is kind of a mess. And that’s okay! It’s the nature of growing organically - and few disciplines have had to learn this the hard way like network infrastructure. Most importantly, we’re all running businesses here. Nothing takes priority over the need to provide ongoing products and services to customers, and to be honest, the rant contained in this post actually points out the need for changes in our industry to be more conducive to this imperative.

All of that said, I feel like the entire networking industry (as well as other, seemingly better-off disciplines to some degree) Continue reading

Big Flowering Thing

This is a rant. It borrows emotional (and some verbal) inspiration from Lewis Black’s “Big F**king Thing” bit. However, in order to keep things light and professional, I will be using the term “flower” in lieu of the four-letter word that I am using in my head.

It’s not unreasonable that ongoing operations for existing applications, and as a result, remaining profitable, have been and always will be the priority. It’s easy to sit atop an ivory tower and critique all of the shortcomings of the industry (applies anywhere, not even just IT), but the reality is, IT (and specifically network infra) is kind of a mess. And that’s okay! It’s the nature of growing organically - and few disciplines have had to learn this the hard way like network infrastructure. Most importantly, we’re all running businesses here. Nothing takes priority over the need to provide ongoing products and services to customers, and to be honest, the rant contained in this post actually points out the need for changes in our industry to be more conducive to this imperative.

All of that said, I feel like the entire networking industry (as well as other, seemingly better-off disciplines to some degree) Continue reading

Big Flowering Thing

This is a rant. It borrows emotional (and some verbal) inspiration from Lewis Black’s “Big F**king Thing” bit. However, in order to keep things light and professional, I will be using the term “flower” in lieu of the four-letter word that I am using in my head. It’s not unreasonable that ongoing operations for existing applications, and as a result, remaining profitable, have been and always will be the priority.

Big Flowering Thing

This is a rant. It borrows emotional (and some verbal) inspiration from Lewis Black’s “Big F**king Thing” bit. However, in order to keep things light and professional, I will be using the term “flower” in lieu of the four-letter word that I am using in my head. It’s not unreasonable that ongoing operations for existing applications, and as a result, remaining profitable, have been and always will be the priority.

Is Container Networking Holding On To The Past?

There has been a plethora of docker-related info on the internet this week, thanks in no small part to DockerCon, and I was motivated to finish this blog post about container networking.

In short, it seems like most if not all container networking projects are going out of their way to give devs the feeling of a “flat” network. My question is - who cares?

For this post, I am not talking about IaaS (which is arguably a declining use case). I am talking about an application cloud provider (i.e. SaaS, and maybe PaaS) where all IP addresses are assigned by the provider and under their control, within the context of the data center.

The way that most of these projects are being marketed to developers is that they provide one big flat network upon which to communicate. Why this choice of terminology? Why does “cloud-native” application design not by default include things like IPv6, or application nodes that are agnostic of what broadcast domain they are participating in?

I have Continue reading

Is Container Networking Holding On To The Past?

There has been a plethora of docker-related info on the internet this week, thanks in no small part to DockerCon, and I was motivated to finish this blog post about container networking.

In short, it seems like most if not all container networking projects are going out of their way to give devs the feeling of a “flat” network. My question is - who cares?

For this post, I am not talking about IaaS (which is arguably a declining use case). I am talking about an application cloud provider (i.e. SaaS, and maybe PaaS) where all IP addresses are assigned by the provider and under their control, within the context of the data center.

The way that most of these projects are being marketed to developers is that they provide one big flat network upon which to communicate. Why this choice of terminology? Why does “cloud-native” application design not by default include things like IPv6, or application nodes that are agnostic of what broadcast domain they are participating in?

I have Continue reading

Is Container Networking Holding On To The Past?

There has been a plethora of docker-related info on the internet this week, thanks in no small part to DockerCon, and I was motivated to finish this blog post about container networking. In short, it seems like most if not all container networking projects are going out of their way to give devs the feeling of a “flat” network. My question is - who cares? Seems to me that "cloud-native" applications should be okay if two of the cattle are not on the same broadcast domain.

Is Container Networking Holding On To The Past?

There has been a plethora of docker-related info on the internet this week, thanks in no small part to DockerCon, and I was motivated to finish this blog post about container networking. In short, it seems like most if not all container networking projects are going out of their way to give devs the feeling of a “flat” network. My question is - who cares? Seems to me that "cloud-native" applications should be okay if two of the cattle are not on the same broadcast domain.

Message Queues: RabbitMQ in Go and Python

I’ve been playing around with various message queue implementations for a few projects, and wanted to write a quick post on some basics. Message Queues Before we get into the detail of RabbitMQ, it’s worth briefly defining exactly what a message queue is, of which RabbitMQ is just one implementation. You may have heard message queues described as a “Publish/Subscribe” system, or “Pub/Sub” for short. This is a style of communication between software elements, where some components publish messages onto a queue, and others subscribe to that queue and listen for messages published on to it.

Message Queues: RabbitMQ in Go and Python

I’ve been playing around with various message queue implementations for a few projects, and wanted to write a quick post on some basics. Message Queues Before we get into the detail of RabbitMQ, it’s worth briefly defining exactly what a message queue is, of which RabbitMQ is just one implementation. You may have heard message queues described as a “Publish/Subscribe” system, or “Pub/Sub” for short. This is a style of communication between software elements, where some components publish messages onto a queue, and others subscribe to that queue and listen for messages published on to it.

Message Queues: RabbitMQ in Go and Python

I’ve been playing around with various message queue implementations for a few projects, and wanted to write a quick post on some basics.

Message Queues

Before we get into the detail of RabbitMQ, it’s worth briefly defining exactly what a message queue is, of which RabbitMQ is just one implementation.

You may have heard message queues described as a “Publish/Subscribe” system, or “Pub/Sub” for short. This is a style of communication between software elements, where some components publish messages onto a queue, and others subscribe to that queue and listen for messages published on to it.

We’ll use Twitter as an illustrative analogy. I sent a link to this blog article within a tweet this morning. I did not address this tweet to anyone in particular, I just put it out there, assuming it was useful to at least somebody. Those that follow me saw this tweet, and made a decision to do something with this information or not. In this scenario, I was the publisher, and my followers were subscribers. Message Queues work very much the same way, but they also provide a much greater level of granularity for how to publish messages and subscribe to them.

Application developers Continue reading

Message Queues: RabbitMQ in Go and Python

I’ve been playing around with various message queue implementations for a few projects, and wanted to write a quick post on some basics.

Message Queues

Before we get into the detail of RabbitMQ, it’s worth briefly defining exactly what a message queue is, of which RabbitMQ is just one implementation.

You may have heard message queues described as a “Publish/Subscribe” system, or “Pub/Sub” for short. This is a style of communication between software elements, where some components publish messages onto a queue, and others subscribe to that queue and listen for messages published on to it.

We’ll use Twitter as an illustrative analogy. I sent a link to this blog article within a tweet this morning. I did not address this tweet to anyone in particular, I just put it out there, assuming it was useful to at least somebody. Those that follow me saw this tweet, and made a decision to do something with this information or not. In this scenario, I was the publisher, and my followers were subscribers. Message Queues work very much the same way, but they also provide a much greater level of granularity for how to publish messages and subscribe to them.

Application developers Continue reading

Open Source Routing: Practical Lab

Earlier, I wrote about some interesting open source routing software that I’ve been exploring lately. In this post, I’ll provide you with some tools to get this lab running on your lab, using Vagrant and Ansible.

In this post, I’ll be using VirtualBox, and also Ansible and Vagrant. For this purpose, I’m assuming you’re at least somewhat familiar with these tools.

Please checkout my GitHub repository for access to the latest versions of all of the files we’ll discuss below - and an easy way to spin all of this up yourself.

Topology

First, here’s the topology we’ll be working with.

All “circuits” are implemented using VirtualBox host networks, described in the Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
 
  config.vm.box = "trusty64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
 
  config.vm.define "r1" do |r1|
    r1.vm.host_name = "r1"
    r1.vm.network "private_network",
                         ip: "192.168.12.11",
                         virtualbox__intnet: "01-to-02"
    r1.vm.network "private_network",
                         ip: "192.168.31.11",
                         virtualbox__intnet: "03-to-01"
    r1.vm.network "private_network",
                         ip: "1.1.1.10",
                         virtualbox__intnet: "Network to Advertise"
    r1.vm.provision "ansible" do |ansible|
      ansible.playbook = "r1.yml"
     Continue reading

Open Source Routing: Practical Lab

Earlier, I wrote about some interesting open source routing software that I’ve been exploring lately. In this post, I’ll provide you with some tools to get this lab running on your lab, using Vagrant and Ansible.

In this post, I’ll be using VirtualBox, and also Ansible and Vagrant. For this purpose, I’m assuming you’re at least somewhat familiar with these tools.

Please checkout my GitHub repository for access to the latest versions of all of the files we’ll discuss below - and an easy way to spin all of this up yourself.

Topology

First, here’s the topology we’ll be working with.

All “circuits” are implemented using VirtualBox host networks, described in the Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
 
  config.vm.box = "trusty64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
 
  config.vm.define "r1" do |r1|
    r1.vm.host_name = "r1"
    r1.vm.network "private_network",
                         ip: "192.168.12.11",
                         virtualbox__intnet: "01-to-02"
    r1.vm.network "private_network",
                         ip: "192.168.31.11",
                         virtualbox__intnet: "03-to-01"
    r1.vm.network "private_network",
                         ip: "1.1.1.10",
                         virtualbox__intnet: "Network to Advertise"
    r1.vm.provision "ansible" do |ansible|
      ansible.playbook = "r1.yml"
     Continue reading

Open Source Routing: Practical Lab

Earlier, I wrote about some interesting open source routing software that I’ve been exploring lately. In this post, I’ll provide you with some tools to get this lab running on your lab, using Vagrant and Ansible. In this post, I’ll be using VirtualBox, and also Ansible and Vagrant. For this purpose, I’m assuming you’re at least somewhat familiar with these tools. Please checkout my GitHub repository for access to the latest versions of all of the files we’ll discuss below - and an easy way to spin all of this up yourself.

Open Source Routing: Practical Lab

Earlier, I wrote about some interesting open source routing software that I’ve been exploring lately. In this post, I’ll provide you with some tools to get this lab running on your lab, using Vagrant and Ansible. In this post, I’ll be using VirtualBox, and also Ansible and Vagrant. For this purpose, I’m assuming you’re at least somewhat familiar with these tools. Please checkout my GitHub repository for access to the latest versions of all of the files we’ll discuss below - and an easy way to spin all of this up yourself.

Open Source Routing: A Comparison

I have been getting more interested in open-source networking software, and I figured it was time to write a post comparing some of the more popular open source projects in this space.

Not only do we have several options (which hasn’t always been the case) for running routing protocols in FOSS, but we also have a variety of use cases that are increasing in popularity (using BGP for SDN-type purposes, not just to do internet peering). So isn’t an idea limited to enthusiasts who like to spin their own router - this kind of software has very interesting large-scale applications as well.

This won’t be a comprehensive list, just the top three that I’ve been looking into. I also won’t be going into too much detail on how to set all this software up - I’m saving that for a follow-up post.

Quagga

Quagga is at the top of this list primarily because from my perspective, it is the most well-known. It is best to think of Quagga as a collection of smaller daemons, each with a specific task. This task may be to run a routing protocol like OSPF or BGP, or it may be something else.

In this Continue reading

1 … 6 7 8 9 10 … 38