Networking

You are currently browsing articles tagged Networking.

OpenStack Summit 2013: Networking In the Cloud, an SDN Primer

Tuesday, April 16, 2013 in General, Networking by slowe | 1 comment

This is a session titled “Networking in the cloud: An SDN primer.” It’s led by Ben Cherian, Chief Strategy Officer for Midokura. Ben indicates he’ll try to remain as impartial as possible while attempting to describe and define SDN.

Ben asserts that the basic driver pushing folks toward SDN is that the current state of networking in the cloud is too complex and too manual. As a result, the first question that people start asking is, how can I automate this? Telecom has gone through this before, and data networking is in a similar state of flux and development.

The presenter next discusses Almon Strowger, who invented the first electromechanical switch. His work–which might have been driven by some level of paranoia–led to automated phone switching and the rotary phone. Almon Strowger wanted to address privacy concerns and intentional human errors, and along the way he also solved unintentional human errors, connection speeds, and lower operational costs.

Ben indicates that the cloud—in particular, networking—is in a similar position. It’s time for the “Almon Strowger” of cloud networking to solve the challenges that keep networking from scaling.

The presenter next covers the concept of a control plane and the data plane. Abstraction is a key tenet of computer science, and when the control plane and the data plane reside on the same physical device (which is typically the case in traditional networks today), there is no abstraction. Abstraction exists in other areas of computing, but not in networking. To bring that abstraction into networking, a simple example is to separate the control plane into a separate controller that exists apart from the data plane. This is basic SDN.

Ben sees three use cases for SDN:

  1. IaaS
  2. Data center fabrics
  3. Carrier/WAN use cases

Looking at these in reverse order, examples of SDN technologies that you could see here would be a “hybrid control plane” leveraging either BGP (a distributed control plane) or OpenFlow (centralized control plane). In the data center fabric space, this involves the use of OpenFlow to manage multiple switches. Finally, in the IaaS space, you see software-based solutions and overlays. Examples of companies in this IaaS space are Midokura, VMware/Nicira, and others.

Some key requirements for IaaS “cloud networking”/SDN:

  • Multi-tenancy
  • L2 isolation
  • L3 isolation
  • Scalable control plane
  • NAT (floating IP)
  • ACLs
  • Stateful (L4) firewall
  • VPN
  • BGP gateway
  • RESTful API
  • Integration with CMS (like OpenStack)

Looking at this list of requirements, Ben feels like you can eliminate the technologies leveraged in the carrier/WAN and data center fabric SDN use cases, because these technologies don’t properly address all the IaaS/cloud networking requirements.

Ben next reviews a networking diagram that shows how these various requirements translate into cloud networks.

The candidate models to address these requirements are:

  • Traditional network
  • Hop=by-hop OpenFlow
  • Edge-to-edge IP overlays

Using traditional network models, VLANs become a constraint (only 4096 VLANs available means only 4096 tenants). This constrains L2 isolation. L3 isolation is constrained by VRFs, which are not fault tolerant, require expensive hardware, and don’t scale well.

If you wanted to use an OpenFlow fabric, the issue is more about the limitations of the physical switch itself. Storing the state in physical switches has issues with scale, not fast enough to update, and no atomicity of updates. There is also the issue of provisioning the physical switches that will then be controlled by OpenFlow. This approach also doesn’t address the other “higher level” concerns of cloud networking.

Edge-to-edge IP overlays are the method that Ben (and his company) prefers. Isolation is provided without VLANs, providing additional scalability. Only IP connectivity is required. You can use a scalable IGP (iBGP, OSPF) to build a reliable multi-path underlay network. This sort of thinking is inspired by a research paper by Microsoft regarding VL2 (no link provided).

Trends that support this sort of solution:

  • Faster packet processing on x86 servers at the edge
  • Clos (fat tree/leaf-spine) networks for the underlay
  • Merchant silicon brings down the cost of efficient IP switches
  • Optical intra-DC networks for plentiful bandwidth

