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.
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.
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.
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.
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.
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).
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Matt Oswalt