Chapter 2: Enterprise Campus Network Design (Part03)

Recommended Practices for Trunk Configuration

A trunk is a point-to-point link between two networking devices that carry the traffic of multiple VLANs. Trunks are typically deployed on the interconnection between the access and distribution layers.

The current recommended practice is to use IEEE 802.1Q trunks. Cisco extensions to 802.1Q avoid security concerns related to the 802.1Q nontagged, native VLAN. The native VLAN is assigned to an unused ID, or the tagged, native VLAN option is used to avoid VLAN hopping.

Note

VLAN hopping is an attack using a double 802.1Q-encapsulated packet. If the attacker has specific knowledge of the 802.1Q native VLAN, a packet could be crafted that when processed, the first or outermost tag is removed when the packet is switched onto the untagged, native VLAN. When the packet reaches the target switch, the inner or second tag is then processed, and the potentially malicious packet is switched to the target VLAN. The traffic in this attack scenario is in a single direction, and no return traffic can be switched by this mechanism. In addition, this attack cannot work unless the attacker knows the native VLAN identity.

VLAN Trunking Protocol (VTP) is a protocol that enables network managers to centrally manage the VLAN database. VTP transparent mode is now a recommended practice because it decreases the potential for operational error.

By default, Cisco switches are configured as a VTP server with no VTP domain name specified.

Therefore, it is also recommended when configuring switches along with setting the mode to Transparent, to set the VTP domain name. This is important if you are connecting your switch to other domains, such as a service provider switch. Misconfiguration of the switch as a server or client with no VTP domain name will cause it to accept the domain name of an adjacent VTP server and overwrite the local VLAN database.

As a recommended practice, when configuring switch-to-switch interconnections to carry multiple VLANs, set Dynamic Trunking Protocol (DTP) to Desirable and Desirable with Encapsulation Negotiate to support DTP negotiation.

Note

Turning DTP to On and On with Nonnegotiate could save seconds of outage when restoring a failed link or node. However, with this configuration, DTP is not actively monitoring the state of the trunk, and a misconfigured trunk is not easily identified. One instance where you would use On with Nonnegotiate is if you are trunking between two different VTP domains. DTP includes the VTP domain name in its messages; and if the names do not match, the trunk will not come up if set to Desirable.

Another recommended practice is to manually prune unused VLANs from trunked interfaces to avoid broadcast propagation. You should avoid automatic VLAN pruning.

The final recommendation for trunk configuration is to disable trunks on host ports, because host devices will not need to negotiate trunk status. This practice speeds up PortFast and is also a VLAN-hopping security measure.

VLAN Trunking Protocol

VTP version 3 supports centralized VLAN administration in a switched network. VTP runs only on trunks and provides the following four modes:

• Server: Updates clients and servers. The VTP server switch propagates the VTP database to VTP client switches.

• Client: Receives updates but cannot make changes.

• Transparent: Does not participate in the VTP domain. Lets updates pass through.

• Off: Ignores VTP updates.

With VTP, when you configure a new VLAN on a switch in VTP server mode, the VLAN is distributed through all switches in the VTP domain. This redistribution reduces the need to configure the same VLAN everywhere.

With hierarchical networks that do not span VLANs across the distribution layer, there is little need for a shared common VLAN database. In the recommended campus design, the same VLAN should not appear in two access layer switches. Adding and removing VLANs is generally not a frequent network management practice. In most cases, VLANs are defined once during switch setup with few, if any, additional modifications to the VLAN database in an access layer switch. The benefits of dynamic propagation of VLAN information across the network are not worth the potential for unexpected behavior due to operational error. For these reasons, VTP transparent mode is the recommended configuration option.

Dynamic Trunking Protocol

DTP provides switch ports to negotiate the trunking method with another device and to automatically allow a link to become a trunk.

With Cisco devices, there are five Layer 2 port modes:

• Trunk: Puts the port into permanent trunking mode and negotiates to convert the link into a trunk link. The port becomes a trunk port even if the neighboring port does not agree to the change.

• Desirable: Actively attempts to form a trunk, subject to neighbor agreement. The port becomes a trunk port if the neighboring port is set to On, Desirable, or Auto mode.

• Auto: Makes the port willing to convert the link to a trunk link. The port becomes a trunk port if the neighboring port is set to on or desirable mode.

• Access: This is the access mode in Cisco IOS Software that specifies that the port never become a trunk, even if the neighbor tries. This mode puts the LAN port into permanent nontrunking mode and negotiates to convert the link into a nontrunking link.

• Nonnegotiate: Prevents the port from generating DTP frames. You must configure the neighboring port manually as a trunk port to establish a trunk link.

With Cisco devices, there are three Ethernet trunk encapsulation types:

• ISL: Uses Inter-Switch Link (ISL) encapsulation on the trunk link

• Dot1q: Uses 802.1Q encapsulation on the trunk link

• Negotiate: Specifies that the LAN port negotiate with the neighboring LAN port to become an ISL (preferred) or 802.1Q trunk, depending on the configuration and capabilities of the neighboring LAN port

The trunking mode, the trunk encapsulation type, and the hardware capabilities of the two connected LAN ports determine whether a link becomes an ISL or 802.1Q trunk. A common practice is to configure both ends of the trunk to desirable. This has the operational benefit of providing a clear indication of a functional trunking connection with show commands, and is the general recommendation for DTP trunking.

An alternative practice is to set one side of the link (typically the access layer) to Auto and the other end (typically the distribution layer) to Desirable. This setting allows for automatic trunk formation, with DTP running on the interconnection to protect against some rare hardware failure scenarios and software misconfigurations.

For fastest convergence, a third configuration turns DTP to On and On with Nonnegotiate to save a few seconds of outage when restoring a failed link or node. However, DTP is not actively monitoring the state of the trunk with this configuration, and a misconfigured trunk is not easily identified. The Nonnegotiate setting can also cause loss of connectivity if the process is not performed in the correct order and there is no out-of-band connectivity to the farthest switch from where the in-band modifications are being made.

Recommended Practices for UDLD Configuration

UDLD enables devices to monitor the physical configuration of the cables and detect when a unidirectional link exists where bidirectional communication has not been established.

UDLD is typically deployed on fiber topologies where physical misconnections can occur that enable a link to appear to be up/up when there is a mismatched set of transmit/receive pairs. UDLD supports both fiber-optic and copper Ethernet cables connected to LAN ports.

Each switch port configured for UDLD will send UDLD protocol hello packets at Layer 2 containing the device and port identifications of the port, and the device and port identifications of the neighbor as seen by UDLD on that port. Neighboring ports should see their own device and port identifications in the packets received from the other side. If the port does not see its own device and port identifications in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional and is shut down. The default 15-second hello timers are the same for normal and aggressive UDLD. In normal mode, UDLD will error-disable only the end where the UDLD is detected; aggressive mode will error-disable both ends of a connection after aging on a previously bidirectional link in eight seconds.

A recommended practice is to enable UDLD aggressive mode in all environments where fiber-optic interconnections are used. UDLD is enabled globally on all fiber-optic LAN ports with the Cisco IOS software udld {enable | aggressive} command. UDLD is enabled on individual LAN ports with the udld port [aggressive] interface command.

Note

You should enable UDLD in global mode so that you do not have to enable it on every individual fiber-optic interface.

Recommended Practices for EtherChannel

An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate bandwidth of up to eight physical links.

EtherChannels are typically deployed between the distribution-to-core and core-to-core interconnections where increased availability and scaled bandwidth are required. EtherChannel link aggregation is used to provide link redundancy and prevent a single point of failure, and to reduce peering complexity because the single logical entity reduces the number of Layer 3 neighbor relationships as compared to multiple parallel links.

Note