The presenter also alludes to the use of configuration management tools (Chef, Puppet) on merchant silicon-based switches.

Ben next shows a diagram that illustrates an overlay network and an underlay network, and he walks through how traffic flows work (both from the overlay perspective as well as the underlay perspective).

Naturally, Ben believes that overlays are the right approach—but you still need a scalable control plane.

At this point, he opens the session up for questions and answers.

Tags: , ,

Network Overlays vs. Network Virtualization

Tuesday, April 16, 2013 in Networking, Virtualization by slowe | 12 comments

Dan Wendlandt said something today in the NVP deep dive session (liveblog of the session here) that really crystallized something for me. I thought perhaps I might be the only one that was seeing a trend, but Dan’s comment leads me to believe there are others seeing this trend as well. Here’s the quote, taken from my liveblog of the session:

It is important to note, as Dan does, that a tunneling protocol alone is not network virtualization.

There’s a lot of buzz in the industry about network virtualization and network overlays, and often those terms are used interchangeably. People talk about the need for multi-tenancy and address space isolation, point to network overlays like VXLAN, NVGRE, and STT as the answer to all our problems, and in so doing they (inadvertently) conflate network overlays with network virtualization. Network overlays and network virtualization aren’t the same thing, and people that use them interchangeably probably don’t fully understand what’s involved.

<aside>By the way, if you’re not familiar with the idea of network overlays, I’d recommend reading this, this, and this to get you started. There’s plenty more out there, but those three articles will at least prime the pump, I think.</aside>

Network overlays are great for address space isolation (for example, isolating duplicate MAC addresses, duplicate IP addresses, or duplicate VLAN IDs). As such, network overlays can be an important part of network virtualization. You need more than a network overlay, though, to have network virtualization; you also need virtualized network services (like NAT, firewalls, ACLs, QoS, routing, and the like) and you need a control plane (else how would you coordinate the various pieces within the network virtualization solution?). The overlay protocol is just one piece of the puzzle, so using “network overlay” interchangeably with “network virtualization” is incorrect.

As always, I welcome the input of those more educated/knowledgeable than I am. If you’re a networking expert (or a virtual networking expert), feel free to speak up in the comments and correct my misunderstanding or misconceptions (please disclose vendor affiliations). I’m always open to deepening my knowledge—and helping others with their understanding and knowledge along the way.

Tags: , ,

OpenStack Summit 2013: Nicira NVP Deep Dive

Monday, April 15, 2013 in General, Networking by slowe | 6 comments

This is a “201 level” technical deep dive on Nicira Network Virtualization Platform (NVP). It was supposed to be led by Brad Hedlund, but due to unforeseen circumstances Brad was unable to make it to the Summit. Instead, Dan Wendlandt is leading the session. Dan, if you aren’t familiar, was the former Quantum PTL. I’m already familiar with all of this stuff (naturally), but wanted to sit in this session so that I could liveblog it for others’ benefit.

Dan starts the session with an explanation of network virtualization and why its important. He provides a technical definition of network virtualization as a “faithful reproduction of physical networks’ that is “fully isolated” and provides “location independence” while being “physical network state independent". This is NOT the same as simply running network software inside a VM. (While that is valuable, that’s not the same as network virtualization.)

NVP 1.0 was released in July 2011; the latest version, NVP 3.0, was released recently. The end of April will see NVP 3.1.

The only requirement from the physical network is IP connectivity. Open vSwitch (OVS) is used in all the various components, like Service Nodes and L2/L3 Gateways, and a set of out-of-band controllers manage all the components. Dan contrasts the “non-virtualized” (more physically-oriented) and “virtualized” (more logically oriented) views of NVP and the functionality is presents.

