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.
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’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.
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.
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:
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.
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.
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.
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.
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.
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.