Since Cisco announced the Nexus 7000, I have seen and heard quite a lot of criticism of NX-OS, often on the basis that it will force engineers to learn a whole new CLI. But Cisco believe that NX-OS is ‘IOS-like', and that engineers have nothing to worry about. So, what's the truth?
I've had access to NX-OS for a few weeks now, and initially at least I had no manuals. I decided to test just how 'IOS-like' NX-OS is.
My rough-and-ready test consisted of using standard IOS commands to configure a wide variety of layer-2 and layer-3 features and functions. In this blog post, I'll share a small but representative sample - just enough to get the flavor of NX-OS.
First, the 'show version' command to verify the OS version:
Mark-Nexus01# show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2008, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
loader: version N/A
kickstart: version 4.0(1)
system: version 4.0(1) [gdb]
<output omitted>
So, I'm using NX-OS version 4.0(1).
Next, I attempted to configure a number of basic layer-2 features using standard IOS commands:
1 a couple of VLANs
2. an access/edge port
3. a trunk port
This is how things went:
Configuring VLANs:
Mark-Nexus01(config)# vlan 2
Mark-Nexus01(config-vlan)# name testvlan
Mark-Nexus01(config-vlan)# vlan 3
Mark-Nexus01(config-vlan)# name anothertestvlan
Mark-Nexus01(config-vlan)#
Configuring an Access Port:
Mark-Nexus01#
Mark-Nexus01# conf t
Mark-Nexus01(config)# interface ethernet 2/2
Mark-Nexus01(config-if)# switchport
Mark-Nexus01(config-if)# switchport mode access
Mark-Nexus01(config-if)# switchport access vlan 3
Mark-Nexus01(config-if)# spanning-tree portfast
Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on Ethernet2/2 but will only
have effect when the interface is in a non-trunking mode.
Mark-Nexus01(config-if)# no shut
Mark-Nexus01(config-if)#
Mark-Nexus01#
Configuring a Trunk:
Mark-Nexus01# conf t
Mark-Nexus01(config)# interface ethernet 2/6
Mark-Nexus01(config-if)# switchport
Mark-Nexus01(config-if)# switchport mode trunk
Mark-Nexus01(config-if)# switchport trunk allowed vlan all
Mark-Nexus01(config-if)# switchport trunk native vlan 2
Mark-Nexus01(config-if)#
Mark-Nexus01#
Pretty successful - just about all standard IOS commands used to configure layer-2 features work.
So far so good. But how about layer-3?
For this part of my rough test of the similarities between NX-OS and IOS, I attempted to configure the following:
1. an IP address
2. a static route
3. basic OSPF
4. basic HSRP
Configuring an IP Address:
Mark-Nexus01#
Mark-Nexus01# conf t
Mark-Nexus01(config)# int eth 2/6
Mark-Nexus01(config-if)# no switchport
Mark-Nexus01(config-if)# ip address 10.10.10.1 255.255.255.0
Mark-Nexus01(config-if)#
Configuring a Static Route:
Mark-Nexus01# conf t
Mark-Nexus01(config)# ip route 172.16.10.0 255.255.255.0 10.10.10.2
Configuring Basic OSPF:
Mark-Nexus01(config)# router ospf 1
^
% invalid command detected at '^' marker.
Mark-Nexus01(config)# feature ?
bgp Enable/Disable Border Gateway Protocol (BGP)
cts Enable/Disable CTS
dhcp Enable/Disable DHCP Snooping
dot1x Enable/Disable dot1x
eigrp Enable/Disable Enhanced Interior Gateway Routing Protocol
(EIGRP)
eou Enable/Disable eou(l2nac)
glbp Enable/Disable Gateway Load Balancing Protocol (GLBP)
hsrp Enable/Disable Hot Standby Router Protocol (HSRP)
interface-vlan Enable/Disable interface vlan
isis Enable/Disable IS-IS Unicast Routing Protocol (IS-IS)
lacp Enable/Disable LACP
msdp Enable/Disable Multicast Source Discovery Protocol (MSDP)
netflow Enable/Disable NetFlow
ospf Enable/Disable Open Shortest Path First Protocol (OSPF)
<output omitted>
Mark-Nexus01(config)# feature ospf
Mark-Nexus01(config)# router ospf 100
Mark-Nexus01(config-router)# network 10.10.10.0 0.0.0.255 area 0
Mark-Nexus01(config-router)# network 10.10.20.0 0.0.0.255 area 1
Mark-Nexus01(config-router)# network 10.10.30.0 0.0.0.255 area 2
Mark-Nexus01(config-router)# area 2 stub no-summary
Mark-Nexus01(config-router)#
Configuring HSRP:
Mark-Nexus01(config)# int eth 2/6
Mark-Nexus01(config-if)# standby 1 ip 10.10.10.5
^
% invalid command detected at '^' marker.
Mark-Nexus01(config-if)#
Mark-Nexus01(config)#
Mark-Nexus01(config)# feature hsrp
Mark-Nexus01(config)# int eth 2/6
Mark-Nexus01(config-if)# standby 1 ip 10.10.10.5
^
% invalid command detected at '^' marker.
Mark-Nexus01(config-if)# hsrp ?
<0-4095> Group number
delay HSRP initialisation delay
use-bia HSRP uses interface's burned in address
version HSRP version
Mark-Nexus01(config-if)# hsrp 1 ?
<CR>
Mark-Nexus01(config-if)# hsrp 1
Mark-Nexus01(config-if-hsrp)# ?
authentication Authentication
exit Exit from command interpreter
ip Enable HSRP IPv4 and set the virtual IP address
mac-address Virtual MAC address
name Redundancy name string
no Negate a command or set its defaults
preempt Overthrow lower priority Active routers
priority Priority level
timers Hello and hold timers
track Associates track object to HSRP group
Mark-Nexus01(config-if-hsrp)# ip 10.10.10.5
Mark-Nexus01(config-if-hsrp)# preempt
Mark-Nexus01(config-if-hsrp)#
Mark-Nexus01#
That's it. As you can see, I had a bit of trouble with OSPF until I discovered the ‘feature' command. In addition, there is a difference in the command syntax for HSRP - but I found the new commands very quickly, and they are more intuitive, in my opinion.
Cisco say that NX-OS CLI is IOS-like. I disagree - it's VERY IOS-like. So, engineers fluent in IOS will feel right at home.
Pretty much all the familiar commands work in NX-OS, and if any engineer feels the urge to learn faster more efficient ways of doing things then NX-OS also provides many commands that will make their lives just that bit easier. And then there are lots of new features to discover as well.
In summary, I like NX-OS, and I think anyone who likes IOS will like it as well. Still, there are one or two deficiencies:
Mark-Nexus01# wr t
^
% invalid command detected at '^' marker.
% Invalid command
Mark-Nexus01#
But hopefully Cisco can fix that in version 4.0(2) :-)
Over the next few weeks, I'll be blogging some more on the new features that can be found in NX-OS (as well as blogging on a number of other subjects).
Mark
Mark Lewis (CCIE#6280) is an independent consultant who helps service provider and large enterprise clients design and implement leading-edge technologies. Over the last couple of years, Mark has designed and implemented a variety of large-scale technology solutions including VPN, MPLS, QoS, data center, and IP telephony. Mark is the author of three books for Cisco Press: Comparing, Designing, and Deploying VPNs, Troubleshooting Virtual Private Networks, and CCIE Voice Exam Quick Reference Sheets.
The opinions expressed in this Weblog are those of the writer and may not represent the opinions of Network World.
|
|
'wr t'
perhaps not a solution for your "wr t" (i prefer "show run" anyway), but NX-OS does have aliases which can give you a 'wr' as an equivalent of 'copy running-config startup-config':
no need to wait until 4.0(2). :)
cheers.
Wow.
I have an HP that can do that too! Now that we've IP'ed the device, please copy over some large ACLs. Of course, we all know the value of online diagnostics -- does your existing monitoring of CISCO-ENTITY-DIAG-MIB work? Passing compliance tests is important too! Can you use the same device hardening scripts and audit rules?
This isn't IOS and only attempts to ape it. Given Cisco's track record, I'm highly skeptical that we'll see nuance-compatible features between it and IOS (they can't even agree on whether call-home has a dash in it). Instead each BU gets to individually decide which are of interest to reimplement on each platform. The split of the 6500 and 7600 has been such a great source of customer goodwill that I'm sure this can only be better.
Cisco's falling over themselves convincing the world that this-is-really-just-like-IOS-really, in which case why bother? If there was a strategy to merge them, then that's great, but instead we get all the fun of a multi-OS environment but without the value. (If my new girlfriend is so much like the last one that you promise I won't know the difference, why change?)
Make it different, but make it better.
I'm not sure about dating either IOS or NX-OS (though ASA is right out, for sure), however I get the point...
The HSRP configuration is a great example. Renaming it makes sense (with the presence of GLBP, VRRP, etc) and the options have grown to the point that a sub-config mode is reasonable. Now, when can similar IOS behavior be expected? How about when the next FHRP is implemented, will it be consistent?
(I couldn't help but notice the workaround for the absense of 'wr t' highlights yet another item).
Your tripping across 'feature ' is another good case; the explicit enabling and disabling of functionality is great, but where was the indication that this needed to be done other than the CLI's simply not existing (which we can now expect to sometimes be what IOS calls it, and other times something else based on apparently little more than a whim). It reinforces most of my impressions so far of Nexus -- its a very cool platform with some incredibly neat stuff (I look forward to more attention paid to things like the preliminary
802.1Qaqbridging, which is a breath of fresh air), but somewhere along the way Cisco fell into the trap their 'advanced services' products usually do -- an elegant, smooth transition.With regards to the CLI's, my concern isn't that its "something new", its that its not something new, but slightly different enough to draw you into thinking of doing things the same way, without any radical value-add. Consider the widely touted restartable processes, ISSU, patching, etc -- in what ways does this differ/exceed functionality that we've already seen the presentations on from 12.2SR and modular 12.2SX?
write t? ho man, its been
write t? ho man, its been years since i've seen that. actually, i didnt think people used that any more.
Clean, polished OS for a datacenter switch
If 3.2 was any indication, I can't wait to replace IOS-based devices! Clearly some spit and polish on CLI's are all that's needed.
2008 Apr 14 06:19:40 sanos-test %KERN-3-SYSTEM_MSG: Aborting journal on device ide1(22,3).
2008 Apr 14 06:19:45 sanos-test %KERN-2-SYSTEM_MSG: ext3_abort called.
2008 Apr 14 06:19:45 sanos-test %KERN-2-SYSTEM_MSG: EXT3-fs abort (device ide1(22,3)): ext3_journal_start: Detected aborted journal
2008 Apr 14 06:19:45 sanos-test %KERN-2-SYSTEM_MSG: Remounting filesystem read-only
2008 Apr 14 06:42:08 sanos-test %DAEMON-3-SYSTEM_MSG: ntp:can't open /mnt/pss/ntp.drift.TEMP: Read-only file system
2008 Apr 14 09:48:09 sanos-test %VSHD-5-VSHD_SYSLOG_CONFIG_I: Configuring console from pts/0 192.0.2.1
2008 Apr 14 09:48:09 sanos-test %PSS-0-PSS_WRITE_LOG_FAILURE: zone: failed to write log: Read-only file system
Post new comment