When implementing the campus infrastructure’s Building Access layer, consider the following questions:

■ How many users or host ports are currently required in the wiring closet, and how many will it require in the future? Should the switches be fixed or modular configuration?

■ How many ports are available for end-user connectivity at the walls of the buildings?

■ How many access switches are not located in wiring closets?

■ What cabling is currently available in the wiring closet, and what cabling options exist for uplink connectivity?

■ What data link layer performance does the node need?

■ What level of redundancy is needed?

■ What is the required link capacity to the Building Distribution layer switches?

■ How will VLANs and STP be deployed? Will there be a single VLAN, or several VLANs per access switch? Will the VLANs on the switch be unique or spread across multiple switches?

The latter design was common a few years ago, but today end-to-end VLANs (also called campuswide VLANs) are not desirable.

■ Are additional features, such as port security, multicast traffic management, and QoS (such as traffic classification based on ports), required?

Based on the answers to these questions, select the devices that satisfy the Building Access layer’s requirements. The Building Access layer should maintain the simplicity of traditional LAN switching, with the support of basic network intelligent services and business applications.

The following are best-practice recommendations for optimal Building Access layer design:

■ Manage VLANs and STP(Spanning tree protocol)

■ Manage trunks between switches

■ Manage default Port Aggregation Protocol (PAgP) settings

■ Consider implementing routing

Managing VLANs and STP

This section details best-practice recommendations related to VLANs and STP (Spanning tree protocol).

Avoid Using STP if Possible

STP is defined in IEEE 802.1d. Avoid requiring any type of STP (including Rapid STP [RSTP]) by design for the most deterministic and highly available network topology that is predictable and bounded and has reliably tuned convergence. For example, the behavior of Layer 2 environments (using STP) and Layer 3 environments (using a routing protocol) are different under “soft failure” conditions, when keepalive messages are lost. In an STP environment, if bridge protocol data units (BPDU) are lost, the network fails in an “open” state, forwarding traffic with unknown destinations on all ports, potentially causing broadcast storms.

If STP Is Required, Use RSTP with Per-VLAN Spanning Tree Plus

Cisco developed Per-VLAN Spanning Tree (PVST) so that switches can have one instance of STP running per VLAN, allowing redundant physical links within the network to be used for different VLANs and thus reducing the load on individual links. PVST works only over ISL trunks. However, Cisco extended this functionality for 802.1Q trunks with the Per-VLAN Spanning Tree Plus (PVST+) protocol. Before this became available, 802.1Q trunks supported only Common Spanning Tree (CST), with one instance of STP running for all VLANs. Multiple-Instance STP (MISTP) is an IEEE standard (802.1s) that uses RSTP and allows several VLANs to be grouped into a single spanning-tree instance. Each instance is independent of the other instances so that a link can forward for one group of VLANs while blocking for other VLANs. MISTP therefore allows traffic to be shared across all the links in the network, but it reduces the number of STP instances that would be required if PVST/PVST+ were implemented. RSTP is defined by IEEE 802.1w. RPVST+ is a Cisco enhancement of RSTP. As a best practice, if STP must be used, use RPVST+.

Two other STP-related recommendations are as follows:

■ If a network includes non-Cisco switches, isolate the different STP domains with Layer 3 routing to avoid STP compatibility issues.

■ Even if the recommended design does not depend on STP to resolve link or node failure events, use STP in Layer 2 designs to protect against user-side loops. A loop can be introduced on the user-facing access layer ports in many ways, such as wiring mistakes, misconfigured end stations, or malicious users. STP is required to ensure a loop-free topology and to protect the rest of the network from problems created in the access layer.

The Cisco STP Toolkit

The Cisco STP toolkit provides tools to better manage STP when RSTP+ is not available:

■ PortFast: Used for ports to which end-user stations or servers are directly connected. When PortFast is enabled, there is no delay in passing traffic, because the switch immediately puts the port in STP forwarding state, skipping the listening and learning states. Two additional measures that prevent potential STP loops are associated with the PortFast feature:

• BPDU Guard: PortFast transitions the port into the STP forwarding state immediately on linkup. Because the port still participates in STP, the potential for an STP loop exists if some device attached to that port also runs STP. The BPDU Guard feature enforces the STP domain borders and keeps the active topology predictable. If the port receives a BPDU, the port is transitioned into errdisable state (meaning that it was disabled due to an error), and an error message is reported.

• BPDU Filtering: This feature blocks PortFast-enabled, nontrunk ports from transmitting BPDUs. STP does not run on these ports. BPDU filtering is not recommended, because it effectively disables STP at the edge and can lead to STP loops.

■ UplinkFast: If the link on a switch to the root switch goes down and the blocked link is directly connected to the same switch, UplinkFast enables the switch to put a redundant port (path) into the forwarding state immediately, typically resulting in convergence of 3 to 5 seconds after a link failure.

