When a FabricPath edge switch needs to send a frame to a remote MAC address, it performs a MAC address table lookup and finds an entry of the form SWID.SSID.LID. The SWID represents the switch-ID of the remote FabricPath edge switch, the SSID represents the sub-switch ID (which is only used in vPC+) and the LID represents the outbound port on the remote edge switch. However, the method by which these LIDs are derived doesn’t seem to be very well documented and this had been bugging me for a while. So I decided to dig in and see if I could find out a bit more about the way LIDs are used on the Nexus switches. Continue reading
As I was studying for the Troubleshooting Cisco Data Center Unified Fabric (DCUFT) exam, I came across a couple of low level NX-OS commands that can help determine whether the Data Center Bridging eXchange (DCBX) protocol is functioning correctly. Being able to verify the operation of DCBX is important when troubleshooting FCoE, because the proper operation of the Data Center Bridging (DCB) extensions is a prerequisite for FCoE.
Unfortunately, the output of these commands is rather cryptic, because it essentially shows the content of the DCBX TLVs as raw hex dumps, rather than nicely decoding the fields in the output of the command. Because I still wanted to understand how to read the DCBX information contained in these commands, I decided to dive a bit deeper into the DCBX protocol. Continue reading
Even though I am the only administrator for the devices in my lab and home network, I thought it would be nice to have some form of centralized authentication, authorization and accounting for these devices. However, I quickly realized that using a dedicated appliance such as Cisco ACS or ISE would mean adding another always-on VM to my lab environment. I wasn’t quite ready to start wasting my lab resources on a basic function like AAA. So instead of using a dedicated appliance, I decide to implement FreeRADIUS on the Ubuntu Linux server that I use for DNS, DHCP, syslog, and other network services in my lab.
Although, TACACS+ is usually the protocol of choice for Cisco AAA, my requirements are simple enough that RADIUS will work just as well. And since FreeRADIUS is included in the standard Ubuntu repositories this should be very easy to install. Continue reading
While I was working on a Nexus lab, I ran into an interesting issue that had me scratching my head for a while before I managed to figure out what was going on. You gotta love those unintentional troubleshooting exercises! This was the situation:
Now that Cisco has finally released the software for the Cisco ASA 1000v virtual security appliance, I am eager to install it and get a feel for its capabilities. However, before I can get to the fun part and start playing with the virtual ASA, I will have to upgrade the virtual infrastructure in my lab to the correct versions to support it. Primarily, this means that I will have to upgrade both the Nexus 1000v and the VNMC that I have running in my lab.
In a lab situation, the simplest way to accomplish this would be to just deploy a completely new instance of the Nexus 1000v and then restore its configuration from a backup, but I decided that it would be more educational to actually perform an upgrade from my current Nexus 1000v version 4.2(1)SV1(5.1a) to the version 4.2(1)SV1(5.2) that is required to support the ASA 1000v. According to the Cisco documentation it should be possible to perform this procedure as a hitless In-Service Software Update (ISSU), so I decide to put that to the test and see if there are any gotchas in this process.