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