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