EtherChannel also provides an optimization to STP by enabling all member ports to be placed in the forwarding mode. STP views the EtherChannel as a single logical link.

EtherChannels create channels containing up to eight parallel links between switches. If the channels are on interfaces that are on different physical line cards, there is increased availability because the failure of a single line card does not cause a complete loss of connectivity.

There are two variants for the control mechanism for EtherChannel: the prestandard Cisco implementation that uses Port Aggregation Protocol (PAgP), and the IEEE 802.3ad standards-based implementation that uses Link Aggregation Control Protocol (LACP). PAgP and LACP do not interoperate. You can manually configure a switch with PAgP on one side and LACP on the other side in the on/on mode. When this is done, ports configured in the on mode do not negotiate, and therefore there is no negotiation traffic between the ports. This configuration results in the EtherChannel being hard-coded.

When connecting a Cisco IOS Software device to a Catalyst operating system device, make sure that the PAgP settings used for establishing EtherChannels are coordinated. The defaults are different for a Cisco IOS Software device and a Catalyst operating system device. As a recommended 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.

Port aggregation should be disabled when not needed. Port aggregation can most effectively be controlled by disabling it on interfaces facing end users with the set port host macro on the Catalyst operating system or the switchport host macro on Cisco ISO Software. These macros disable both trunking and EtherChannel while enabling STP PortFast.

Port Aggregation Protocol

PAgP is one of the control mechanisms for EtherChannel. PAgP has four modes related to the automatic formation of bundled, redundant switch-to-switch interconnections (see Figure 2-12):

• On: Mode that forces the LAN port to channel unconditionally. In the on mode, a usable EtherChannel exists only when a LAN port group in the on mode is connected to another LAN port group in the on mode. Because ports configured in the on mode do not negotiate, no negotiation occurs traffic between the ports. You cannot configure the on mode with an EtherChannel protocol. If one end uses the on mode, the other end must also.

• Desirable: Places a port into an active negotiating state, in which the port starts negotiations with other ports by sending PAgP packets. This mode is not supported when the EtherChannel members are from different switches in the switch stack (cross-stack EtherChannel).

• Auto: Places a port into a passive negotiating state, in which the port responds to PAgP packets it receives but does not start PAgP packet negotiation. This setting minimizes the transmission of PAgP packets. This mode is not supported when the EtherChannel members are from different switches in the switch stack (cross-stack EtherChannel).

• Off: Do not become a member.

As with DTP, the long-standing practice for EtherChannel/PAgP has been to set one side of the interconnection (typically the access switch) to Auto and the other side (typically the distribution switch) to Desirable, or both sides to Desirable. In these configurations, an EtherChannel is established when configuration is complete, and connectivity to the remote switch is always available, even when the EtherChannel is not completely established.

Note

For Layer 2 EtherChannels, a desirable/desirable PAgP configuration is recommended so that PAgP is running across all members of the bundle, ensuring that an individual link failure will not result in a STP failure.

Link Aggregation Control Protocol

LACP is another control mechanism for EtherChannel. LACP has four modes related to the automatic formation of bundled, redundant switch-to-switch interconnections:

• On: Mode that forces the LAN port to channel unconditionally. In the on mode, a usable EtherChannel exists only when a LAN port group in the on mode is connected to another LAN port group in the on mode. Because ports configured in the on mode do not negotiate, no negotiation traffic occurs between the ports. You cannot configure the on mode with an EtherChannel protocol. If one end uses the on mode, the other end must also.

• Active: LACP mode that places a port into an active negotiating state, in which the port initiates negotiations with other ports by sending LACP packets.

• Passive: LACP mode that places a port into a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP negotiation.

• Off: Do not become a member.

Note

The recommended practice for EtherChannel LACP is to set one side of the interconnection (typically the access switch) to Active and the other side (typically the distribution switch) to Passive, or both sides to Active. In these configurations, a channel is established when configuration is complete, and connectivity to the remote switch is always available, even when the channel is not completely established.