Please note: This site is in no way affiliated with Cisco and is intended only to make light of the differences between the various aspects of their product range that causes frustration amongst some of their user-base.
cis·con·sist·en·cyNoun
1. The fact or state of being inconsistent between Cisco products.
2. An inconsistent element or an instance of being inconsistent between Cisco products.
Have you ever worked with a Cisco device? How about 2 of them? The chances are you've noticed a couple of differences between what seem like very similar devices, from obvious hardware variations to bizarre CLI output inconsistencies (or Cisconsistencies). Eventually, you'll just learn to live with them, but every now and again you're going to scream and shout and possibly destroy your keyboard: probably with a bit of post-rage embarrassment as everyone around you slowly inches away. Have a look at our collection of Cisconsistencies and and either diffuse or fuel your frustration.
Update: I've had it with the Cisco 3750 platform. Enjoy my battle stories.
'show running-config': CatOS, IOS, NXOS vs. ASA, PIX
ASA and PIX obfuscate keys and passwords when issuing 'show running-config', unlike the other OSes. I guess this is an intentional feature but the effect is that many configuration management utilities that retrieve the config interactively don't have a copy of the config you could actually restore to a device.
Workaround: 'more system:running-config', or copy the config off the box with FTP/TFTP etc. Cisco say.
Benefits: now you can actually keep a backup of your device configuration that you could restore from in the event of catastrophe.
Down-side: you lose the 'last modified by' line in the config which screws up some configuration change auditing tools.
'terminal length 0': HP switches running IOS vs. every other product running IOS
Pager length needs to be set differently on this platform. Improperly configured configuration management utilities that retrieve the config interactively are often broken by this subtlety and so choke on 'show running-config' after blindly running 'terminal length 0' expecting the pager to be disabled.
Workaround: command.
Benefits: none.
Down-side: none.
NXOS vs. NXOS: 'show interface EthX/Y transceiver detail' contains spurious alarms that disappear when you run the command a second time
Optical transceiver diagnostics (which the CLI output is quick to remind you 'are not reliable') can be seen to display low power warning indicators (--) next to power measurement values when the value itself is clearly inside normal operating thresholds which it prints in the same output. Run the same command a second time (literally: up, enter) and hey presto! The alarm is gone.
Workaround: run 'show interface EthX/Y transceiver detail' twice before reading the output?!
Benefits: none.
Down-side: annoying
4948 port buffers 0-indexed in some output, 1-indexed in others.
The output of some QoS related commands gives buffers numbered from 0, and other QoS related commands show buffers numbered from 1.
Workaround: none.
Benefits: N/A.
Down-side: N/A.
'ip http-server' vs. 'ip http server': IOS
Amongst other similar commands, these 2 variants work happily on most versions of IOS, but depending on the platform your config may not actually reflect what you typed, just like the parser won't suggest both variants on the same platform.
Workaround: N/A.
Benefits: N/A.
Down-side: N/A.
'do' vs. 'DO' in configuration mode: IOS (Bug CSCtr46734)
Every person who works with IOS should know about the 'do' command to save themselves exiting and re-entering 'conf t' when needing the output of a 'show' command to determine what the next piece of configuration should be. However, Cisco once again manage to do something inconsistent and wacky. If you use upper-case characters ANYWHERE (OK, so there are only 2 places, but this accounts for 3 of the 4 permutations) in the word while you are in a nested config block (such as 'router x y' or 'interface Ethernet1'), the parser deems it appropriate to exit this nest for you. From (config-if) to (config) by just capitalising one or both characters in the word 'do' (situation where this might happen? 'conf t', 'int Eth1', 'descr I_USED_CAPS_LOCK (MAIN VLAN)', 'DO SHO VLAN | INC MAIN', 'switchport access vlan 1'... this last command is now invalid because it's unintentionally at (config) instead of (config-if). D'oh!)
Workaround: Don't use caps-lock or accidentally capitalise 'do'?.
Benefits: I guess this could be useful if you know about it and want to save yourself typing 'exit' from a piece of nested config such as router or interface configurations.
Down-side: Unintended exiting of a mode you wanted to stay in, potentially leading to accidental configuration of something globally, or more likely an error for invalid command at the current configuration level which is a real PITA if it's copy/pasted config.
Example:
Switch(config)#int gi4/0/5
Switch(config-if)#DO
% Incomplete command.