Starting at the “bottom” of the stack:

  • NVP wants to treat your network as a pool of resource capacity to be sliced on-demand for tenants.
  • NVP relies only on commodity features (specifically, L3 forwarding).
  • Configuration is done once (when the equipment is racked).
  • No humans in the loop when provisioning occurs.
  • Have the flexibility to choose/change architecture without it impacting the logical abstractions you’ve created for your workloads.

Next Dan shows that you could use a very scalable leaf-spine L3 network design, but you could also leverage existing network architectures—NVP only requires L3 connectivity.

The session then moves on to discuss Open vSwitch (OVS), which forms the basis for many of the Quantum plugins in OpenStack. It’s important to understand OVS is really like a generic “engine” that can be programmed to provide various levels of functionality, from “dumb” L2 learning to more sophisticated OpenFlow-based and tunnel-oriented networking.

This leads into a discussion of why L2/L3 tunneling as employed by NVP is important in satisfying the definition of network virtualization provided earlier. In order to truly isolate networks, NVP leverages tunneling protocols to encapsulate the traffic and provide the isolation and decoupling properties.

It is important to note, as Dan does, that a tunneling protocol alone is not network virtualization.

Next Dan moves on to describing the NVP controllers, which are x86-based software that manages OVS southbound and uses a northbound API (to expose to Quantum, for example). NVP controllers are NEVER in the data plane. The NVP controllers leverage a clustered/distributed architecture that provides both high availability (HA) and scale-out functionality.

As mentioned earlier, the controllers also provide the NVP API northbound to applications and/or cloud management systems (CMSes, like OpenStack and CloudStack). In an OpenStack environment, the NVP API is consumed by Quantum to create logical networks and logical network services.

Dan next provides an overview of the communication flow between the various components in a Quantum+NVP deployment.

The session now shifts focus to gateways, which provide the mechanism to get into or out of logical networks created by NVP. An L2 gateway allows you to map physical systems or VLANs into a logical switch managed/created by NVP. (Kudos to Dan, who actually goes with a very complex example–mapping in a remote VLAN across the WAN as an adjacent L2 segment–in order to explain L2 gateways.) He also explains the use of L3 gateways, which provide routed access into and out of the NVP logical networks. One of the interesting things about L3 gateways is that they are highly available (using failure zones) and a scale-out architecture (meaning that multiple L3 gateway appliances are supported).

Service nodes are used to handle broadcast and multicast packet replication. Using service nodes allows you to offload these tasks, if you wish, from the hypervisor compute nodes. Like the L3 gateways, the service nodes are built to provide high availability and scale-out functionality.

Dan wraps up the session with a review of the management and operations tool that NVP provides. NVP provides tunnel status, has a “port connectivity” tool that shows VM-to-VM connectivity, and actively inject traffic into flows to test network connectivity.

NVP isn’t just about scale. It’s about:

  • Data plane performance
  • Fast, reliable high availability
  • Rich logical capabilities (ACLs, QoS, statistics)
  • Ability to bring physical workloads into logical networks, onboard remote customers
  • Rich management and operations tools

At this point, Dan opens the session for questions and answers.

Tags: ,

Technology Short Take #31

Monday, April 8, 2013 in Macintosh, Networking, Security, Storage, Virtualization by slowe | 3 comments

Welcome to Technology Short Take #31, my irregularly published series that takes a look at links, posts, articles, and thoughts from around the web related to core data center technologies. I hope that you find something useful!

