Home > Articles > Networking > Routing & Switching

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Initial Configuration

Configuration begins with naming each switch and assigning an IP address to a management interface on each switch shown in Figure 7-2. Refer to Chapter 5, "Using Catalyst Software," for examples of setting system and host names, along with setting an enable password. Private IP addresses described in Request for Comments (RFC) 1918 will be used in all the examples in this chapter.

NOTE

RFC 1918 along with others can be viewed online at http://www.ietf.org/rfc. RFC 1918 defines private address ranges as

  • 10.0.0.0–10.255.255.255 (10/8 prefix)

  • 172.16.0.0–172.31.255.255 (172.16/12 prefix)

  • 192.168.0.0–192.168.255.255 (192.168/16 prefix)

In this chapter, addresses from the 172.16.0.0–172.31.255.255 range are used.

Before implementing any IP equipment, take the time to develop an IP addressing standard. Going back and readdressing devices in production can be quite time consuming. Although development of an IP addressing standard is beyond the scope of this book, a few important items should be considered when developing a standard, including

  • Planning the IP address space so it can be summarized, resulting in as few routes as possible being required to reach any network.

  • Determining whether private, public, or a mix of private and public addressing will be used and how.

  • Planning the IP address space to scale to the necessary number of devices. For example, assigning a network of 172.16.200.0/24 to a user VLAN on a switch provides 254 host addresses for user devices, but if 300 devices need to be supported, you must decide either to assign a second class C or /24 VLAN for the additional 46 devices or assign a larger network of 172.16.200/22.

In preparation for the configuration examples throughout the rest of this chapter, Table 7-3 provides a simple IP addressing scheme.

Table 7-3 IP Address Ranges

Function

IP Address Range

User VLANs

172.16.192–223.0 255.255.255.0

Loopback interfaces

172.16.224–239.0 255.255.255.255

Point-to-point links

172.16.240.4–252 255.255.255.252


Using the preceding ranges, IP addresses are plentiful because private addressing space is being used, but it is always a good practice to conserve addressing space whenever possible. The address ranges in Table 7-3 can all be summarized into a single 172.16.192.0/18 route advertisement.

Configuring VTP

Chapter 4 discussed the various modes and capabilities of VTP in detail. In this chapter, VTP transparent mode is used on all the example switches. A VTP domain name of Cisco is used. A VTP password is unnecessary in transparent mode but should be carefully chosen in client/server mode. Prior to Cisco IOS version 12.1(11b)E, VTP and VLANs could only be configured in VLAN database mode on IOS devices. In IOS version 12.1(11b)E and later, VTP and VLANs can be configured either in database mode or in global configuration mode. In either case, the VTP and VLAN configuration information is stored in a vlan.dat file and is not part of the running configuration. To properly back up a native IOS configuration, both the running-configuration and the vlan.dat file must be saved. CiscoWorks Resource Manager Essentials, starting with version 3.5, automatically saves the vlan.dat file. Using Examples 7-1 through 7-4, VTP is configured on each switch along with a VLAN that will be used for user devices later in the chapter.

Example 7-1 Configuring VTP Using VLAN Database Mode on SW1

SW1#vlan database
SW1(vlan)#vtp transparent
Setting device to VTP TRANSPARENT mode.
SW1(vlan)#vtp domain Cisco
Changing VTP domain name from NULL to Cisco
SW1(vlan)#vlan 110
VLAN 110 added:
  Name: VLAN0110
SW1(vlan)#exit
APPLY completed.
Exiting....
SW1#

Example 7-2 Configuring VTP Using VLAN Database Mode on SW2

SW2#vlan database
SW2(vlan)#vtp transparent
Setting device to VTP TRANSPARENT mode.
SW2(vlan)#vtp domain Cisco
Changing VTP domain name from NULL to Cisco
SW2(vlan)#vlan 120
VLAN 120 added:
  Name: VLAN0120
SW2(vlan)#exit
APPLY completed.
Exiting....

