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.
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.
A little detour from the networking topics today to show off a little weekend tech project.
I recently ran into some overheating problems with my home BYO PC. Core Temp was showing upwards of 70 degrees Celsius during normal operation, and under load, it would sometimes just shut down completely.
Here’s the setup I had as of 2 days ago:
The rear fan, which takes air in, was not working due to a short.
I have always used the “network 0.0.0.0 0.0.0.0” statement to describe “all interfaces” when configuring a routing protocol like EIGRP. I know that it’s not correct, but I never stopped to wonder why my bad habit still worked.
Then, I found this good article by @jdsilva explains this is IOS just assuming you had a “brain fart” and meant to type the proper “network 0.0.0.0 255.255.255.255”
I’m studying for the CCIE and it can be really good to identify these bad habits that, while in real life may not be too bad, especially this kind, where the result is the same, but on exams can mean the difference between failure and success.
This is a specific video on Rapid Spanning Tree Synchronization.
See my full writeup on RSTP in general.
Forgive the low(er) quality of this particular video, it was recorded at an hour in the morning that frankly should not exist.
This post picks up where the previous left off. Again, a CCNP-level knowledge of STP is recommended.
So…Spanning Tree didn’t converge quickly enough for some people, and enabling PortFast everywhere kind of defeats the purpose, so 802.1w Rapid Spanning Tree was born. RSTP in essence puts into place some additional features to speed up STP reconvergence. Old-school 802.1D meant that you had to wait at least 30 seconds to get a port from blocking to forwarding, and this means that recovering from a failure takes at least that much time (sometimes more depending on other factors).
This is a specific video on Rapid Spanning Tree Synchronization.
See my full writeup on RSTP in general.
Forgive the low(er) quality of this particular video, it was recorded at an hour in the morning that frankly should not exist.
This post picks up where the previous left off. Again, a CCNP-level knowledge of STP is recommended.
So…Spanning Tree didn’t converge quickly enough for some people, and enabling PortFast everywhere kind of defeats the purpose, so 802.1w Rapid Spanning Tree was born. RSTP in essence puts into place some additional features to speed up STP reconvergence. Old-school 802.1D meant that you had to wait at least 30 seconds to get a port from blocking to forwarding, and this means that recovering from a failure takes at least that much time (sometimes more depending on other factors).
This is a video on some of the “nerd knobs” that we get to play with in a traditional spanning tree environment.
I have done a full writeup on the topic that goes along with this video - you can view this video on that page as well.
I wrote this post not only to put out some information on one of the least-understood facets of networking (especially in data center, as most technology today is aimed at making STP irrelevant) but also to help get something on paper for me, seeing as I am going down the CCIE path full force now, and this has always been a weak area of mine. This post will assume you have CCNP-level knowledge about Spanning Tree Protocol (STP).
This is a video on some of the “nerd knobs” that we get to play with in a traditional spanning tree environment.
I have done a full writeup on the topic that goes along with this video - you can view this video on that page as well.
I wrote this post not only to put out some information on one of the least-understood facets of networking (especially in data center, as most technology today is aimed at making STP irrelevant) but also to help get something on paper for me, seeing as I am going down the CCIE path full force now, and this has always been a weak area of mine. This post will assume you have CCNP-level knowledge about Spanning Tree Protocol (STP).
I mentioned in a previous post regarding the connectivity options to each blade if you’re using the appropriate hardware.
If you’re using a 2208 FEX, you have 8 upstream ports, each at 10GbE. This means the FEX can support up to 80 Gbps total. You can provide potentially 4:1 oversubscription (math later) to each blade by connecting a 2208 FEX into a blade chassis with blades that can also support 80Gbps each.
Cisco UCS offers a few policies that are applied globally to all equipment in a given UCS domain. These policies are found by selecting the “Equipment” node under the “equipment” tab. (You can also change on an individual chassis basis but the default behavior is for all chassis to inherit this global policy)
This is specifically referring to the connectivity between the Fabric Interconnects and the Chassis FEX modules or I/O modules (IOM).
I was introduced by a colleague and mentor a few years ago to the concept of powerless words. Words like “try”, “but”, and “maybe/might”, among others, seem to be our mind’s way of protecting itself against the unknown. After all, we’re only human, right? We can’t control what the world throws at us, right?
I encourage you to read the article I linked to as well as this one, which the first article refers to.
To say that Ethernet as a L2 protocol is well-known is an understatement - it’s in every PC network card, and every network closet. Back during the inception of Ethernet, the world needed an open, efficient, standardized method of communicating between nodes on a LAN. Widely regarded as the “mother of the Internet” for many reasons - not the least of which is the invention of the Spanning Tree Protocol - Radia Perlman equated the wide proliferation of Ethernet to the same events that have made English such as popular language on Earth.
Name: UltimateUCSBuild.ps1
Author: Matthew Oswalt
Created: 6/10/2013
Current Version: v0.2 (ALPHA)
Revision Date: 6/18/2013
Description:
–THIS SCRIPT IS VERY NEW, EXPECT FREQUENT CHANGES AND IMPROVEMENTS–
A script that starts with a completely blank UCS system and configures it to completion.
This version of the script is very non-modular and static, but that will change in future versions.
My long-term vision for this script is to be simple, yet powerful. I want it to have the ability to provision lots of stuff very quickly, with minimal code changes.
Keeping It Classless