Networking

  • Umair Hoodbhoy speculates in this post that the inclusion of Cisco’s ONE Controller in the recently-announced “Daylight” effort could mean the end for Big Switch’s Floodlight. (Umair’s play on words—”in Daylight there is no need for Floodlights”—is cute.)
  • Of course, Big Switch recently moved to “diversify,” if you will, away from just Floodlight with the introduction of Switch Light. As usual, Brent Salisbury has an excellent write-up on Switch Light, so I recommend reading his post. Switch Light seems like a good idea—more competition is always good, isn’t that what people say?—but I wonder how much cooperation Big Switch will get from the major networking vendors with regards to OpenFlow interoperability now that Big Switch is competing even more directly with them via Switch Light.
  • I think I might have mentioned this before (sorry if so), but here’s a good write-up on using the Edge Gateway CLI for monitoring and troubleshooting. Nice.
  • Greg Ferro examines a potential SDN use case (an OpenFlow use case) in the form of enterprise firewall migrations.
  • Just getting started in the networking field? Last year, Brent Salisbury put together a couple of great posts that help “refresh the basics” of networking. Part 1 covers Ethernet, IP, and TCP headers in Wireshark captures; part 2 pulls that together to show how the headers encapsulate in the OSI stack. If you’re not already familiar with this information, this is good reading.

Servers/Hardware

Nothing this time around, but I’ll stay alert for information I can include in the next Technology Short Take!

Security

  • Mounting guest disk images on the host? That’s a no-no from a security perspective—see here to learn why.
  • Mike Foley shared recently that the release candidate of the vSphere 5 Security Hardening Guide has been released. Check it out here.

Cloud Computing/Cloud Management

  • I haven’t had the chance to actually try it out myself, but Blueprint looks interesting. As the website describes it, it’s designed to “reverse engineer” servers so that you can migrate them into a configuration management system like Chef or Puppet.
  • Looking for a decent high-level overview of OpenStack and how it works? Check out this article titled “In a nutshell: How OpenStack works”. (As an aside, I think it’s awesome how Ken Pepple’s diagrams show up in all sorts of places. One day I hope my material proves as useful to folks.)
  • If you use Puppet for configuration management and want to deploy GlusterFS, be sure to check out this Puppet Forge module. I’ve tested it and it works as advertised.
  • This is an older article (published in May of last year), and it’s a bit on the lengthy side, but I like the tack the author uses. He describes cloud as the synthesis of many different forms of innovation within IT, pulling together things like open source, virtualization, distributed programming, NoSQL, DevOps/NoOps, distributed teams, dynamic languages, and Big Data (among others). He then goes on to provide examples of how organizations building or leveraging clouds are synthesizing these various independent technological innovations together. If you have a few minutes (as I said, it’s a bit on the lengthy side), I’d recommend reading it.

Operating Systems/Applications

  • This series is a bit older, but an interesting one nevertheless. Brian McClain, who was one of the presenters in a Cloud Foundry/BOSH session I liveblogged at VMworld 2012, has his own personal blog and posted a series of articles on using BOSH with vSphere. I hadn’t really considered how one might use BOSH for deploying (and managing) multi-VM applications on vSphere, but Brian provides some practical examples. Part 1 of the series is here, followed by part 2, part 3, part 4, and part 5.
  • Like using Markdown on OS X? You might find these handy.
  • Ah, the good old days of DOS…reborn as FreeDOS.
  • Go ahead, read up on YAML. You know you want to. Well, YAML is used in both Hiera (can be used with Puppet) and BOSH, after all.
  • Here’s another interesting tool that I haven’t had the opportunity to actually test myself. Oz looks like it could be quite useful—especially in virtualized/cloud computing environments—but I’m struggling to determine why I should use Oz instead of OS-specific mechanisms (like a kickstart file). If anyone has used Oz and can shed some light on this question, I’d appreciate it.
  • You may have heard that I recently switched from TextMate to BBEdit as my default OS X text editor (and therefore the tool whereby I do most of my content generation). As part of the switch, I found this to be helpful. (I might post a separate entry about the switch, if enough people seem interested in reading about it.)

Storage

Virtualization

That’s it for this time. I have plenty more links I wanted to share, but I figured I’d better not let this post get any longer. As always, courteous comments are welcome, so I invite you to participate in the conversation by adding your thoughts below.

Tags: , , , , , , , , , ,

Highly Recommended Quantum and Open vSwitch Resource

Friday, April 5, 2013 in Networking, Virtualization by slowe | 2 comments

