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