This chapter is from the book
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.
){kind=link}
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
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.