Scenario 10-2: Troubleshooting Workstation Startup Problems

A very common issue with switched networks is a lack of initial LAN connectivity when workstations are powered on or rebooted. Core network devices such as routers, switches, and servers are rarely powered off or rebooted. Workstations are often powered down or rebooted at least once a day, which means that the problem is much more apparent to workstation users. Workstations also typically boot much faster than servers, to the extent that you might have a user expecting access to the network in a matter of seconds. If you have read through the previous chapters of this book, you probably have a good idea as to why LAN connectivity is not immediately granted. The issue stems from the fact that physical connectivity is lost on the switch port when a workstation is powered off, and even sometimes when a workstation is rebooted (depending on the network interface card). Once the workstation powers up (or starts the boot process) and physical connectivity is restored, the default operation of Cisco switches is to not forward traffic on the port until various protocol negotiations have occurred and checks have been made (via spanning tree) to ensure that forwarding traffic in and out of the switch port does not introduce Layer 2 loops into the LAN. You can break down the delay factors for placing a switch port into a forwarding state as follows:

• Protocol negotiation

• Spanning-tree listening and learning

In this scenario, you learn how to reduce port startup delays for switch ports. Figure 10-5 shows the topology used for this scenario.

Figure 10-5. Scenario 10-2 Topology

In Figure 10-5, two standalone switches each attach a single host. Each host is assumed to contain a standard 10/100BaseT network interface card (NIC) and requires only an access port connection with no requirements for trunking or EtherChannel. Therefore, the startup delay for the ports attached to each workstation can (and should be) significantly reduced. In this scenario, the default startup delay of each port is measured, with the startup delay then measured after the various techniques available to reduce port delay are implemented.

Understanding the Causes of Port Startup Delays

Before implementing and testing techniques to reduce port startup delay, you need to understand exactly what causes startup delays. The causes of port startup delay can be broadly categorized into two categories:

• Protocol negotiation delays Speed/duplex auto-negotiation (802.1u), Dynamic Trunking Protocol (DTP), and Port Aggregation Protocol (PAgP)

• Spanning-tree delays Spanning-tree listening and learning states

Each of the listed delays occurs in sequential order. In other words, protocol negotiation delays occur first, which determine how a port is going to operate at both the physical layer and at Layer 2. Once these attributes are known, the port comes up at Layer 2 (i.e., spanning tree sees the port as just having come up), and the delays associated with the spanning-tree listening and learning phases take place. Figure 10-6 illustrates the causes of port startup delays.

Figure 10-6. Port Startup Delays

In Figure 10-6, you can see the sequence in which each contributing factor to port startup delay occurs. Protocol negotiation delays, related to 802.1u speed/duplex auto-negotiation, DTP negotiation, and PAgP negotiation, take approximately 20 seconds. Next, the spanning-tree listening and learning phases take 30 seconds, for a total of approximately 50 seconds before a port can start forwarding data. During the initial startup delay period, any traffic sent from an attached device is discarded.

Each of the causes of startup delay is now discussed in more detail.

Protocol Negotiation Delays

On Cisco Catalyst switches, a number of default settings enabled on each port introduce protocol negotiations, each of which introduces some factor of delay. The following lists the various protocol negotiations that take place by default when a port is initialized:

• Speed/duplex auto-negotiation The default speed and duplex settings for 10/100BaseT and 10/100/1000BaseT Ethernet ports on Catalyst switches is to auto-negotiate. The auto-negotiation process takes a few seconds.

• Dynamic Trunking Protocol (DTP) DTP is used to negotiate whether a switch port becomes a trunk port that transports traffic from multiple VLANs. The default DTP setting on CatOS-based Catalyst switches is "auto," while the default DTP setting on Cisco IOS-based Catalyst switches is "desirable." For both DTP modes of operation, this means the port listens for DTP messages from the remote device. The switch normally listens for 5 to 10 seconds before assuming the port will not trunk.

