Hello, writing a quick post based on my recent experience implementing a pair of Nexus 3548 switches. To this point I’ve only had experience with Catalyst switches and while the Nexus OS functions similarly, there were quite a few differences that made going back and forth between the two platforms a little challenging. First, just a few little things…
- You can run a “show run” or “ping” commands from global config without using “do”. This was kind of cool, but sure made life harder when I went back to a Catalyst switch. I ended up using “do” anyway just to keep my commands consistent.
- No “logging synchronous” command available on “con” or “line vty”.. Huh? This was probably one of my favorite features and I was sad to not see it available in the version of the Nexus OS I was using.
- You need to use quotes when filtering output.. For example this would work on a Catalyst switch “do show run | i Interface Gi.. What I found with the Nexus OS is that you needed to wrap the filter in quotes if there were spaces.. Ie.. do show run | i “Interface Eth”
- Some features in Nexus OS are not enabled by default. For example if you want to use LACP port channels or lldp, these features have to be enabled first with the “feature lacp” and “feature lldp” commands.
- Nexus OS (at least on this model) doesn’t support VTP. I was a bit floored that this wasn’t supported. Why Cisco? You can enable the VTP feature, but it will only operate in transparent mode.
- Firmware upgrades require a “kickstart” file and a “system” file. They both need to be the same version. Again quite a bit different from the Catalyst switches. At first I tried to just upload a new “system” file, but it wouldn’t work unless I had both and they needed to be part of the same revision. Also, uploading via TFTP was EXTREMELY slow. I ended up having much better luck just throwing the firmware files on a USB stick and connecting the stick directly to the USB port on the front of the switch. You can “dir” through the USB storage and copy the files to local flash.
Configure Jumbo frames
This process was completely different than I’ve seen before.. I used the following commands to globally enable Jumbo frames support across every VLAN and switchport. Credit to this Link for config tip.
policy-map type network-qos jumbo class type network-qos class-default mtu 9216 system qos service-policy type network-qos jumbo
Virtual Port Channel
Among one of the most interesting features I discovered with the Nexus switches was the Virtual Port Channel. Basically because these devices aren’t stacked, you would lose the ability to span Port Channels across the two switches like you would with a traditional Catalyst stack. Virtual Port Channel answers this and allows for ports from each switch to be part of the same Port Channel. I am using this for redundant links up to our existing Catalyst stack, all ports stay in the forwarding state. Perhaps the best article I found on this configuration was here.
So I am sure that I am not alone when I say that licensing across the industry of products is usually a huge pain. originally we had ordered a pair of Nexus 3524 switches and I was surprised when a couple of 48 port switches showed up. In fact, I reported it to our reseller and almost started an RMA before we discovered the product was actually correct. Cisco sells a 24 port license, but ships the 48 port chassis and uses the “honor” system to ensure you buy a license when need comes up for that 25th port. All ports function, there didn’t appear to be any restrictions and the 24 port license was installed by Cisco before they shipped.
Thanks for reading!