Example 7-3 Configuring VTP on SW3 in Catalyst OS

SW3 (enable) set vtp mode transparent
VTP domain modified
SW3 (enable) set vtp domain Cisco
VTP domain Cisco modified
SW3 (enable) set vlan 130
Vlan 130 configuration successful
SW3 (enable)

Example 7-4 Configuring VTP on SW4 in Global Configuration Mode

SW4#config t
Enter configuration commands, one per line. End with CNTL/Z.
SW4(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
SW4(config)#vtp domain Cisco
Changing VTP domain name from NULL to Cisco
SW4(config)#vlan 140
SW4(config-vlan)#end
SW4#

When created, you can delete VLANs one at a time using either a clear command in Catalyst OS or the no form of the VLAN command in IOS. To delete all VTP and VLAN information in Catalyst OS, you can use the clear config all command. Although there is no vlan.dat file in Catalyst OS, the vlan.dat file is stored in NVRAM on Catalyst 6000/6500s in const_nvram: and 4000/4500s running native in cat4000_flash:. To delete all VTP and VLAN information in native IOS on the Catalyst 6000/6500, use the erase const_nvram: command. On the Catalyst 4000/4500 running native IOS, use the erase cat4000_flash:. As shown in Example 7-5, vlan.dat files can be copied to flash or to a TFTP server using the copy command.

Example 7-5 Copying vlan.dat to Flash in Slot0:

SW1#copy const_nvram:
SW1#copy const_nvram:vlan.dat slot0:
Destination filename [vlan.dat]?
660 bytes copied in 0.328 secs

Configuring sc0 and LO0

Because SW3 is running hybrid, it will be configured with both a sc0 management interface in Catalyst OS and a Loopback 0 (LO0) interface in IOS on the Route Switch Module (RSM). Figure 7-3 shows the management interfaces assigned to each of the four switches.

Figure 3Figure 7-3 IP Addresses Assigned to Management Interfaces

To prevent the use of a separate VLAN for switch management, the choice is made to place the sc0 interface in the user VLAN 130. Switches 1, 2, and 4 running native IOS are configured with only a Loopback interface (LO0), just like any other Cisco router. The primary benefit of a loopback interface is that it never goes down unless manually shut down. Example 7-6 shows the configuration of LO0 on SW1.

Example 7-6 Configuring LO0 on SW1 (Native)

SW1#config t
1w5d: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#interface loopback0
SW1(config-if)#ip address 172.16.224.1 255.255.255.255
SW1(config-if)#end
1w5d: %SYS-5-CONFIG_I: Configured from console by console
SW1#show interface loopback0
Loopback0 is up, line protocol is up
 Hardware is Loopback
 Internet address is 172.16.224.1/32
 MTU 1514 bytes, BW 8000000 Kbit, DLY 5000 usec,
   reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation LOOPBACK, loopback not set
 Last input never, output never, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue :0/0 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
 L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
 L3 out Switched: ucast: 0 pkt, 0 bytes
   0 packets input, 0 bytes, 0 no buffer
   Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
   0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
   0 packets output, 0 bytes, 0 underruns
   0 output errors, 0 collisions, 0 interface resets
   0 output buffer failures, 0 output buffers swapped out
SW1#

In Example 7-6, an IP address of 172.16.224.1 is assigned using a 32-bit subnet mask. The output of the show interface loopback0 command shows the interface in the UP/UP state. Because this is a loopback, the interface will show up even though no connectivity to the switch exists, and the loopback interface is, at the moment, unreachable. Example 7-7 shows the configuration of LO0 on SW2.

In Example 7-8, sc0 is assigned an IP address of 172.16.196.5/24 in VLAN 130. The default route added for sc0 will eventually point to the IP address of the VLAN 130 interface on the RSM.

Example 7-7 Configuring LO0 on SW2 (Native)

SW2#config t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#interface loopback0
SW2(config-if)#ip address 172.16.225.1 255.255.255.255
SW2(config-if)#end

Example 7-8 Configuring sc0 on SW3 (Hybrid-Catalyst OS)

SW3> (enable) set int sc0 130 172.16.196.5 255.255.255.0
Interface sc0 vlan set, IP address and netmask set.
SW3> (enable) set ip route default 172.16.196.1
Route added.

Example 7-9 shows the configuration of LO0 on SW3.

Example 7-9 Configuring LO0 on SW3 (Hybrid-IOS)

SW3 (enable) show module
Mod Module-Name     Ports Module-Type      Model  Serial-Num Status
--- ------------------- ----- --------------------- --------- --------- -------
1            0   Supervisor III    WS-X5530 030061500 faulty
3            1   Route Switch     WS-X5304 006578507 ok
4            24  10/100BaseTX Ethernet WS-X5224 009607843 ok
6            12  100BaseTX Ethernet  WS-X5113 002503515 ok
7            24  10/100BaseTX Ethernet WS-X5234 019554483 ok
8            24  10/100BaseTX Ethernet WS-X5225R 013458239 ok
13              ASP/SRP

Mod MAC-Address(es)            Hw   Fw     Sw
--- -------------------------------------- ------ ---------- -----------------
1  00-90-86-66-50-00 to 00-90-86-66-53-ff 3.5  5.1(2)   4.5(5)
3  00-e0-1e-91-b9-7c to 00-e0-1e-91-b9-7d 7.7  20.22   12.2(10a)
4  00-10-7b-78-57-00 to 00-10-7b-78-57-17 1.4  3.1(1)   4.5(5)
6  00-40-0b-b0-95-40 to 00-40-0b-b0-95-4b 1.2  1.2    4.5(5)
7  00-30-7b-b7-77-00 to 00-30-7b-b7-77-17 1.0  4.5(2)   4.5(5)
8  00-d0-06-9b-83-10 to 00-d0-06-9b-83-27 3.3  4.3(1)   4.5(5)

Mod Sub-Type Sub-Model Sub-Serial Sub-Hw
--- -------- --------- ---------- ------
1  NFFC II WS-F5531A 0030060943 2.2
SW3 (enable) session 3
Trying Router-3...
Connected to Router-3.
Escape character is '^]'.

RSM1>en
RSM1#config t
Enter configuration commands, one per line. End with CNTL/Z.
RSM1(config)#int loopback0
RSM1(config-if)#ip address 172.16.226.1 255.255.255.255
RSM1(config-if)#end
RSM1#sh interface loopback0
Loopback0 is up, line protocol is up
 Hardware is Loopback
 Internet address is 172.16.226.1/32
 MTU 1514 bytes, BW 8000000 Kbit, DLY 5000 usec,
   reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation LOOPBACK, loopback not set
 Last input never, output never, output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue :0/0 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
   0 packets input, 0 bytes, 0 no buffer
   Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
   0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
   0 packets output, 0 bytes, 0 underruns
   0 output errors, 0 collisions, 0 interface resets
   0 output buffer failures, 0 output buffers swapped out
RSM1#

In Examples 7-8 and 7-9, the switch is running hybrid Catalyst OS/IOS and the connection is to the console port on the supervisor. The first step is to determine in which slot the RSM is installed, and then session to the RSM. In this case, the RSM is installed in slot 3. After a session to the module in slot 3 is established, the loopback interface is configured the same way as in native. (See Example 7-10.)

Example 7-10 Configuring LO0 on SW4 (Native)

SW4(config)#interface loopback0
SW4(config-if)#ip address 172.16.227.1 255.255.255.255
SW4(config-if)#end
SW4#

In each of the loopback configuration examples, the loopback interface is administratively up and the line protocol is up even though no active ports are configured on the switch. This again is because loopback interfaces are special and cannot go down unless administratively shut down. This is not true for VLAN interfaces because of a feature called autostate. It is important to understand how autostate operates, as you learn in the next section.

Autostate

Hybrid and native switches have a feature called autostate. The feature is enabled by default and can only be disabled in hybrid. In hybrid, logical VLAN interfaces configured on the RSM/RSFC, MSFC, or Layer 3 module on the Catalyst 4000 rely on ports in Catalyst OS to be active in the same VLANs before communication is possible. For example, it is possible to configure a VLAN interface on an MSFC for VLAN 100 without any switchports in Catalyst OS belonging to VLAN 100, or VLAN 100 even being defined in Catalyst OS for that matter. Because this is possible, the Cisco IOS portion of the hybrid configuration attempts to prevent a routing "black hole" by placing the VLAN interface in a down/down state. After one or more active ports or a trunk is configured in the same VLAN as the interface in Cisco IOS, the VLAN interface changes to an up/up state. This checking mechanism is the result of the autostate feature. One exception to this feature is for the VLAN assigned to the management interface (sc0) on the switch. The sc0 interface can be shut down administratively.

To further prevent black holes, the autostate feature on the Catalyst 6000/6500 waits for the valid Layer 2 port(s) to transition into a forwarding state before allowing the Layer 3 VLAN interface to transition to an UP/UP state. The autostate on the Catalyst 6000/6500 feature began synchronizing with spanning tree in this way starting in 5.5(10) and 6.1(1) Catalyst OS software.

The commands in Example 7-11 disable autostate depending on the platform.

Example 7-11 Disabling Autostate on Catalyst 6000/6500 Hybrid

Switch (enable) set msfcautostate disable 
Switch (enable) show msfcautostate
MSFC Auto port state: disabled
Switch (enable)

A Catalyst 6000/6500 with dual MSFCs would require autostate to be disabled to allow traffic to flow between the MSFCs on that VLAN if no active ports existed. In most situations, this is not necessary, and autostate should be enabled unless a specific need exists to disable it. Example 7-12 shows autostate being disabled on a Catalyst 5500 with an RSM.

Example 7-12 Disabling Autostate on Catalyst 5000/5500 with RSM

Switch (enable) set rsmautostate disable 
RSM port auto state disabled.
Switch (enable) show rsmautostate
RSM Auto port state: disabled
Multi-RSM Option: enabled
Switch (enable)

If autostate is enabled and no active ports exist on a specific VLAN in the switch, the interface on the RSM remains up if there is more than one RSM. Essentially, the RSMs see each other's interfaces as valid. This allows traffic to flow between the two RSMs on that VLAN without disabling the autostate feature. The autostate feature is enhanced for multi-RSM configurations starting in 6.1(2) Catalyst OS software. Multi-RSM allows the interfaces on two RSMs to go down when the last active port on that VLAN in the switch goes down. Example 7-13 shows autostate being disabled on a Catalyst 4000 using hybrid software.

Example 7-13 Disabling Autostate on Catalyst 4000 Hybrid with a Layer 3 Module

Router#autostate disable
Disabling Autostate
Router#show autostate entries 
Autostate Feature is currently disabled on the system.

System Logging

Cisco devices including Catalyst switches generate a variety of system messages for events such as changes in interface status, environmental conditions, parity memory errors, and security alerts. These messages are displayed on the system console by default. Console logging is a high-priority task in Cisco IOS, and, in some cases, enough console messages can effectively hang the router or switch and render the console unusable. Cisco recommends disabling console and monitor logging and configuring the switch or router to send console messages to an internal buffer that is adjustable in size. Disabling monitor logging prevents system messages from being displayed on terminal lines. Table 7-4 lists the levels of syslog messages supported on a Cisco device.

Table 7-4 Syslog Severity Levels, Types, and Descriptions

Severity Level

Severity Type

Description

0

Emergencies

System unusable

1

Alerts

Immediate action is required

2

Critical

Critical condition

3

Errors

Error conditions

4

Warnings

Warning conditions

5

Notifications

Normal, but significant condition

6

Informational

Informational messages

7

Debug

Debugging messages


Examples 7-14 and 7-15 show console logging being disabled and logging to a buffer being enabled on both native and hybrid software.

Example 7-14 Disabling Console and Monitor Logging and Enabling Logging Buffered (Native)

SW1(config)#no logging console
SW1(config)#no logging monitor
SW1(config)#logging buffered 16384
SW1(config)#end
SW1#

Example 7-15 Disabling Console and Monitor Logging and Enabling Logging Buffered (Hybrid-Catalyst OS)

SW3> (enable) set logging console disable
System logging messages will not be sent to the console.
SW3> (enable) set logging buffer 500
System logging buffer size set to <500>
SW3> (enable)

The logging buffers in Examples 7-14 and 7-15 are specified in bytes and are circular, meaning the oldest log messages will be overwritten by the newest messages after the buffer is full. The maximum logging buffer size in Catalyst OS is 500 bytes. To view the contents of the logging buffer, use the show log command. One problem with relying only on the logging buffer is that it is wiped clean during a reload. A more effective solution for logging system messages is the addition of a syslog server. A syslog server is simply a machine running a syslog daemon conforming to the Berkley Standard Distribution (BSD) standard. A syslog server stores the messages in the order received for later viewing. Many network management tools such as CiscoWorks and HP Openview can operate as a syslog server. In larger environments, it is generally recommended to set up a dedicated syslog server because of the number of messages that can be generated each day by dozens or hundreds of Cisco devices. Example 7-16 shows the configuration of logging to a syslog server using native software.

Example 7-16 Completing the Logging Configuration (Native)

SW1#config t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#logging 10.10.10.1
SW1(config)#logging facility local7
SW1(config)#logging trap notifications
SW1(config)#logging source-interface lo0
SW1(config)#

In Example 7-16, the switch is pointed to a syslog server at IP address 10.10.10.1 and sets the default logging facility for logging. The syslog server specified should also be set for the same facility/level. The switch is configured to send notification level (5) messages and above to the syslog server and not send informational and debug level (6 and 7, respectively) messages because of the sheer number of level 6 and 7 messages generated during operation. Finally, the switch is configured to send log messages with a source address of loopback0. Example 7-17 shows the configuration of logging to a syslog server using hybrid software.

Example 7-17 Completing the Logging Configuration (Hybrid-Catalyst OS)

SW3> (enable) set logging server 10.10.10.1
10.10.10.1 added to System logging server table.

In Example 7-17, the switch is pointed to the same syslog server at 10.10.10.1. Catalyst OS does not support a loopback interface and log messages are sent with a source address of sc0.

By default, syslog messages are not time stamped. This can cause major issues when attempting to troubleshoot the switch because not knowing when the message occurred can sometimes render the messages almost useless. In Example 7-18, a switch running native software is configured for time stamping of syslog messages and system debug messages.

Example 7-18 Configuring Debug and Log Message Time Stamps (Native)

SW1#config t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#service timestamps debug datetime localtime show-timezone msec
SW1(config)#service timestamps log datetime localtime show-timezone msec
SW1(config)#end
SW1#

In Example 7-19, a switch running hybrid software is configured for time stamping of syslog messages and system debug messages.

Example 7-19 Configuring Log Message Time Stamps (Hybrid-Catalyst OS)

SW3> (enable) set logging timestamp enable
System logging messages timestamp will be enabled. 

NOTE

A discussion of external time sources is beyond the scope of this book. You should reference documentation on the Network Time Protocol (NTP) on Cisco.com, along with publicly available information on the types of time sources that can be purchased for or accessed in networking environments.

Logging levels can be adjusted in both Catalyst OS and Cisco IOS for a wide variety of facilities or features. For example, spanning tree in Catalyst OS defaults to generating log messages for level 2 and higher, but is many times adjusted to level 6 so that more information is recorded during spanning-tree changes. Consult the Cisco web page at Cisco.com for a complete listing of facilities and their default levels for each platform and operating system.

  • + Share This
  • 🔖 Save To Your Account