• Port Aggregation Protocol (PAgP) PAgP is similar in nature to DTP, except it is used to negotiate EtherChannel bundles. The default PAgP setting on most Catalyst switches is "auto," which means the port listens for PAgP messages from the remote device. The switch normally listens for approximately 10 to 15 seconds before assuming the port will not form a bundle.

If you add the times listed in the preceding list, you come out with a figure of somewhere between 15 and 25 seconds. During this time, the port is not even up at a Layer 2 level, as attributes specific to how the interface operates at both a physical level (i.e., EtherChannel) and Layer 2 level (i.e., trunking) are attempting to be determined. In other words, once DTP and PAgP negotiations are complete, a port comes up at Layer 2. At this point, the port becomes available for spanning tree, which then applies spanning-tree delays

Reducing Ethernet Auto-Negotiation Delays

To eliminate delays associated with speed and duplex auto-negotiation, you must hard code speed and duplex settings. On Cisco IOS, you can achieve this by using the speed and duplex interface configuration commands, as demonstrated in Example 10-13.

Example 10-13. Hard Coding Speed and Duplex Settings on Cisco IOS

 Switch# configure terminal Switch(config)# interface fastEthernet 0/1 Switch(config-if)# speed 100 Switch(config-if)# duplex full 

On CatOS, you use the set port speed and set port duplex configuration commands to hard code speed and duplex settings, as demonstrated in Example 10-14.

Example 10-14. Hard Coding Speed and Duplex Settings on CatOS

 Console> (enable) set port speed 2/1 100 Port(s)  2/1 speed set to 100Mbps. Console> (enable) set port duplex 2/1 full Port(s)  2/1 set to full-duplex. 

NOTE

On Cisco IOS and CatOS, you must hard code interface speed before you can hard code the duplex setting.

It is important to note that it is not recommended to hard code speed and duplex settings unless each device that attaches to a hard coded port has hard coded speed and duplex settings as well. Most organizations leave user workstation NIC settings in an auto-sensing configuration to reduce administrative overheads and to accommodate the capabilities of the various user workstation NICs that might be present within the organization. For this reason, it is recommended you leave auto-negotiation on for ports connected to user workstations (turning it off only saves a couple of seconds). For ports connected to servers and other network devices (e.g., routers and firewalls), it is also recommended to hard code speed and duplex where possible, although primarily to reduce the chance of negotiation mismatches, rather than for reducing port startup delay (as most servers and network devices are rarely rebooted or cycled).

Reducing DTP and PAgP Negotiation Delays

To eliminate delays associated with DTP and PAgP negotiation, you must configure each protocol to operate in an off mode, meaning the protocol is essentially disabled. By default on Cisco IOS, all interfaces are configured with a DTP mode of desirable; however, PAgP is disabled by default. You can configure a DTP mode of off by using the switchport mode access interface configuration command, and if you do need to disable PAgP for some reason (for example, because an interface has previously been part of an EtherChannel bundle), then you can use the no channel-group interface configuration command. Example 10-15 demonstrates disabling DTP and ensuring PAgP is disabled.

Example 10-15. Disabling DTP and PAgP on Cisco IOS

 Switch# configure terminal Switch(config)# interface fastEthernet 0/1 Switch(config-if)# switchport mode access Switch(config-if)# no channel-group 

On CatOS, the default DTP mode and PAgP mode is auto, which means you must explicitly disable both DTP and PAgP (unlike Cisco IOS, where PAgP is already disabled by default). To disable DTP, you use the set trunk command, and to disable PAgP, you use the set port channel command, as demonstrated in Example 10-16.

Example 10-16. Disabling DTP and PAgP on CatOS

 Console> (enable) set trunk 2/1 off Port(s)  2/1 trunk mode set to off. Console > (enable) set port channel 2/1 mode off Port(s) 2/1 channel mode set to off. 

Spanning-Tree Listening and Learning

