By Thomas Chipman
You’ve configured countless Cisco routers and switches over the years. Navigating through configuration mode has become a breeze thanks to abbreviated commands and memorized defaults. What was once a systematic, deliberate, and almost tedious configuration methodology learned back in your CCNA days has gradually evolved into something considerably more streamlined and efficient— something shorter, faster, better. But is it really? Is it really “better”?
Despite the appearance of uniformity that Cisco presents across its product lines, experience will undoubtedly show you a frustrating number of inconsistencies between the default settings on various hardware platforms and even software revisions. Too often we can find ourselves getting burned by the inconsistencies and ultimately learning that nothing is a better tutor than pain.
Take for example the default automatic summarization setting for an Enhanced Interior Gateway Routing Protocol (EIGRP) Autonomous System (AS) configured on a 2800 series Integrated Services Router running IOS revision 15.0. Will the routing process automatically summarize routes on their classful bit boundaries or will it not? If you know the correct default behavior, that’s one less command you’ll need to enter when configuring EIGRP on that particular router; however, if you’re wrong, you might just break your network.
You would think that Cisco’s documentation would give us an easy enough answer, but often even the vendor documentation doesn’t exactly make things as clear as one would expect. To continue our automatic summarization example, Cisco mentions the default behavior in the Cisco IOS IP Routing: EIGRP Command Reference as follows:
Command Default
The behavior of this command is enabled by default (the software does not send subprefix routing information across classful network boundaries).
Cisco IOS Release 15.0(1)M, 12.2(33)SRE, 12.2(33)XNE, Cisco IOS XE Release 2.5, Cisco IOS Release 12.2(33)SXI4 and Later Releases
The behavior of this command is disabled by default (the software sends subprefix routing information across classful network boundaries).
Clear as mud, right? So is automatic summarization enabled or disabled by default? Maybe we just need another reference? Let’s take a look at what Cisco says about automatic summarization in IP Routing: EIGRP Configuration Guide, Cisco IOS Release 15M&T:
Route Summarization
You can configure EIGRP to perform automatic summarization of subnet routes into network-level routes. For example, you can configure subnet 172.16.1.0 to be advertised as 172.16.0.0 over interfaces that have been configured with subnets of 192.168.7.0. Automatic summarization is performed when two or more network router configuration or address family configuration commands are configured for an EIGRP process. This feature is enabled by default.
Clear enough yet? Is it clear enough to take a chance on the default setting rather than just entering the no auto summary command to be certain of the behavior?
Many of the apparent inconsistencies can easily be mitigated by simply not assuming any relevant, default behaviors during the configuration process. Although it may take more time and might even feel “less efficient,” it is far better to issue an “extra” command that mimics the default behavior on a particular platform than it is to discover that the default wasn’t quite what you thought it was when that device ends up breaking your production environment.
“Oh, but I’m safe. All of my hardware is from the same platform or runs the same software revision,” you say. OK, let’s look at another scenario. Let’s say you work for an organization that has a remote site with a Cisco Catalyst 2960 series switch. This site has requested a second Catalyst 2960 switch and you have been tasked with configuring the switch in your staging environment, boxing it up, and sending it out to the remote site for installation. Your organization only uses Catalyst 2900 series switches, so you feel pretty comfortable with them. You even have a Catalyst 2950 series switch in the staging area that you can use to verify the operation of the Catalyst 2960 switch before shipping it off.
The remote site has requested that you configure the FastEthernet 0/12 interface on the new switch to dynamically form a trunk link with the existing switch upon installation. OK, no sweat. Cisco switches come preconfigured to dynamically form trunk links. All you’ve got to do is ensure that the Virtual Trunking Protocol (VTP) settings are correct and the switch will take care of the rest, right? That assumption depends entirely on the default trunking behavior of each switch. So what is the default trunking mode for FastEthernet interfaces on the Catalyst 2900 series switches?
You know from experience that the default trunking mode on the Catalyst 2950 in your staging area is dynamic desirable. You can even confirm it with the show interface FastEthernet 0/12 switchport command and with a quick glance at the command reference.
Ok, so let’s ride the default, configure VTP and whatever else has been specified by the remote site, and verify the new switch’s operation. The show interface FastEthernet 0/12 trunk command output from the new switch shows that everything is working as expected and that the new switch has happily formed a trunk link with the staging area switch:
NewSwitch#show interface fastethernet 0/12 trunk
Port Mode Encapsulation Status Native
vlan
Fa0/12 auto 802.1q trunking 1
You can see similar command output if you issue the show interface FastEthernet 0/12 trunk command on the staging area switch:
Staging#show interface fastethernet 0/12 trunk
Port Mode Encapsulation Status Native
vlan
Fa0/12 desirable 802.1q trunking 1
So are you confident enough to save the configuration of the new switch, box it up, and ship it off? Let’s say that you are. You will likely be surprised to find that the new switch will fail to establish a trunk link with its neighbor upon installation at the remote site. Why? Because although both the Catalyst 2950 and 2960 series switches are from the same family, they have wildly different default behaviors when it comes to forming trunk links.
The Catalyst 2960 and 2960 -S Switch Command Reference tells us that the default trunking mode on a Catalyst 2960 series switch is dynamic auto, which is a mode that will prevent the switch from actively initiating a trunk link with a neighbor. However, a switch port configured in dynamic auto mode will form a trunk link if the neighboring switch is configured for either dynamic desirable or trunk mode. Unfortunately for us, both the old switch and the new switch are configured with their default trunking behavior, so no trunk link will be formed.
This scenario demonstrates the darker side of relying on default behaviors in the Cisco world. Hopefully they have shown that skipping relevant default configuration settings is not the hallmark of a seasoned network engineer. Instead, it is often the sign of impatience and inexperience. The stereotypical crusty old network guru has been burned enough by defaults in the past to know they should never be trusted. In fact, most of the engineers I know will go out of their way to confirm default settings and disable automatic configuration protocols. Not because they are control freaks (OK, so most of them are) or because they fear automation, but because experience has taught them not to rely on their operation. The time that is generally saved by omitting commands that are assumed to be default behaviors is rarely enough to warrant the risk of error and the resulting time lost in troubleshooting and correcting the misconfiguration.
“But I’m not a seasoned network engineer, I’m just some cat trying to make my way through Cisco’s certification program,” you might say. Well then, these examples should be even more relevant to helping you ensure success as you embark on your certification journey. You will encounter many simulations in the exams that make up your certification path, and in every one of those simulations, Cisco will be evaluating your command-line decisions. Never skip a command in a simulation on the live exam because you think it is a default setting. It is always better to have issued an extra command or two and to be certain of your configuration than it is to have mistakenly relied on what you thought were default settings. It can be crushing to fail an exam by only a few points and even more so if those few points were from the lack of a “default” configuration command. The few seconds of time you save completing the simulation are simply not worth the risk.
Studying for CCENT, CCNA or CCNP exams? Download the NetSim Network Simulator® and try our demo labs!