If you want to read a masterpiece of an article describing how OpenStack Quantum works with Open vSwitch (OVS) and the OVS plugin, this write-up by Florian Otel should be your first stop.

Florian’s treatise—it’s far too in-depth and comprehensive to be referred to as anything else—covers just about everything and anything you want to know about getting OpenStack Quantum and OVS up and running. Florian not only walks readers through the configuration, but then “peels back the covers” to show them what’s happening underneath. For example, the write-up documents the settings for using the Quantum DHCP agent and L3 agent, and then goes on to explain (and demonstrate!) how each of these components leverages different Linux network namespaces to accomplish their tasks.

I highly recommend reading and reviewing this resource, and on behalf of everyone else out there like me who’s searching for more documentation on how the various OpenStack components work, I’d like to thank Florian for his efforts in putting this together. Well done.

Tags: , ,

Thinking Out Loud: Targeting the Real Problem

Wednesday, April 3, 2013 in Networking, Virtualization by slowe | 8 comments

Two (relatively) independent thought streams collided late last week, and this post is the result.

The first thought stream was about the benefits and drawbacks of OpenFlow. As I’ve said on many occasions, every technology decision has benefits and drawbacks. OpenFlow is no exception, in my opinion. Clearly there are some real benefits to using OpenFlow in certain use cases (here’s one example), but that doesn’t mean OpenFlow—especially hop-by-hop OpenFlow, where OpenFlow is involved at every “hop” of the packet forwarding process throughout the network—is the right solution for all environments.

The collision occurred after I read these two blog posts (here and here) by Ivan Pepelnjak on manual VLAN provisioning.

Now, you might be thinking “Scott, what do manual VLAN provisioning and hop-by-hop OpenFlow have to do with each other?” That is a valid question, and it was this phrase by Ivan that connected the two (for me, at least):

I love listening to the Packet Pushers (the best networking podcast there is) on my way to work, and I know what to expect in every SDN-focused episode: an “I’m sick and tired of using [the] CLI to manually provision VLANs” rant.

Based on what I’ve seen and read so far, it seems like a lot of folks see software-defined networking (SDN), especially hop-by-hop OpenFlow, as the solution to manual VLAN provisioning. After all, if I can use a controller—there are numerous open source and proprietary controllers out there—to gain programmatic access to controlling individual flows within my data center, why do I need VLANs? I can provide a greater level of automation (via an API provided by the controller) and eliminate the need to use VLANs (because traffic can be separated at the flow level). Win-win, right?

As I thought about this more, though, it seemed to me that perhaps this line of thinking is targeting the wrong problem. OpenFlow, as I understand it, is targeted at modifying/controlling how packet forwarding occurs across the network. However, it seems to me that this isn’t the real problem. The real problem is the configuration and management of network policy: stuff like QoS, VLANs, ACLs, NAT, VRFs, firewalls, load balancing, etc. If we could automate that stuff—perhaps even using OpenFlow in some capacity—then the packet forwarding would, in turn, be properly shaped/controlled/influenced by that policy.

Or am I missing something? I’d love to hear what you think, so feel free to add your thoughts in the comments below. Please be sure to add vendor affiliations, where applicable. All courteous comments are welcome!

Tags: , ,

Call for Networking Topics

Tuesday, March 19, 2013 in Networking by slowe | 18 comments

I’m getting ready to start a “Virtual Networking 101″ series of blog posts, where I’m going to try to help introduce the ideas and concepts of virtual networking to VM admins that might not be familiar with these concepts. These are not deep dives; rather, I’m aiming to provide enough introductory knowledge that VM admins are who aren’t familiar with this stuff can at least understand what’s going on. However, I’ve been working in this stuff for a little while now, so it’s a bit difficult for me to tell what core/base concepts would really be helpful to others.