Once the protocol negotiation phases are complete, the port is placed into an up state at Layer 2, at which point in time spanning tree sees the port. Spanning-tree delays are now incurred before traffic is actually forwarded on the port. Spanning tree listens for 15 seconds by default, determining whether or not a loop would be formed by placing the port into a forwarding state. Next, spanning tree learns the MAC addresses of devices transmitting into the port and place entries into the bridge table. This continues for a period of 15 seconds and prevents the large-scale flooding of frames (due to the bridge table being empty) when the port starts forwarding frames. So by default, a delay of 30 seconds is incurred by the spanning-tree behavior of the switch. If you add the protocol negotiation and spanning-tree delays, you are looking at a total delay of 45 to 55 seconds before a port starts forwarding data after it has detected physical connectivity.

Reducing Spanning-Tree Timers

The first option to reduce spanning-tree delays is to reduce the forward delay timer, which defines the length of the Spanning Tree Protocol (STP) listening and learning periods. The default spanning-tree timers are designed for a Layer 2 network that has a network diameter (maximum number of hops between any device) of 7. By using a hierarchical, star topology, you can significantly reduce the network diameter to 2 or 3 hops. This means that if your network is smaller than 7 hops, you can use shorter spanning-tree timers because the amount of time taken for spanning-tree messages to reach the entire Layer 2 network is shorter. For example, assuming a network diameter of 3, you can reduce the spanning-tree delay for a new port from 30 seconds to 18 seconds. You can also reduce timers further by lowering the Hello timer from the default value of 2 seconds to 1 second (the Hello timer affects the calculation of other STP timers). For example, assuming a network diameter of 3 and a Hello timer of 1 second, you can reduce the spanning-tree delay for a new port from 30 seconds to 10 seconds (compared with 18 seconds if the hello timer is 2 seconds).

When modifying spanning-tree timers, you must use the formulas specified in the IEEE 802.1d specification. Both Cisco IOS and CatOS include spanning-tree macros, which automatically calculate and configure the appropriate spanning-tree timers according to the 802.1d specification based upon the network diameter input to the macro. Example 10-17 and Example 10-18 demonstrate the use of the spanning-tree macros on Cisco IOS and CatOS, respectively, to reduce the spanning tree timers for a switched network with a network diameter of three switches.

Example 10-17. Reducing Spanning-Tree Delays on Cisco IOS

 Switch# configure terminal Switch(config)# spanning-tree vlan 1 root primary diameter 3 hello-time 1 Switch(config)# exit Switch# show spanning-tree vlan 1 VLAN0001   Spanning tree enabled protocol ieee   Root ID    Priority    24577              Address     0009.b7aa.9c80              This bridge is the root              Hello Time   1 sec  Max Age  7 sec  Forward Delay  5 sec   Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)              Address     0009.b7aa.9c80              Hello Time   1 sec  Max Age  7 sec  Forward Delay  5 sec              Aging Time 15 Interface        Role Sts Cost      Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Fa0/1            Desg FWD 19        128.1    P2p 

Example 10-18. Reducing Spanning-Tree Delays on CatOS

 Console> (enable) set spantree root 1 dia 3 hello 2 VLAN 1 bridge priority set to 8192. VLAN 1 bridge max aging time set to 7. VLAN 1 bridge hello time set to 1. VLAN 1 bridge forward delay set to 9. Switch is now the root switch for active VLAN 1. 

In Example 10-17 and Example 10-18, the shaded lines indicate the forward delay timer, which is the timer that determines the length of the listening and learning STP states. In both examples, the network diameter is configured as 3; however, notice that the forward delay for each example is different. This is because in Example 10-17, the Hello timer is reduced to one second (resulting in a forward delay of 5 seconds, or a combined listening and learning delay of 10 seconds), while in Example 10-18, the Hello timer is configured as the default setting of one second (resulting in a forward delay of 9 seconds, or a combined listening and learning delay of 18 seconds).

Enabling Spanning Tree PortFast