Switch(config-if)#DO SHOW
% Type "show ?" for a list of subcommands
Switch(config)#int gi4/0/5
Switch(config-if)#do show
% Type "show ?" for a list of subcommands
Switch(config-if)#Do show
% Type "show ?" for a list of subcommands
Switch(config)#int gi4/0/5
Switch(config-if)#dO show
% Type "show ?" for a list of subcommands
Switch(config)#int gi4/0/5
Switch(config-if)#do Show
% Type "show ?" for a list of subcommands
Switch(config-if)#SWItchport access vlan 70
Switch(config-if)#
'boot system' vs. 'boot system flash': 3750 vs. Most other platforms.
The 3750, for reasons I cannot fathom (but are documented) differs from most of the other Catalyst platform products by using 'boot system bootflash:file.bin' for example, rather than 'boot system flash bootflash:file.bin'. Just one to be aware of, because it's caught me out on late-night fixing sprees.
Workaround: N/A.
Benefits: N/A.
Down-side: N/A.
'errdisable flap-setting cause link-flap flap-count' vs. 'errdisable flap-setting cause link-flap max-flap': HP Switches running IOS/CBS software.
CBS30X0 software version 12.2(40)SE2 disagrees between the CLI parser and what it generates in the config. The parser requires 'errdisable flap-setting cause link-flap max-flap' to be executed, and it dumps 'errdisable flap-setting cause link-flap flap-count' into the config. The latter isn't recognised as a valid command, and so every time the config is re-read (on boot) it is rejected and not coppied to running-config.
Workaround: Upgrade? Re-apply the 'correct' version of the command every reboot?
Benefits: None.
Down-side: Config requires manual fixing every time the switch is booted.
Example:
Switch(config)#errdisable flap-setting cause link-flap flap-count 10 time 10 ?
% Unrecognized command
Switch(config)#errdisable flap-setting cause link-flap flap-count 10 time 10
^
% Invalid input detected at '^' marker.

Switch(config)#errdisable flap-setting cause link-flap ?
max-flaps maximum flaps allowed before setting to errdisable

Switch(config)#do sho run | inc errdis
errdisable flap-setting cause link-flap flap-count 10 time 10
Switch(config)#do sho ver
Cisco IOS Software, CBS30X0 Software (CBS30X0-LANBASE-M), Version 12.2(40)SE2, RELEASE SOFTWARE (fc1)
NXOS vs. NXOS: 'show run interface <L3 interface>' sometimes omits configuration commands (Bug CSCtt01413)
You might expect that the output of the running configuration was something fairly trivial, but it turns out Cisco have managed to break it. This bizarre omission of configuration (I've seen it drop 'no shutdown' and 'description' commands, but there may be others affected) from L3 interfaces (SVIs, or 'interface VlanX') caught me out twice: once when reviewing SVI configuration between two HSRP peer 5548UPs and observing odd discrepancies that disappeared before my very eyes, and again when my configuration management server backed up the config with a 'show run', processed the diff and alerted us to the apparent removal of 'no shutdown' and 'description' commands on all the SVIs. The next change detected had these reinstated. Odd!
Workaround: None.
Benefits: None.
Down-side: annoying, potentially dangerous if relied upon for backups captured from a VTY 'interactively'.
NXOS vs. IOS: TACACS+ RemoteAddr field not populated in all cases (Bug CSCTi35651)
IOS devices populate the RemoteAddr field in TACACS authentication and authorization requests, allowing for granular permissioning. We had a use-case where ApplicationA was allowed to log into a set of devices from ServerA, while NetworkAdmins were allowed to log into the same devices only from WorkstationB. In addition, we needed NetworkAdmins to be allowed to log into the console. No other access to be permitted: NetworkAdmins not allowed to log in from ServerA. IOS populates RemoteAddr with 'async' when the console is used to trigger authentication/authorization requests. NX-OS, not so much. Authentication requests from a vty populate RemoteAddr. Authentication requests from console leave it blank. All authorization requests leave RemoteAddr blank. Great! This left us with a policy that could only authenticate based on vty IP (you can't match an empty string as a RemoteAddr value in Cisco SecureACS 5.4, not that you'd want to) and therefore denied console access, or left us with an attack vector where console-authenticated users were not authorized per-command.
Workaround: Upgrade, when they fix it. Possibly implement a local authorization configuration to apply to users, if that's possible?
Benefits: None.
Down-side: annoying, completely breaks a complex use-case where vty source, username and command are all authorized in combination.
Catalyst 4948: Interface counter might go backwards (Bug CSCuc98759)
While troubleshooting an issue with packet-loss on a circuit, we had a hard-loop applied on a DS3 circuit which had been media-converted to Ethernet and presented as copper on a Cisco Catalyst 4948. Interface counters were being inspected during ping and other traffic generation tests and it was observed at very low traffic rates that the received packet counter would occasionally be 1 higher than the transmitted packet counter, then after interrogating the counters again it would revert to being equal to the transmitted counter: 1 lower than it showed just a moment ago. Further inspection observed both the tx and rx counters increased by 1, as expected due to the OSPF hello timer that was in operation on the interface.
Workaround: Tap the link and analyse independently for accuracy.
Benefits: None.
Down-side: annoying, and I find it undermines the reliability of the device.
ASA: Performing commands on failover unit with TACACS command accounting configured fail due to passing enable_n as username (Bug CSCti22636)
Discovered when a friend and colleague was trying to verify the serial number of the failover unit in a pair of ASA5510s, this little blighter caught us out because the command executed successfully on the primary unit (verified with AAA logs), but the device output 'command authorization failed'. The command was accepted by the primary, dispatched to the failover not as his user but enable_15, and then rejected by command authorization on the failover when it consulted TACACS for the user enable_15.
Workaround: Log into the failover unit separately, upgrade the software.
Benefits: None.
Down-side: annoying.