https://oswalt.dev/ Recent content on Matt Oswalt Hugo -- gohugo.io en Thu, 19 Nov 2020 00:00:00 +0000 https://oswalt.dev/2020/11/what-are-data-types-anyways/ Thu, 19 Nov 2020 00:00:00 +0000 https://oswalt.dev/2020/11/what-are-data-types-anyways/ There are actually quite a few resources out there for a novice programmer to learn about data types like strings, integers, floats, and more. The wikipedia page, as an example, covers a broad spectrum of potential meanings. Just about any book or tutorial focused on a particular programming language will start off by listing the types supported by that language. This makes sense, since they are the fundamental building block of being able to do pretty much anything in that language. https://oswalt.dev/2020/11/anatomy-of-a-binary-executable/ Wed, 04 Nov 2020 00:00:00 +0000 https://oswalt.dev/2020/11/anatomy-of-a-binary-executable/ Even though I’ve developed software for a number of years now, there’s one question that has always been in the back of my mind and I haven’t had the time or patience to really answer, until now: What is a binary executable anyways? For this example, I wrote a brutally simple Rust program that includes a function “sum” to add two integers together, and am invoking it from main(): fn main() { println! https://oswalt.dev/2020/08/what-is-generic-programming/ Tue, 04 Aug 2020 00:00:00 +0000 https://oswalt.dev/2020/08/what-is-generic-programming/ This year, my journey to learn Rust (and actively use it in a few side projects) has been a treasure trove of learning experiences. Lately, I’ve been finding myself trying to wrap my head around not just new syntax, but entirely new software programming paradigms that I simply haven’t been exposed to before. In my career thus far, I’ve mainly used two languages professionally: Python, and Go. It turns out this forms a pretty interesting story arc, since these two languages paint a wide spectrum of approaches to enabling the developer to be expressive and productive while managing the runtime tradeoffs of doing so. https://oswalt.dev/2020/07/rust-traits-defining-behavior/ Wed, 22 Jul 2020 00:00:00 +0000 https://oswalt.dev/2020/07/rust-traits-defining-behavior/ Before jumping into any programming language, you often hear about its “heavy hitters” - the features that usually make the highlight reel when someone “in the know” is trying to summarize the strong points of the language. In 2015, as I was learning Go, I would often hear things like concurrency support, channels, concurrency support, and Interfaces. Also concurrency support. With Rust, thus far the highlights have included things like strong support for generics, lower-level control, and an emphasis on memory safety manifested in the unavoidable ownership model. https://oswalt.dev/2020/05/mutable-references-to-self-in-rusts-object-methods/ Wed, 20 May 2020 00:00:00 +0000 https://oswalt.dev/2020/05/mutable-references-to-self-in-rusts-object-methods/ Lately I’ve been working on graphics programming in Rust, as a continuation of my first steps with the language. As part of this work, I created a type I created called Vec3f, to hold cartesian coordinates for a given vector: #[derive(Copy, Clone, Debug)] struct Vec3f { x: f32, y: f32, z: f32 } In the natural course of this work, I needed to add certain methods for this type to allow me to perform calculations like cross product, and dot/scalar product. https://oswalt.dev/2020/05/beyond-hello-world-sorting-algorithms-in-rust/ Wed, 13 May 2020 00:00:00 +0000 https://oswalt.dev/2020/05/beyond-hello-world-sorting-algorithms-in-rust/ This year I’ve been picking up Rust as not only a new learning opportunity but also in service to a few side-projects I’ve been getting involved with. Like a lot of developers, I learn by doing. After spending a few weeks reading the Rust book and watching videos, I looked for some easy project ideas that I could use to explore the language that goes further than a simple “Hello World” which often doesn’t actually give you much breadth at all. https://oswalt.dev/2020/03/solving-name-is-not-exported-by-module-when-using-local-npm-dependencies/ Wed, 18 Mar 2020 00:00:00 +0000 https://oswalt.dev/2020/03/solving-name-is-not-exported-by-module-when-using-local-npm-dependencies/ This blog post will focus on a topic I don’t usually dive into (Javascript and related tooling), but I felt like others might benefit from the solution to a problem I encountered while doing local development for antidote-web, the web front-end that powers NRE Labs. A quick aside on the architecture for the front-end code for the Antidote platform - the antidote-web project is the lynchpin for everything. It’s where the general structure of the front-end app is managed. https://oswalt.dev/2020/03/building-your-own-junos-router-with-crpd-and-linuxkit/ Tue, 10 Mar 2020 00:00:00 +0000 https://oswalt.dev/2020/03/building-your-own-junos-router-with-crpd-and-linuxkit/ Lately I’ve been looking at some tools to make it easier to package containerized applications as lightweight virtual machines, to get the best of both worlds: the developer experience of a Dockerfile with the added protection of a hypervisor. As part of this process, I’ve been digging into Juniper’s containerized routing stack called cRPD, and trying to get that into a virtual form factor, so that I can effectively have a Linux router that happens to use the Junos routing stack. https://oswalt.dev/2020/03/rust-constants-variables-and-mutability-oh-my/ Thu, 05 Mar 2020 00:00:00 +0000 https://oswalt.dev/2020/03/rust-constants-variables-and-mutability-oh-my/ In the last post I wrote about my journey from Python to Go as my primary language, and how I am now exploring Rust. This will be the first in a series of posts on Rust, mostly written from this perspective. I realize not everyone is going to Rust from Go, but that’s my perspective, and it will be impossible to keep this perspective from showing through and making comparisons between Rust and Go or Python. https://oswalt.dev/2020/03/getting-rusty/ Wed, 04 Mar 2020 00:00:00 +0000 https://oswalt.dev/2020/03/getting-rusty/ Early this year I wrote about returning to first principles. I think this desire to dive deeper is a natural continuation of my goal of becoming a more well-rounded technologist. While it’s good to know and exploit your strengths, I think it’s also healthy to try and fill gaps where you see them, and I feel this is an area that warrants some focus for me. One way that I’ll be working towards this focus in 2020 is learning Rust. https://oswalt.dev/2020/01/returning-to-first-principles/ Thu, 02 Jan 2020 00:00:00 +0000 https://oswalt.dev/2020/01/returning-to-first-principles/ I feel very strongly (and have for some time) that fundamentals are really important in a technical career. I didn’t start my career with a traditional CS degree, and while there were some fundamental knowledge to be picked up along the way, much of my education and early work experience bypassed a lot of the lower-level fundamentals and placed heavy emphasis on operating technology. This feeling of pulling levers and pushing buttons, rather than actually building things, in large part was responsible for me shifting back into software development full-time. https://oswalt.dev/2019/10/keeping-nats-connections-dry-in-go/ Tue, 15 Oct 2019 00:00:00 +0000 https://oswalt.dev/2019/10/keeping-nats-connections-dry-in-go/ In the previous posts, I covered the basics of connecting to NATS in Go and the different ways subscribers can request information is sent to them. In this post, I’d like to build on those concepts by exploring how to structure your NATS-powered Go code so that things are clean and DRY. I’ll also show that trying to make things too DRY can be problematic; as with everything, moderation is a good idea. https://oswalt.dev/2019/09/controlling-information-flow-nats-subjects-and-queues/ Wed, 25 Sep 2019 00:00:00 +0000 https://oswalt.dev/2019/09/controlling-information-flow-nats-subjects-and-queues/ Publish/subscribe messaging platforms like NATS allow us to build highly event-driven software systems, where we can build software to constantly listen for relevant messages and take action accordingly. This is what makes EDI projects like StackStorm (a project I’ve worked on and written about before) - and others like it- so powerful. Another advantage of pub/sub systems is that publishers don’t have to know or care if anyone is listening. Whenever information needs to be sent, it’s sent. https://oswalt.dev/2019/09/kicking-the-tires-with-the-nats-go-client/ Sun, 22 Sep 2019 00:00:00 +0000 https://oswalt.dev/2019/09/kicking-the-tires-with-the-nats-go-client/ I am doing some prototyping for a project and part of this includes becoming more familiar with the NATS project, including its Go client (since all of the components in my project that will be talking to NATS are written in Go). In short, I have a bunch of little services that need to talk to each other, and a message broker like NATS fits the bill. One thing that drew me to NATS specifically is that it is unapologetically - nay, proudly - simple. https://oswalt.dev/2018/12/december-4-nre-labs-outage-post-mortem/ Wed, 05 Dec 2018 00:00:00 +0000 https://oswalt.dev/2018/12/december-4-nre-labs-outage-post-mortem/ I awoke yesterday to a very crisp Tuesday morning in Portland, Oregon. I had just poured myself a nice glass of Stumptown Nitro cold brew coffee, and wandered upstairs to my office for an 8AM conference call. I joined the meeting, and started going through my usual routine - part of which includes looking at the day’s NRE Labs stats. Here’s what I saw: Well, that kind of sucks. https://oswalt.dev/2018/11/troubleshooting-nginx-ingress-rewrites-in-kubernetes/ Tue, 13 Nov 2018 00:00:00 +0000 https://oswalt.dev/2018/11/troubleshooting-nginx-ingress-rewrites-in-kubernetes/ When deploying an application to Kubernetes, you almost certainly will want to create a Service to represent that application. Rather than relying on direct connectivity to Pods, which may be ephemeral, Services by contrast are long-living resources that sit on top of one or more Pods. They are also the bare minimum for allowing those pods to communicate outside the cluster. While Services are a nice abstraction so we don’t have to worry about individual Pods, they are also fairly dumb. https://oswalt.dev/2018/05/up-and-running-with-kubernetes-and-tungsten-fabric/ Tue, 08 May 2018 00:00:00 +0000 https://oswalt.dev/2018/05/up-and-running-with-kubernetes-and-tungsten-fabric/ I have a predominantly technical background. You can show me all the slide decks you want but until I can get my hands on it, it’s not real to me. This has greatly influenced what I’m focusing on now that I’m doing more than just technical work - how to reduce the barrier to entry for people to become acquainted with a project or product. As a result, I’ve been getting more involved with Tungsten Fabric (formerly OpenContrail). https://oswalt.dev/2018/04/get-started-with-junos-quickly-and-free/ Mon, 23 Apr 2018 00:00:00 +0000 https://oswalt.dev/2018/04/get-started-with-junos-quickly-and-free/ When I got started in networking, my education (like so many network engineers) was all about Cisco. All my networking courses in college, as well as my early networking jobs all used Cisco curricula and equipment, and valued Cisco certifications like the CCNA/CCNP/CCIE above all. It wasn’t until I had already been in the industry for about three years or so before I even got my hands on a Juniper device, and by that time, my IOS habits had taken root in my muscles, which made the new set/delete style of Junos configurations even more strange. https://oswalt.dev/2018/02/unit-testing-junos-with-jsnapy/ Tue, 27 Feb 2018 00:00:00 +0000 https://oswalt.dev/2018/02/unit-testing-junos-with-jsnapy/ I’ve been passionate about the idea of proactively testing network infrastructure for some time. I revived and added to these ideas in my last post. In that post’s video, I lay out three types of network testing in my presentation: Config-Centric - Verify my network is configured correctly State-Centric - Verify the network has the operational state I expect Application-Centric - Verify my applications can use the network in the way I expect In the same way a software developer might write tests in Python or Go that describe and effect desired behavior, the network engineer now has a growing set of tools they can use to make assertions about what “should be” and constantly be made aware of deviations. https://oswalt.dev/2018/02/nasa-social-oa-4-tours-and-launch/ Mon, 12 Feb 2018 00:00:00 +0000 https://oswalt.dev/2018/02/nasa-social-oa-4-tours-and-launch/ In December 2015 I had the distinct honor to be selected to attend a NASA Social event that coincided with the OA-4 launch, an ISS resupply mission. NASA runs these events occasionally to give the world some insight into what goes on at various locations pertaining to the space industry. There’s a lot of really cool work going on, and I’m happy to finally have a chance to publish my experience on this amazing trip. https://oswalt.dev/2018/02/intentional-infrastructure/ Sun, 04 Feb 2018 00:00:00 +0000 https://oswalt.dev/2018/02/intentional-infrastructure/ I gave a presentation at the recent Network Field Day 17 (on my 3rd day working for Juniper). My main goal for this presentation was just to get people excited about building stuff. We tend to focus on vendor-provided solutions in this industry, and there’s a lot of good reasons for that, but it’s also good to stay sharp and be able to build your own solution to fill gaps where necessary. https://oswalt.dev/2018/01/new-role-same-goal/ Mon, 29 Jan 2018 00:00:00 +0000 https://oswalt.dev/2018/01/new-role-same-goal/ I recently gave a presentation at Network Field Day 17 wherein I announced that not only was I about to give probably the most compressed talk of my life (time constraints are unforgiving) but that I also was now working for Juniper. Until today, this was pretty much the most explanation I had time to give: I decided to accept a position with Juniper over the 2017 holiday, and I started last week. https://oswalt.dev/2017/12/a-guide-to-open-source-for-it-practitioners/ Wed, 20 Dec 2017 00:00:00 +0000 https://oswalt.dev/2017/12/a-guide-to-open-source-for-it-practitioners/ It’s easy to see that open source is changing the way people think about infrastructure. However, as the saying goes: “The future is here, it’s just not evenly distributed”. As is normal, there will always be pockets of IT where active involvement in open source will just take some more time. I’ve worked on open source for a few years now, and I have always wanted to publish a post that focuses on a few key ideas that I wish I could tell every new entrant into the world of open source. https://oswalt.dev/2017/08/stackstorm-architecture-part-i-stackstorm-core-services/ Mon, 28 Aug 2017 00:00:00 +0000 https://oswalt.dev/2017/08/stackstorm-architecture-part-i-stackstorm-core-services/ A while ago, I wrote about basic concepts in StackStorm. Since then I’ve been knee-deep in the code, fixing bugs and creating new features, and I’ve learned a lot about how StackStorm is put together. In this series, I’d like to spend some time exploring the StackStorm architecture. What subcomponents make up StackStorm? How do they interact? How can we scale StackStorm? These are all questions that come up from time to time in the StackStorm community, and there are a lot of little details that I even forget from time-to-time. https://oswalt.dev/2017/04/your-cheese-moved-a-long-time-ago/ Thu, 06 Apr 2017 00:00:00 +0000 https://oswalt.dev/2017/04/your-cheese-moved-a-long-time-ago/ I was recently on a panel at the Event-Driven Automation Meetup at LinkedIn in Sunnyvale, CA, and we all had a really good hour-long conversation about automation. What really made me happy was that nearly the entire conversation focused on bringing the same principles that companies like LinkedIn and Facebook use on their network to smaller organizations, making them practical for more widespread use. Nina Mushiana of @LinkedIn says "Anything that can be documented should be automated". https://oswalt.dev/2017/03/learn-programming-or-perish/ Mon, 27 Mar 2017 00:00:00 +0000 https://oswalt.dev/2017/03/learn-programming-or-perish/ I was honored to return to Packet Pushers for a discussion on programming skillsets in the networking industry. I verbalized some thoughts there, but even 60 minutes isn’t enough for a conversation like this. To be clear, this post is written primarily to my followers in the networking industry, since that’s largely where this conversation is taking place. Scripting is NOT Programming I want to put something to rest right now, and that is the conflation of scripting and software development. https://oswalt.dev/2016/12/2016-recap-and-2017-goals/ Sat, 31 Dec 2016 00:00:00 +0000 https://oswalt.dev/2016/12/2016-recap-and-2017-goals/ Yet another recap post to follow up on last year’s. 2015 was a big transition year for me, and last year I wanted to make sure I kept the momentum going. I make this post yearly to publicly track my own professional development goals. I find this helps me stay accountable to these goals, and it also allows others to give me a kick in the butt if I’m falling behind. https://oswalt.dev/2016/12/introduction-to-stackstorm/ Fri, 16 Dec 2016 00:00:00 +0000 https://oswalt.dev/2016/12/introduction-to-stackstorm/ Earlier I wrote about some fundamental principles that I believe apply to any form of automation, whether it’s network automation, or even building a virtual factory. One of the most important concepts in mature automation is autonomy; that is, a system that is more or less self-sufficent. Instead of relying on human beings for input, always try to provide that input with yet another automated piece of the system. There are several benefits to this approach: https://oswalt.dev/2016/10/a-new-automation-chapter-begins/ Wed, 19 Oct 2016 00:00:00 +0000 https://oswalt.dev/2016/10/a-new-automation-chapter-begins/ Two years ago, while I worked as a network engineer/consultant, I felt strongly that the industry was ripe for change. In February 2015 I jumped feet-first into the world of network automation by going back to my roots in software development, combining those skills with the lessons I learned from 3 years of network engineering. I’ve learned a ton in the last 2 years - not just at the day job but by actively participating in the automation and open source communities. https://oswalt.dev/2016/10/principles-of-automation/ Tue, 18 Oct 2016 00:00:00 +0000 https://oswalt.dev/2016/10/principles-of-automation/ Automation is an increasingly interesting topic in pretty much every technology discipline these days. There’s lots of talk about tooling, practices, skill set evolution, and more - but little conversation about fundamentals. What little is published by those actually practicing automation, usually takes the form of source code or technical whitepapers. While these are obviously valuable, they don’t usually cover some of the fundamental basics that could prove useful to the reader who wishes to perform similar things in their own organization, but may have different technical requirements. https://oswalt.dev/2016/09/todd-has-moved/ Fri, 30 Sep 2016 00:00:00 +0000 https://oswalt.dev/2016/09/todd-has-moved/ ToDD has been out in the wild for 6 months, and in that time I’ve been really pleased with it’s growth and adoption. Considering this was just a personal side-project, I’ve been blown away by what it’s doing for my own learning experiences as well as for the network automation pipelines of the various folks that pop onto the slack channel asking questions. For the last 6 months I’ve hosted ToDD on my personal Github profile. https://oswalt.dev/2016/08/the-importance-of-the-network-software-supply-chain/ Tue, 16 Aug 2016 00:00:00 +0000 https://oswalt.dev/2016/08/the-importance-of-the-network-software-supply-chain/ At Networking Field Day 12, we heard from a number of vendors that offered solutions to some common enterprise network problems, from management, to security, and more. However, there were a few presentations that didn’t seem directly applicable to the canonical network admin’s day-to-day. This was made clear by some comments by delegates in the room, as well as others tweeting about the presentation. Accelerating the x86 Data Plane Intel, for instance, spent a significant amount of time discussing the Data Plane Development Kit (DPDK), which provides a different way of leveraging CPU resources for fast packet processing. https://oswalt.dev/2016/08/cs101-algorithms/ Tue, 09 Aug 2016 00:00:00 +0000 https://oswalt.dev/2016/08/cs101-algorithms/ First in this series is the subject of Algorithms. This topic is very interesting to me because when I first strived to understand what exactly they were, I was expecting something a lot more complicated than what they turned out to be. I think, shamefully, that Hollywood may have had an influence on this, as the term “algorithm” is one of many terms abused by “cyber” movies and the like, portrayed to be some sort of ultimate cyber weapon in the war against Ellingson Mineral Company. https://oswalt.dev/2016/08/new-series-cs-101/ Tue, 09 Aug 2016 00:00:00 +0000 https://oswalt.dev/2016/08/new-series-cs-101/ Historically, my background is far closer to the systems side of things, but as I’ve picked up software development experience over the past few years, I’ve come to appreciate the fundamentals of computer science that others in my shoes may not have been exposed to. That said, I have been working on a pseudo-formal blog series on computer science fundamentals. These fundamentals have a wide variety of applications. Those with more of an IT-focused background will learn that even if you don’t use graph theory, or optimize algorithms in your day job, many of these concepts are at the crux of many of the technologies that we use every day. https://oswalt.dev/2016/05/introducing-http-testing-in-todd/ Thu, 12 May 2016 00:00:00 +0000 https://oswalt.dev/2016/05/introducing-http-testing-in-todd/ Now that ToDD has been in the public arena for two months, one of the things I’m happiest about is the fact that testing in ToDD is totally flexible. Thanks to the concept of testlets, ToDD doesn’t have an opinion on the specifics of your tests - all of that logic is contained within the testlet. I believe there’s real value in going further than simple “ping” tests when validating that your network is working as you expect. https://oswalt.dev/2016/04/interop-vegas-2016/ Tue, 05 Apr 2016 00:00:00 +0000 https://oswalt.dev/2016/04/interop-vegas-2016/ I’m happy to be given the opportunity to speak once more at Interop Vegas in 2016. No workshop for me this year, but I will be putting on three individual talks, all focusing on topics that have been very near and dear to me over the past year. Last year I was very focused on putting the theory behind network automation into practical terms, and making it “real”. Over the past year I’ve seen rapid growth in adoption of these ideas, and I was happy to be just one very small part of helping to make that happen. https://oswalt.dev/2016/03/next-generation-network-telemetry/ Wed, 30 Mar 2016 00:00:00 +0000 https://oswalt.dev/2016/03/next-generation-network-telemetry/ Late last year, I was pleased to be part of a special Tech Field Day event focused on network analytics. We had a day full of presentations from folks like Netflix, Google, and some goofball with a wrinkly jacket - all focused on what the next-generation networks will look like with respect to analytics. This was a while ago, but I’ve wanted to write about this ever since, and a recent conversation gave me the spark I needed. https://oswalt.dev/2016/03/the-power-of-test-driven-network-automation/ Mon, 14 Mar 2016 00:00:00 +0000 https://oswalt.dev/2016/03/the-power-of-test-driven-network-automation/ Over the past few years, I’ve seen (and contributed to) a rise of real network engineers taking on the new and sometimes challenging world of network automation. Every time I check in on Jason Edelman’s Network Automation Slack channel, I’m very happy to see the sheer number of folks asking questions, trying to get the the concepts and tools of network automation working in their own environment. For many, this is all very new, and there’s a lot to soak up. https://oswalt.dev/2016/01/sdn-and-network-automation-splitting-hairs/ Wed, 27 Jan 2016 00:00:00 +0000 https://oswalt.dev/2016/01/sdn-and-network-automation-splitting-hairs/ At the recent Network Field Day 11, there were several discussions at the Cisco offices after the Cisco folks left the room. One of these discussions, led by Terry Slattery, was centered around SDN, and I think it’s worth a listen/watch (only about 20 minutes): In this video, I made the argument that SDN should be limited to a very specific definition, which eliminates the management plane from the conversation entirely (around 5:40). https://oswalt.dev/2016/01/the-unspoken-benefits-of-open-networking/ Wed, 27 Jan 2016 00:00:00 +0000 https://oswalt.dev/2016/01/the-unspoken-benefits-of-open-networking/ I have noticed a lot of very premature dismissal of a growing trend in the networking industry, which is the rise of open network operating systems. Nearly every post-announcement discussion that I hear among peers tends to sound something like this: I am not Facebook or Google. I don’t want to install third-party software on my switches, so this “open networking” movement is not relevant to me or my organization. https://oswalt.dev/2015/12/2015-recap-and-2016-goals/ Thu, 31 Dec 2015 00:00:00 +0000 https://oswalt.dev/2015/12/2015-recap-and-2016-goals/ Wow, it’s that time of year again! 2015 went by really quickly, and a lot has changed for me. It’s also worth mentioning that this is the first year-end recap to be published on my new github pages site! If you haven’t seen this kind of thing before, I make this post yearly to publicly track my own professional development goals. I find this helps me stay accountable to these goals, and it also allows others to give me a kick in the butt if I’m falling behind. https://oswalt.dev/2015/12/training-the-next-generation-network-engineer/ Mon, 28 Dec 2015 00:00:00 +0000 https://oswalt.dev/2015/12/training-the-next-generation-network-engineer/ The networking industry is at a crossroads. In the past few years, we’ve seen a flurry of activity in the world of software-defined networking (SDN), but this has mostly just resulted in a bunch of new products. I don’t feel that this has done nearly enough to improve network operations. In fact, this has in many ways resulted in more complexity. What we desperately need more than shiny new products (hardware or software) is a better understanding of simple tools and open source software. https://oswalt.dev/2015/11/kubernetes-basic-concepts/ Mon, 09 Nov 2015 00:00:00 +0000 https://oswalt.dev/2015/11/kubernetes-basic-concepts/ I have been diving into Kubernetes lately, for both personal and $dayjob reasons. With the combined effect of my attendance at a recent Kubernetes workshop by Kelsey Hightower (on his very last day at CoreOS no less!) and also having the amazing opportunity to attend the inaugural and sold-out Kubecon that starts today, I figured it’s high time I tackle a “basics of Kubernetes” post. This blog post is meant to serve as a very high-level introduction to Kubernetes concepts and components. https://oswalt.dev/2015/10/the-benefits-of-a-proper-development-environment/ Thu, 29 Oct 2015 00:00:00 +0000 https://oswalt.dev/2015/10/the-benefits-of-a-proper-development-environment/ I’ve had a number of folks approach me about the topic of development environments, so I figured it was worth a blog post. Maybe you’re curious what a development environment is, or perhaps you’re working through the challenge of developing code on one platform, and deploying on another. Maybe you already have a development environment - like a virtual machine - but you aren’t happy with your workflow, and feel it could use some upgrades. https://oswalt.dev/2015/10/network-namespaces-the-new-access-layer/ Tue, 27 Oct 2015 00:00:00 +0000 https://oswalt.dev/2015/10/network-namespaces-the-new-access-layer/ When considering containers and how they connect to the physical network, it may be easy to assume that this paradigm is identical to the connectivity model of virtual machines. However, the advent of container technology has really started to popularize some concepts and new terminology that you may not be familiar with, especially if you’re new to the way linux handles network resources. What is a Namespace? It’s important to understand this concept, because containers are NOT simply “miniature virtual machines”, and understanding namespaces is very important to conceptualizing the way a host will allocate various system resources for container workloads. https://oswalt.dev/2015/09/network-automation-be-bold/ Tue, 29 Sep 2015 00:00:00 +0000 https://oswalt.dev/2015/09/network-automation-be-bold/ I’ve had something on my mind concerning network automation, and I think it’s worth mentioning it here. There’s been a lot of talk - including plenty from myself - about using tools like Ansible for creating network configuration files; that is, text files that contain configurations for network devices, usually a list of CLI commands. And this is a great first step, certainly if you’re new to network automation. It’s really not that hard to generate configurations. https://oswalt.dev/2015/09/the-importance-of-quality-in-infrastructure-software/ Tue, 01 Sep 2015 00:00:00 +0000 https://oswalt.dev/2015/09/the-importance-of-quality-in-infrastructure-software/ Infrastructure doesn’t matter. That’s what we keep hearing, right? The ongoing effort to commoditize infrastructure has generated a lot of buzzwords and clickbait taglines, and this is one of the biggest. IT infrastructure has had a long history of hero culture, and it’s easy to make the assumption - given how low many of these technologies sit in the stack - that we are the important snowflakes and that we run the whole show. https://oswalt.dev/2015/08/docker-for-netops/ Fri, 21 Aug 2015 00:00:00 +0000 https://oswalt.dev/2015/08/docker-for-netops/ I have been spending this week in Silicon Valley at Network Field Day 10. One of the announcements struck a chord with me, as this year has marked some significant career changes for me: specifically an uptake in involvement with containers and software development. My good friend Brent Salisbury once wrote about the idea of using Golang for Network Operations tooling. While I’ve continued (and will continue) to build my Python skillset, I’ve also been getting more and more experience with Golang and with some of the great software projects created by it, such as Docker, and Kubernetes. https://oswalt.dev/2015/08/using-vagrant-with-cumulusvx/ Thu, 13 Aug 2015 00:00:00 +0000 https://oswalt.dev/2015/08/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. https://oswalt.dev/2015/07/big-flowering-thing/ Thu, 09 Jul 2015 00:00:00 +0000 https://oswalt.dev/2015/07/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. https://oswalt.dev/2015/06/is-container-networking-holding-on-to-the-past/ Wed, 24 Jun 2015 00:00:00 +0000 https://oswalt.dev/2015/06/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. https://oswalt.dev/2015/06/message-queues-rabbitmq-in-go-and-python/ Sat, 20 Jun 2015 00:00:00 +0000 https://oswalt.dev/2015/06/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. https://oswalt.dev/2015/06/open-source-routing-practical-lab/ Mon, 15 Jun 2015 00:00:00 +0000 https://oswalt.dev/2015/06/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. https://oswalt.dev/2015/05/double-parentheses-in-python/ Sat, 23 May 2015 00:00:00 +0000 https://oswalt.dev/2015/05/double-parentheses-in-python/ Python is one of the easiest programming languages to learn, because of it’s inherent flexibility. (This can be a good thing as well as a bad thing.) One example of Python’s flexibility is the double parentheses. Take the following snippet for example: print(funcwrapper(3)(2)) Even an inexperienced programmer should be able to make sense of most of this. Reading from left to right, it looks like we want to print the output of a function, and we’re passing an integer - 3 - to that function. https://oswalt.dev/2015/05/open-source-routing-a-comparison/ Fri, 22 May 2015 00:00:00 +0000 https://oswalt.dev/2015/05/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). https://oswalt.dev/2015/05/a-new-home-looking-back/ Mon, 18 May 2015 00:00:00 +0000 https://oswalt.dev/2015/05/a-new-home-looking-back/ I have moved to a new blogging platform! The timing was interesting, since the wordpress installation on which Keeping It Classless has operated for so long is about 5 years old (I operated on an older domain before Keeping It Classless was born). WOW. Five years is a long time in blog years. I could not have possibly predicted back then what this blog would do for me. In going over these old posts, I saw a very interesting progression of my own skillsets and mentality, and I figured I’d share. https://oswalt.dev/2015/05/moving-soon/ Sat, 16 May 2015 00:00:00 +0000 https://oswalt.dev/2015/05/moving-soon/ I would like to take the opportunity to let you all know that Keeping It Classless will be moving to a different blogging platform in the near future. For the vast majority of you, this will not be a problem. My intent is to keep as much as possible consistent between moves. However, some of you subscribe to my blog using some WordPress-specific features such as email subscription, as well as following me through the WordPress service itself. https://oswalt.dev/2015/05/sdn-integration-over-manipulation/ Wed, 13 May 2015 00:00:00 +0000 https://oswalt.dev/2015/05/sdn-integration-over-manipulation/ I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change. https://oswalt.dev/2015/05/the-two-network-as-code-domains/ Wed, 06 May 2015 00:00:00 +0000 https://oswalt.dev/2015/05/the-two-network-as-code-domains/ You’ve probably heard the term “network programmability” at this point. You probably also heard it equated to anything to do with code, automation, and networking. This was not always the case. Network programmability really first hit the big time back in 2011 in the early days of the public OpenFlow discussion. That phrase was almost universally understood to be a data plane concept - because it was describing the revolutionary ideas brought up by abstracting away a forwarding pipeline. https://oswalt.dev/2015/03/three-tips-for-technical-blogging/ Tue, 31 Mar 2015 00:00:00 +0000 https://oswalt.dev/2015/03/three-tips-for-technical-blogging/ From time to time, I’m asked by new or potential technical bloggers for advice on how to get into writing, or how to overcome some kind of mental reservation that he/she may have. It’s actually somewhat ironic - I still suffer from many of the same issues that I suffered from back before Keeping It Classless existed. I have been having some serious "Newbie Blogger" issues last few weeks. Ironically, I feel compelled to write about them. https://oswalt.dev/2015/03/sdn-protocols-part-5-netconf/ Mon, 30 Mar 2015 00:00:00 +0000 https://oswalt.dev/2015/03/sdn-protocols-part-5-netconf/ For those that followed my SDN Protocols series last summer, you might have noticed a missing entry: NETCONF. This protocol has actually existed for some time (the original now-outdated specification was published in 2006), but is appearing more often, especially in discussions pertaining to network automation. The current, updated specification - RFC6241 - covers a fairly large amount of material, so I will attempt to condense here. NETCONF operates at the management layer of the network, and therefore plays a role similar to that of OVSDB. https://oswalt.dev/2015/03/go-go-gadget-networking-lab/ Fri, 27 Mar 2015 00:00:00 +0000 https://oswalt.dev/2015/03/go-go-gadget-networking-lab/ For the last few years, if you wanted to set up a virtual network environment (for testing purposes, or setting up a lab, etc), it was more or less a manual process of installing software like the CSR 1000v from an ISO or OVA. Rinse and repeat. If you were fortunate enough to work at a company with decent virtual machine automation and infrastructure (and had access to it) then you could in theory make this a little easier, but it’s hardly portable. https://oswalt.dev/2015/03/networks-now-with-more-devops/ Thu, 12 Mar 2015 00:00:00 +0000 https://oswalt.dev/2015/03/networks-now-with-more-devops/ TL;DR - buzzwords suck and I want to rant about that. I’ve been doing a lot of posts lately on the skillsets and technologies needed to move networking into the same level of productivity that other disciplines have reached. During this process, I’ve had time to contemplate labels and buzzwords. By itself, I don’t see much value in the term “DevOps”, whether it’s succeeded by the phrase “for networking” or not. https://oswalt.dev/2015/02/free-form-discussion-at-cleur/ Wed, 18 Feb 2015 00:00:00 +0000 https://oswalt.dev/2015/02/free-form-discussion-at-cleur/ I was fortunate enough to be invited out to Milan, Italy for Cisco Live Europe, and we had a few interesting discussions about a multitude of topics. One of them was more free-form than the others, and focused on defining SDN, what it’s value is, and where that value is most realized. Check out this video recording of the session; it was good to get a few perspectives from non-networkers, since I’m sure their perspective is different from the network administrator’s as it pertains to the ongoing shift in this industry: https://oswalt.dev/2015/02/five-next-gen-networker-skills/ Thu, 12 Feb 2015 00:00:00 +0000 https://oswalt.dev/2015/02/five-next-gen-networker-skills/ With all the flux that is going on in the networking space, it’s hard to figure out what to do next. You may want to add to your skillset, but you’re not sure where to throw your effort. I’d like to focus on five different areas you can focus on, without talking about a specific product - at the end of the day, that’s just implementation details. These areas are going to be increasingly more valuable and will help you be more marketable when added to your existing network knowledge and experience. https://oswalt.dev/2015/01/network-automation-interop-vegas-2015/ Thu, 22 Jan 2015 00:00:00 +0000 https://oswalt.dev/2015/01/network-automation-interop-vegas-2015/ In case you are planning on attending Interop in Las Vegas this year, I’d like to let you know about my two sessions, both centered around emerging methodologies and technologies in the networking space. Practical Network Automation With Ansible and Python This is going to be a 3 hour workshop, aiming to be a practical look into network automation. I picked the topics that I have been working with most heavily in this space, and I think this workshop will be a great way to get up to speed with some down-to-earth network automation methodologies. https://oswalt.dev/2015/01/remove-duplicates-from-pocket-list/ Wed, 07 Jan 2015 00:00:00 +0000 https://oswalt.dev/2015/01/remove-duplicates-from-pocket-list/ One problem I’ve noticed with my Pocket list is that my reading list contains quite a few duplicate entires. Sometimes I forget I saved an article and I save it multiple times, or maybe I save it across-sources (like Twitter or Facebook, or just browsing. It looks like Pocket has some protective capabilities around this. If I endlessly spam the button provided to me by my Pocket chromecast extension, Pocket only saves the one copy and all is good. https://oswalt.dev/2015/01/continuous-integration-pipeline-for-networking/ Mon, 05 Jan 2015 00:00:00 +0000 https://oswalt.dev/2015/01/continuous-integration-pipeline-for-networking/ Popular development methodologies like Continuous Integration are usually accompanied by some kind of automated workflow, where a developer checks in some source code, which kicks off automated review, testing, and deployment jobs. I believe the same workflows can be adopted by network engineers. Let’s say you are the Senior Network Engineer for your entire company, which boasts a huge network. You don’t have time to touch every device, so you have a team of junior-level network engineers that help you out. https://oswalt.dev/2014/12/2014-recap-and-2015-goals/ Wed, 31 Dec 2014 00:00:00 +0000 https://oswalt.dev/2014/12/2014-recap-and-2015-goals/ When I started this post, the following mental image popped into my head, and I found it an apt description of 2014: Doing the year-end recap post. 2014 was all: pic.twitter.com/aXtC2sjN8l — Matt Oswalt (@Mierdin) December 30, 2014 Oh well…..let’s give this a try anyways. 2014 Recap I’ll list off the goals I set in my post one year ago, and reflect upon how they were pursued in 2014: https://oswalt.dev/2014/12/automation-isnt-just-about-speed/ Mon, 22 Dec 2014 00:00:00 +0000 https://oswalt.dev/2014/12/automation-isnt-just-about-speed/ In talking with folks about automation, the conversation almost always come around to “speed, speed, speed”. It’s easy to see why this is the first benefit that pops into mind - we’ve all spent gratuitous amounts of time doing repetitive, time-consuming tasks. It’s obvious why the prospect of automating these tasks and getting the time back is such an attractive one, even though most of us that have tried know that this is an absolute reality: https://oswalt.dev/2014/12/automating-san-zoning-with-schprokits/ Thu, 04 Dec 2014 00:00:00 +0000 https://oswalt.dev/2014/12/automating-san-zoning-with-schprokits/ Since this post was written, the company behind Schprokits has unfortunately gone out of business. Though this approach is no longer something that you can read and follow along with, I have left this post active as an academic exercise in network automation. I hope it is useful in some way. I recorded an in-depth explanation of the process (~42 mins), and [it can be found here](), as well as at the end of this post. https://oswalt.dev/2014/11/source-driven-configuration-for-netops/ Mon, 10 Nov 2014 00:00:00 +0000 https://oswalt.dev/2014/11/source-driven-configuration-for-netops/ I mentioned in a previous post that version control is an important component of efficiently managing network infrastructure. I’m going to take is a step further than what most are doing with RANCID, which is traditionally used at the end of a workflow (gathering running config diffs) and show you what it’s like to start with version controlled configuration artifacts, specifically using Ansible’s “template” module. I’m not going to discuss how you get the resulting configurations actually running on your network devices - that is best saved for another post. https://oswalt.dev/2014/11/storage-traffic-magic-with-openflow/ Fri, 07 Nov 2014 00:00:00 +0000 https://oswalt.dev/2014/11/storage-traffic-magic-with-openflow/ I am in the Bay Area this week, working on some network automation stuff, and I was fortunate to be able to stop by and say hello to the Storage Field Day 6 folks over drinks. I was told by several impressed delegates about a talk by Andy Warfield of Coho Data, where he described how they used OpenFlow to steer storage traffic intelligently to and from various nodes in a distributed storage array. https://oswalt.dev/2014/11/mass-customization/ Wed, 05 Nov 2014 00:00:00 +0000 https://oswalt.dev/2014/11/mass-customization/ I’ve mentioned in past articles about my belief that networking - both as a discipline and a technology - needs to be more consumable to other disciplines. But what does this mean? I was reminded of a few great examples today that I think are relevant to this idea, and might help explain my point a little more clearly. Mass Production Meets Customization The assembly line revolutionized the auto industry. Prior to this, vehicle production was very slow, and extremely costly. https://oswalt.dev/2014/10/5-dev-tools-for-network-engineers/ Mon, 27 Oct 2014 00:00:00 +0000 https://oswalt.dev/2014/10/5-dev-tools-for-network-engineers/ I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code - this is less about programming, and more about the tools that software developers use every day to work more efficiently. https://oswalt.dev/2014/10/why-network-automation-wont-kill-your-job/ Wed, 15 Oct 2014 00:00:00 +0000 https://oswalt.dev/2014/10/why-network-automation-wont-kill-your-job/ I’ve been focusing lately on shortening the gap between traditional automation teams and network engineering. This week I was fortunate enough to attend the DevOps 4 Networks event, and though I’d like to save most of my thoughts for a post dedicated to the event, I will say I was super pleased to spend the time with the legends of this industry. There are a lot of bright people looking at this space right now, and I am really enjoying the community that is emerging. https://oswalt.dev/2014/10/cisco-nx-api-1.0-update/ Wed, 08 Oct 2014 00:00:00 +0000 https://oswalt.dev/2014/10/cisco-nx-api-1.0-update/ If you weren’t paying attention, it was easy to miss. NX-API, Cisco’s new JSON/XML switch API is now shipping as version 1.0. NX-API originated on the Nexus 9000 platform created by the Insieme group, and I’ve explored this in detail before. In review, NX-API is a new, programmatic method of interacting with a Cisco Nexus switch. In many ways, Cisco is playing catch-up here, since this interface is really just a wrapper for the CLI (admittedly with some convenient output parsing), and most of their competitors have had similar interfaces for a while. https://oswalt.dev/2014/09/network-troubleshooting-with-thousandeyes/ Wed, 24 Sep 2014 00:00:00 +0000 https://oswalt.dev/2014/09/network-troubleshooting-with-thousandeyes/ My first experience with ThousandEyes was a year ago at Network Field Day 6, where they were kind enough to give us a tour of their office, and introduce us to their products. I’ve been fairly distracted since then, but kept an eye on what other delegates like Bob McCouch were doing with the product since that demo. A year later, at Network Field Day 8, they presented again. If you’ve never heard of ThousandEyes, and/or would like an overview, watch Mohit’s (CEO) NFD8 introduction: https://oswalt.dev/2014/09/sdn-protocols-part-4-opflex-and-declarative-networking/ Mon, 22 Sep 2014 00:00:00 +0000 https://oswalt.dev/2014/09/sdn-protocols-part-4-opflex-and-declarative-networking/ In this post, we will be discussing a relatively new protocol to the SDN scene - OpFlex. This protocol was largely championed by Cisco, but there are a few other vendors that have announced planned support for this protocol. I write this post because - like OVSDB - there tends to be a lot of confusion and false information about this protocol, so my goal in this post is to provide some illustrations that (hopefully) set the record straight, with respect to both OpFlex’s operation, and it’s intended role. https://oswalt.dev/2014/08/sdn-protocols-part-3-ovsdb/ Thu, 28 Aug 2014 00:00:00 +0000 https://oswalt.dev/2014/08/sdn-protocols-part-3-ovsdb/ Today, we will be discussing the Open vSwitch Database Management Protocol, commonly (and herein) referred to as OVSDB. This is a network configuration protocol that has been the subject of a lot of conversations pertaining to SDN. My goal in this post is to present the facts about OVSDB as they stand. If you want to know what OVSDB does, as well as does NOT do, read on. I would like to call out a very important section, titled “OVSDB Myths”. https://oswalt.dev/2014/08/dealing-with-schema-changes/ Mon, 04 Aug 2014 00:00:00 +0000 https://oswalt.dev/2014/08/dealing-with-schema-changes/ It’s not often I get to write about concepts rooted in database technology, but I’d like to illuminate a situation that software developers deal with quite often, and one that those entering this space from the network infrastructure side may want to consider. Software will often communicate with other software using APIs - an interface built so that otherwise independent software processes can send and receive data between each other, or with other systems. https://oswalt.dev/2014/07/sdn-protocols-part-2-openflow-deep-dive/ Mon, 28 Jul 2014 00:00:00 +0000 https://oswalt.dev/2014/07/sdn-protocols-part-2-openflow-deep-dive/ In the last post, I introduced you to the concept of control plane abstraction, specifically the OpenFlow implementation. I talked about how OpenFlow allows us to specify the flows that we want to be programmed into the forwarding plane, from outside the forwarding device itself. We can also match on fields we typically don’t have access to in traditional networking, since current hardware is optimized for destination-based forwarding. In this post, I plan to cover quite a few bases. https://oswalt.dev/2014/07/handling-multiples-in-cisco-nx-api-with-python/ Thu, 24 Jul 2014 00:00:00 +0000 https://oswalt.dev/2014/07/handling-multiples-in-cisco-nx-api-with-python/ A few weeks ago, I was working with the NX-API currently found on Cisco’s Nexus 9000 series switches, and ran into some peculiar behavior. NX-API returns all information in terms of Tables and Rows. For a specific example, let’s look at what NX-API returns when I ask the switch for running OSPF processes: There’s actually a lot more information in this snippet that pertains to the OSPF process itself, but I have omitted it for brevity. https://oswalt.dev/2014/07/sdn-protocols-part-1-openflow-basics/ Mon, 21 Jul 2014 00:00:00 +0000 https://oswalt.dev/2014/07/sdn-protocols-part-1-openflow-basics/ Let’s get into our first topic. And what better place to start than with the protocol that arguably started the SDN madness that we’re experiencing today - OpenFlow! I got fairly carried away with writing about this protocol, and understandably so - this is a complicated topic. That’s why I’ve split this post (which is already part of a series - very meta, much deep) into two parts. This post - Part 1 - will address OpenFlow’s mid to high-level concepts, exploring what it does, why/how the idea of control plane abstraction may be useful, and some details on how hardware interaction works. https://oswalt.dev/2014/07/sdn-protocols-new-series/ Sun, 20 Jul 2014 00:00:00 +0000 https://oswalt.dev/2014/07/sdn-protocols-new-series/ The networking industry in the last few years has seen an explosion in buzzwords, slide decks, new technologies, and SDN product announcements. The honest truth is that the networking industry is still in a great state of flux, as we collectively discover what SDN means to us. There’s a lot of new terms floating around, and what makes things even harder to keep up with, the marketing engines are alive and well - muddying the waters, and making it nearly impossible to get technical facts straight. https://oswalt.dev/2014/07/what-is-unidirectional-automation/ Wed, 09 Jul 2014 00:00:00 +0000 https://oswalt.dev/2014/07/what-is-unidirectional-automation/ I was pleased as punch to wake up the other day and read Marten Terpstra’s blog post on getting over the fear of using automation to make changes on our network infrastructure. He illuminated a popular excuse that I’ve heard myself on multiple occasions - that automation is great for things like threshold alarms, or pointing out the percieved root cause of a problem, but not actually fixing the problem. The idea is that the problems that occur on a regular basis, or even performing configuration changes in the first place - is a specialized task that a warm-blooded human being absolutely, no-doubt must take total control of in order to be successful. https://oswalt.dev/2014/06/spine/leaf-topology-explorer-with-ansible/ Mon, 30 Jun 2014 00:00:00 +0000 https://oswalt.dev/2014/06/spine/leaf-topology-explorer-with-ansible/ I’ve mentioned before the need for networks to be addressed in a very programmatic way. Very often, I’ve found the discussion is actually a lot less about “programming language” details and more about getting rid of the methodology of addressing the network as a mere “collection of boxes” (see “Box Mentality"). Instead, we have the ability to address the network as any developer would address the distributed components of an application. https://oswalt.dev/2014/06/network-automation-or-sdn/ Tue, 24 Jun 2014 00:00:00 +0000 https://oswalt.dev/2014/06/network-automation-or-sdn/ With all of the activity going on in the networking industry right now, and all of the new terminology (as well as old re-invented terminology), it’s quite easy to get messages mixed up. After all, there’s no centralized dictionary for all of this stuff. I’d like to address something that has bugged me for a while. I’ve now heard from quite a few folks that SDN to them means the ability to automate network tasks. https://oswalt.dev/2014/06/glue-networks-at-onug-2014/ Sat, 07 Jun 2014 00:00:00 +0000 https://oswalt.dev/2014/06/glue-networks-at-onug-2014/ Glue Networks had a presence at the last ONUG, where Tom Hollingworth was able to get an overview from Glue’s founder, Jeff Gray: As you can see, Glue’s product targets the WAN, and specifically addresses the difficult provisioning tasks that most shops do manually. These include but are not limited to: Provisioning (and deprovisioning) of QoS resources for various applications like SAP and Lync based off of need and time of day. https://oswalt.dev/2014/05/pylint-errors-final-newline-missing/ Tue, 27 May 2014 00:00:00 +0000 https://oswalt.dev/2014/05/pylint-errors-final-newline-missing/ I recently ran into a slew of errors when using Pylint - a sort of “quality checker” for your Python code. If you haven’t used it yourself, I highly recommend you check it out - it WILL make you a better Python coder.(Thanks to Matt Stone for introducing me!) This particular error is common if you forget to append a newline character to the end of your python script, but I was getting one for every single line of code in my program. https://oswalt.dev/2014/05/the-evolution-of-network-programmability/ Tue, 27 May 2014 00:00:00 +0000 https://oswalt.dev/2014/05/the-evolution-of-network-programmability/ This post is the “text” version of a talk I gave at Cisco Live US 2014 titled “SDN: People, Process, and Evolution”. While there is certainly some technical details involved here, this topic is really more of a philosophical one, and it is very near and dear to my heart as I talk with more folks about how networking is going to evolve in the years to come. The Problem with Networking Most of my readers would consider themselves network engineers - folks that live and breathe networking and everything that’s required to build them. https://oswalt.dev/2014/05/recap-of-onug-conference-2014/ Mon, 12 May 2014 00:00:00 +0000 https://oswalt.dev/2014/05/recap-of-onug-conference-2014/ Last week I attended the Open Networking User Group conference. My main reason for attending was to participate in three roundtable discussions put on by Tech Field Day. These sessions were recorded, and I’ll be following up with specific thoughts on each session in later blog posts. These round-tables only occupied a portion of the two-day conference, so I spent the remainder of the time speaking with some of the vendors and sitting in a few of the sessions. https://oswalt.dev/2014/05/open-networking-user-group-conference-2014/ Sun, 04 May 2014 00:00:00 +0000 https://oswalt.dev/2014/05/open-networking-user-group-conference-2014/ Today I’m off to NYC for Open Networking User Group 2014. Tech Field Day was at the last ONUG back in October, 2013 and they were kind enough to invite me out to this one. Here’s a quick intro video of ONUG for those that aren’t aware of it - Tom Hollingsworth interviews ONUG creator Nick Lippis: We have a good group of vendors lined up for similar round-table discussions. https://oswalt.dev/2014/04/networking-and-the-consumption-model/ Thu, 17 Apr 2014 00:00:00 +0000 https://oswalt.dev/2014/04/networking-and-the-consumption-model/ I’ve talked with all kinds of IT professionals in the past year or so about building an organization of various IT disciplines that are truly service-oriented towards each other and to the other parts of the business. While I will never claim to be an expert in business development and will always claim allegiance to the nerdy technical bits, it’s easy to see the value in such an organizational model, and very interesting to explore the changes that technical people can make to push for such an approach. https://oswalt.dev/2014/04/introduction-to-ansible-and-san-configuration-automation/ Mon, 14 Apr 2014 00:00:00 +0000 https://oswalt.dev/2014/04/introduction-to-ansible-and-san-configuration-automation/ My previous post on automatically generating a SAN configuration explored what is possible when using a templating language like Jinja2, and a little Python work. I’d like to take this a step further. There are two areas I did not address in that post. The typical SAN or UCS administrator likely knows little if any Python. I’d like to produce a tool that is easy enough to consume, and requires no programming knowledge to use. https://oswalt.dev/2014/04/the-learning-curve-implementations-vs-fundamentals/ Tue, 08 Apr 2014 00:00:00 +0000 https://oswalt.dev/2014/04/the-learning-curve-implementations-vs-fundamentals/ I’ve spent a lot of time lately considering skillsets, and how people go about learning new things. Many aspects of the IT industry are starting to overlap with each other (the idea of DevOps being just one manifestation) and it’s incredibly interesting to see how individual professionals are incorporating new knowledge into their repertoire. I did a little contemplation on this over the weekend and I’d like to share some observations I’ve made. https://oswalt.dev/2014/03/san-automation-with-python-and-jinja/ Fri, 28 Mar 2014 00:00:00 +0000 https://oswalt.dev/2014/03/san-automation-with-python-and-jinja/ One of my least favorite things to do in my day job is create or maintain a zoning configuration on a fibre channel switch, such as a Cisco Nexus or MDS. It’s tedious, very error prone, and annoying when changes need to be made. I wrote earlier in the week on the value of using a templating language like Jinja to define the structure of a switch configuration, but dynamic enough to accept all kinds of input from some higher-level intelligence elsewhere. https://oswalt.dev/2014/03/opendaylight-at-networking-field-day-7/ Thu, 27 Mar 2014 00:00:00 +0000 https://oswalt.dev/2014/03/opendaylight-at-networking-field-day-7/ Networking Field Day 7 was the third Tech Field Day event I attended as a delegate, and as expected, it was a blast. Its always good to be reunited with old friends, especially in this kind of environment, where constant technical discussions are…….well, they’re just going to happen. There were certainly some common undertones in every single presentation. One big example is OpenDaylight - nearly every vendor had at least something to say about it. https://oswalt.dev/2014/03/network-configuration-templates-using-jinja2/ Wed, 26 Mar 2014 00:00:00 +0000 https://oswalt.dev/2014/03/network-configuration-templates-using-jinja2/ We’ve all been there at some point in our careers - especially those that work for VARs. You’re presented with a bunch of new gear that needs to be configured and deployed, and you’re tasked with making the magic happen. It was great to wake up yesterday to read Jason Edelman’s post on Ansible for networking - taking an approach to network automation that’s built upon existing, proven tools just makes sense, especially for the use case of initial configuration, but hopefully beyond. https://oswalt.dev/2014/03/the-foundation-of-network-programmability/ Tue, 25 Mar 2014 00:00:00 +0000 https://oswalt.dev/2014/03/the-foundation-of-network-programmability/ Ever since I entered this field, I’ve been interested in this concept of “network programmability”. Forgetting for a second what we’ve been talking about in the past few years since the advent of the “SDN tsunami”, even the ability to automate simple infrastructure tasks at a small scale has grabbed my attention. It’s important to note something here; the CLI is a wonderful tool. So many vendors take the wrong approach and say the CLI is going away in lieu of pretty GUIs and APIs, as if someone can’t write a really good CLI to consume a really good API. https://oswalt.dev/2014/03/the-dry-principle-and-why-network-engineers-should-care/ Wed, 12 Mar 2014 00:00:00 +0000 https://oswalt.dev/2014/03/the-dry-principle-and-why-network-engineers-should-care/ The networking industry has long speculated that coding skillsets are something that will likely become key in the future. I’m sure this will vary from job to job, but I can tell you that - at least for me - it’s already happened. I’m not even just talking about knowing syntax like Python, Java, Ruby, etc. I’ve maintained these skillsets sufficiently throughout my network-specific studies that recalling these skills isn’t that hard (admittedly I’m a youngin so it hasn’t been that long). https://oswalt.dev/2014/03/mtu-considerations-for-vxlan/ Tue, 11 Mar 2014 00:00:00 +0000 https://oswalt.dev/2014/03/mtu-considerations-for-vxlan/ When using overlays, its important to remember (in most cases) that an entire Ethernet frame is being encapsulated in something else (usually Ethernet + IP + UDP + Overlay Header). This means that the Maximum Transmission Unit for the underlay must be adjusted. There are a number of posts out there about correct MTU settings for VXLAN. Unfortunately, many of them are either wrong, or unclear as to the math behind these calculations. https://oswalt.dev/2014/02/network-configuration-the-case-for-normalization/ Fri, 28 Feb 2014 00:00:00 +0000 https://oswalt.dev/2014/02/network-configuration-the-case-for-normalization/ I’ve had network configuration tools and protocols on my mind for the last few weeks. Everyone’s got some hot new API or configuration protocol - and on the outside looking in, it’s easy to assume that they’re all just different flavors of the same general concept - network configuration. So are they basically competing standards (VHS vs Betamax, anyone?)? Or is there a method to this madness? Just to name a few, OVSDB and Netconf are actually established JSON-RPC and XML-RPC (respectively) based standardized formats for accomplishing network configuration on the wire, rather than chase down each vendor’s individual XML/JSON API. https://oswalt.dev/2014/02/cisco-nexus-9000-nx-api/ Tue, 18 Feb 2014 00:00:00 +0000 https://oswalt.dev/2014/02/cisco-nexus-9000-nx-api/ A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well. https://oswalt.dev/2014/02/cisco-aci-nexus-9000-initial-configuration/ Mon, 17 Feb 2014 00:00:00 +0000 https://oswalt.dev/2014/02/cisco-aci-nexus-9000-initial-configuration/ I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations. https://oswalt.dev/2014/02/the-role-of-code-in-the-new-network/ Fri, 07 Feb 2014 00:00:00 +0000 https://oswalt.dev/2014/02/the-role-of-code-in-the-new-network/ I was inspired by many little things over the past few days to begin writing a post about this whole “writing code” thing that network engineers the world over have been asking about. I’ve said before I know that most network engineers already write some kind of code - even if it’s as simple as a snippet of VBA in an Excel spreadsheet to automatically convert a spreadsheet of configuration options into an actual running configuration. https://oswalt.dev/2014/02/on-the-ground-at-opendaylight-summit-2014/ Tue, 04 Feb 2014 00:00:00 +0000 https://oswalt.dev/2014/02/on-the-ground-at-opendaylight-summit-2014/ I was fortunate enough to spend this morning (and will be here for quite a while) in Silicon Valley at the first ever OpenDaylight Summit. The initial keynotes were good, but for me the event started last night when I had the opportunity to sit with some of my own industry role models and just talk nerdy, nerdy networking. Considering how very young this project is (10 months), there are a surprisingly large number of people here - over 550 attendees. https://oswalt.dev/2014/01/why-python/ Fri, 31 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/why-python/ It’s been really interesting to see the industry in an all-out zerg rush to adopt Python as a skill-set. What is it about this seemingly arbitrary selection in the vast array of programming languages available out there? What is so special about Python that it comes up in nearly every conversation about SDN? This post has been in drafts for some time, and I was motivated to finish it up by this Packet Pushers episode, where Jeremy Schulman and others discuss Python and its impact to networking. https://oswalt.dev/2014/01/networking-field-day-7-here-we-go-again/ Tue, 28 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/networking-field-day-7-here-we-go-again/ I’m pleased to be invited back for the 7th installment of Networking Field Day in San Jose, CA from February 19th - 21st. This event is part of a series of independent IT community-powered events that give the vendors an opportunity to talk about the products and ideas they’ve been working on, and receive honest and direct feedback from the delegates. The results of this dynamic vary quite greatly - sometimes a vendor doesn’t quite bring their A-game and we let them know. https://oswalt.dev/2014/01/storage-flow-control-part-2-implementation-and-troubleshooting/ Wed, 22 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/storage-flow-control-part-2-implementation-and-troubleshooting/ This will be a short follow-up to my last post about the idea of Flow Control in storage protocols. As a review, the three main options in common use today are: IP Storage - uses TCP windowing to provide feedback to client on how much data to send Native Fibre Channel - uses buffer credits (typically on a hop-by-hop basis when using N_port to F_port) FCoE - uses Priority Flow Control to define a class of service on which to send Ethernet PAUSE frames to manage congestion The last item is really the only one that warrants any kind of configuration, as the first two are more or less baked into the protocol stacks. https://oswalt.dev/2014/01/opendaylight-summit-2014/ Wed, 22 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/opendaylight-summit-2014/ I will be at the OpenDaylight Summit in Santa Clara on February 4th and 5th. To me, OpenDaylight represents a platform on which we can test SDN ideas today, right here, and right now. In my day job I may never be called upon to help deploy OpenDaylight (here’s hoping!) but nonetheless, it’s projects like this where the best and the brightest come together to share ideas and help to form the technology that the industry will be using for the next few decades. https://oswalt.dev/2014/01/vif-down-issues-with-ucsm-2.21b/ Mon, 20 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/vif-down-issues-with-ucsm-2.21b/ Sadly, this will be another post regarding issues I’ve had with UCSM firmware release 2.2(1b). During the upgrade process, I experienced a lot of issues with data plane connectivity - after I activated (and subsequently rebooted) a Fabric Interconnect, and it came up with the new NXOS version, a slew of blades would have persistent errors regarding virtual interfaces (VIFs) that wouldn’t come back online. Here is the error report for a single blade where I was seeing these errors: https://oswalt.dev/2014/01/cisco-ucs-unable-to-communicate-with-ucsm-controller/ Sun, 19 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/cisco-ucs-unable-to-communicate-with-ucsm-controller/ When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this: 6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary. https://oswalt.dev/2014/01/cisco-ucs-error-process-failed/ Sat, 18 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/cisco-ucs-error-process-failed/ One of the (sadly numerous) issues I’ve run into while upgrading to Cisco UCSM version 2.2(1b) is this little error message indicating that a service failed to start: This gives us an error code of F0867 and it’s letting us know that the UCSM process httpd_cimc.sh failed on one of our Fabric Interconnects. For those that don’t know, you can get a list of processes within UCSM by connecting to local management and running “show pmon state”. https://oswalt.dev/2014/01/storage-flow-control-part-1-introduction/ Fri, 17 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/storage-flow-control-part-1-introduction/ When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time. https://oswalt.dev/2014/01/the-illusion-of-lock-in-avoidance/ Thu, 09 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/the-illusion-of-lock-in-avoidance/ Over the past few months I’ve heard a lot about vendor lock-in, specifically with respect to new SDN/Network Virtualization products that have come out last year. It appears that no matter what product you look at, there’s some major factor that will cause you to be severely locked in to that vendor until the end of time. Unless, of course, you’re a proponent of that vendor, in which case, that vendor is NOT locking you in, but that other guy totally is. https://oswalt.dev/2014/01/libvirt-intro-and-basic-configuration/ Tue, 07 Jan 2014 00:00:00 +0000 https://oswalt.dev/2014/01/libvirt-intro-and-basic-configuration/ I’ve been hearing a lot about libvirt, so I figured I’d check it out, and see if I could play around with it in my own home lab. According to the wiki, libvirt is a “collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management.” Okay that’s pretty cool - basically if I have a multi-hypervisor environment, I can build my operational policies around libvirt, so that no matter what hypervisor a workload is being instantiated on, the process is the same. https://oswalt.dev/2013/12/2013-recap-and-2014-goals/ Mon, 30 Dec 2013 00:00:00 +0000 https://oswalt.dev/2013/12/2013-recap-and-2014-goals/ Wow - this one snuck up on me. Seriously, when I think of how 2013 went, I’m amazed at how much happened this year but also how fast it flew by. As per the tradition I started last year, I thought it prudent to write a post summarizing how terribly I was able to forecast 2013 in terms of personal goals, and make another feeble attempt at planning out 2014. Let’s start with last year: https://oswalt.dev/2013/12/a-christmas-binary-miracle/ Thu, 26 Dec 2013 00:00:00 +0000 https://oswalt.dev/2013/12/a-christmas-binary-miracle/ My brother got a little puzzle in his stocking this Christmas. It was a little cardboard booklet, and on each page was written a block of numbers, like so: BLOCK ONE 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 BLOCK TWO 2 3 6 7 10 11 14 15 18 19 22 23 26 27 30 31 34 35 38 39 42 43 46 47 50 51 54 55 58 59 62 63 BLOCK THREE 4 5 6 7 12 13 14 15 20 21 22 23 28 29 30 31 36 37 38 39 44 45 46 47 52 53 54 55 60 61 62 63 BLOCK FOUR 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 47 56 57 58 59 60 61 62 63 BLOCK FIVE 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 BLOCK SIX 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 You’re to ask someone to pick any number they see in any block, and don’t tell you what it is. https://oswalt.dev/2013/12/what-is-a-best-practice/ Thu, 19 Dec 2013 00:00:00 +0000 https://oswalt.dev/2013/12/what-is-a-best-practice/ I see a lot of articles and even vendor whitepapers that like to throw the term “best practice” around like it’s pocket change. Truth be told, while there are plenty of general best practices that are recommended in any case, many of what a vendor will call “best practices” are usually just the most common response to an If/Then statement that represents the surrounding environment. Here’s a good example. I’ve heard on multiple occasions regarding the standard vSwitch in VMWare vSphere that it is a “best practice” to set the load balancing policy to “route based on the originating virtual port ID”. https://oswalt.dev/2013/12/default-cos-value-in-netapp-cluster-mode/ Mon, 16 Dec 2013 00:00:00 +0000 https://oswalt.dev/2013/12/default-cos-value-in-netapp-cluster-mode/ I was troubleshooting an MTU related issue for NFS connectivity in a Flexpod (Cisco UCS, Cisco Nexus, and Netapp storage with VMware vSphere, running the Nexus 1000v). Regular-sized frames were making it through, but not jumbo frames. I ensured the endpoints were set up correctly, then moved inwards….in my experience, the problem is usually there. The original design basically included the use of CoS tag 2 for all NFS traffic, so that it could be honored throughout the network, and given jumbo frames treatment. https://oswalt.dev/2013/12/converging-skillsets-with-technology/ Tue, 10 Dec 2013 00:00:00 +0000 https://oswalt.dev/2013/12/converging-skillsets-with-technology/ I saw this Engineers Unplugged video today and was reminded of a viewpoint I’ve been slowly developing over the last two years or so: Essentially the discussion is about convergence technologies like FCoE, where we rid ourselves of a completely separate network, and converge FC storage traffic onto our standard Ethernet network. With this technology shift, how does this impact the administration of the technology? Do the teams have to converge as well? https://oswalt.dev/2013/11/preventing-information-overload/ Thu, 21 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/preventing-information-overload/ Man, did I pick a tumultuous time to start a career in technology - there are so many great debates going on right now, with vendors working around the clock churning out new products for the general populace to chew on and talk about. I’m becoming more and more involved with the community nowadays, and top of that, I’m a big nerd to start with. So it’s easy for me to suffer from information overload, and I’d be lying if I said it didn’t happen just about every week. https://oswalt.dev/2013/11/the-new-face-of-the-access-layer/ Wed, 20 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/the-new-face-of-the-access-layer/ The role, and the features of the access layer in the datacenter has changed dramatically in such a short time. Prior to virtualization, the DC access layer was still relatively simple. Now that the majority of workloads are virtualized, we’re seeing some pretty crazy shifts. Many simple network functions like routing and security, as well as some advanced functions like load balancing are moving into software. This follows the general best practice of applying policy as close to the edge of your network as possible. https://oswalt.dev/2013/11/mass-esxi-deployment-using-auto-deploy-boot-from-san-and-powershell/ Tue, 19 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/mass-esxi-deployment-using-auto-deploy-boot-from-san-and-powershell/ I recently had a need to deploy quite a few ESXi hosts on top of Cisco UCS B-Series blades (60+) back-ended by Netapp storage. I needed some kind of method to do this quickly so that I didn’t have to spend days just installing ESXi. Here were some of the design guidelines: Needed an ESXi 5.5 installation with the Cisco enic and fnic drivers installed, as well as the Cisco 1000v VEM module https://oswalt.dev/2013/11/tech-field-day-round-table-at-cisco-aci-launch/ Tue, 12 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/tech-field-day-round-table-at-cisco-aci-launch/ I was honored to be part of a round table discussion held at the Cisco ACI launch with a lot of smart folks. I recommend a watch, we got into some really cool topics, and helped create the framework for some future blog posts of mine. For more on Tech Field Day, head over to TechFieldDay.com I attended the Cisco ACI launch event as a Tech Field Day delegate. https://oswalt.dev/2013/11/cisco-aci-as-the-dust-settles/ Mon, 11 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/cisco-aci-as-the-dust-settles/ So, the industry is sufficiently abuzz about the Cisco ACI launch last week, and the stats on my introductory series I wrote tells me that, like it or not, this is having a pretty big impact. The focus on the application is clearly the right approach - all of this talk about SDN and network virtualization is taking place because the current network model’s complexity results in bad kluges and long provisioning times, and the applications folks are always waiting on the network to respond. https://oswalt.dev/2013/11/insieme-and-cisco-aci-part-1-hardware/ Wed, 06 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/insieme-and-cisco-aci-part-1-hardware/ I’m pleased to kick off my 3-part blog series regarding the VERY recently announced data center networking products by Insieme, now (or very soon) part of Cisco. Nexus 9000 Overview From a hardware perspective, the Nexus 9000 series seems to be a very competitively priced 40GbE switch. As (I think) everyone expected, the basic operation of the switch is to serve up a L3 fabric, using VXLAN as a foundation for overlay networks. https://oswalt.dev/2013/11/insieme-and-cisco-aci-part-2-programmability/ Wed, 06 Nov 2013 00:00:00 +0000 https://oswalt.dev/2013/11/insieme-and-cisco-aci-part-2-programmability/ Introduction to Application-Centric Infrastructure In the last post, we discussed the hardware that was being announced from Cisco’s Insieme spin-in. While the hardware that is comprising the new Nexus 9000 series is certainly interesting, it wouldn’t mean nearly as much without some kind of integration on an application level. Traditionally, Cisco networking has been relatively inaccessible to developers or even infrastructure folks looking to automate provisioning or configuration tasks. It looks like the release of ACI and the Nexus 9000 switch line is aiming to change that. https://oswalt.dev/2013/10/plexxi-optimized-workload-and-workflow/ Mon, 28 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/plexxi-optimized-workload-and-workflow/ Plexxi was a vendor that presented at Networking Field Day 6, and was one that really got me excited about what’s possible when you think about what kind of metadata your data center contains, and what products like Plexxi can do with that data once abstracted and normalized the right way. I will be intentionally brief with respect to my thoughts on the hardware - others like Ivan (and more) have already done a better job with this than I ever will. https://oswalt.dev/2013/10/im-a-networking-guy-and-im-here-to-talk-about-programming/ Fri, 25 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/im-a-networking-guy-and-im-here-to-talk-about-programming/ I’m fortunate enough to work and be connected with some stellar networking professionals. I mean it - they’re rock stars. In my quest to surround myself with smart folks like this - in an attempt to at the very least learn by osmosis - I’ve clearly succeeded. I haven’t been in the industry for that long - but I’ve chosen networking (among other things) to be what I want to focus on professionally, and these are the best people to learn it from. https://oswalt.dev/2013/10/network-function-abstraction-redux-now-with-devops/ Tue, 22 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/network-function-abstraction-redux-now-with-devops/ I wrote a few days ago about how cool projects like OpenDaylight are abstracting network functions into consumable policies that non-network folks can use (and that’s a good thing!). I felt this quick follow-up was necessary. Providing the right tools to the application folks that allow network provisioning to occur as quickly as anything else that’s software-defined, such as servers, while keeping those tools light on the learning curve, is exactly what the apps folks have been wanting from the network for the last 10 years or so. https://oswalt.dev/2013/10/opendaylight-and-those-pesky-southbound-apis/ Mon, 21 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/opendaylight-and-those-pesky-southbound-apis/ In case you’ve noticed I’ve been pretty quiet - I’d be lying if I said my day job wasn’t at least partially to blame. However, a good chunk of my free time has also been spent jumping back into the software development game. I was never really a “programmer” in the common sense - I’ve always written code strictly as part of an infrastructure effort. My first “job” that involved writing code was on a VoIP team for a retail company, creating web service-type applications that interacted with the voice infrastructure; think “IVR” on steroids. https://oswalt.dev/2013/10/cisco-ucs-sdk-for-python-and-building-in-windows/ Fri, 18 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/cisco-ucs-sdk-for-python-and-building-in-windows/ So I’m tackling a little side project - and that is to replicate my Cisco UCS configuration scripts, currently in PowerShell, but instead in Python. While the UCS API is actually an XML interface on the Fabric Interconnects, Cisco has created a module of cmdlets called PowerTool so that this service can be easily consumed, rather than deal with XML serialization directly. For instance, once authenticated, you can do cool stuff like get a list of all Service Profiles on a system: https://oswalt.dev/2013/10/cisco-ucs-crossing-the-streams/ Thu, 10 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/cisco-ucs-crossing-the-streams/ Apparently you can cable the A-side Fabric Interconnect to the right IOM in a chassis, and it works just fine. You can even look at the DCE interfaces on a VIC in this chassis and see that the paths have been flipped: This is not true for the “correctly” cabled chassis, where the A-side traces occupy the first two slots: The first two interfaces will always go to the left IOM because the backplane traces are cabled that way. https://oswalt.dev/2013/10/introduction-to-open-vswitch/ Mon, 07 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/introduction-to-open-vswitch/ In the early days of my quest to cut through the jungle of hype regarding SDN, it was difficult to go a single day without hearing about Open vSwitch, or OVS. I’ve been tinkering with Open vSwitch in my lab for a few months now, and realized that I haven’t yet written an introductory post about it for those that haven’t tried it out. If you’re involved with data center like I am, you’re probably familiar with the concept of a vSwitch. https://oswalt.dev/2013/10/ovsdb-echo-in-python/ Wed, 02 Oct 2013 00:00:00 +0000 https://oswalt.dev/2013/10/ovsdb-echo-in-python/ I don’t mind coding in Java (i.e. OpenDaylight) but I wanted something quick and easy, so I’m writing a utility-esque script that sacrifices extensibility for speed. And since Python is something I’ve been meaning to stretch my muscles in, I decided to throw this together. Keep in mind that this can all be done by ovsdb-client natively via Linux command line, but I wanted to write it in Python to learn it, as well as provide it for a cool (technically) cross-platform language. https://oswalt.dev/2013/09/nuage-networks-at-network-field-day-6/ Thu, 26 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/nuage-networks-at-network-field-day-6/ Nuage is tackling the “rapid provisioning” problem when it comes to networking. How can we convince customers or LoB owners to not push everything up to AWS, when the provisioning mechanisms behind a private solution are not nearly as good? The ultimate goal is to have the network immediately ready upon instantiating a workload, physical or virtual. The key focus we heard about is that an SDN solution must provide this policy automation framework across virtual AND non-virtual workloads. https://oswalt.dev/2013/09/sdn-and-programming-a.k.a.-what-the-heck-is-a-rest-api/ Thu, 19 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/sdn-and-programming-a.k.a.-what-the-heck-is-a-rest-api/ Early on in my IT career I was fortunate enough to work with a few technologies and projects that forced me to get some decent experience writing code. While I’ve definitely moved into more of an infrastructure focus since then, this experience allowed me to get a firm grasp on good software development practices, and working with open communication formats between software systems. If you’re in networking, and have never heard of an API (Application Programming Interface) or haven’t quite grasped the concept, it’s quite simple. https://oswalt.dev/2013/09/the-benefit-of-infrastructure-apis/ Wed, 18 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/the-benefit-of-infrastructure-apis/ A lot of networking folks have heard of the concept of an API but have been too easily discouraged when they realize many of their favorite platforms don’t really have a good one. As a result, the scripting-savvy networking guy is typically relegated to what I lovingly refer to as “SSH scraping”, or the act of making a really nice script that, after it’s all said and done, just sends SSH commands to the devices in the same way that a human would, only……faster. https://oswalt.dev/2013/09/plexxi-dse-an-informal-analogy/ Wed, 11 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/plexxi-dse-an-informal-analogy/ Sitting in the NFD6 demo with Plexxi and got a great overview of the DSE product they’ve been working on. This service allows them to dynamically build network configurations based on external services like Openstack, puppet, etc. The example that Derick provided was the fact that an access list - instead of referring to a source IP address, or destination port, etc. - we can now refer to a puppet request, for instance. https://oswalt.dev/2013/09/nfd6-preview-solarwinds/ Tue, 10 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/nfd6-preview-solarwinds/ You can’t really be in the networking industry without hearing about Solarwinds. Their IT management and monitoring products are very widely used. Nearly every customer I’ve worked with is using Solarwinds’ tools to some extent, whether it’s the ever-popular Orion NCM for network management and monitoring, or the slew of free tools that Solarwinds makes available for little troubleshooting or configuration tasks. Solarwinds has supported NFD for quite some time. At NFD5, they presented on quite a few things. https://oswalt.dev/2013/09/nfd6-vendor-preview-nuage-networks/ Mon, 09 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/nfd6-vendor-preview-nuage-networks/ Nuage Networks is making an appearance at both Network Field Day 6 and the Software-Defined Datacenter Symposium the day before. Nuage is new to me, but after perusing some of their literature, I was very comfortable with some of the concepts. First, you’ll recognize the three-tier architecture that’s being used in most SDN discussions in most of their visuals (data plane / controller / NB API) Nuage uses an product called the VSD (Virtual Services Directory) to define network policies and business logic integration. https://oswalt.dev/2013/09/overlay-networking-part-3-the-underlay/ Thu, 05 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/overlay-networking-part-3-the-underlay/ We finally arrive at the physical topology that all of the stuff I discussed in the previous posts is built upon. “Underlay” is a term that is starting to catch on - this describes the infrastructure that all of the overlay networks ride on top of, and I’ll be using it to describe this physical infrastructure in this post. Keep in mind the term is used no matter how our physical infrastructure is laid out - there’s quite a few different ways to build this thing. https://oswalt.dev/2013/09/nfd6-vendor-preview-aruba-networks/ Thu, 05 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/nfd6-vendor-preview-aruba-networks/ I’ll be the first to admit, I don’t really know that much about Aruba Networks. They’re most widely known for their work in the wireless area and that’s an area of technology I have yet to play with. As someone who is admittedly wireless-green, I’m eager to get schooled. While they may be new to me, they are heavily involved with the Tech Field Day community, especially at Wireless Field Day events. https://oswalt.dev/2013/09/nfd6-vendor-preview-big-switch/ Thu, 05 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/nfd6-vendor-preview-big-switch/ Big Switch will be making their first appearance at Network Field Day 6 next week, and I’m pretty excited to hear their session. This isn’t their first appearance at a Tech Field Day event, however. They first appeared at the OpenFlow Symposium back in 2011. I re-watched that video and realized that they were talking about network virtualization a long time ago. They even made the statement that they viewed SDN “like VMware but for networking” - something we’re hearing a lot of these days. https://oswalt.dev/2013/09/overlay-networking-part-1-the-basics/ Wed, 04 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/overlay-networking-part-1-the-basics/ Wow. Lots of talk regarding overlay networking, both last week, and now this week. No doubt largely caused by the VMware NSX announcement last week. This post is an attempt on my part to clarify some fundamental ideas regarding overlay networking for my own benefit, but hopefully it helps you too. After all, we’re all learning. I’ll also be referring a LOT to some community content from blogs and twitter, because there’s a lot of great opinions out there. https://oswalt.dev/2013/09/overlay-networking-part-2-vteps-and-software/ Wed, 04 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/overlay-networking-part-2-vteps-and-software/ In the previous post, we discussed the role of the overlay network, and the virtual switches they connect to. In this post, we’re going to talk about a few additional components. The Role of the Hardware VTEP There’s been a lot of talk about VTEP, and how virtually every networking vendor but Cisco is part of this elaborate ecosystem of vendors that contribute to the angelic glory that is NSX. Let’s put the politics aside and talk about what (specifically hardware) VTEPs could do, even if they’re not doing them right now (announced and shipping are two very different things. https://oswalt.dev/2013/09/nfd6-vendor-preview-plexxi/ Wed, 04 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/nfd6-vendor-preview-plexxi/ Plexxi was first involved with Network Field Day about 5 months ago at Network Field Day 5. There, they demo’d their very unique approach to networking. You won’t hear about Plexxi without hearing about their WDM-based optical network design. You may even hear it referred to unofficially as Layer 1 SDN - and that’s a pretty apt description. Plexxi uses special From a logical perspective (kind of semi-logical and semi-physical) I think it’s great. https://oswalt.dev/2013/09/virtual-networking-and-the-concept-of-abstraction/ Tue, 03 Sep 2013 00:00:00 +0000 https://oswalt.dev/2013/09/virtual-networking-and-the-concept-of-abstraction/ There’s a lot of talk about “network abstraction” lately in circles where it wasn’t discussed before - all thanks to our friends at Vmware and the announcement of NSX at VMworld. For around the past two years I’ve been doing my best to stay involved in the SDN conversation - while it’s still really new technology, it’s fun to debate about and great to help define the next era of networking. https://oswalt.dev/2013/08/networking-field-day-6/ Wed, 21 Aug 2013 00:00:00 +0000 https://oswalt.dev/2013/08/networking-field-day-6/ I’ll be attending Networking Field Day 6 in San Jose, CA from September 11 - 13th. I am both honored and humbled to be a part of this event, and I am counting the days until my flight leaves for Silicon Valley. I love the area in general, as I’ve been there several times now - but having the privilege to go back for something like Networking Field Day is truly exciting. https://oswalt.dev/2013/08/ucs-central-keeping-it-classless-labs/ Fri, 02 Aug 2013 00:00:00 +0000 https://oswalt.dev/2013/08/ucs-central-keeping-it-classless-labs/ I put together a lab on UCS Central, showing how you can load all the necessary software up in a hypervisor environment. https://oswalt.dev/2013/08/ucs-central-1.1-lab/ Fri, 02 Aug 2013 00:00:00 +0000 https://oswalt.dev/2013/08/ucs-central-1.1-lab/ I saw the announcement that Cisco had posted the emulator for UCS version 2.1(2a) a week ago. @CiscoServerGeek that integrates with UCS Central 1.1, right? — Frank Jimenez (@franjimecsco) July 26, 2013 This was pretty cool, seeing as the firmware version in general had only been out for a few weeks, and the emulators have traditionally taken a bit longer after their firmware release. I took this as an opportunity to set up my own UCS Central lab. https://oswalt.dev/2013/08/teaching-without-a-teaching-degree/ Thu, 01 Aug 2013 00:00:00 +0000 https://oswalt.dev/2013/08/teaching-without-a-teaching-degree/ So, let’s say you’re a technical admin, engineer, architect, whatever (most of you are). It’s probably safe to say that nearly all of you (I fit into this) have an occupation where our primary ongoing task is some combination of system or network administration, design, software and hardware engineering work, including build-out or troubleshooting, etc. Maybe it’s all of these. No matter what, it’s a safe assumption that a big, or maybe even number one reason we all get paid is because we’re really good at the technical work. https://oswalt.dev/2013/07/that-ole-familiar-network-command/ Wed, 31 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/that-ole-familiar-network-command/ A basic concept, but one that is consistently the cause of confusion even in the most learned technical circles within Cisco networking, is the specific role that the “network” command plays in various routing protocols. The reason for this confusion? The use of the word “network” itself. Let’s explain. The Problem Let’s say you had a shiny new Cisco router, and that router had 4 networks you wished to advertise (I used loopbacks for simplicity): https://oswalt.dev/2013/07/the-dangers-of-fanboyism/ Wed, 31 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/the-dangers-of-fanboyism/ In the short amount of time since I tripped and fell into this industry, one thing is clear - fanboyism (Is that a word? It is now.) is EVERYWHERE. Those that love Cisco, really love Cisco. Those that love Juniper, really hate Cisco. It’s hard to start working in this industry, especially in a relatively single-vendor environment, and not acquire a strong affinity to one side of the other. Not to mention the fact that big companies like Cisco have huge, widely used and respected certification programs, so it’s easy for an engineer to take Cisco’s word as the word of god. https://oswalt.dev/2013/07/hp-moonshot/ Tue, 30 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/hp-moonshot/ Despite my humble beginnings as a network engineer, I’m almost always including servers/virtualization/storage in my day-to-day work. If you’re not into building servers from scratch (not a bad venture) then the leaders in the server space might be a good fit for you - most are doing some pretty interesting things in the battle for the top spot in this space. Most folks would agree that HP is still the number one leader, even if only considering pure volume (I see c7000 chassis EVERYWHERE). https://oswalt.dev/2013/07/igp-metric-tweaks-direction-is-important/ Mon, 29 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/igp-metric-tweaks-direction-is-important/ A while back I was responsible for setting up a group of switches and routers to serve as the internet distribution for a hospital, mainly the function of designing the IGP of choice to work given the hospital’s requirements and coordinating with the teardown of the old gear. The idea was to configure EIGRP so that one next-hop was preferred over another. We know this is possible through tweaking the various metrics for a given IGP, but in the process, I was reminded of something that’s quite important to think about when doing so. https://oswalt.dev/2013/07/cisco-ucs-vnic-switchport-mode/ Tue, 23 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/cisco-ucs-vnic-switchport-mode/ I wrote an article a while back regarding VLAN configuration when running vSphere ESXi on top of Cisco UCS. A comment pointed out that all vNICs are automatically configured as trunks. I had not heard of this before, so I got into the CLI to take a look. Here’s a VLAN configuration screen in the UCSM GUI for a sample vNIC: Check out the running configuration for this vNIC on the underlying NX-OS CLI. https://oswalt.dev/2013/07/heatsink-upgrade/ Sun, 14 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/heatsink-upgrade/ A little detour from the networking topics today to show off a little weekend tech project. I recently ran into some overheating problems with my home BYO PC. Core Temp was showing upwards of 70 degrees Celsius during normal operation, and under load, it would sometimes just shut down completely. Here’s the setup I had as of 2 days ago: The rear fan, which takes air in, was not working due to a short. https://oswalt.dev/2013/07/kiclet-ios-network-command-cheating/ Fri, 12 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/kiclet-ios-network-command-cheating/ I have always used the “network 0.0.0.0 0.0.0.0” statement to describe “all interfaces” when configuring a routing protocol like EIGRP. I know that it’s not correct, but I never stopped to wonder why my bad habit still worked. Then, I found this good article by @jdsilva explains this is IOS just assuming you had a “brain fart” and meant to type the proper “network 0.0.0.0 255.255.255.255” I’m studying for the CCIE and it can be really good to identify these bad habits that, while in real life may not be too bad, especially this kind, where the result is the same, but on exams can mean the difference between failure and success. https://oswalt.dev/2013/07/ccie-spanning-tree-part-2-rstp/ Mon, 01 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/ccie-spanning-tree-part-2-rstp/ This post picks up where the previous left off. Again, a CCNP-level knowledge of STP is recommended. So…Spanning Tree didn’t converge quickly enough for some people, and enabling PortFast everywhere kind of defeats the purpose, so 802.1w Rapid Spanning Tree was born. RSTP in essence puts into place some additional features to speed up STP reconvergence. Old-school 802.1D meant that you had to wait at least 30 seconds to get a port from blocking to forwarding, and this means that recovering from a failure takes at least that much time (sometimes more depending on other factors). https://oswalt.dev/2013/07/rapid-spanning-tree-synchronization-keeping-it-classless-labs/ Mon, 01 Jul 2013 00:00:00 +0000 https://oswalt.dev/2013/07/rapid-spanning-tree-synchronization-keeping-it-classless-labs/ This is a specific video on Rapid Spanning Tree Synchronization. See my full writeup on RSTP in general. Forgive the low(er) quality of this particular video, it was recorded at an hour in the morning that frankly should not exist. https://oswalt.dev/2013/06/ccie-spanning-tree-part-1-nerd-knobs/ Thu, 27 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/ccie-spanning-tree-part-1-nerd-knobs/ I wrote this post not only to put out some information on one of the least-understood facets of networking (especially in data center, as most technology today is aimed at making STP irrelevant) but also to help get something on paper for me, seeing as I am going down the CCIE path full force now, and this has always been a weak area of mine. This post will assume you have CCNP-level knowledge about Spanning Tree Protocol (STP). https://oswalt.dev/2013/06/spanning-tree-nerd-knobs-keeping-it-classless-labs/ Thu, 27 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/spanning-tree-nerd-knobs-keeping-it-classless-labs/ This is a video on some of the “nerd knobs” that we get to play with in a traditional spanning tree environment. I have done a full writeup on the topic that goes along with this video - you can view this video on that page as well. https://oswalt.dev/2013/06/host-interfaces-on-ucs-fex-2204-vs-fex-2208/ Thu, 20 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/host-interfaces-on-ucs-fex-2204-vs-fex-2208/ I mentioned in a previous post regarding the connectivity options to each blade if you’re using the appropriate hardware. If you’re using a 2208 FEX, you have 8 upstream ports, each at 10GbE. This means the FEX can support up to 80 Gbps total. You can provide potentially 4:1 oversubscription (math later) to each blade by connecting a 2208 FEX into a blade chassis with blades that can also support 80Gbps each. https://oswalt.dev/2013/06/cisco-ucs-port-channeling/ Wed, 19 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/cisco-ucs-port-channeling/ Cisco UCS offers a few policies that are applied globally to all equipment in a given UCS domain. These policies are found by selecting the “Equipment” node under the “equipment” tab. (You can also change on an individual chassis basis but the default behavior is for all chassis to inherit this global policy) This is specifically referring to the connectivity between the Fabric Interconnects and the Chassis FEX modules or I/O modules (IOM). https://oswalt.dev/2013/06/powerless-words-and-technology/ Wed, 19 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/powerless-words-and-technology/ I was introduced by a colleague and mentor a few years ago to the concept of powerless words. Words like “try”, “but”, and “maybe/might”, among others, seem to be our mind’s way of protecting itself against the unknown. After all, we’re only human, right? We can’t control what the world throws at us, right? I encourage you to read the article I linked to as well as this one, which the first article refers to. https://oswalt.dev/2013/06/code-ultimateucsbuild/ Tue, 18 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/code-ultimateucsbuild/ Name: UltimateUCSBuild.ps1 Author: Matthew Oswalt Created: 6/10/2013 Current Version: v0.2 (ALPHA) Revision Date: 6/18/2013 Description: –THIS SCRIPT IS VERY NEW, EXPECT FREQUENT CHANGES AND IMPROVEMENTS– A script that starts with a completely blank UCS system and configures it to completion. This version of the script is very non-modular and static, but that will change in future versions. My long-term vision for this script is to be simple, yet powerful. I want it to have the ability to provision lots of stuff very quickly, with minimal code changes. https://oswalt.dev/2013/06/why-we-want-to-kill-spanning-tree/ Tue, 18 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/why-we-want-to-kill-spanning-tree/ To say that Ethernet as a L2 protocol is well-known is an understatement - it’s in every PC network card, and every network closet. Back during the inception of Ethernet, the world needed an open, efficient, standardized method of communicating between nodes on a LAN. Widely regarded as the “mother of the Internet” for many reasons - not the least of which is the invention of the Spanning Tree Protocol - Radia Perlman equated the wide proliferation of Ethernet to the same events that have made English such as popular language on Earth. https://oswalt.dev/2013/06/code-powertool-poweronucsblades/ Fri, 14 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/code-powertool-poweronucsblades/ # InstallBFS.ps1 # # Very brief and informal PowerShell script to configure a Boot-From-SAN policy and attach it to the relevant service profile templates. Import-Module CiscoUcsPs Disconnect-Ucs Connect-Ucs 10.0.0.1 $organization = "SUBORG_01" #Add Boot Policies $bp = Add-UcsBootPolicy -Org $organization -Name "BFS-ESX-PROD" -EnforceVnicName yes $bp | Add-UcsLsBootVirtualMedia -Access "read-only" -Order "1" $bootstorage = $bp | Add-UcsLsbootStorage -ModifyPresent -Order "2" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "primary" -VnicName "ESX-PROD-A" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "secondary" -VnicName "ESX-PROD-B" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bp = Add-UcsBootPolicy -Org $organization -Name "BFS-ESX-NONP" -EnforceVnicName yes $bp | Add-UcsLsBootVirtualMedia -Access "read-only" -Order "1" $bootstorage = $bp | Add-UcsLsbootStorage -ModifyPresent -Order "2" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "primary" -VnicName "ESX-NONP-A" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "secondary" -VnicName "ESX-NONP-B" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bp = Add-UcsBootPolicy -Org $organization -Name "BFS-WIN-PROD" -EnforceVnicName yes $bp | Add-UcsLsBootVirtualMedia -Access "read-only" -Order "1" $bootstorage = $bp | Add-UcsLsbootStorage -ModifyPresent -Order "2" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "primary" -VnicName "BARE-PROD-A" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "secondary" -VnicName "BARE-PROD-B" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bp = Add-UcsBootPolicy -Org $organization -Name "BFS-WIN-NONP" -EnforceVnicName yes $bp | Add-UcsLsBootVirtualMedia -Access "read-only" -Order "1" $bootstorage = $bp | Add-UcsLsbootStorage -ModifyPresent -Order "2" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "primary" -VnicName "BARE-NONP-A" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage = $bootstorage | Add-UcsLsbootSanImage -Type "secondary" -VnicName "BARE-NONP-B" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "primary" -Wwn "50:00:00:00:00:00:00:00" $bootsanimage | Add-UcsLsbootSanImagePath -Lun 0 -Type "secondary" -Wwn "50:00:00:00:00:00:00:00" Get-UcsServiceProfile -Name "SPT-ESX-PROD" | Set-UcsServiceProfile -BootPolicyName "BFS-ESX-PROD" -force Get-UcsServiceProfile -Name "SPT-ESX-NONP" | Set-UcsServiceProfile -BootPolicyName "BFS-ESX-NONP" -force Get-UcsServiceProfile -Name "SPT-WIN-PROD" | Set-UcsServiceProfile -BootPolicyName "BFS-WIN-PROD" -force Get-UcsServiceProfile -Name "SPT-WIN-NONP" | Set-UcsServiceProfile -BootPolicyName "BFS-WIN-NONP" -force https://oswalt.dev/2013/06/cisco-ucs-ascii-art/ Fri, 14 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/cisco-ucs-ascii-art/ A while back I wrote about the problems with using some of the newer 3rd generation blade hardware from Cisco with older generations of the chassis FEX/IOM. Because of the way that the VIC and the chassis IOM interact, certain combinations yield different amounts of aggregate bandwidth, and certain combinations don’t work at all, as was evidenced in that post. As a reminder, here are the valid combinations (these are still accurate to my knowledge, but may change in a few weeks if any new tech is announced at Cisco Live) of FEX and blade VIC: https://oswalt.dev/2013/06/cisco-vm-fex-and-the-nexus-1000v/ Mon, 10 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/cisco-vm-fex-and-the-nexus-1000v/ Many of those that have supported a vSphere-based virtualization infrastructure for any length of time have probably heard of the Cisco Nexus 1000v. I’ve written a few posts that mention it, and I’ve been deploying the product quite successfully for the past few years. Even cooler, the Nexus 1000v is now available for Hyper-V as well. For those that are not familiar with the idea of distributed switches in general, I’ll overview the concept briefly. https://oswalt.dev/2013/06/service-profiles-and-service-profile-templates-in-cisco-ucs-powertool/ Mon, 10 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/service-profiles-and-service-profile-templates-in-cisco-ucs-powertool/ I had a few scripts that were written WAY before PowerTool was out of beta, and the only way I knew how to generate a Service Profile Template was to use manual XML calls. For instance: $cmd = "<configConfMos inHierarchical='true'> <inConfigs> <pair key='org-root/org-" + $orgName + "/ls-" + $serviceProfileName + "' > <lsServer agentPolicyName='' biosProfileName='' bootPolicyName='" + $bootPolicyName + "' descr='' dn='org-root/org-" + $orgName + "/ls-" + $serviceProfileName + "' dynamicConPolicyName='' extIPState='none' hostFwPolicyName='' identPoolName='" + $UUID_POOL_NAME + "' localDiskPolicyName='default' maintPolicyName='default' mgmtAccessPolicyName='' mgmtFwPolicyName='' name='" + $serviceProfileName + "' powerPolicyName='default' scrubPolicyName='' srcTemplName='' statsPolicyName='default' status='created' type='initial-template' usrLbl='' uuid='0' vconProfileName=''> <vnicEther adaptorProfileName='VMWare' addr='derived' adminVcon='any' identPoolName='' mtu='1500' name='" + $VNIC_A_NAME + "' nwCtrlPolicyName='' nwTemplName='" + $VNIC_TEMPLATE_A_NAME + "' order='3' pinToGroupName='' qosPolicyName='' rn='ether-" + $VNIC_A_NAME + "' statsPolicyName='default' status='created' switchId='" + $switchId + "'> </vnicEther> <vnicEther adaptorProfileName='VMWare' addr='derived' adminVcon='any' identPoolName='' mtu='1500' name='" + $VNIC_B_NAME + "' nwCtrlPolicyName='' nwTemplName='" + $VNIC_TEMPLATE_B_NAME + "' order='4' pinToGroupName='' qosPolicyName='' rn='ether-" + $VNIC_B_NAME + "' statsPolicyName='default' status='created' switchId='" + $switchId + "'> </vnicEther> <vnicFcNode addr='pool-derived' identPoolName='" + $WWNN_POOL_NAME + "' rn='fc-node' > </vnicFcNode> <vnicFc adaptorProfileName='VMWare' addr='derived' adminVcon='any' identPoolName='' maxDataFieldSize='2048' name='" + $VHBA_A_NAME + "' nwTemplName='" + $VHBA_TEMPLATE_A_NAME + "' order='1' persBind='disabled' persBindClear='no' pinToGroupName='' qosPolicyName='' rn='fc-" + $VHBA_A_NAME + "' statsPolicyName='default' status='created' switchId='" + $switchId + "'> </vnicFc> <vnicFc adaptorProfileName='VMWare' addr='derived' adminVcon='any' identPoolName='' maxDataFieldSize='2048' name='" + $VHBA_B_NAME + "' nwTemplName='" + $VHBA_TEMPLATE_B_NAME + "' order='2' persBind='disabled' persBindClear='no' pinToGroupName='' qosPolicyName='' rn='fc-" + $VHBA_B_NAME+ "' statsPolicyName='default' status='created' switchId='" + $switchId + "'> </vnicFc> <lsRequirement name='" + $SERVER_POOL_NAME + "' qualifier='' restrictMigration='no' rn='pn-req' > </lsRequirement> <lsPower rn='power' state='down' > </lsPower> </lsServer> </pair> </inConfigs> </configConfMos>" Invoke-UcsXml -XmlQuery $cmd If most of your script is composed of normal cmdlets, this looks pretty absurd - so if you can avoid calling direct XML, you should. https://oswalt.dev/2013/06/the-software-defined-datacenter-symposium-2013-tech-field-day/ Mon, 03 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/the-software-defined-datacenter-symposium-2013-tech-field-day/ About a year and a half ago, arguably well before the biggest of all the SDN hype that we’ve come to know and love, Stephen Foskett and company organized a fantastic OpenFlow Symposium aimed at getting deep into the state of the protocol at that time and what was being done with it at some of the leading tech companies like Google, Yahoo, Cisco, Brocade, and others. For those keeping track, Dave Meyer was on the panel at the time representing Cisco but is now CTO and Chief Scientist with Brocade and getting to do some really cool stuff with OpenDaylight. https://oswalt.dev/2013/06/when-the-world-runs-as-software/ Mon, 03 Jun 2013 00:00:00 +0000 https://oswalt.dev/2013/06/when-the-world-runs-as-software/ I have heard so many sweeping statements in the past few weeks like “network engineers’ jobs are in danger” or “will my CCIE have any value when networking is run in the hypervisor”? Clearly the social media community is preaching “software or bust” these days, clearly leaving those that are not used to this kind of talk, or have been doing infrastructure the same way for years, quite alienated. I want to make one thing extremely clear - It’s okay to be an infrastructure person. https://oswalt.dev/2013/05/code-powertool-poweronucsblades/ Wed, 29 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/code-powertool-poweronucsblades/ # ---------------------------------------------------------------------- # Name: PowerOnUCSBlades.ps1 # Author: Matthew Oswalt # Created: 3/30/2012 # Revision: v0.2 - BETA # Rev. Date: 4/30/2013 # Description: A script that powers on blades in a UCS system. # Can be configured to boot all blades, or # only those associated to service profiles in a # given sub-organization. # ---------------------------------------------------------------------- # Import the Cisco UCS PowerTool module Import-Module CiscoUcsPs #Enable Multiple System Config Mode Set-UcsPowerToolConfiguration -SupportMultipleDefaultUcs $true ##################################################################################################################### # AUTHENTICATION # #################################### #Stored method of authentication - change the two values shown below $user = "admin" $password = "password" | ConvertTo-SecureString -AsPlainText -Force $cred = New-Object system. https://oswalt.dev/2013/05/outgoing-interface-determination/ Mon, 27 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/outgoing-interface-determination/ I received a comment on an old post regarding the identification of outgoing interface for learned routes through BGP. In fact, it’s not the first time I’ve had a discussion in the comment section regarding the interaction between the control plane and the forwarding plane. So, let’s work backwards from the point where our packet leaves some interface on a router, which would be considered purely an act of the forwarding plane. https://oswalt.dev/2013/05/virtual-routing-part-4-the-use-case/ Thu, 23 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/virtual-routing-part-4-the-use-case/ Moving along in my “Virtual Routing” series, I’d like to switch gears and talk a little more “big picture”. In the previous posts, we’ve discussed a few different things: Part 1 - A first look at the CSR 1000v from Cisco Part 2 - An examinations of using FHRPs in a virtual environment Part 3 - A comparison of virtual routing redundancy options Seeing as these were all pretty technical configuration-oriented posts, I wanted to take a step back and think about some of the reasons why one would want to perform routing in a virtual environment. https://oswalt.dev/2013/05/how-taco-bell-taught-me-about-converged-networks/ Wed, 22 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/how-taco-bell-taught-me-about-converged-networks/ I would make the argument that the term “converged networks” is not really a buzzword the way it used to be, since the world now generally understands the concept. Rather than have isolated physical networks, lets make a very popular network topology more robust in terms of capacity, but also features. After all, the networks and protocols we’re combining have some pretty stringent requirements, and we want to make sure that this transition actually works. https://oswalt.dev/2013/05/moving-forward-changing-focus/ Wed, 22 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/moving-forward-changing-focus/ The past two years have been nothing short of a whirlwind for me. I had the privilege of helping to create the Data Center practice for a technology startup in Cincinnati, and as a result, I’ve figuratively been drinking from a fire hydrant non stop. In the past two years I’ve learned more about technology than I could have ever imagined, part of which was the fact that what I have learned only scratches the surface of what’s likely in store for me in the rest of my career. https://oswalt.dev/2013/05/esxi-vswitch-load-balancing-woes/ Tue, 21 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/esxi-vswitch-load-balancing-woes/ There are a million articles out there on ESXi vSwitch Load Balancing, many of which correctly point out that the option for routing traffic based on IP Hash is probably the best option, if your upstream switch is running 802.3ad link aggregation to the ESXi hosts. It offers minimal complexity, while also providing the best load-balancing capabilities for network devices utilizing a vSwitch (Virtual Machine OR vmkernel). So…this article will be catered towards a very specific problem. https://oswalt.dev/2013/05/quality-of-service-part-3-nexus-1000v-the-servers-are-doing-qos-now/ Fri, 10 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/quality-of-service-part-3-nexus-1000v-the-servers-are-doing-qos-now/ I’m going to talk a little bit about performing QoS functions from within the Nexus 1000v. Since it’s been awhile since I made the last post in this series, a recap is in order: In my first post, I explained what the different types of QoS policies were in the context of Cisco’s MQC In my second post, I went through the actual configuration on specific platforms like the Cisco Nexus and Unified Compute platforms, as well as a brief mention of vSphere’s participation, but less on the QoS aspects and more on MTU. https://oswalt.dev/2013/05/humor-virtual-routing-inception/ Fri, 10 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/humor-virtual-routing-inception/ Don’t ask me what kind of daydreaming it took to arrive at this, but….I just realized that the following was possible: Which was ALREADY terrifying enough - but then my mind went here: Have a great weekend. https://oswalt.dev/2013/05/open-source-switching/ Thu, 09 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/open-source-switching/ There’s been a ton of attention lately around the concept of using commodity hardware in an area of the industry that is currently dominated by proprietary ASIC-based solutions - networking. When it comes to crossing paths between open source and networking, the obvious low-hanging fruit has been software-based switching solutions like Open vSwitch, or cool ways to make virtual switching do bigger, better stuff for cloud providers like Openstack Quantum (awesome, by the way). https://oswalt.dev/2013/05/virtual-routing-part-3-router-redundancy-in-vmware-vsphere/ Tue, 07 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/virtual-routing-part-3-router-redundancy-in-vmware-vsphere/ My post a few weeks ago about the CSR 1000v made a pretty big splash - it’s clear that the industry is giving a lot of attention to IP routing within a virtual environment. No doubt, Vyatta is largely credited for this, as they’ve been pushing this idea for a long time. When Brocade announced that they were acquiring Vyatta, and Cisco announced they were working on a “Cloud Services Router”, this idea became all the more legitimate, and as you can tell from this series, it’s of particular interest to me. https://oswalt.dev/2013/05/sdn-use-case-end-to-end-qos/ Mon, 06 May 2013 00:00:00 +0000 https://oswalt.dev/2013/05/sdn-use-case-end-to-end-qos/ Just a little unicorn-y brainstorming today. This post is in some ways an extension of my earlier post on the importance of QoS in a converged environment like FCoE or VoIP (or both). This will be a good example of a case where SDN very efficiently solves a policy problem that is present in an unfortunately large number of networks today. For many organizations, large or small, the network is approached with a very siloed, “good enough” mentality - meaning that each portion of an organization’s technology implementation is typically allocated to those that have that particular skillset. https://oswalt.dev/2013/04/igp-route-multipathing/ Mon, 29 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/igp-route-multipathing/ In preparation for an upcoming post, I was reminded about a commonly referred to feature in most IGPs - the concept of Equal-Cost Multipath, or simply ECMP. This is the idea that multiple routes with the same cost to a remote network should get placed in the routing table alongside each other and packets should load-balance over them to use the additional available paths. After all, it’s the same cost, so why not? https://oswalt.dev/2013/04/fusionio-acquires-nexgen/ Thu, 25 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/fusionio-acquires-nexgen/ For anyone keeping tabs on the storage industry these days, you might have noticed the news today regarding FusionIO’s acquisition of Nexgen - one of a myriad of storage startups that have cropped up in the past few years to address the ever-changing needs of the data center industry. After looking through some of the articles that were published today, I think we all understand the financial details behind the transaction. https://oswalt.dev/2013/04/routing-iscsi-traffic/ Tue, 23 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/routing-iscsi-traffic/ This post was initiated by a side conversation I had about iSCSI. From time to time I’m required to implement an iSCSI-based solution, and this is not the first time I’ve heard the question: “So why can’t I route iSCSI traffic?” Most folks with any knowledge of storage protocols will have at some point picked up this informal best practice idea; some will vehemently defend this idea as the word of $deity and shun all those who contradict this truth. https://oswalt.dev/2013/04/multi-vendor-ospf-cost-calculations/ Mon, 22 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/multi-vendor-ospf-cost-calculations/ While on my current kick with virtual routing, I stumbled across an interesting concept regarding OSPF, and the flexibility that vendors have in determining the best path through an OSPF network. The following topology is what I’ve been staring at for the last few days Pretty simple, right? There’s a single network (192.168.123.0/24) down inside each virtual host where the VMs are to sit. Each host has a router on it (one Cisco CSR 1000v and the other Vyatta Core 6. https://oswalt.dev/2013/04/virtual-routing-part-2-fhrp-issues-in-vmware-vsphere/ Fri, 19 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/virtual-routing-part-2-fhrp-issues-in-vmware-vsphere/ I was working on a topology for another post regarding interoperability between the recently released Cisco Cloud Services Router (CSR 1000v) and Vyatta when I ran into an issue regarding vSphere network security policies and First Hop Redundancy Procotols (FHRP) such as VRRP. This post will serve as a precursor to that overall post, but I want to point out a key configuration piece when performing redundant gateways with a FHRP like VRRP. https://oswalt.dev/2013/04/virtual-routing-part-1-csr-1000v-first-glance/ Tue, 16 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/virtual-routing-part-1-csr-1000v-first-glance/ As some of you have heard, the Cisco Cloud Services Router (CSR) 1000v has recently been released for download, and I quite literally pounced on it when I first heard the word. For those that haven’t heard, the CSR 1000v is essentially Cisco’s answer to the problem that has existed in datacenters for a while - that the current multi-tenancy mechanisms, especially overlays like VXLAN and yes, even NVGRE, are just not cutting it for everyone. https://oswalt.dev/2013/04/kiclet-sdn-pick-your-poison/ Mon, 15 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/kiclet-sdn-pick-your-poison/ I keep having to remind myself that SDN is more about solving a policy problem than a transport problem. This is why the answer to the question “Will SDN solve all of our networking problems?” is always NO. Truth be told, SDN has been around for a while (see SNMP, Perl, Netconf) in various forms, but it’s receiving a lot of attention right now because the mechanisms are starting to mature and frankly, the networking industry hasn’t really seen a lot of groundbreaking innovations lately. https://oswalt.dev/2013/04/the-route-to-null0-is-ok/ Mon, 15 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/the-route-to-null0-is-ok/ Back to the basics today. I have seen this pop up a few times and wanted to offer some clarification on what seems to be a cloudy issue for CCNP (and some CCIE) candidates. I’ve seen quite a few times now where engineers see a route to Null0 in a Cisco router and assume instantly that the router is “black holing” traffic.   Sometimes, a route to Null0 is inserted into the routing table when performing summarization with nearly every routing protocol in common use today. https://oswalt.dev/2013/04/the-importance-of-qos-in-a-converged-infrastructure/ Wed, 10 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/the-importance-of-qos-in-a-converged-infrastructure/ I’ve done quite a few posts on Quality of Service, particularly on it’s basic concepts, as well as specific implementation details in a Data Center environment. Many of these concepts can be applied to really any use case, since QoS is QoS - just depends on how you classify traffic. But what do we gain by implementing QoS, especially in a context like Data Center, where a modern core layer is typically at least 10GbE and network congestion is rarely seen? https://oswalt.dev/2013/04/no-experience-is-irrelevant/ Tue, 09 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/no-experience-is-irrelevant/ So you’ve recently changed jobs, and you have a very extensive linux skillset. Your new job doesn’t include or require this skillset. Does that mean that experience will not serve you in this new role? Absolutely false. The most valuable thing these experiences give us is perspective. The ability to see things from a unique point of view makes you a unique and valuable addition to any team. This is a strong reason for my advocacy of the Unified Skillset. https://oswalt.dev/2013/04/call-for-ipv6-papers/ Mon, 01 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/call-for-ipv6-papers/ I am working on an IPv6-related project, and though I think I have enough content to at least get started, I’d like to submit a request to the community at large. This project is aimed at providing additional awareness around IPv6 in general, but will be geared towards the entire networking community, ranging from those familiar with the protocol, to those that barely know what an 128-bit address is. This material will be publicly available and organized towards the goal of learning and becoming more aware of the new protocol. https://oswalt.dev/2013/04/sdn-and-virtualization-utilizing-ip-over-avian-carrier-networks/ Mon, 01 Apr 2013 00:00:00 +0000 https://oswalt.dev/2013/04/sdn-and-virtualization-utilizing-ip-over-avian-carrier-networks/ Network Virtualization has been a hot button topic for the last few years, particularly in the data center. With trends like SDN, cloud, and unicorns taking off, it’s incredibly important to move towards technologies that improve scalability while preserving proper multi-tenancy. You may be wondering that all this vendor-supplied, marketing-fueled magic and fairydust is too good to be true. You wouldn’t be too far off - the fact is that none of the solutions provided thus far have addressed the implementation and operation of network virtualization in cases such as a remote datacenter where traditional connectivity like satellite and long-haul fiber is unavailable. https://oswalt.dev/2013/03/the-software-defined-nerds-of-tomorrow/ Tue, 26 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/the-software-defined-nerds-of-tomorrow/ This is one of my favorite times of the year. Despite the terrible weather that Ohio usually affords the month of March, I brave the wet cold and return to my alma mater for this year’s round of senior presentations. During the five-year IT program, students are required to learn just about anything and everything you can imagine in IT. This ranges from software development of all kinds, database administration, systems administration, network services and even pure route/switch. https://oswalt.dev/2013/03/ipv6-next-hop-best-practices/ Thu, 21 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/ipv6-next-hop-best-practices/ The concept of a link-local address is new to some, seeing as the term is not widely talked about in IPv4 circles, despite the fact that some folks see them daily. In IPv4, the range 169.254.1.0 through 169.254.254.255 has been reserved for this purpose. You may see this in the “ipconfig” output of a windows host that failed to pull a DHCP address. In IPv6, fe80::/10 is reserved for this purpose, though link-local addresses are always configured with a fe80::/64 prefix. https://oswalt.dev/2013/03/ipv6-host-networking-and-insomnia/ Wed, 20 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/ipv6-host-networking-and-insomnia/ I’ve been running IPv6 on my home network for a while. The solution in place has evolved over time, from terminating tunnels to a linux VM using gogo6 all the way to front-ending with a Cisco ISR using Hurricane Electric, the goal has always been the same - to practice what I preach. Running IPv6 at home and REFUSING to turn it off when problems arise is one of the best ways to learn the protocol. https://oswalt.dev/2013/03/a-contest-of-protocols-eigrp-or-ospf/ Mon, 18 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/a-contest-of-protocols-eigrp-or-ospf/ Ah, the age old question that nearly every CCNA and CCNP candidate asks of themselves and others at some point. We see a minimum of 4 routing protocols in our networking studies, more if you decide to take on the Service Provider track. What makes one routing protocol better than another? I think it’s clear why (at least mostly) these particular two protocols are different, keeping in mind that one is distance vector (yes, distance vector, not hybrid distance vector) and the other is link state. https://oswalt.dev/2013/03/nexus-5000-qos-keeping-it-classless-labs/ Fri, 15 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/nexus-5000-qos-keeping-it-classless-labs/ I’m pleased to revive the KIC LABS series with a video on Cisco MQC-style QoS on the Nexus 5000. PLEASE read these two articles first, as they do a lot better job at explaining the structure that we’re going to be putting together in the video. Unfortunately I was not able to provide this during the video, as I was pressed for time. https://oswalt.dev/2012/11/cisco-quality-of-service-part-1-types-of-qos-policies/ https://oswalt.dev/2012/11/qos-part-2-qos-and-jumbo-frames-on-nexus-ucs-and-vmware/ Download the configuration used in this video here. https://oswalt.dev/2013/03/cisco-exams/ Thu, 14 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/cisco-exams/ This started off as a company email but I wanted to share it, since I’ve been asked before. Below is opinion and opinion only. I’m more interested in how this compares with your study methods and Cisco exam experiences, so please let me know your thoughts in the comments. Cisco exams….let’s face it, they suck. (In a good way though) I’ve taken exams from all kinds of vendors, and Cisco is really good at creating exams that vet you technically, but also require that you understand the practical reasons for the technologies we work with, not just memorizing maximum values, or configuration steps. https://oswalt.dev/2013/03/jumbo-frames-beyond-the-broadcast-domain/ Tue, 12 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/jumbo-frames-beyond-the-broadcast-domain/ I’ve run into many circumstances where jumbo frames are enabled, most notably in the data center. After all, allowing for a maximum tranmission unit of greater than 1500 bytes allows us to transmit more data per frame As I explained in Part 2 of my QoS Series, MTU can be a touch subject. Do it wrong, and you encounter one of two big network problems. One potential issue when configuring jumbo frames at L2 is that stuff just doesn’t work. https://oswalt.dev/2013/03/network-field-day-5/ Thu, 07 Mar 2013 00:00:00 +0000 https://oswalt.dev/2013/03/network-field-day-5/ Yesterday kicked off the 5th iteration of Network Field Day. For those that haven’t heard of Tech Field Day, you need to check it out - there’s something for everyone, and it’s a great event that gets the technical details from vendors on their solutions. The delegates that are invited are what I consider thought leaders in each field. I’ve had the privileged of blogging, podcasting, and even meeting with them in person over the past few years, and they’re just the right kind of folks to help keep these vendors honest. https://oswalt.dev/2013/02/a-/64-on-every-link-are-you-crazy/ Mon, 25 Feb 2013 00:00:00 +0000 https://oswalt.dev/2013/02/a-/64-on-every-link-are-you-crazy/ I’ve had some great conversations lately with a lot of folks on the topic of IPv6 prefix length in a variety of applications, specifically one very good discussion on just about anything IPv6 between me, the kind folks over at The Class-C Block and Tom Hollingworth (aka The Networking Nerd). For many folks that are considering the impact of going dual-stack in their environments, the idea of using a /64 on all links is still a point of contention. https://oswalt.dev/2013/02/assigning-ipv6-prefixes-for-customers/ Mon, 25 Feb 2013 00:00:00 +0000 https://oswalt.dev/2013/02/assigning-ipv6-prefixes-for-customers/ Now we arrive at the question of how much address space to allocate for…anyone. You may be a service provider, you may be a business, you may be a home user. Today, this question is quite easy to solve. If you’re a business-class customer, you ask your ISP for a block of addresses, and based off of your need (or ability to justify the need), you’ll be allocated some addresses. For many small-to-medium businesses, this can be as small as 8, or even 4 addresses. https://oswalt.dev/2013/02/a-cloud-without-ipv6/ Thu, 14 Feb 2013 00:00:00 +0000 https://oswalt.dev/2013/02/a-cloud-without-ipv6/ As a Data Center junkie, I daily bear witness to the glorious transformations that are taking place all around me with respect to the “next-generation” of data center. Everyone who wants to move their DC to the next level are millions of dollars worth of DC networking gear that is EXTREMELY cutting edge, enabling virtualization and cloud to do things we only dreamed of being able to do mere years ago. https://oswalt.dev/2013/02/using-gns3-for-switching-labs/ Wed, 13 Feb 2013 00:00:00 +0000 https://oswalt.dev/2013/02/using-gns3-for-switching-labs/ For so long, I’ve heard - as have many of you I’m sure - that GNS3, though a GREAT emulator for Cisco IOS software, is not practical for studying anything related to switching. Routing is handled just fine, but because of the proprietary ASICs in Cisco switches, it is not something that can be easily reverse-engineered, thus GNS3 cannot do it. After all, all routing is essentially done in software in GNS3. https://oswalt.dev/2013/02/the-d-in-sdn/ Tue, 12 Feb 2013 00:00:00 +0000 https://oswalt.dev/2013/02/the-d-in-sdn/ I have seen the conversation around SDN evolve over what amounts to the last few years from something that was barely whiteboard material, to something on everyone’s lips in this industry. Why? What’s so interesting about these three little letters? Well, if you’ve heard of it, you’ve undoubtedly heard from your local vendor account manager that their product is the leader in the SDN market, or that they just made a big acquisition that really puts them ahead in the SDN space, blah, blah, blah. https://oswalt.dev/2013/02/vsphere-network-security-policies/ Mon, 11 Feb 2013 00:00:00 +0000 https://oswalt.dev/2013/02/vsphere-network-security-policies/ The idea of security in a vSphere vSwitch is a concept not usually discussed in vSphere peer groups or curricula. They are somewhat specialized features that are normally either not used, or irrelevant due to the presence of another switching architecture such as the vDS (including the Cisco Nexus 1000v) or VM-FEX, where these policies also exist and are much more feature-rich. Thus, the idea of performing these functions on a native vSwitch is usually not talked about. https://oswalt.dev/2013/01/tcp-handshakes-routing-hairpinning-oh-my/ Mon, 28 Jan 2013 00:00:00 +0000 https://oswalt.dev/2013/01/tcp-handshakes-routing-hairpinning-oh-my/ I’m working on setting up a lab that consists of leading storage and compute products for testing, and I ran into some interesting issues with a few different things…some with respect to the way the Cisco ASA does hairpinning, as well as allowed connections in such a configuration. There were also some routing issues experienced as a result, and I want to explore my experience in all of this during this post. https://oswalt.dev/2013/01/nexgen-storage-part-2-hardware-overview/ Tue, 22 Jan 2013 00:00:00 +0000 https://oswalt.dev/2013/01/nexgen-storage-part-2-hardware-overview/ Last week I did an overview of the performance-minded storage solution that Nexgen has put together. In summary, by using SSD-based read AND write caching that’s moved in and out of the cache in an intelligent way, we can get better performance than traditional disk arrays with slower disks, and fewer of them. I’d like to do a quick tour of the hardware for their low-end model, the n5-50. It’s actually pretty straightforward and the internals are interesting enough that I decided to take some pictures and discuss their role in the solution. https://oswalt.dev/2013/01/the-unified-skillset/ Mon, 14 Jan 2013 00:00:00 +0000 https://oswalt.dev/2013/01/the-unified-skillset/ I began my professional career after college by starting in route/switch. Although I still do plenty of route/switch work, I have also recently taken on responsibilities focused on more datacenter-centric technologies like virtualization, and storage, in addition to the networking in the back-end that makes it all work. Much to the stress of my schedule (and my……stress), one has not trumped the other - they simply exist in parallel. I’m not alone - many engineers branch out into new technologies beyond what they view as their core competency. https://oswalt.dev/2013/01/nexgen-storage-part-1-solution-overview/ Fri, 11 Jan 2013 00:00:00 +0000 https://oswalt.dev/2013/01/nexgen-storage-part-1-solution-overview/ I was given the privilege to tinker with some gear from my friends over at Nexgen Storage. For those that have not heard of them, I encourage you to head over to http://www.nexgenstorage.com/product/technology and take a peek at the solution. They are one of the “little guys”, but they’re doing some cool things with respect to performance, and providing the ability to give priority to certain tiers of applications or tenants that are using the system. https://oswalt.dev/2013/01/vsphere-5.1-auto-deploy-on-cisco-ucs-c220-m3-server/ Mon, 07 Jan 2013 00:00:00 +0000 https://oswalt.dev/2013/01/vsphere-5.1-auto-deploy-on-cisco-ucs-c220-m3-server/ I set up Auto Deploy in my home lab using vSphere 5.1 on an existing server, in order to boot a Cisco UCS C220 M3 server whose local hard drives have not arrived yet. I followed Duncan Epping’s walkthrough for Auto Deploy on vSphere 5.0, but this post is about what I had to do differently to get it working. Hopefully I save you some headaches. There might be some improvements to this process, but I was under a deadline and I know that it worked for me - please share any improvements in the comments. https://oswalt.dev/2013/01/2012-in-review-and-2013-resolutions/ Tue, 01 Jan 2013 00:00:00 +0000 https://oswalt.dev/2013/01/2012-in-review-and-2013-resolutions/ 2012 has been a crazy year for me. I’d like to briefly summarize my year and publicly post some of my goals for 2013. Accomplishments in 2012 Blogging - Monthly Views to Keeping It Classless increased by over 450% this year, and every single month had consistently more views than the month before. I want to thank each and every one of you for reading my articles - I really only got into this recently and the explosive growth is still hard to believe. https://oswalt.dev/2012/12/pinging-a-firewall-is-it-up-or-down/ Tue, 18 Dec 2012 00:00:00 +0000 https://oswalt.dev/2012/12/pinging-a-firewall-is-it-up-or-down/ Let’s say you’re trying to find a free IP on a network so you can assign one to your PC to do some work. First off, shame on you for not using proper addressing design with an IP address manager software. Second, you might use basic ping tests to properly identify alive hosts vs. dead hosts (free IP addresses). Most do. In fact, you can use nmap to do simple ping sweeps of entire subnets. https://oswalt.dev/2012/12/ccna-datacenter/ Fri, 07 Dec 2012 00:00:00 +0000 https://oswalt.dev/2012/12/ccna-datacenter/ I passed 640-916 - Introducing Cisco Data Center Technologies earlier this week. I was going to publish this post on they day of or after the pass, but unfortunately I was put out of commission by the winter bug that’s going around and did not get to give this post the attention it deserved. The first test in the CCNA Datacenter track, which is 640-911 - Introducing Cisco Data Center Networking, was a pretty straightforward test for someone with my background. https://oswalt.dev/2012/12/grumpy-cat-hates-ipv6/ Mon, 03 Dec 2012 00:00:00 +0000 https://oswalt.dev/2012/12/grumpy-cat-hates-ipv6/ IPv6 will ruin the world! What is so terrible now will be a DESOLATE APOCALYPSE WITH IPV6!! BECAUSE…..IT JUST WILL BE - OKAY YOU GUYS???!?!? Don’t be grumpy - be happy. NAT is not a device. It is a function. An archaic one that should and can be abandoned, and we don’t have to compromise on security to do it. https://oswalt.dev/2012/11/the-failing-crusade-against-nat/ Tue, 20 Nov 2012 00:00:00 +0000 https://oswalt.dev/2012/11/the-failing-crusade-against-nat/ After watching the recent epic that was the comment thread on networkingnerd’s NAT66 blog post from last year, I was initially persuaded to sit and watch from afar. I’ve had the opportunity to work with IPv6 quite a bit, and though I’ve done a few IPv6-related posts on the site, I still feel like there’s always something missing. After all, much of IPv6 is still just talk (sadly) and not enough wide-spread adoption to really put it through it’s paces. https://oswalt.dev/2012/11/quality-of-service-part-2-bringing-it-together-cisco-nexus-cisco-ucs-and-vmware/ Tue, 13 Nov 2012 00:00:00 +0000 https://oswalt.dev/2012/11/quality-of-service-part-2-bringing-it-together-cisco-nexus-cisco-ucs-and-vmware/ When you’re talking about something like MTU or QoS, it’s important to think about technology implementations in an end-to-end fashion by analyzing every possible path network traffic can take - always planning for the big picture and never simply a single connection between devices. For instance, poor planning can result in confusing QoS configurations that don’t match from device to device. Depending on the platform, this can result in mismatched MTU configurations, which at worst breaks your network and at best causes elusive performance problems that can be incredibly difficult to troubleshoot. https://oswalt.dev/2012/11/quality-of-service-part-1-types-of-qos-policies/ Wed, 07 Nov 2012 00:00:00 +0000 https://oswalt.dev/2012/11/quality-of-service-part-1-types-of-qos-policies/ There’s a lot of information out there about QoS and it’s an area where I’m only now starting to feel comfortable. I’ve been fortunate enough to have a decent amount of experience configuring datacenter equipment, especially in the context of a Flexpod, so I’ve been forced to know how all of these technologies play together with respect to QoS, which is very important when running sensitive applications like voice on such an infrastructure. https://oswalt.dev/2012/11/the-formation-of-brocatta-brocade-aquires-vyatta/ Mon, 05 Nov 2012 00:00:00 +0000 https://oswalt.dev/2012/11/the-formation-of-brocatta-brocade-aquires-vyatta/ Yes, I invented the word “Brocatta”, and I am not ashamed. The announcement was made today that Vyatta, a company that I’ve long used for their software routers and firewalls, has been acquired by Brocade. The move was not a surprise to me, as Brocade has yet to define a proper SDN strategy to compete with the announcement of Cisco’s Open Network Environment and onePK. Positioning Vyatta as Brocade’s “Software Networking” business unit is a good move because now Vyatta can operate more like an R&D department with better funding than I’m sure they’ve enjoyed thus far. https://oswalt.dev/2012/10/cisco-ucs-b200-m3-invalid-adaptor-iocard/ Fri, 19 Oct 2012 00:00:00 +0000 https://oswalt.dev/2012/10/cisco-ucs-b200-m3-invalid-adaptor-iocard/ I received two brand spanking new B200 M3 blade servers for a new project. These bad boys are packing 393GB of RAM and two Intel Xeon E5-2680 2.7GHz 8-core processors each. I wanted to get these installed as soon as possible, so I could make sure the firmware was up to current (they came with 2.0(3c), which is what I’m running) and apply service profiles to them. At the end of the initial deep hardware discovery, I received a strange error in UCSM - “Invalid Adaptor Iocard”: https://oswalt.dev/2012/09/kiclet-nx-os-ethernetx-is-down-inactive/ Fri, 21 Sep 2012 00:00:00 +0000 https://oswalt.dev/2012/09/kiclet-nx-os-ethernetx-is-down-inactive/ This is a short one. I didn’t see a ton of information on this on the internet so I figured I’d put it forward. I’m using a pair of Nexus 2K FEX switches (N2K-C2248TP-1GE) for 1GbE copper connectivity off of a pair of Nexus 5548UP switches. I needed to set one of the 2K ports to access mode and place it in a VLAN. Pretty simple. After configuring one of the 2K ports through the 5K CLI though, I noticed that the port was listed as “down (inactive)”. https://oswalt.dev/2012/09/spanning-tree-requirements-for-cisco-issu/ Wed, 19 Sep 2012 00:00:00 +0000 https://oswalt.dev/2012/09/spanning-tree-requirements-for-cisco-issu/ I had a great conversation with a coworker regarding the requirements for the In-Service Software Upgrade (ISSU) feature on Cisco switches. For this post, I’m using Nexus 5548UP switches as a distribution layer to my Cisco UCS environment, and at the core is sitting a pair of Catalyst 6500s, set up in a VSS pair. For those unfamiliar with ISSU, it is a way for Cisco devices to upgrade their running firmware without the need for a disruptive reboot of the device, which is what has traditionally been used for upgrades to IOS, NX-OS, etc. https://oswalt.dev/2012/09/the-pros/cons-of-public-dns/ Tue, 11 Sep 2012 00:00:00 +0000 https://oswalt.dev/2012/09/the-pros/cons-of-public-dns/ I strongly believe that every route/switch engineer, even highly experienced ones, should have at least a fundamental understanding of DNS architectures and best practices. More importantly, it should be understood how DNS is being used in today’s service providers and enterprises. DNS is one of those services that has been applied to many different use cases, such as a form of load balancing, or even an additional layer of security. https://oswalt.dev/2012/09/esxi-5-on-cisco-ucs-no-local-disks-showing-up/ Thu, 06 Sep 2012 00:00:00 +0000 https://oswalt.dev/2012/09/esxi-5-on-cisco-ucs-no-local-disks-showing-up/ I am installing ESXi 5 on a Cisco UCS B440 M1 blade, and ran into some local disk issues. I used both the stock ESXi 5 image from VMware, as well as the recently released image from Cisco that contains the latest UCS drivers. Same issue on both. The issue was that when I got to the disk selection screen on the ESXi installation, I did not see any disks: https://oswalt.dev/2012/09/my-ccie-journey-begins/ Wed, 05 Sep 2012 00:00:00 +0000 https://oswalt.dev/2012/09/my-ccie-journey-begins/ I am happy to say that I have officially started putting things together for my CCIE R/S studies. I have been and will continue to be pulled in many different directions, but since my CCNP was completed a few months ago, and I recently passed my VCP exam, I decided that the time was now to begin the long journey ahead. I have a few other certifications in mind, and I will have to carefully weigh how they impact (or preferably do not impact) my CCIE studies, but this journey is important to me personally and professionally, so I’m pulling the trigger. https://oswalt.dev/2012/08/thoughts-on-vxlan-and-cisco-1000v/ Wed, 29 Aug 2012 00:00:00 +0000 https://oswalt.dev/2012/08/thoughts-on-vxlan-and-cisco-1000v/ I know vXLAN has been around for a year now, but because of the reviews it got from the community immediately upon announcement, I decided to let it mature as an idea before I got involved. Here are some of my thoughts after attending a vXLAN session by Cisco at VMworld 2012. vXLAN really just solves one problem. Most virtual infrastructures depend on L2 connectivity. vMotion is a good example of this. https://oswalt.dev/2012/08/whats-new-in-vsphere-5.1-networking/ Tue, 28 Aug 2012 00:00:00 +0000 https://oswalt.dev/2012/08/whats-new-in-vsphere-5.1-networking/ I attended the VMworld 2012 session that covered the new features in vSphere 5.1 with regards to networking. Many features were rolled out to both VDS and the standard switch, and other features just had improved functionality. First off, apparently it’s now VDS, not vDS. This announcement came hours after the announcement that VXLAN was being changed to vXLAN. Um…okay, I guess? Anyways - The speaker pointed out at the beginning that a big change was that many of these features were being rolled out to both the standard and distributed switches. https://oswalt.dev/2012/08/important-fcoe-considerations-cisco-nexus-and-netapp/ Wed, 22 Aug 2012 00:00:00 +0000 https://oswalt.dev/2012/08/important-fcoe-considerations-cisco-nexus-and-netapp/ I ran into an issue that presented itself two different ways, each at a different customer. I posted a while back about a customer that wanted to use only a single Nexus 5000, since that was all that was available. I wanted to bundle all four CNA ports on the Netapp storage array to the Netapp SAN. However, after I created this port channel and bound the virtual fibre channel (VFC) interface to it, the VFC interface would not come up. https://oswalt.dev/2012/08/scripted-flexpod-provisioning-first-impressions/ Fri, 17 Aug 2012 00:00:00 +0000 https://oswalt.dev/2012/08/scripted-flexpod-provisioning-first-impressions/ I had the opportunity this week to ascertain the feasibility of automating the provisioning of a full Flexpod. For reference, this is considering a “vanilla” Flexpod build: Pair of Nexus 5ks Pair of Cisco UCS Fabric Interconnects (with a few chassis) Netapp running ONTAP 7-Mode (I tested on FAS6070) Note that this also makes a few assumptions about the build. FC via Nexus 5000, no MDS No existing vCenter integration or storage migration So - pretty much a green field Flexpod build, pretty close to the specs laid out in the design guide. https://oswalt.dev/2012/07/kiclet-solarwinds-dirty-google-tricks/ Fri, 27 Jul 2012 00:00:00 +0000 https://oswalt.dev/2012/07/kiclet-solarwinds-dirty-google-tricks/ This is a (justifiable) rant. You’ve been warned. Solarwinds Orion NPM is an okay tool, but when it comes to managing anything other than Cisco switches and routers, it’s…..meh. It takes very little effort to get devices like that monitored to the fullest extent, but when it comes to something like a storage array, it seems like you really have to make tweaks until your fingers bleed to get the minimal monitoring functionality out of it. https://oswalt.dev/2012/07/kiclet-sub-optimal-fibre-channel-path-selection/ Thu, 12 Jul 2012 00:00:00 +0000 https://oswalt.dev/2012/07/kiclet-sub-optimal-fibre-channel-path-selection/ The SAN I’m currently working with connects a pair of Netapp FAS3270 filers running ONTAP 8.0.2 7-Mode. If you’re running VMware ESXi in your environment in front of a Fibre Channel SAN, path selection is discovered more or less in a first-come-first-served fashion. I got this message on my Netapp filer: FCP Partner Path Misconfigured: Host I/O access through a non-primary and non-optimal path was detected. Since the LUNs mounted by ESXi were residing on the A-side filer, the paths going through the B-side filer would just be sent over the partner link to the A-side, which is less efficient than going directly through A. https://oswalt.dev/2012/07/kiclet-microphone-troubles-with-lenovo-w520/ Wed, 11 Jul 2012 00:00:00 +0000 https://oswalt.dev/2012/07/kiclet-microphone-troubles-with-lenovo-w520/ I came across this the other day and wanted to share. For some reason, Windows by default decided to enable the “audio enhancements” feature on my new Lenovo Thinkpad w520. This caused my microphone to essentially be unusable - I was in several webex meetings and each time everyone said I was completely garbled and not even close to being able to understand me. After a little poking around, I found this: https://oswalt.dev/2012/05/cisco-ucs-b440-blade-replacement/ Wed, 09 May 2012 00:00:00 +0000 https://oswalt.dev/2012/05/cisco-ucs-b440-blade-replacement/ Cisco announced recently a replacement program for their B440 blades (M1 and M2) http://www.cisco.com/en/US/ts/fn/634/fn63430.html Something I noticed on the front of each blade, where the model is shown, the new generation blades (replacements) have the black background with the silver text, shown as the top blade on the picture below: However, the old blades still have the black text with no background. An interesting way to identify the newer generation of hardware. https://oswalt.dev/2012/05/management-vlan-best-practices-in-esxi-and-cisco-ucs/ Tue, 01 May 2012 00:00:00 +0000 https://oswalt.dev/2012/05/management-vlan-best-practices-in-esxi-and-cisco-ucs/ If you’ve set up an ESXi host, you’ve likely seen this screen: This allows you to configure which VLAN is used for management. But what does this really do? Time after time I run into very smart engineers that primarily work on virtualization and not as much on the physical networking side - and they miss a few of the networking fundamentals that those of us that were brought up in ROUTE/SWITCH know and love. https://oswalt.dev/2012/04/review-remote-desktop-connection-manager/ Fri, 27 Apr 2012 00:00:00 +0000 https://oswalt.dev/2012/04/review-remote-desktop-connection-manager/ It’s been a while since I’ve done a review of anything on the site and since I’d rather continue to make use of the category than delete it, I decided to share a piece of software I recently discovered that’s helping make my life easier. Remote Desktop Connection Manager is essentially just that - it manages remote desktop connections. However, it does it in a way that I find appealing and EASIER to use than the native client or other organizational methods out there. https://oswalt.dev/2012/04/windows-server-2008-r2-boot-from-san-on-cisco-ucs/ Wed, 25 Apr 2012 00:00:00 +0000 https://oswalt.dev/2012/04/windows-server-2008-r2-boot-from-san-on-cisco-ucs/ For those that have worked with any type of blade server system, you know that boot from SAN is just about the coolest thing since sliced bread. Cisco UCS makes this even cooler by integrating with the service profile concept, allowing for stateless compute provisioning across the board. I’ve done boot from SAN many times, but never with Windows. I’ve primarily used ESXi4.1 or ESXi5.0 stored on a Fibre Channel LUN, then the VMs are stored in either a FC or NFS datastore. https://oswalt.dev/2012/04/a-quick-and-dirty-netapp-snapmirror/ Thu, 19 Apr 2012 00:00:00 +0000 https://oswalt.dev/2012/04/a-quick-and-dirty-netapp-snapmirror/ Snapmirror is a Netapp feature that’s pretty commonly used to copy data from one system to another. You can copy volumes, or qtrees. It’s also very useful in Disaster Recovery plans, since volumes can be incrementally backed up to an offsite location. I have a VMWare vCenter instance running on Cisco UCS that utilizes a Fibre Channel LUN to store VM templates. It’s pretty large, since it holds templates for a variety of operating systems. https://oswalt.dev/2012/04/cisco-ucs-firmware-upgrade-explorations/ Wed, 18 Apr 2012 00:00:00 +0000 https://oswalt.dev/2012/04/cisco-ucs-firmware-upgrade-explorations/ I’m currently working with a relatively large Cisco UCS installation. Initially, the system was installed and brought up to relatively recent levels of firmware, but a mismatch in the way that the firmware packages were set up in various sub-organizations on some of the UCS systems caused some of the blades to retain the old version of firmware on the M81KR adapters and the CIMC controllers. Due to the scope of the installation, I wanted to ensure that the blades were able to continue operating while I made my changes. https://oswalt.dev/2012/04/kiclet-cisco-ucs-socket-connect-error/ Wed, 18 Apr 2012 00:00:00 +0000 https://oswalt.dev/2012/04/kiclet-cisco-ucs-socket-connect-error/ I recently observed some strange behavior with Cisco UCS Manager. When I visited the web page that allows me to download the .jnlp file that launches UCSM, it came up just fine. But when I clicked on “Launch UCS Manager” to actually launch this applet, the splash screen showed briefly, but disappeared after a few seconds, never to be seen again. Eventually, you might also see some java error messages that say something like https://oswalt.dev/2012/04/vital-gadgets-for-a-datacenter-network-engineer/ Wed, 11 Apr 2012 00:00:00 +0000 https://oswalt.dev/2012/04/vital-gadgets-for-a-datacenter-network-engineer/ I would like to share some tips regarding gadgets that I believe every Datacenter Network Engineer should have with them. There are several, but I want to bring up my top two.ß Travel Router I am often in situations where it is either difficult or impossible to manage Nexus switches and/or UCS remotely. Pick your reasons - sometimes the management network doesn’t exist (yet) or there are heavy security measures in place that restrict wired management, whatever. https://oswalt.dev/2012/03/static-routes-to-an-interface-not-a-next-hop/ Thu, 15 Mar 2012 00:00:00 +0000 https://oswalt.dev/2012/03/static-routes-to-an-interface-not-a-next-hop/ Static routes can be handy in some situations where you want to do some quick and (sometimes) easy routing to get the job done, whether replacing the job that a routing protocol would perform, or redistributing the static route into that protocol. The best way to do this would be to identify the remote subnet being routed to, and specify a next-hop IP address to send traffic to so that it can be reached. https://oswalt.dev/2012/02/netapp-cna-link-redundancy-with-a-single-nexus-switch/ Thu, 23 Feb 2012 00:00:00 +0000 https://oswalt.dev/2012/02/netapp-cna-link-redundancy-with-a-single-nexus-switch/ I ran into a configuration recently where I had a Netapp storage array with the UTA cards installed, so there two CNA ports on each filer for a total of 4 ports. However, instead of a dual-switch design, there was only a single Nexus 5000, and therefore, no vPC configuration. I needed to achieve some level of redundancy on an interface level, but ran into some problems which I’ll discuss. https://oswalt.dev/2012/02/nx-os-virtual-portchannels-and-best-practices/ Wed, 08 Feb 2012 00:00:00 +0000 https://oswalt.dev/2012/02/nx-os-virtual-portchannels-and-best-practices/ Port-Channels, are a way of aggregating physical links together so that you can load balance traffic over each link to increase bandwidth, and create more redundancy. You might commonly see this configured between two switches, as shown below: Each link works together to form a logical, loop-free interface. These are relatively commonplace, and in this scenario highly useful because it prohibits spanning tree from blocking one of these ports, allowing the switch to utilize each link. https://oswalt.dev/2012/02/some-out-of-box-netapp-tweak-suggestions/ Wed, 01 Feb 2012 00:00:00 +0000 https://oswalt.dev/2012/02/some-out-of-box-netapp-tweak-suggestions/ It’s interesting to me to see the differences in infrastructure products as it pertains to out of the box, or default configuration. Take for instance, the relationship between a firewall and a switch. Your average firewall is configured “closed”, meaning that if you want to allow anything, you have to explicitly allow that certain type of traffic. If you do not, it is not allowed. A switch, on the other hand, is configured to be functional above all, out of the box. https://oswalt.dev/2012/01/port-monitoring/mirroring-on-nx-os-span-profiles/ Wed, 25 Jan 2012 00:00:00 +0000 https://oswalt.dev/2012/01/port-monitoring/mirroring-on-nx-os-span-profiles/ Port mirroring is a very valuable troubleshooting tool. Cisco calls this SPAN, and it’s pretty easy to do. Cisco’s NX-OS platform does it a little differently than traditional IOS, so I wanted to briefly post a walkthrough. First, you have to set up the monitor session and configure source and destination interfaces: switch(config)# monitor session 1 switch(config-monitor)# source int port-channel 2 both switch(config-monitor)# source int port-channel 3 both switch(config-monitor)# destination interface ethernet 1/7 switch(config-monitor)# no shut switch(config-monitor)# https://oswalt.dev/2012/01/kiclet-cisco-ucs-vhba-template-bug/ Tue, 24 Jan 2012 00:00:00 +0000 https://oswalt.dev/2012/01/kiclet-cisco-ucs-vhba-template-bug/ I found a bug in the vHBA Template creation screen on Cisco UCS 2.0. It’s not too bad, but still a little annoying, and can cause you to have some problems depending on how you have your VSANs set up. If you notice, the default VSAN is selected for my vHBA template. I have named my VSANs “fabric-a” and “fabric-b”. If I drop down the VSAN selector, I have the ability to select the VSAN I have associated with fabric A: https://oswalt.dev/2012/01/kiclet-nx-os-default-switchport-state/ Thu, 19 Jan 2012 00:00:00 +0000 https://oswalt.dev/2012/01/kiclet-nx-os-default-switchport-state/ Cisco switches (and the vast majority of other vendors) ship their switches with all ports in the enabled state. This allows someone with no networking background to plug stuff in, the switch starts learning MAC addresses, and everything works just fine. Sometimes it’s necessary from a security perspective to change this default behavior, so the network engineer is forced to “no shut” every port he or she wishes to use. https://oswalt.dev/2012/01/new-post-type-kiclets/ Thu, 19 Jan 2012 00:00:00 +0000 https://oswalt.dev/2012/01/new-post-type-kiclets/ My time lately has been just blasted. I’m being placed into new projects with a large company that involves just about every technology found in a datacenter, and as a result, my spare time is….nonexistent. My knowledge levels in many areas continues to increase, and my need to spew some of it onto the internet in the form of helpful posts, or opinions is not quenched, but unfortunately I do not have a ton of time to dedicate to full-on blog posts during the week. https://oswalt.dev/2011/12/redundancy-protocols-vs-stacking-pros-and-cons/ Mon, 12 Dec 2011 00:00:00 +0000 https://oswalt.dev/2011/12/redundancy-protocols-vs-stacking-pros-and-cons/ I was recently asked whether or not I preferred to use a router redundancy protocol like HSRP, VRRP, or GLBP, or stack switches together to form a sort of “virtual router”, and use that for redundancy. Just like anything else, the immediate answer is “it depends”, but there are a few things to remember when considering a redundant design with your routers or Layer 3 switches. First, redundancy protocols can be found nearly everywhere. https://oswalt.dev/2011/11/multi-vendor-network-woes/ Wed, 23 Nov 2011 00:00:00 +0000 https://oswalt.dev/2011/11/multi-vendor-network-woes/ First, I’d like to thank you all for continuing to read my thoughts these last few weeks. Some already know that I passed the CCNP ROUTE exam this past weekend, and that has slowed my ability to write consistently. Fortunately, I laid that beast of an exam to rest and I get to focus on bigger, better things. I’ve been working a project for the past few weeks that’s involved the integration of HP and Cisco networking equipment. https://oswalt.dev/2011/11/address-port-stall-tactics/ Mon, 14 Nov 2011 00:00:00 +0000 https://oswalt.dev/2011/11/address-port-stall-tactics/ I recently listened to Packet Pushers Show 72 on “How we are killing the internet” and want to voice my thoughts on the topics discussed. The majority of the conversation circled around IPv6 adoption, and the state of the internet in light of the existence of tunneling mechanisms being used. Ivan mentioned that we are destroying the internet with all the tunnels (PPPoE, PPPoA, 6to4, 4to6, 6rd, etc) and translation points. https://oswalt.dev/2011/11/this-new-cloudshark-thing/ Mon, 07 Nov 2011 00:00:00 +0000 https://oswalt.dev/2011/11/this-new-cloudshark-thing/ I had heard of CloudShark a while back but was reminded of it by a recent Packet Pushers article. For those that haven’t, CloudShark is a new product that basically claims to be a cloud-based capture file (such as from Wireshark) archiving solution. Viewing the main CloudShark website, you’ll be unable to miss what is obviously their big pull - CLOUDSHARK BRINGS YOUR CAPTURE FILES TO THE CLOUD OMGZ!!! (Did the fact that those words are at the top of each page on their site not give away their enthusiasm? https://oswalt.dev/2011/11/hopping-on-the-fcotr-bandwagon/ Thu, 03 Nov 2011 00:00:00 +0000 https://oswalt.dev/2011/11/hopping-on-the-fcotr-bandwagon/ Finally got the shirt in the mail. Ready to start implementing this at customer sites. https://oswalt.dev/2011/10/openflow-symposium-2011-morning-session/ Thu, 27 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/openflow-symposium-2011-morning-session/ I was able to watch a good chunk of the morning session of the OpenFlow Symposium in San Jose. The stream was having issues at the beginning of the afternoon session, plus I was pulled away for other issues, so I was only able to watch the morning session. I’d like to provide a bit of a write-up from what I was able to catch, and point out some of the highlights that I took interest in from the day’s speakers. https://oswalt.dev/2011/10/link-state-vs.-distance-vector-the-lowdown/ Tue, 25 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/link-state-vs.-distance-vector-the-lowdown/ I’ve been trying to get more into networking message boards like Networking Forum and TechExams.net lately. It’s a great way to get in touch with fellow packet lovers and gain some interesting perspectives along the way. In fact, it’s great for anyone in networking, whether you’re a hardened veteran or a newbie - there’s usually a place for you in at least one of these sites. As a result, I’ve seen quite a few posts asking about fundamental concepts, which is great because it shows that new networkers are getting out there and learning new things proactively. https://oswalt.dev/2011/10/well-theres-your-problem..../ Tue, 25 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/well-theres-your-problem..../ I think they refer to this as a Layer 1 issue: https://oswalt.dev/2011/10/network-humor-partial-mesh/ Tue, 18 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/network-humor-partial-mesh/ Partial Mesh [pahr-shuhl mesh] noun A type of networking where each node must not only capture and disseminate its own data, but also serve as a relay for other nodes, that is, it must collaborate to propagate the data in the network. What happens to your screen doors when you get cats Image and definition credit: Wikipedia https://oswalt.dev/2011/10/neighbor-solicitation-ipv6s-replacement-for-arp/ Mon, 10 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/neighbor-solicitation-ipv6s-replacement-for-arp/ Like most others that start tinkering with IPv6, I quickly learned that there was no such thing as broadcasts on v6 networks. Since I thought that was a pretty revolutionary concept, I started thinking about all the protocols that until now have relied upon the ability to send via broadcast. The first that came to mind was ARP, which resolves known IP addresses to unknown MAC addresses by sending to the Layer 2 broadcast address of FF:FF:FF:FF:FF:FF. https://oswalt.dev/2011/10/virtual-switching-system-vss-on-cisco-catalyst-6500/ Wed, 05 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/virtual-switching-system-vss-on-cisco-catalyst-6500/ I’m currently working on a project that, among other things, involves the installation of two Catalyst 6509 switches. I was recently shown a redundancy feature that I had never heard of before called Virtual Switching System (VSS). The more I looked at it, the cooler it was. The main reason for VSS is something that is typically addressed when there are redundant routing platforms on a network. There are actually quite a few solutions that can be used in the presence of redundant devices, such as the popular and Cisco-proprietary Hot Standby Router Protocol (HSRP), or the IETF open standard Virtual Router Redundancy Protocol (VRRP). https://oswalt.dev/2011/10/i-am-cisco-man/ Tue, 04 Oct 2011 00:00:00 +0000 https://oswalt.dev/2011/10/i-am-cisco-man/ Hello. Let me begin by saying you have arrived. Pardon me, where are my manners? I am CiscoMan - the comforting presence at the top of a large number of Cisco documents such as configuration and installation notes for Catalyst switches. I’m here to tell you that everything is going to be alright - that it’s okay to be scared. CiscoMan is here to help you out. Believe me, you’re not my first. https://oswalt.dev/2011/09/where-did-all-the-time-go/ Thu, 29 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/where-did-all-the-time-go/ I woke up this morning and realized that I had broken my 3-week long streak of blog posting, where I had gotten in the habit of making a new post nearly every day of the week. Since I have been unemployed for the past three weeks and my primary priority was to study for the CCNP, it was easy to come up with new blog content at a relatively rapid pace. https://oswalt.dev/2011/09/bgp-weight-and-local-preference/ Mon, 26 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/bgp-weight-and-local-preference/ It’s important to remember that since BGP is the routing protocol of the internet, there are quite a few attributes that it uses to give preference to a single route out of several redundant paths to a given destination. I was recently contemplating several of these and it occurred to me that two of these attributes in particular are pretty similar. I’d like to compare and contrast them and give reasoning for situations that call upon one or the other. https://oswalt.dev/2011/09/eigrp-unequal-cost-load-balancing/ Thu, 22 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/eigrp-unequal-cost-load-balancing/ In a previous post, I explored the basics of IP routing, and in the process, we discovered an interesting default feature of OSPF. When there were two OSPF routes in the routing table to a network, and both routes had the same cost, the router performed load balancing between the two. Take, for instance, the following route: 172.16.2.0 [110/12] via 1.1.1.13, 00:09:24, FastEthernet0/0 [110/12] via 1.1.1.2, 00:09:24, FastEthernet0/1 In this example, every packet sent would take one of two routes. https://oswalt.dev/2011/09/changing-gears-virtual-networking/ Wed, 21 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/changing-gears-virtual-networking/ When it came to networking, my university classes didn’t teach me much more than the basics of network infrastructure, and a little bit of route/switch. Now that I’ve graduated, I continue to learn as I strive for the next steps. So far, it’s been CCNP ROUTE, since I knew I wanted to go for it soon after CCNA. Because of this trend, I’ve been pretty devoted to routing, with a small segway into security as I obtained my Security+ certification. https://oswalt.dev/2011/09/review-ethernet-fabric-whitepaper-by-brocade/ Tue, 20 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/review-ethernet-fabric-whitepaper-by-brocade/ I’ve been pretty deep into my CCNP ROUTE studies, which is mostly WAN and routing protocols, so I haven’t had much chance to dive any deeper when it comes to datacenter stuff. I’d seen several ads for the Brocade whitepaper titled “Five Reasons Classic Ethernet Switches Won’t Support the Cloud” and I figured I’d give it a shot. The whitepaper is not long, and is quite easy to understand. It contrasted well between traditional switches and Ethernet Fabric switches in terms of supporting SaaS application requirements, pointing out that while STP is a necessary evil in a classic Ethernet switched infrastructure, it creates several problems for “the cloud”. https://oswalt.dev/2011/09/eigrp-over-nbma-networks/ Mon, 19 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/eigrp-over-nbma-networks/ Commonly used routing protocols like OSPF and EIGRP utilize multicast addresses to distribute hello messages, and routing information. In a broadcast-capable layer 2 network like Ethernet, EIGRP will send a packet containing a hello message to the address 224.0.0.10, which results in a corresponding layer2 destination 01:00:5e:00:00:0a. Something I used to wonder about all the time is how routing protocols work over Non-Broadcast Multi-Access networks like Frame Relay. In these networks, there are no broadcasts or multicasts. https://oswalt.dev/2011/09/vyatta-ospf-designated-router-concepts/ Fri, 16 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/vyatta-ospf-designated-router-concepts/ I was inspired by a (relatively) recent post by Jeremy Stretch at Packetlife.net that explained OSPF designated router configuration in Cisco IOS. I’d like to go into a bit more detail regarding the need for a designated router, and explore the same configuration steps on the Vyatta Core platform. I’ve already shown how easy it is to integrate a Cisco router with a Vyatta router using OSPF, so you can use a mix of Cisco and Vyatta gear if you wish. https://oswalt.dev/2011/09/routing-information-protocol-keeping-it-classless-labs/ Thu, 15 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/routing-information-protocol-keeping-it-classless-labs/ Today we’ll be looking at Routing Information Protocol, or RIP. This is an easy-to-use protocol to distribute routing information around a network. We’ll explore how to configure it on a Cisco router, and some of the tweaks necessary to get it to perform well in a modern network. Download the Lab Outline Download the GNS3 Lab used in this video https://oswalt.dev/2011/09/useful-openflow-resources/ Thu, 15 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/useful-openflow-resources/ I wrote a post a while back introducing OpenFlow, and I informed you of my thoughts concerning this relatively new technology. Regardless of your need for a programmable network, the concept is certainly interesting and warrants some tinkering. It’s important to remember that OpenFlow itself is just a protocol definition, and until recently, there wasn’t a lot of software available that implemented it, and thus, no in-home tinkering. I’d like to point out a few new projects that are implementing OpenFlow and making it relatively easy to implement on your own. https://oswalt.dev/2011/09/ipv6-prefix-lengths/ Wed, 14 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/ipv6-prefix-lengths/ For years, discussions regarding the appropriate prefix length for IPv6 subnets have been waged, with high profile organizations and bloggers chipping in their $0.02 for all kinds of opinions. IPv6 enthusiasts have long-adhered to their “A /64 for every subnet” approach, and they give many good reasons for this approach. There are others who recognize the sheer amount of waste from this method, and suggest much more restrictive prefixes, such as /126 for a point-to-point link, as that prefix allocates 2 addresses, identical to the /30 mask in the IPv4 world. https://oswalt.dev/2011/09/ipv6-hacking-thc-ipv6-part-2/ Mon, 12 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/ipv6-hacking-thc-ipv6-part-2/ A while back I did a post called IPv6 Hacking - “thc-ipv6” Part 1 - it was, in fact, the first post here on Keeping It Classless. That post focused on the flood_router6 script, which unleashed a flood of IPv6 Router Advertisements (RAs) on a layer 2 network segment, bringing vulnerable operating systems like Windows 7 to their knees. The “fake_router6” script is another member of the “thc-ipv6” suite that grants a powerful weapon to a would-be attacker. https://oswalt.dev/2011/09/configuring-ospf-between-vyatta-and-cisco-ios/ Thu, 08 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/configuring-ospf-between-vyatta-and-cisco-ios/ This is a guide to configuring OSPF between Cisco IOS and the open-source Vyatta router platform. I was able to do all of this on my desktop PC, by running Cisco IOS in GNS3 and Vyatta as a virtual machine. I used the guide here to bridge both virtual routers together, so that communication could be established. The Cisco side was pretty straightforward. I configured the FastEthernet interface and enabled OSPF on it: https://oswalt.dev/2011/09/ospf-wont-redistribute-my-static-routes/ Wed, 07 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/ospf-wont-redistribute-my-static-routes/ I was working on some CCNP ROUTE labs, and I was attempting to rebuild a basic OSPF lab from memory. The lab included practice with inter-area route summarization, and static route redistribution. I ran across a problem that seems to be plaguing others, at least according to google, but my searches didn’t yield a solution to my specific problem, which was that the static routes I had created weren’t being redistributed by OSPF. https://oswalt.dev/2011/09/the-global-internet-speedup-not/ Fri, 02 Sep 2011 00:00:00 +0000 https://oswalt.dev/2011/09/the-global-internet-speedup-not/ I recently saw posts from a few sources on a new initiative backed by a consortium that includes Google and OpenDNS to attempt to improve the overall speed of the internet by optimizing the way DNS works on the internet. If you think about it, a great deal of internet traffic is high-volume requests for things like photos, music, video, and the like. You may know, then, that content providers like Akamai have positioned themselves globally around the world to provide this content at a relatively close physical location to those requesting it. https://oswalt.dev/2011/08/keeping-it-classless-labs-static-routing/ Tue, 30 Aug 2011 00:00:00 +0000 https://oswalt.dev/2011/08/keeping-it-classless-labs-static-routing/ This is the first in what I hope to be a useful series on configuration/walk through videos aimed at educating up-and-coming networking professionals on some of the more fundamental concepts. Today we’ll be looking at static routing and how to configure it in a small Cisco network. Below are the lab files (GNS3) and the videos themselves. Download the Lab Outline Download the GNS3 Lab used in this video Since it’s a new Youtube channel, I’m limited to 15 minutes per clip, and therefore had to break it into two parts. https://oswalt.dev/2011/08/new-feature-keeping-it-classless-labs/ Tue, 30 Aug 2011 00:00:00 +0000 https://oswalt.dev/2011/08/new-feature-keeping-it-classless-labs/ I’m pleased to announce a new feature on the site. I’m going to start publishing some articles on more fundamental concepts in networking in the form of video walk throughs / labs. I wanted to free up the main blog feed for some more advanced topics, and a lot more of an overall network design discussion, as well as the occasional fun stuff. Several people have approached me in the past about making something like this that would help beginners learn the fundamentals, and at the time I wasn’t able to, but I feel like I’m able to do them now. https://oswalt.dev/2011/08/my-three-favorite-pop-culture-meets-computers-epic-fails/ Mon, 29 Aug 2011 00:00:00 +0000 https://oswalt.dev/2011/08/my-three-favorite-pop-culture-meets-computers-epic-fails/ The television and video game industry are just absolutely RIDDLED with terrible attempts at referencing technology. Typically, these scenes will try to delve into some sort of computer-like concept, often related to computer networking, to try to improve the modernity of the content. Before you say anything, I did pull a bit of inspiration from this Cracked article, but there are a few I’ve encountered on my own. I hope you enjoy! https://oswalt.dev/2011/08/three-traits-of-an-effective-network-engineer/ Wed, 24 Aug 2011 00:00:00 +0000 https://oswalt.dev/2011/08/three-traits-of-an-effective-network-engineer/ Over the past few years, I’ve made some observations about the people I’ve worked and communicated with. Some of these people were colleagues, others acquaintances, and still others were simply bloggers that I look up to. I’m talking specifically of those people that are in my field of Network Engineering, and they all share a few traits in common. I’ve deemed a few of these traits to be important things to remember when trying to make yourself a better network engineer, and a better IT professional in general. https://oswalt.dev/2011/08/monitoring-an-entire-vlan-on-a-layer-3-switch/ Tue, 09 Aug 2011 00:00:00 +0000 https://oswalt.dev/2011/08/monitoring-an-entire-vlan-on-a-layer-3-switch/ A recent and relatively quiet IOS release allows the Catalyst 2960 platform to perform limited Layer 3 Switching (See this thread and this blog post). There are limitations - for instance, it cannot run any sort of routing protocol, so routing must be done statically. Up to 16 static routes can be entered, and routing is limited to SVI’s (maximum of 8), as the platform is not able to route to or from a physical interface, like you’re able to do with most layer 3 switches. https://oswalt.dev/2011/07/eigrp-feasible-successors/ Sat, 30 Jul 2011 00:00:00 +0000 https://oswalt.dev/2011/07/eigrp-feasible-successors/ Link state routing protocols maintain topology tables to determine the best candidate to place in the routing table. EIGRP is no different - it uses this topology table to build a vision of the network from the perspective of each participating router. This topology table is reviewed by the routing algorithm (in the case of EIGRP, it is DUAL) and decisions are made regarding what gets placed into the routing table. https://oswalt.dev/2011/07/the-anatomy-of-show-ip-route/ Mon, 18 Jul 2011 00:00:00 +0000 https://oswalt.dev/2011/07/the-anatomy-of-show-ip-route/ One of the most important skills to have when it comes to basic networking is the ability to look at a routing table and determine exactly where a packet will be routed when it comes to a router. Sometimes a routing table is relatively simple, and this process is easy. However, many times this is not the case. In large networks, especially networks that implement a hub and spoke design where core routers are often required to know hundreds of routes or more, this can be tedious. https://oswalt.dev/2011/06/a-primer-on-ip/ipv6-mobility/ Mon, 27 Jun 2011 00:00:00 +0000 https://oswalt.dev/2011/06/a-primer-on-ip/ipv6-mobility/ At the end of my Senior Design sequence, a professor asked if I had time to look into IPv6 Mobility. At the time, I had to tell him no, since it was considered to be out of scope for the project. It’s a shame really - the concept of IP Mobility in general is extremely fascinating. I’d like to point out that IP Mobility is well-documented technology - and I’d rather not spend a lot of time explaining it, since I’m sure there are articles out there that do a much better job. https://oswalt.dev/2011/06/securely-wipe-your-hard-drive-the-quick-and-dirty-way/ Mon, 20 Jun 2011 00:00:00 +0000 https://oswalt.dev/2011/06/securely-wipe-your-hard-drive-the-quick-and-dirty-way/ We’ve all heard about tools like Darik’s Boot and Nuke for performing secure hard drive wipes suitable for even the most paranoid. However, in a pinch, there’s an alternative that often goes overlooked, but is able to erase data at a level comparable to all the usual standards like DoD (or even the incredibly obnoxious 35-pass Guttmann method) The ‘shred’ utility exists on nearly every popular Linux live CD/DVD and can be executed in a live environment to do the job when it’s all you have. https://oswalt.dev/2011/06/introduction-to-openflow/ Wed, 15 Jun 2011 00:00:00 +0000 https://oswalt.dev/2011/06/introduction-to-openflow/ Ah - I can finally breathe a sigh of relief, for I am finally done with my Senior Design sequence, as well as my undergraduate education. I’ve been feeling a little out of place, actually, since I’ve been in research mode for the last 9 months for my IPv6 project. So, after a short break, I decided to get back into things that I was just getting started with before all of that started. https://oswalt.dev/2011/05/world-ipv6-day-what-it-is-and-what-you-should-do/ Fri, 27 May 2011 00:00:00 +0000 https://oswalt.dev/2011/05/world-ipv6-day-what-it-is-and-what-you-should-do/ Arguably the most important day for IPv6 since it was created is World IPv6 Day, which falls on June 8th, 2010. This has been a highly publicized day when the top internet content providers like Google, Facebook, and Yahoo provide native IPv6 DNS records to their sites. But what does this mean? And how can you be prepared? Most of all, what will break, if anything? What will happen on World IPv6 Day? https://oswalt.dev/2011/05/new-blog-location-/-ipv6-hacking-thc-ipv6-part-1/ Mon, 23 May 2011 00:00:00 +0000 https://oswalt.dev/2011/05/new-blog-location-/-ipv6-hacking-thc-ipv6-part-1/ I’m pleased to announce the first post in my blog’s new location, here at keepingitclassless.net). I have been running a casual blog from my house for the past two years with mixed success. Residential internet connections as they are, this was usually hit or miss regarding whether or not my blog was even reachable. I’ve moved all that content to a web host which should prove to be much more reliable. https://oswalt.dev/2011/01/ipv6-subnetting-wait-we-still-need-to-do-that/ Tue, 11 Jan 2011 00:00:00 +0000 https://oswalt.dev/2011/01/ipv6-subnetting-wait-we-still-need-to-do-that/ Subnetting, in short, can be thought of as an adjustable “slide rule” that tells the network infrastructure the logical size of a sub-network, or subnet. This is useful if you know how many IP addresses you’ll to suit the needs of a predetermined number of PCs, so you can plan the size of your subnets to match that requirement. With IPv4, subnet masks are used to determine how big the subnets are. https://oswalt.dev/2010/10/t-minus-one-week/ Sat, 30 Oct 2010 00:00:00 +0000 https://oswalt.dev/2010/10/t-minus-one-week/ That’s right, I’m taking the 640-802 exam from Cisco to attain my CCNA (Cisco Certified Network Associate) certification in one week! The last four weeks have been quite eventful, although I’m ashamed I didn’t really start studying REALLY hard until about 3 weeks ago. Regardless, I’ve learned a lot! I’ve been following the book “31 Days Before Your CCNA Exam”, which is essentially a daily planner for study topics regarding CCNA material. https://oswalt.dev/2010/10/raw-ip-traffic-export-rite-on-cisco-ios/ Wed, 13 Oct 2010 00:00:00 +0000 https://oswalt.dev/2010/10/raw-ip-traffic-export-rite-on-cisco-ios/ Often, especially in medium to large networks, it’s crucial to monitor the traffic traversing your networks. Those in the networking industry know that tools like tcpdump and wireshark are crucial for deeply investigating network issues. Even developers use these tools to diagnose issues with applications utilizing network resources. Many times, it is helpful to install/use one of these tools to figure out exactly what’s traversing the network, by seeing the frames and packets themselves, in a visual way. https://oswalt.dev/2010/06/android-eclipse-troubles/ Wed, 30 Jun 2010 00:00:00 +0000 https://oswalt.dev/2010/06/android-eclipse-troubles/ Setting up a new Android Development Environment in Eclipse? Having troubles? Maybe one of these two solutions will help: PROBLEM #1 I recently re-imaged my PC and decided to build my Android Development Environment from scratch. Some recent modifications to my eclipse installation messed it up so I cut my losses and started over again. This time around, I noticed that Eclipse Helios was available for download, and not only that, it was the first version of Eclipse to offer a 64-bit version of the IDE for windows. https://oswalt.dev/2010/06/apps-of-empowerment/ Wed, 23 Jun 2010 00:00:00 +0000 https://oswalt.dev/2010/06/apps-of-empowerment/ This will be a short one (cough, I’m at work, cough) but I gotta share these links. Downloadsquad.com shares some great links, but these stories in particular give lists of apps that any computer-savvy person must at least be aware of. Before you go googling to download some shoddy software that may or may not do what you want it to, check out these lists first: http://www.downloadsquad.com/2008/09/02/24-killer-portable-apps-for-your-usb-flash-drive/ http://www.downloadsquad.com/2008/10/01/24-great-open-source-apps-for-admins-and-technicians/ http://www.downloadsquad.com/2009/05/18/40-great-open-source-apps-and-games-to-trick-out-your-new-windows/ Again, thanks to Downloadsquad. https://oswalt.dev/2010/02/breaking-firewalls-with-ssh-and-putty-not-with-a-proxy./ Thu, 11 Feb 2010 00:00:00 +0000 https://oswalt.dev/2010/02/breaking-firewalls-with-ssh-and-putty-not-with-a-proxy./ I’ve been seeing a lot out on the internet about proxy servers and how to use them to circumvent your school or workplace internet filters. Lifehacker recently posted an ~EIGHT PAGE~ walkthrough on how to set up such a proxy at home. This is entirely too complicated. Not only is it a long walkthrough, but your traffic is still unencrypted. Unless your school, work or other bought their filter technology more than 4 years or so ago, they can still see the header of your packets and where they’re headed. https://oswalt.dev/about/ Mon, 01 Jan 0001 00:00:00 +0000 https://oswalt.dev/about/ Matt Oswalt hails from Portland, OR, and focuses on the intersection of network infrastructure, automation, systems, and software engineering. He’s passionate about enabling engineers to evolve their careers to the next level, and getting the word out about bright spots across the technology landscape. You can often find him speaking at conferences or meetups about these topics, as well as writing about them on his blog (https://oswalt.dev) or on Twitter as @Mierdin. https://oswalt.dev/bookshelf/ Mon, 01 Jan 0001 00:00:00 +0000 https://oswalt.dev/bookshelf/ I am a big fan of Audible for books. Every once in a while I have time and patience to read a physical book, but often times I find myself needing to do things like washing dishes, going on a long walk or drive, and Audible has made it so much easier for me to get back into “reading”. Since I started doing this, I’d like to share the books that I’ve been able to get through this way.