The other option to reduce spanning-tree delays is to eliminate them completely by enabling the PortFast feature, which is a proprietary Cisco enhancement that places a switch port immediately into a forwarding state while the listening and learning phases take place. This reduces the normal STP delay of 30 seconds to 0clearly quite an improvement. The restriction with PortFast is that you should only ever use it on ports that have single-homed (single network card) connections. You should never use PortFast on a port that connects to another Layer 2 network device, such as a switch or hub. You can enable PortFast for multi-homed routing devices (e.g., routers, firewalls, and multi-homed workstations); however, you must ensure that the multi-homed device is in no way bridging traffic between local interfaces. PortFast is the most common method used to reduce spanning-tree delays, as it totally eliminates any delay. In fact, it can be used in conjunction with reduced spanning-tree timers, where reducing the spanning-tree timers reduces the convergence time of other parts of the Layer 2 network.

To enable PortFast on Cisco IOS, you use the spanning-tree portfast interface configuration command, and on CatOS, you use the set spantree portfast configuration command. Example 10-19 and Example 10-20 demonstrate enabling spanning-tree PortFast on Cisco IOS and CatOS, respectively, to eliminate spanning-tree delays completely.

Example 10-19. Enabling Spanning-Tree PortFast on Cisco IOS

 Switch# configure terminal Switch(config)# interface fastEthernet0/1 Switch(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 

Example 10-20. Enabling Spanning-Tree PortFast on CatOS

 Console> (enable) set spantree portfast 2/1 enable Warning: Connecting Layer 2 devices to a fast start port can cause temporary spanning tree loops. Use with caution. Spantree port  2/1 fast start enabled. 

The switchport host and set port host Macros

At this point, it is appropriate to discuss the switchport host interface configuration macro (Cisco IOS) and the set port host macro (CatOS), which are macros that automatically configure all the various commands used implement the following configuration tasks:

• Disabling DTP

• Disabling PAgP

• Enabling spanning-tree PortFast

The switchport host and set port host macros reduce the administrative overhead and errors associated with having to manually perform each of the configuration tasks mentioned in the preceding list. Example 10-21 and Example 10-22 demonstrate the use of these macros on Cisco IOS and CatOS.

Example 10-21. Using the switchport host Macro on Cisco IOS

 Switch# configure terminal Switch(config)# interface range fastEthernet0/1 - 24 Switch(config-if)# switchport host ! switchport mode will be set to access ! spanning-tree portfast will be enabled channel group will be disabled 

Example 10-22. Using the set port host Macro on CatOS

 Console> (enable) set port host 2/1-48 Port(s) 2/1-48 channel mode set to off. Warning: Connecting Layer 2 devices to a fast start port can cause temporary spanning tree loops. Use with caution. Spantree port  2/1-48 fast start enabled. Port(s)  2/1-48 trunk mode set to off. 

As you can see in Example 10-21 and Example 10-22, DTP is disabled, PAgP is disabled, and spanning-tree PortFast is enabled after executing the macro.

Configuration Tasks

In this scenario, reducing the port startup delay on a CatOS-based switch is demonstrated, with each contributing delay factor incrementally eliminated and tested to determine the effect it has on reducing the total port startup delay. This requires the following configuration tasks:

• Measuring the default port startup delay

• Measuring the delay associated with spanning-tree timers and protocol negotiation

Measuring the Default Port Startup Delay

Before commencing configuration and testing, enable spanning tree informational event logging (level 6) so that a switch generates SYSLOG events when spanning tree events occur to detect when spanning tree sees a port first come up (i.e., after protocol negotiations occur) and to detect when a port is placed into a forwarding state (i.e., after the STP listening and learning phases). By default, the logging level is critical (level 2), which does not generate the required SYSLOG messages upon normal spanning tree events. Example 10-23 demonstrates configuring the spanning tree logging level as informational on Switch-A.

Example 10-23. Configuring Spanning-Tree Logging Level

 Switch-A> (enable) set logging level spantree 6 System logging facility <spantree> for this session set to severity 6(information) 