■ BackboneFast: If a link on the way to the root switch fails but is not directly connected to the same switch (in other words, it is an indirect failure), BackboneFast reduces the convergence time by max_age (which is 20 seconds by default), from 50 seconds to approximately 30 seconds. When this feature is used, it must be enabled on all switches in the STP domain.

■ STP Loop Guard: When one of the blocking ports in a physically redundant topology stops receiving BPDUs, usually STP creates a potential loop by moving the port to forwarding state. With the STP Loop Guard feature enabled, and if a blocking port no longer receives BPDUs, that port is moved into the STP loop-inconsistent blocking state instead of the listening/ learning/forwarding state. This feature avoids loops in the network that result from unidirectional or other software failures.

■ RootGuard: The RootGuard feature prevents external switches from becoming the root. RootGuard should be enabled on all ports where the root bridge should not appear; this feature ensures that the port on which RootGuard is enabled is the designated port. If a superior BPDU (a BPDU with a lower bridge ID than that of the current root bridge) is received on a RootGuard-enabled port, the port is placed in a root-inconsistent state—the equivalent of the listening state.

■ BPDU Skew Detection: This feature allows the switch to keep track of late-arriving BPDUs (by default, BPDUs are sent every 2 seconds) and notify the administrator via Syslog messages. Skew detection generates a report for every port on which BPDU has ever arrived late (this is known as skewed arrival). Report messages are rate-limited (one message every 60 seconds) to protect the CPU.

■ Unidirectional Link Detection (UDLD): A unidirectional link occurs whenever traffic transmitted by the local switch over a link is received by the neighbor but traffic transmitted from the neighbor is not received by the local device. If the STP process that runs on the switch with a blocking port stops receiving BPDUs from its upstream (designated) switch on that port, STP eventually ages out the STP information for this port and moves it to the forwarding state. If the link is unidirectional, this action would create an STP loop. UDLD is a Layer 2 protocol that works with the Layer 1 mechanisms to determine a link’s physical status. If the port does not see its own device/port ID in the incoming UDLD packets for a specific duration, the link is considered unidirectional from the Layer 2 perspective. After UDLD detects the unidirectional link, the respective port is disabled, and an error message is generated.

Managing Trunks Between Switches

Trunks are typically deployed on the interconnection between the Building Access and Building Distribution layers. There are several best practices to implement with regard to trunks.

Trunk Mode and Encapsulation

As a best practice when configuring trunks, set Dynamic Trunking Protocol (DTP) to desirable on one side and desirable (with the negotiate option) one the other side to support DTP protocol (encapsulation) negotiation.

Manually Pruning VLANs

Another best practice is to manually prune unused VLANs from trunked interfaces to avoid broadcast propagation. Cisco recommends not using automatic VLAN pruning; manual pruning provides stricter control. As mentioned, campuswide or access layer–wide VLANs are no longer recommended, so VLAN pruning is less of an issue than it used to be.

VTP Transparent Mode

VTP transparent mode should be used as a best practice because hierarchical networks have little need for a shared common VLAN database. Using VTP transparent mode decreases the potential for operational error.

Trunking on Ports

Trunking should be disabled on ports to which hosts will be attached so that host devices do not need to negotiate trunk status. This practice speeds up PortFast and is a security measure to prevent VLAN hopping.

Managing Default PAgP Settings

Fast EtherChannel and Gigabit EtherChannel solutions group several parallel links between LAN switches into a channel that is seen as a single link from the Layer 2 perspective. Two protocols handle automatic EtherChannel formation: PAgP, which is Cisco-proprietary, and the Link Aggregation Control Protocol (LACP), which is standardized and defined in IEEE 802.3ad. When connecting a Cisco IOS software device to a Catalyst operating system device using PAgP, make sure that the PAgP settings used to establish EtherChannels are coordinated; the defaults are different for a Cisco IOS software device and a Catalyst operating system device. As a best practice, Catalyst operating system devices should have PAgP set to off when connecting to a Cisco IOS software device if EtherChannels are not configured. If EtherChannel/PAgP is used, set both sides of the interconnection to desirable.

Implementing Routing in the Building Access Layer

Although not as widely deployed in the Building Access layer, a routing protocol, such as EIGRP, when properly tuned, can achieve better convergence results than Layer 2 and Layer 3 boundary hierarchical designs that rely on STP. However, adding routing does result in some additional complexities, including uplink IP addressing and subnetting, and loss of flexibility. Figure 3.6 illustrates a sample network with Layer 3 routing in both the Building Access and Building Distribution layers. In this figure, equal-cost Layer 3 load balancing is performed on all links (although EIGRP could perform unequal-cost load balancing). STP is not run, and a first-hop redundancy protocol (such as Hot Standby Router Protocol [HSRP]) is not required. VLANs cannot span across the multilayer switch.