In that vein, then, I’m asking for you–the readers–to let me know: what core/base concepts of virtual networking would you find most helpful? I’m initially thinking of topics like OpenFlow or network overlays, but what would you find helpful? What topics do you want to see or would find useful? Speak up in the comments below to let me know your thoughts. Thanks!

Tags:

Technology Short Take #30

Tuesday, March 5, 2013 in General by slowe | 4 comments

Welcome to Technology Short Take #30. This Technology Short Take is a bit heavy on the networking side, but I suppose that’s understandable given my recent job change. Enjoy!

Networking

  • Ben Cherian, Chief Strategy Officer for Midokura, helps make a case for network virtualization. (Note: Midokura makes a network virtualization solution.) If you’re wondering about network virtualization and why there is a focus on it, this post might help shed some light. Given that it was written by a network virtualization vendor, it might seem a bit rah-rah, so keep that in mind.
  • Brent Salisbury has a fantastic series on OpenFlow. It’s so good I wish I’d written it. He starts out by discussing proactive vs. reactive flows, in which Brent explains that OpenFlow performance is less about OpenFlow and more about how flows are inserted into the hardware. Next, he tackles the concerns over the scale of flow-based forwarding in his post on coarse vs. fine flows. I love this quote from that article: “The second misnomer is, flow based forwarding does not scale. Bad designs are what do not scale.” Great statement! The third post in the series tackles what Brent calls hybrid SDN deployment strategies, and Brent provides some great design considerations for organizations looking to deploy an SDN solution. I’m looking forward to the fourth and final article in the series!
  • Also, if you’re looking for some additional context to the TCAM considerations that Brent discusses in his OpenFlow series, check out this Packet Pushers blog post on OpenFlow switching performance.
  • Another one from Brent, this time on Provider Bridging and Provider Backbone Bridging. Good explanation—it certainly helped me.
  • This article by Avi Chesla points out a potential security weakness in SDN, in the form of a DoS (Denial of Service) attack where many switching nodes request many flows from the central controller. It appears to me that this would only be an issue for networks using fine-grained, reactive flows. Am I wrong?
  • Scott Hogg has a nice list of 9 common Spanning Tree mistakes you shouldn’t make.
  • Schuberg Philis has a nice write-up of their CloudStack+NVP deployment here.

Servers/Hardware

  • Alex Galbraith recently posted a two-part series on what he calls the “NanoLab,” a home lab built on the Intel NUC (“Next Unit of Computing”). It’s a good read for those of you looking for some very quiet and very small home lab equipment, and Alex does a good job of providing all the details. Check out part 1 here and part 2 here.
  • At first, I thought this article was written from a sarcastic point of view, but it turns out that Kevin Houston’s post on 5 reasons why you may not want blade servers is the real deal. It’s nice to see someone who focuses on blade servers opening up about why they aren’t necessarily the best fit for all situations.

Security

  • Nick Buraglio has a good post on the potential impact of Arista’s new DANZ functionality on tap aggregation solutions in the security market. It will be interesting to see how this shapes up. BTW, Nick’s writing some pretty good content, so if you’re not subscribed to his blog I’d reconsider.

Cloud Computing/Cloud Management

  • Although this post is a bit older (it’s from September of last year), it’s still an interesting comparison of both OpenStack and CloudStack. Note that the author apparently works for Mirantis, which is a company that provides OpenStack consulting services. In spite of that fact, he manages to provide a reasonably balanced approach to comparing the two cloud management platforms. Both of them (I believe) have had releases since this time, so some of the points may not be valid any longer.
  • Are you a CloudStack fan? If so, you should probably check out this collection of links from Aaron Delp. Aaron’s focused a lot more on CloudStack now that he’s at Citrix, so he might be a good resource if that is your cloud management platform of choice.