Now that the appropriate events are displayed as they occur, testing can begin. To emulate when a port is physically not connected and when a port transitions to a physically connected state, you can use the set port disable command to physically disable a port and then use the set port enable command to bring the port up (effectively emulating the port being physically connected). In this scenario, Host-A is always connected to Switch-A physically; the set port disable command is used to emulate Host-A being physically disconnected from the switch.

To begin the first port delay test, port 2/1 on Switch-A is disabled, to emulate Host-A being disconnected from the switch. The show time command is then used to display the current time in hh:mm:ss format. Immediately after this command is entered, the set port enable 2/1 command is executed. Doing this emulates bringing up the port from a physical point of view; the faster you enter the set port enable 2/1 command after entering the show time command, the more accurate timing is. After port startup delays are completed and the port goes up from a Layer 2 perspective, a "%PAGP-5-PORTTOSTP" message is displayed, which includes a timestamp that can be used to determine how long protocol negotiation took to bring up the port. Once spanning tree places the port into a forwarding state, a "%SPANTREE-6-PORTFWD" message is displayed, which also includes a timestamp. This enables measurement of exactly how long spanning tree takes to place the port into a forwarding state, as well as the total delay from when the port goes up physically to when the port actually starts forwarding data. Example 10-24 demonstrates the entire process just described.

Example 10-24. Timing the Default Startup Delay of a Port

 Switch-A> (enable) set port disable 2/1 Port 2/1 disabled. 2002 Jul 08 19:28:30 %ETHC-5-PORTFROMSTP:Port 2/1 left bridge port 2/1 Switch-A> (enable) show time Mon Jul 8 2002, 19:28:16 Switch-A> (enable) set port enable 2/1 Port 2/1 enabled. 2002 Jul 08 19:28:36 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1 2002 Jul 08 19:28:36 %SPANTREE-6-PORTBLK: Port 2/1 state in VLAN 1 changed to blocking 2002 Jul 08 19:28:36 %SPANTREE-5-PORTLISTEN: Port 2/1 state in VLAN 1 changed to listening 2002 Jul 08 19:28:50 %SPANTREE-6-PORTLEARN: Port 2/1 state in VLAN 1 changed to learning 2002 Jul 08 19:29:06 %SPANTREE-6-PORTFWD: Port 2/1 state in VLAN 1 changed to forwarding 

In Example 10-24, the show time command is issued to determine the current time, and then the set port enable 2/1 command is entered immediately. It is paramount that this command is entered as quickly as possible after the show time command to ensure timing is accurate.

TIP

To obtain the most accurate timing, in your favorite text editor type the show time command, press Enter, type the set port enable 2/1 command, and then press Enter again. Select all of the text including the last blank line (you need this to apply a carriage return after set port enable 2/1) and copy this to the clipboard. Pasting this into your terminal emulation package automatically implements the commands shown in Example 10-24 in the quickest fashion possible.

After the port is enabled physically (at 19:28:16), 20 seconds later (at 19:28:36) the port is placed into an up state at the Layer 2 level. This is determined by subtracting the first two shaded timestamps in Example 10-24. After another 30 seconds, the port is placed into a forwarding state as indicated by the "%SPANTREE-6-PORTFWD" event. Thus in total, it takes 50 seconds for the port to actually be in a state that forwards data from the time it first comes up physically.

Measuring the Delay Associated with Spanning-Tree Timers and Protocol Negotiation

At this point, a baseline default time delay of 50 seconds has been measured, during which time a switch port is physically up but not actually forwarding data. To reduce this delay, spanning-tree PortFast can be enabled, which should reduce the startup delay by 30 seconds. Example 10-25 shows the process of enabling PortFast on Switch-A.

Example 10-25. Enabling PortFast on Switch-A

 Switch-A> (enable) set spantree portfast 2/1 enable Warning: Spantree port fast start should only be enabled on ports connected to a single host.  Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops.  Use with caution. Spantree port 2/1 fast start enabled. 

