I recently observed some strange behavior with Cisco UCS Manager. When I visited the web page that allows me to download the .jnlp file that launches UCSM, it came up just fine. But when I clicked on “Launch UCS Manager” to actually launch this applet, the splash screen showed briefly, but disappeared after a few seconds, never to be seen again.
Eventually, you might also see some java error messages that say something like
I’m currently working with a relatively large Cisco UCS installation. Initially, the system was installed and brought up to relatively recent levels of firmware, but a mismatch in the way that the firmware packages were set up in various sub-organizations on some of the UCS systems caused some of the blades to retain the old version of firmware on the M81KR adapters and the CIMC controllers.
Due to the scope of the installation, I wanted to ensure that the blades were able to continue operating while I made my changes.
I would like to share some tips regarding gadgets that I believe every Datacenter Network Engineer should have with them. There are several, but I want to bring up my top two.ß
Travel Router I am often in situations where it is either difficult or impossible to manage Nexus switches and/or UCS remotely. Pick your reasons - sometimes the management network doesn’t exist (yet) or there are heavy security measures in place that restrict wired management, whatever.
I would like to share some tips regarding gadgets that I believe every Datacenter Network Engineer should have with them. There are several, but I want to bring up my top two.ß
Travel Router I am often in situations where it is either difficult or impossible to manage Nexus switches and/or UCS remotely. Pick your reasons - sometimes the management network doesn’t exist (yet) or there are heavy security measures in place that restrict wired management, whatever.
Static routes can be handy in some situations where you want to do some quick and (sometimes) easy routing to get the job done, whether replacing the job that a routing protocol would perform, or redistributing the static route into that protocol.
The best way to do this would be to identify the remote subnet being routed to, and specify a next-hop IP address to send traffic to so that it can be reached.
Static routes can be handy in some situations where you want to do some quick and (sometimes) easy routing to get the job done, whether replacing the job that a routing protocol would perform, or redistributing the static route into that protocol.
The best way to do this would be to identify the remote subnet being routed to, and specify a next-hop IP address to send traffic to so that it can be reached.
I ran into a configuration recently where I had a Netapp storage array with the UTA cards installed, so there two CNA ports on each filer for a total of 4 ports. However, instead of a dual-switch design, there was only a single Nexus 5000, and therefore, no vPC configuration. I needed to achieve some level of redundancy on an interface level, but ran into some problems which I’ll discuss.
I ran into a configuration recently where I had a Netapp storage array with the UTA cards installed, so there two CNA ports on each filer for a total of 4 ports. However, instead of a dual-switch design, there was only a single Nexus 5000, and therefore, no vPC configuration. I needed to achieve some level of redundancy on an interface level, but ran into some problems which I’ll discuss.
Port-Channels, are a way of aggregating physical links together so that you can load balance traffic over each link to increase bandwidth, and create more redundancy. You might commonly see this configured between two switches, as shown below:
Each link works together to form a logical, loop-free interface. These are relatively commonplace, and in this scenario highly useful because it prohibits spanning tree from blocking one of these ports, allowing the switch to utilize each link.
Port-Channels, are a way of aggregating physical links together so that you can load balance traffic over each link to increase bandwidth, and create more redundancy. You might commonly see this configured between two switches, as shown below:
Each link works together to form a logical, loop-free interface. These are relatively commonplace, and in this scenario highly useful because it prohibits spanning tree from blocking one of these ports, allowing the switch to utilize each link.
It’s interesting to me to see the differences in infrastructure products as it pertains to out of the box, or default configuration. Take for instance, the relationship between a firewall and a switch. Your average firewall is configured “closed”, meaning that if you want to allow anything, you have to explicitly allow that certain type of traffic. If you do not, it is not allowed. A switch, on the other hand, is configured to be functional above all, out of the box.
It’s interesting to me to see the differences in infrastructure products as it pertains to out of the box, or default configuration. Take for instance, the relationship between a firewall and a switch. Your average firewall is configured “closed”, meaning that if you want to allow anything, you have to explicitly allow that certain type of traffic. If you do not, it is not allowed. A switch, on the other hand, is configured to be functional above all, out of the box.
Port mirroring is a very valuable troubleshooting tool. Cisco calls this SPAN, and it’s pretty easy to do. Cisco’s NX-OS platform does it a little differently than traditional IOS, so I wanted to briefly post a walkthrough.
First, you have to set up the monitor session and configure source and destination interfaces:
switch(config)# monitor session 1 switch(config-monitor)# source int port-channel 2 both switch(config-monitor)# source int port-channel 3 both switch(config-monitor)# destination interface ethernet 1⁄7 switch(config-monitor)# no shut switch(config-monitor)#
Port mirroring is a very valuable troubleshooting tool. Cisco calls this SPAN, and it’s pretty easy to do. Cisco’s NX-OS platform does it a little differently than traditional IOS, so I wanted to briefly post a walkthrough.
First, you have to set up the monitor session and configure source and destination interfaces:
switch(config)# monitor session 1 switch(config-monitor)# source int port-channel 2 both switch(config-monitor)# source int port-channel 3 both switch(config-monitor)# destination interface ethernet 1⁄7 switch(config-monitor)# no shut switch(config-monitor)#
I found a bug in the vHBA Template creation screen on Cisco UCS 2.0.
It’s not too bad, but still a little annoying, and can cause you to have some problems depending on how you have your VSANs set up.
If you notice, the default VSAN is selected for my vHBA template. I have named my VSANs “fabric-a” and “fabric-b”. If I drop down the VSAN selector, I have the ability to select the VSAN I have associated with fabric A:
I found a bug in the vHBA Template creation screen on Cisco UCS 2.0.
It’s not too bad, but still a little annoying, and can cause you to have some problems depending on how you have your VSANs set up.
If you notice, the default VSAN is selected for my vHBA template. I have named my VSANs “fabric-a” and “fabric-b”. If I drop down the VSAN selector, I have the ability to select the VSAN I have associated with fabric A:
Cisco switches (and the vast majority of other vendors) ship their switches with all ports in the enabled state. This allows someone with no networking background to plug stuff in, the switch starts learning MAC addresses, and everything works just fine. Sometimes it’s necessary from a security perspective to change this default behavior, so the network engineer is forced to “no shut” every port he or she wishes to use.
My time lately has been just blasted. I’m being placed into new projects with a large company that involves just about every technology found in a datacenter, and as a result, my spare time is….nonexistent.
My knowledge levels in many areas continues to increase, and my need to spew some of it onto the internet in the form of helpful posts, or opinions is not quenched, but unfortunately I do not have a ton of time to dedicate to full-on blog posts during the week.
My time lately has been just blasted. I’m being placed into new projects with a large company that involves just about every technology found in a datacenter, and as a result, my spare time is….nonexistent.
My knowledge levels in many areas continues to increase, and my need to spew some of it onto the internet in the form of helpful posts, or opinions is not quenched, but unfortunately I do not have a ton of time to dedicate to full-on blog posts during the week.
Cisco switches (and the vast majority of other vendors) ship their switches with all ports in the enabled state. This allows someone with no networking background to plug stuff in, the switch starts learning MAC addresses, and everything works just fine. Sometimes it’s necessary from a security perspective to change this default behavior, so the network engineer is forced to “no shut” every port he or she wishes to use.