Operating Systems/Applications

  • If you’re just now getting into the whole configuration management scene where tools like Puppet, Chef, and others play, you might find this article helpful. It walks through the difference between configuring a system imperatively and configuring a system declaratively (hint: Puppet, Chef, and others are declarative). It does presume a small bit of programming knowledge in the examples, but even as a non-programmer I found it useful.
  • Here’s a three-part series on beginning Puppet that you might find helpful as well (Part 1, Part 2, and Part 3).
  • If you’re a developer-type person, I would first ask why you’re reading my site, then I’d point you to this post on the AMQP, MQTT, and STOMP messaging protocols.

Storage

Virtualization

  • Although these posts are storage-related, the real focus is on how the storage stack is implemented in a virtualization solution, which is why I’m putting them in this section. Cormac Hogan has a series going titled “Pluggable Storage Architecture (PSA) Deep Dive” (part 1 here, part 2 here, part 3 here). If you want more PSA information, you’d be hard-pressed to find a better source. Well worth reading for VMware admins and architects.
  • Chris Colotti shares information on a little-known vSwitch advanced setting that helps resolve an issue with multicast traffic and NICs in promiscuous mode in this post.
  • Frank Denneman reminds everyone in this post that the concurrent vMotion limit only goes to 8 concurrent vMotions when vSphere detects the NIC speed at 10Gbps. Anything less causes the concurrent limit to remain at 4. For those of you using solutions like HP VirtualConnect or similar that allow you to slice and dice a 10Gb link into smaller links, this is a design consideration you’ll want to be sure to incorporate. Good post Frank!
  • Interested in some OpenStack inception? See here. How about some oVirt inception? See here. What’s that? Not familiar with oVirt? No problem—see here.
  • Windows Backup has native Hyper-V support in Windows Server 2012. That’s cool, but are you surprised? I’m not.
  • Red Hat and IBM put out a press release today on improved I/O performance with RHEL 6.4 and KVM. The press release claims that a single KVM guest on RHEL 6.4 can support up to 1.5 million IOPS. (Cue timer until next virtualization vendor ups the ante…)

I guess I should wrap things up now, even though I still have more articles that I’d love to share with readers. Perhaps a “mini-TST”…

In any event, courteous comments are always welcome, so feel free to speak up below. Thanks for reading and I hope you’ve found something useful!

Tags: , , , , , , , , , , , ,

Automating Open vSwitch Configuration with Puppet

Tuesday, February 26, 2013 in Linux, Networking by slowe | 1 comment

In this post, I’m going to show you a way to automate the configuration of Open vSwitch (OVS) using Puppet. While this method will work, it is not without its drawbacks (which I’ll explain later in the post). I freely admit that there might be better ways of accomplishing this task; this is one simple way that I discovered.

I wish I could say that this method of automating OVS with Puppet was clever, but—to be honest—it’s really more of a brutish hack that anything else. In an earlier post, I described some integrations between RHEL and OVS that allows you to use interface configuration files in /etc/sysconfig/network-scripts to configure portions of OVS. For example, you could use this interface configuration file to create an OVS internal interface for management traffic:

Further, based on a number of the Puppet-related posts I’ve written (this one, for example), you probably know that Puppet has the ability to enforce the presence and contents of file-based resources.

So, Puppet can create and manage files, and files can be used to configure OVS. You can probably see where this is going. That’s right—if we use Puppet to manage interface configuration scripts, we can automate the configuration of OVS (only on systems running RHEL or RHEL variants, naturally).

Here’s a snippet of Puppet code that could be used to automate the configuration of OVS to use an internal interface for management traffic:

As I said, this is a bit of a brutish hack—not an elegant solution, but one that works. Naturally, because this builds on the RHEL-OVS integrations, you’ll need to do an ifdown and/or ifup to make the change(s) effective. (One could likely use an exec statement in the Puppet manifest to run these commands for you.) Another drawback is that this only works on RHEL and RHEL variants, whereas both OVS and Puppet are far more widely supported. Still, it might come in handy in some situations.