Now that PortFast is enabled, the same testing procedure used in Example 10-24 must be repeated to measure the effect that PortFast has on reducing startup delay. Example 10-26 demonstrates measuring startup delay with PortFast enabled.

Example 10-26. Timing the Startup Delay of a Port with PortFast Enabled

 Switch-A> (enable) set port disable 2/1 Port 2/1 disabled. 2002 Jul 08 19:34:35 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1 Switch-A> (enable) show time Mon Jul 8 2002, 19:35:08 Switch-A> (enable) set port enable 2/1 Port 2/1 enabled. 2002 Jul 08 19:35:28 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1 2002 Jul 08 19:35:28 %SPANTREE-6-PORTFWD: Port 2/1 state in VLAN 1 changed to forwarding 

Notice in Example 10-26 that the time between when the port comes up at a Layer 2 level (20 seconds after the port is physically enabled) and when the port starts forwarding data is instantaneous. This means the port startup delay has been reduced from 50 seconds (see Example 10-24) to just 20 seconds by enabling spanning-tree PortFast.

To further reduce startup delays, PAgP can be disabled by configuring a PAgP mode of off. Example 10-27 demonstrates viewing the default PAgP configuration on Switch-A for port 2/1 and then disabling PAgP on port 2/1.

Example 10-27. Disabling PAgP for Port 2/1 on Switch-A

 Switch-A> (enable) show port channel 2/1 Port  Status     Channel              Admin Ch                  Mode                 Group Id ----- ---------- -------------------- ----- -----  2/1  connected  auto silent             27     0 Port  Device-ID                       Port-ID                   Platform ----- ------------------------------- ------------------------- ----------------  2/1 Switch-A> (enable) set port channel 2/1 mode off Port(s) 2/1 channel mode set to off. 

As you can see in Example 10-27, the default PAgP mode is auto, which means PAgP negotiations and the associated delay take place when port 2/1 comes up. By disabling PAgP in Example 10-27, the delays associated with PAgP negotiations are eliminated.

Now that PortFast is enabled and PAgP is disabled, the same testing procedure used in Example 10-24 and Example 10-26 must be repeated to measure the effect that PortFast and disabling PAgP has on reducing startup delay. Example 10-28 demonstrates measuring startup delay with PortFast enabled and PAgP disabled.

Example 10-28. Timing the Startup Delay of a Port with PortFast Enabled and PAgP Disabled

 Switch-A> (enable) set port disable 2/1 Port 2/1 disabled. 2002 Jul 08 19:39:57 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1 Switch-A> (enable) show time Mon Jul 8 2002, 19:40:13 Switch-A> (enable) set port enable 2/1 Port 2/1 enabled. 2002 Jul 08 19:40:24 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1 2002 Jul 08 19:40:24 %SPANTREE-6-PORTFWD: Port 2/1 state in VLAN 1 changed to forwarding 

Notice in Example 10-28 that the time between when the port is physically enabled (19:40:13) and when the port comes up at a Layer 2 level (19:40:24) is now reduced to just 11 seconds from 20 seconds in Example 10-26. This means that the reduction in delay due to the disabling of PAgP is 9 seconds.

To further reduce startup delays, DTP can be disabled by configuring a DTP mode of off. Example 10-29 demonstrates viewing the default DTP configuration on Switch-A for port 2/1 and then disabling DTP for port 2/1.

Example 10-29. Disabling DTP for Port 2/1 on Switch-A

 Switch-A> (enable) show trunk 2/1 * - indicates vtp domain mismatch Port      Mode         Encapsulation  Status        Native vlan --------  -----------  -------------  ------------  -----------  2/2      auto         dot1q          not-trunking  1 Port      Vlans allowed on trunk --------  ---------------------------------------------------------------------  2/2      1-1005,1025-4094 Port      Vlans allowed and active in management domain --------  ---------------------------------------------------------------------  2/2      1 Port      Vlans in spanning tree forwarding state and not pruned --------  ---------------------------------------------------------------------  2/2 Switch-A> (enable) set trunk 2/1 off Port(s)  2/1 trunk mode set to off. 