If you have corrections, clarifications, or suggestions, please feel free to speak up in the comments below. Courteous comments are both encouraged and welcomed!

Tags: , , , , ,

Exploring RHEL-OVS Integrations

Thursday, February 7, 2013 in Linux, Networking by slowe | 2 comments

In this post, I’m going to explore some integrations between Red Hat Enterprise Linux (RHEL)/RHEL variants and Open vSwitch (OVS). This post will lay the foundation for a future post describing OVS automation using Puppet.

Over the past few weeks, I’ve been rebuilding my home lab to focus on some core projects/technologies for the upcoming year (more on that in this post). As part of the rebuild effort, I’ve rebuilt my hosts to run CentOS 6.3 x64, KVM, Libvirt, GlusterFS, and OVS, and have crafted Puppet code to help install (and configure, in some cases) most of these components. This post, as with some others, is an offshoot of the lab rebuild work.

(In case you were wondering, the other posts that have come out of the home lab rebuild project include building Libvirt RPMs, using Mock to build Sanlock RPMs, using Mock to build libssh2 RPMs, using Mock to build Libvirt RPMs, and using Puppet for user accounts and configuration files. I’m sure there will be more.)

The information in this post will build upon some base OVS knowledge, so if you aren’t familiar with OVS, then you might want to go back and read some of my earlier OVS posts (these will at least get you started):

Some Insight into Open vSwitch Configuration
Link Aggregation and LACP with Open vSwitch
VLANs with Open vSwitch Fake Bridges
Running Host Management on Open vSwitch
Layer 3 Routing with Open vSwitch

Finally, before we get into the real meat of the information, I’d like to point out that the information in this post builds upon the information already included in the OVS documentation (see the README.RHEL file in the distribution tarball). I’m merely attempting to provide some additional context and examples on how these can be used.

Now that the preliminaries are out of the way…

The basic gist of the RHEL-OVS integration is support for the use of the scripts in /etc/sysconfig/network-scripts to do some configuration of OVS itself. For example, creating bridges, establishing bonds, configuring internal ports—all these tasks can be done using an ifcfg-<name> script.

Let’s start with a very basic example. Let’s say that you want to create a single OVS bridge named ovsbr0. To do that, you’d create a file named ifcfg-ovsbr0 in the /etc/sysconfig/network-scripts directory, and make the contents look like this:

Now let’s say that you want to create a link aggregate on that bridge. To create a link aggregate on ovsbr0 (the bridge you just created), create a file named ifcfg-bond0 in the same directory, and make its contents look like this:

Note that this is an LACP-enabled link aggregate, so you’ll also have to configure your physical switch appropriately.

Finally, suppose that you want to create an internal interface (it will appear as a physical interface to Linux, but is hosted on OVS) across which you can run your management traffic. No problem! Just create a file named ifcfg-mgmt0 and make the contents of the file look like this:

Each of these scripts will create the corresponding structures/configurations within OVS. There is a drawback, however. In order for these changes to take effect, you must restart the network (perform a service network restart). This doesn’t appear to be an OVS limitation of any sort; if you’ve read any of the other OVS posts, you know that you can make these changes live via the ovs-vsctl command. Instead, it simply appears to be a limitation of the fact that these scripts are only evaluated during a network stop/start event.

Once these scripts have been evaluated, though, you should end up with a configuration that looks something like this (UUIDs have been changed to protect the innocent):

Given the limitation, I can imagine that a natural question to ask would be, “Why use this integration, which requires a network restart, when you could just make the configuration changes yourself?” Excellent question. I see this as a way of establishing a “baseline” configuration for OVS, upon which you could (dynamically) add all the other configurations you need. In addition, because the base OVS configuration exists as a set of files, this opens up some other interesting possibilities. I’ll explore those possibilities in a future post.

As always, courteous comments are welcome, so feel free to add your questions, thoughts, corrections, or clarifications in the comments below.

Tags: , ,

« Older entries § Newer entries »