Notice that the default (DTP) mode in the show trunk output is set to auto, which means the port listens for DTP messages until a timeout period expires. By disabling DTP in Example 10-29, the delays associated with DTP negotiations are eliminated.

Now that PortFast is enabled, PAgP is disabled, and DTP is disabled, the same testing procedure used in Example 10-24, Example 10-26 and Example 10-28 must be repeated to measure the effect that enabling PortFast, disabling PAgP, and disabling DTP has on reducing startup delay. Example 10-30 demonstrates measuring startup delay with PortFast enabled, PAgP disabled, and DTP disabled.

Example 10-30. Timing the Startup Delay of a Port with PortFast Enabled and PAgP and DTP Disabled

 Switch-A> (enable) set port disable 2/1 Port 2/1 disabled. 2002 Jul 08 19:44:06 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1 Switch-A> (enable) show time Mon Jul 8 2002, 19:44:18 Switch-A> (enable) set port enable 2/1 Port 2/1 enabled. 2002 Jul 08 19:44:22 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1 2002 Jul 08 19:44:22 %SPANTREE-6-PORTFWD: Port 2/1 state in VLAN 1 changed to forwarding 

Notice in Example 10-30 that the time between when the port is physically enabled and when the port is placed up at Layer 2 is now reduced to just 4 seconds in total, compared with 11 seconds in Example 10-28. This means that the reduction in delay due to disabling DTP is 7 seconds.

Finally, to reduce startup delays as much as possible, speed and duplex settings can be configured on port 2/1, eliminating the delays associated with Ethernet auto-negotiation on port 2/1. To ensure optimal performance on the port, the speed and duplex settings on Host-A must also be hard coded with a matching speed and duplex configuration. Assuming the speed and duplex settings on Host-A are configured as 100 Mbps full-duplex, Example 10-31 demonstrates hard coding the speed and duplex settings for port 2/1 on Switch-A.

Example 10-31. Disabling Auto-Negotiation for Port 2/1 on Switch-A

 Switch-A> (enable) set port speed 2/1 100 Port(s)  2/1 speed set to 100Mbps. Switch-A> (enable) set port duplex 2/2 full Port(s)  2/1 set to full-duplex. 

Now that all startup delay factors have been eliminated (i.e., PortFast, DTP, PAgP, and Ethernet auto-negotiation), a final test of startup delay is required. Example 10-32 demonstrates measuring startup delay with PortFast enabled, PAgP disabled, DTP disabled, and Ethernet speed/duplex auto-negotiation disabled.

Example 10-32. Timing the Startup Delay of a Port with PortFast Enabled, PAgP + DTP Disabled and Ethernet Auto-negotiation Disabled

 Switch-A> (enable) set port disable 2/1 Port 2/1 disabled. 2002 Jul 08 19:52:07 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1 Switch-A> (enable) show time Mon Jul 8 2002, 19:52:10 Switch-A> (enable) set port enable 2/1 Port 2/1 enabled. 2002 Jul 08 19:44:12 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1 2002 Jul 08 19:44:12 %SPANTREE-6-PORTFWD: Port 2/1 state in VLAN 1 changed to forwarding 

Notice in Example 10-32 that the time between when the port is physically enabled and when the port is placed up at Layer 2 is now reduced to just 2 seconds in total, compared with 4 seconds in Example 10-30. This means that the reduction in delay due to disabling auto-negotiation is 2 seconds. You would normally not disable auto-negotiation on a workstation port, because this would require the disabling of auto-negotiation on the workstation NIC as well to ensure proper duplex matching.

NOTE

The 2-second delay that still remains can be attributed to processing and port initialization delays that cannot be eliminated.