Ch. 8 Switching Features and Technologies for Campus Networks

Ch. 8 Switching Features and Technologies for Campus Networks
CIS 187 Multilayer Switched Networks CCNP version 7 Rick Graziani Spring 2016

Chapter 8 Switching Features and Technologies for the Campus Network
Discovery Protocols 352 Introduction to LLDP 352 Basic Configuration of LLDP 353 Discovering Neighbors Using LLDP 355 Unidirectional Link Detection 357 UDLD Mechanisms and Specifics 358 UDLD Configuration 358 Leveraging UDLD and STP Loop Guard Together 360 Power over Ethernet 360 PoE Components 362 PoE Standards 362 PoE Negotiation 362 Configuring and Verifying PoE 363

SDM Templates 364 SDM Template Types 365 Choosing the Right SDM Template 367 System Resource Configuration on Other Platforms 367 Monitoring Features 368 SPAN and RSPAN Overview 368 SPAN Configuration 371 RSPAN Configuration 372

IP SLA 374 Introduction to IP SLA 375 IP SLA Source and Responder 377 IP SLA Configuration 377 IP SLA Operation with Responder 379 IP SLA Time Stamps 381 Configuring Authentication for IP SLA 382 IP SLA Example for UDP Jitter 383

Discovery Protocols Discovery Protocols 352
Introduction to LLDP 352 Basic Configuration of LLDP 353 Discovering Neighbors Using LLDP 355 Unidirectional Link Detection 357 UDLD Mechanisms and Specifics 358 UDLD Configuration 358 Leveraging UDLD and STP Loop Guard Together 360 Power over Ethernet 360 PoE Components 362 PoE Standards 362 PoE Negotiation 362 Configuring and Verifying PoE 363 The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation. In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions. Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms. Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN. Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+. Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP. Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

Cisco Discovery Protocol (CDP)
CDP is the original link layer (Layer 2) information-gathering / troubleshooting tool for directly connected Cisco neighbors. CDP is a Cisco proprietary tool. CDP advertisements sent to directly connected Cisco device which contain information such as: The device type The interfaces they are connected to The model number of the device. CDP is enabled by default but can be disabled/enabled: Globally: [no] cdp run global configuration command Interface: [no] cdp enable interface configuration command

show cdp neighbors Command
S1# show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, D - Remote, C - CVTA, M - Two-port Mac Relay Device ID Local Intrfce Holdtme Capability Platform Port ID Switch Fas 0/ S I WS-C2960- Fas 0/4 Switch Fas 0/ S I WS-C2960- Fas 0/3 Switch Fas 0/ S I WS-C2960- Fas 0/2 Switch Fas 0/ S I WS-C2960- Fas 0/1 R Fas 0/ R B S I CISCO1941 Gig 0/1 S1#

show cdp entry Command S1# show cdp entry R1 -------------------------
Device ID: R1 Entry address(es): IP address: Platform: Cisco CISCO1941/K9, Capabilities: Router Source-Route-Bridge Switch IGMP Interface: FastEthernet0/5, Port ID (outgoing port): GigabitEthernet0/1 Holdtime : 151 sec Version : Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.4(3)M2, RELEASE SOFTWARE (fc2) Technical Support: Copyright (c) by Cisco Systems, Inc. Compiled Fri 06-Feb-15 17:01 by prod_rel_team advertisement version: 2 Duplex: full Power Available TLV: Power request id: 0, Power management id: 0, Power available: 0, Power management level: 0 Management address(es): S1#

show cdp neighbors Command
R1# sho cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, D - Remote, C - CVTA, M - Two-port Mac Relay Device ID Local Intrfce Holdtme Capability Platform Port ID S Gig 0/ S I WS-C2960- Fas 0/5 Total cdp entries displayed : 1 R1#

show cdp neighbors detail Command
R1# sho cdp neighbors detail Device ID: S1 Entry address(es): Platform: cisco WS-C TT-L, Capabilities: Switch IGMP Interface: GigabitEthernet0/1, Port ID (outgoing port): FastEthernet0/5 Holdtime : 151 sec Version : Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE7, RELEASE SOFTWARE (fc1) Technical Support: Copyright (c) by Cisco Systems, Inc. Compiled Thu 23-Oct-14 14:49 by prod_rel_team advertisement version: 2 Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value= FFFFFFFF010221FF CD996E23D00FF0000 VTP Management Domain: '' Native VLAN: 1 Duplex: full Total cdp entries displayed : 1 R1#

Link Layer Discovery Protocol (LLDP)
For interoperability between different vendors the IEEE introduced 802.1AB - Link Layer Discovery Protocol (LLDP). All current Cisco device models support LLDP. Enabled by default on some platforms. However, it is not as lightweight as CDP. Implementation properties of LLDP: LLDP is unidirectional link-local protocol. LLDP operates only in an advertising mode which means LLDP does not solicit for information or monitor state changes between LLDP nodes. LLDP captures all information received about its neighbors.

Link Layer Discovery Protocol (LLDP)
The specification defines mandatory and optional TLVs (device information): System name and description Port name and description Port VLAN and VLAN name Management IP address System Capabilities (Wi-Fi, routing, switching, and so on) Power over Ethernet Link aggregation

Configuring LLDP LLDP can be disabled/enabled:
Globally: [no] lldp run global configuration command Interface: [no] lldp receive interface configuration command [no] lldp transmit interface configuration command

Enabling LLDP on a Switch
S1# show lldp % LLDP is not enabled S1# S1# conf t Enter configuration commands, one per line. End with CNTL/Z. S1(config)# lldp run S1(config)# exit Global LLDP Information: Status: ACTIVE LLDP advertisements are sent every 30 seconds LLDP hold time advertised is 120 seconds LLDP interface reinitialisation delay is 2 seconds Media Notes: -New Figure

Enabling LLDP on a Router
R1# show lldp % LLDP is not enabled R1# R1# conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)# lldp run R1(config)# exit Global LLDP Information: Status: ACTIVE LLDP advertisements are sent every 30 seconds LLDP hold time advertised is 120 seconds LLDP interface reinitialisation delay is 2 seconds R1# show lldp ? entry Information for specific neighbor entry errors LLDP computational errors and overflows interface LLDP interface status and configuration neighbors LLDP neighbor entries traffic LLDP statistics | Output modifiers <cr> Enabling LLDP on a Router Media Notes: -New Figure

Verifying LLDP on a Router
R1# show lldp traffic LLDP traffic statistics: Total frames out: 56 Total entries aged: 0 Total frames in: 28 Total frames received in error: 0 Total frames discarded: 0 Total TLVs discarded: 0 Total TLVs unrecognized: 0 R1# R1# show lldp neighbors Capability codes: (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other Device ID Local Intf Hold-time Capability Port ID S Gi0/ B Fa0/5 Total entries displayed: 1 Media Notes: -New Figure

Verifying LLDP on a Router
R1# show lldp neighbors detail Local Intf: Gi0/1 Chassis id: 0cd9.96e2.3d00 Port id: Fa0/5 Port Description: FastEthernet0/5 System Name: S1 System Description: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE7, RELEASE SOFTWARE (fc1) Technical Support: Copyright (c) by Cisco Systems, Inc. Compiled Thu 23-Oct-14 14:49 by prod_rel_team Time remaining: 106 seconds System Capabilities: B Enabled Capabilities: B Management Addresses - not advertised Auto Negotiation - supported, enabled Physical media capabilities: 100base-TX(FD) 100base-TX(HD) 10base-T(FD) 10base-T(HD) Media Attachment Unit type: 16 Vlan ID: 1 Total entries displayed: 1 R1# Verifying LLDP on a Router Media Notes: -New Figure

Configuring LLDP Interface Specifics
S1# show running-config interface fa0/6 Building configuration... Current configuration : 33 bytes ! interface FastEthernet0/6 end S1# S1# conf t S1(config)# interface fa0/6 S1(config-if)# no lldp transmit S1(config-if)# lldp receive S1(config-if)# S1(config-if)# do show running-config interface fa0/6 Current configuration : 51 bytes no lldp transmit Media Notes: -New Figure

Unidirectional Link Detection
Discovery Protocols 352 Introduction to LLDP 352 Basic Configuration of LLDP 353 Discovering Neighbors Using LLDP 355 Unidirectional Link Detection 357 UDLD Mechanisms and Specifics 358 UDLD Configuration 358 Leveraging UDLD and STP Loop Guard Together 360 Power over Ethernet 360 PoE Components 362 PoE Standards 362 PoE Negotiation 362 Configuring and Verifying PoE 363 The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation. In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions. Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms. Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN. Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+. Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP. Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

Preventing Forwarding Loops
Prevention of forwarding loops and black holes in a network is a required aspect of network design. Black holes are created when a device receives frames but has no forwarding information for that packet. It essentially drops all such packets. Cisco Catalyst switches support two important features to address such conditions: Loop Guard: Loop Guard prevents bridging loops. UDLD: UDLD detects and disables unidirectional links.

X Loopguard Loop! BPDU No BPDU’s Received Change to Forwarding State
No Loopguard Configured Change to Forwarding State Loopguard also protects against ports erroneously transitioning to forwarding mode. Loopguard will also protect against STP failures, designated switch not sending BPDUs due to software problems. Rick Graziani

Loop Guard In STP, switches rely on continuous reception or transmission of BPDUs, depending on the port role. A designated port transmits BPDUs whereas a nondesignated port receives BPDUs. Bridging loops occur when a port erroneously transitions to forwarding state because it has stopped receiving BPDUs. Ports with loop guard enabled do an additional check before transitioning to forwarding state. If a nondesignated port stops receiving BPDUs, the switch places the port into the STP loop-inconsistent blocking state. If a switch receives a BPDU on a port in the loop-inconsistent STP state, the port transitions through STP states according to the received BPDU. As a result, recovery is automatic, and no manual intervention is necessary. Prevention of forwarding loops and black holes in a network is a required aspect of network design. Black holes in the network are created when a device that receives frames has no forwarding information for that packet and thus essentially drops all such packets. Cisco Catalyst switches support two important features to address such conditions: Loop Guard: The Loop Guard STP feature improves the stability of Layer 2 networks by preventing bridging loops. UDLD: UDLD detects and disables unidirectional links. If a switch receives a BPDU on a port in the loop-inconsistent STP state, the port transitions through STP states according to the received BPDU. As a result, recovery is automatic, and no manual intervention is necessary.

Configuring Loop Guard
Loop guard can be enabled: Per Port: Use the spanning-tree guard loop interface configuration command. Globally: Use the spanning-tree loopguard default global config command. This enables Loop guard on all point-to-point links.

Unidirectional Link Detection Protocol (ULDP)
Designated Port BPDU Blocked Port BPDU Received only, none sent Spanning-Tree Protocol (STP) resolves redundant physical topology into a loop-free, tree-like forwarding topology. This is done by blocking one or more ports. Rick Graziani

ULDP Loop! BPDU BPDU BPDU BPDU BPDU No BPDU’s Received BPDU
Change to Forwarding State STP uses Bridge Protocol Data Units (BPDUs). If a switch’s port in blocking port stops receiving BPDUs: STP eventually ages out the STP information for the port (up to 50 secs) Moves port to forwarding state. This creates a forwarding loop or STP loop. How is it possible for the switch to stop receiving BPDUs while the port is up? The reason is unidirectional link. Rick Graziani

Unidirectional Link Problem
A unidirectional link occurs when traffic is transmitted between neighbors in one direction only. Unidirectional links can cause spanning-tree topology loops. S2 A unidirectional link occurs when traffic is transmitted between neighbors in one direction only. Unidirectional links can cause spanning-tree topology loops. Unidirectional Link Detection (UDLD) enables devices to detect when a unidirectional link exists and also to shut down the affected interface. UDLD is useful on fiber ports to prevent network issues related to miswiring at the patch panel, causing the link to be in up/up status but with BPDUs being lost. UDLD is a Layer 2 protocol that works with Layer 1 mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of the physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot, such as detecting the identities of neighbors and shutting down misconnected ports. When enabling both autonegotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols. With UDLD enabled, the switch periodically sends UDLD protocol packets to its neighbor and expects the packets to be echoed back before a predetermined timer expires. If the timer expires, the switch determines the link to be unidirectional and shuts down the port. The default interval for UDLD message is 15 seconds, which is configurable for faster detection. UDLD is a Layer 2 protocol enabled between adjacent switches. It uses MAC ccc-cc-cc with Subnetwork Access Protocol (SNAP) High-Level Data Link Control (HDLC) protocol type 0x0111. UDLD packets contain information including the device ID and port ID (of the sending switch) and the neighbor’s device ID and port ID. Neighbor devices with UDLD enabled send the same hello message. The link is bidirectional if devices on both sides receive each other’s UDLD packets. In Normal mode, UDLD simply changes the UDLD-enabled port to an undetermined state if it stops receiving UDLD messages from its directly connected neighbor. Aggressive mode UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port changes to the err-disable state, which effectively disables the port. Aggressive mode is the preferred method of configuring UDLD. By preventing this one-way communication, UDLD can be useful in spanning-tree networks. UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed. To reenable the port after correcting the problem, use the following interface-level commands in Cisco Catalyst switches: Switch(config-if)# shutdown Switch(config-if)# no shutdown STP prevents loops in the network by detecting loops and blocking the redundant ports. This loop detection is based on BPDUs received on switch ports. If a switch receives the same root BPDU from more than one port, it chooses the best port to the root bridge and blocks the other, redundant ports. Because receiving BPDUs is a critical part of the loop prevention process, it is important to detect unidirectional links by another method to ensure that BPDUs are sent in the appropriate direction on all links at all times. Otherwise, a unidirectional link ultimately leads to spanning-tree loops or black holes for routed traffic. For instance, if a Layer 3 or routed interface is experiencing a unidirectional link condition but the interface stays up, the switch continues to forward traffic to that interface, but the packet never reaches the far-end device. In this situation, a routing black hole exists. The solution to preventing these issues is to use aggressive mode UDLD. Aggressive mode UDLD running on Switches B and C in this scenario would detect the condition and would take corrective action before STP moves into the forwarding state. UDLD works by exchanging UDLD protocol packets between connected switches. For UDLD to function correctly, it must be enabled on switches on both sides of the link. A UDLD-enabled switch sends UDLD protocol packets with its own device ID and port ID to the neighboring device. The UDLD is in determined status if the switch sees its own information in the packet sent by the neighbor. If the device does not see itself in the neighboring device’s UDLD protocol packets, the link is determined as unidirectional. S2 S3 S2 is the designated bridge sending the root BPDUs At this moment, both S2 and S3 are forwarding to each other and there is no blocking port in the network! S3 waits until the max-age timer (20 seconds) expires before it takes action. When this timer expires, S3 moves through the listening and learning and then forwarding states. The link between S2 and S3 becomes unidirectional S2 can receive traffic from S3 S3 cannot receive traffic from S2

Unidirectional Link Detection (UDLD)
UDLD is a feature that is not specific to STP but is used with STP to enhance it. Unidirectional Link Detection (UDLD) Unidirectional Link Detection (UDLD) enables devices to detect when a unidirectional link exists and shuts down the affected interface. Useful on fiber ports to prevent network issues related to miswiring at the patch panel, causing the link to be in up/up status but with BPDUs being lost. A port configured with UDLD sends UDLD frames about every 15 seconds expecting a UDLD Echo reply. If there is no response, (i.e., no echo reply) then that signals a unidirectional link. S1 S2 S3 UDLD Reply

Two UDLD Modes Normal Mode:
When a unidirectional link is detected, the switch takes no action and the port is allowed to continue its operation. UDLD port status transitions to an undetermined state and generates a syslog message. Aggressive Mode: (Preferred) When a unidirectional link is detected the switch tries to reestablish the link. It sends one message a second, for 8 seconds. If none of these messages are sent back, the port is placed in error-disabled state. To reset interfaces shut down by UDLD, use either: udld reset privileged EXEC command Shut down the interface and then bringing it back up (i.e., shut, then no shut). UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed.

Enable UDLD Globally UDLD is disabled on all interfaces by default.
UDLD can be enabled / disabled globally: For normal mode: [no] udld enable global configuration command For aggressive mode: [no] udld aggressive global configuration command S1(config)# udld ? aggressive Enable UDLD protocol in aggressive mode on fiber ports except where locally configured enable Enable UDLD protocol on fiber ports except where locally configured message Set UDLD message parameters S1(config)# udld aggressive S1(config)# UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed. UDLD messages are sent every 60 seconds. Use these commands to reset an interface shut down by UDLD: The udld reset privileged EXEC command to reset all interfaces shut down by UDLD The shutdown and no shutdown interface configuration commands The no udld enable global configuration command followed by the udld {aggressive | enable} global configuration command to re-enable UDLD globally The no udld port interface configuration command followed by the udld port or udld port aggressive interface configuration command to re-enable UDLD on the specified interface The errdisable recovery cause udld and errdisable recovery interval interval global configuration commands to automatically recover from the UDLD error-disabled state.

port Enable UDLD protocol on this interface S1(config-if)# udld port ?
S1(config)# int fa0/1 S1(config-if)# udld ? port Enable UDLD protocol on this interface S1(config-if)# udld port ? aggressive Enable UDLD protocol in aggressive mode on this interface <cr> S1(config-if)# udld port aggressive S1(config-if)# end S1# *Mar 1 01:50:32.670: %SYS-5-CONFIG_I: Configured from console by console S1# show udld neighbors Port Device Name Device ID Port ID Neighbor State Fa0/1 FCQ1628Y5LK Fa0/ Unknown Fa0/1 FCQ1628Y5LK Fa0/ Bidirectional UDLD must be enabled on interconnecting interfaces. UDLD is now enable on S2 UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed. UDLD messages are sent every 60 seconds. Use these commands to reset an interface shut down by UDLD: The udld reset privileged EXEC command to reset all interfaces shut down by UDLD The shutdown and no shutdown interface configuration commands The no udld enable global configuration command followed by the udld {aggressive | enable} global configuration command to re-enable UDLD globally The no udld port interface configuration command followed by the udld port or udld port aggressive interface configuration command to re-enable UDLD on the specified interface The errdisable recovery cause udld and errdisable recovery interval interval global configuration commands to automatically recover from the UDLD error-disabled state. The port eventually transitions to a bidirectional state

Verify UDLD S1# show udld fa0/1 Interface Fa0/1 ---
Port enable administrative configuration setting: Enabled / in aggressive mode Port enable operational state: Enabled / in aggressive mode Current bidirectional state: Bidirectional Current operational state: Advertisement - Single neighbor detected Message interval: 15000 Time out interval: 5000 Entry 1 Expiration time: 31300 Device ID: 1 Current neighbor state: Bidirectional Device name: FCQ1628Y5LK Port ID: Fa0/1 Neighbor echo 1 device: FCQ1628Y5LE Neighbor echo 1 port: Fa0/1 Message interval: 15 Time out interval: 5 CDP Device name: S2 S1# Verify UDLD UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed. UDLD messages are sent every 60 seconds. Use these commands to reset an interface shut down by UDLD: The udld reset privileged EXEC command to reset all interfaces shut down by UDLD The shutdown and no shutdown interface configuration commands The no udld enable global configuration command followed by the udld {aggressive | enable} global configuration command to re-enable UDLD globally The no udld port interface configuration command followed by the udld port or udld port aggressive interface configuration command to re-enable UDLD on the specified interface The errdisable recovery cause udld and errdisable recovery interval interval global configuration commands to automatically recover from the UDLD error-disabled state.

Power Over Ethernet Discovery Protocols 352
Introduction to LLDP 352 Basic Configuration of LLDP 353 Discovering Neighbors Using LLDP 355 Unidirectional Link Detection 357 UDLD Mechanisms and Specifics 358 UDLD Configuration 358 Leveraging UDLD and STP Loop Guard Together 360 Power over Ethernet 360 PoE Components 362 PoE Standards 362 PoE Negotiation 362 Configuring and Verifying PoE 363 The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation. In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions. Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms. Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN. Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+. Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP. Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

Supplying Power to Network Peripherals
PoE switches allow for centralized methods of backup power. PoE leverages the data cabling infrastructure, and no additional power cable is required as with the case with power adapters or injectors.

Power over Ethernet (PoE)
PoE, also referred to as inline power, supplies power through the same cable as data. This technology reduces the need for power when wired connectivity is needed. PoE terminology includes: Power-sourcing devices (PSE): Includes Cisco Catalyst switches and power injectors. Powered devices: Includes access points, IP phones, IP cameras, thin clients, sensors, wall clocks, remote switches, and so on. Ethernet cabling All VoIP-enabled devices need a source of power. When these devices are handheld or mobile devices, the source of energy is usually a battery. Desktop or wall-mount VoIP phones can be connected to an A/C adapter for power. Although power is easily available in an office environment, using one AC/DC socket per VoIP device might be considered as a waste of physical resources. Because the phone has a cable connection to the Ethernet switch, a logical solution is to use this cable to provide power and connectivity. This setting, called Power over Ethernet (PoE), implies that the power comes through the Ethernet cable. The source of this power can be the switch itself, if the switch supports the PoE feature. If the switch cannot provide power, it is often possible to install an intermediate device between the switch and the VoIP phone. This device will receive power from a power outlet and will connect to the switch with another cable. It connects to the port to which the phone is supposed to connect. A third cable runs from this intermediate device to the phone, providing power along with data transmission to and from the switch. This device is called a power injector. To decrease the cost and complexity of the installation, powering the devices directly from the switch is often seen as the best solution. A great advantage of PoE is that no electrician is required. Anyone qualified to run Category 5e cable can install the cabling required to power PoE enabled devices. The standard Category 5e cable requirements still apply (maximum 328 feet or 100 meters). Two common PoE methods exist: the Cisco inline power and the IEEE 802.3af standard. Cisco inline power is pre-standard because the IEEE standard did not include specifications for PoE. The 802.3af task force amended this omission and a standard was realized in Cisco was actively involved in the 802.3af taskforce and support of the IEEE inline power standard. One of the main differences is that 802.3af uses a power detection mechanism that detects if the connected device needs power. Standard ratification of 802.3af occurred on September 11, 2009. New Cisco devices (switches, access points) support both methods for backward compatibility. No specific configuration is required to choose the Cisco pre-standard or the 802.3af standard. The IEEE 803.2af standard will be enhanced with a new standard 802.3at, which will provide more power in future. Note: Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP) protocol is a new standards-based protocol currently implemented in the Cisco phone and switching products. This protocol provides capability for the switches to recognize and provide power to any vendor phone attached to the network. An interim solution from Cisco called enhanced PoE provides up to 20W of power with the E-series switches. Although most devices can use power supplied by a standard 802.3af source, some new devices require more power. Power requirements for access-points are specific. Cisco IP Phones use less than 15 Watts and can be powered from a standard 802.3af switch. PoE support is done at the port level. The command power inline auto is sufficient to enable PoE and auto-detection of power requirements. A device not needing any PoE can still be connected to that port: Power is supplied only if the device requires it. The amount of power supplied will be automatically detected. You still have to plan for the overall power consumed by all the devices connected to the PoE switch.

PoE Negotiation IEEE Power Class Minimum Power Output Notes 15.4 Watts Default class 1 4 Watts Optional class 2 7 Watts 3 4 51 Watts Valid for 802.3at (thin client) devices only Cisco PoE switches only provide to a port if it specifically detects the need by the end device preventing the wasting of unnecessary power and so on. With 802.3af and 802.3at, the switch detects if there’s a powered device connected by supplying a small voltage across the Ethernet cable and then measures the resistance. The powered device can provide the switch with a power class information and the PoE switch allocates the powered device with the appropriate maximum power. IEEE 802.3at power classes are numbered from 0 to 4. All VoIP-enabled devices need a source of power. When these devices are handheld or mobile devices, the source of energy is usually a battery. Desktop or wall-mount VoIP phones can be connected to an A/C adapter for power. Although power is easily available in an office environment, using one AC/DC socket per VoIP device might be considered as a waste of physical resources. Because the phone has a cable connection to the Ethernet switch, a logical solution is to use this cable to provide power and connectivity. This setting, called Power over Ethernet (PoE), implies that the power comes through the Ethernet cable. The source of this power can be the switch itself, if the switch supports the PoE feature. If the switch cannot provide power, it is often possible to install an intermediate device between the switch and the VoIP phone. This device will receive power from a power outlet and will connect to the switch with another cable. It connects to the port to which the phone is supposed to connect. A third cable runs from this intermediate device to the phone, providing power along with data transmission to and from the switch. This device is called a power injector. To decrease the cost and complexity of the installation, powering the devices directly from the switch is often seen as the best solution. A great advantage of PoE is that no electrician is required. Anyone qualified to run Category 5e cable can install the cabling required to power PoE enabled devices. The standard Category 5e cable requirements still apply (maximum 328 feet or 100 meters). Two common PoE methods exist: the Cisco inline power and the IEEE 802.3af standard. Cisco inline power is pre-standard because the IEEE standard did not include specifications for PoE. The 802.3af task force amended this omission and a standard was realized in Cisco was actively involved in the 802.3af taskforce and support of the IEEE inline power standard. One of the main differences is that 802.3af uses a power detection mechanism that detects if the connected device needs power. Standard ratification of 802.3af occurred on September 11, 2009. New Cisco devices (switches, access points) support both methods for backward compatibility. No specific configuration is required to choose the Cisco pre-standard or the 802.3af standard. The IEEE 803.2af standard will be enhanced with a new standard 802.3at, which will provide more power in future. Note: Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP) protocol is a new standards-based protocol currently implemented in the Cisco phone and switching products. This protocol provides capability for the switches to recognize and provide power to any vendor phone attached to the network. An interim solution from Cisco called enhanced PoE provides up to 20W of power with the E-series switches. Although most devices can use power supplied by a standard 802.3af source, some new devices require more power. Power requirements for access-points are specific. Cisco IP Phones use less than 15 Watts and can be powered from a standard 802.3af switch. PoE support is done at the port level. The command power inline auto is sufficient to enable PoE and auto-detection of power requirements. A device not needing any PoE can still be connected to that port: Power is supplied only if the device requires it. The amount of power supplied will be automatically detected. You still have to plan for the overall power consumed by all the devices connected to the PoE switch.

Enabling PoE To enable PoE and autodetection at the port level, use the power inline auto command. The amount of power that is supplied will be automatically detected. A non-PoE device can still be connected to a PoE port. PoE is disabled with the power inline never command. Shutting down the port also stops the power supply. A PoE switch is limited by a switch power budget which indicates the amount of PoE devices it can connect to. The power budget is the total amount of power that a switch can offer to end devices collectively. The show power inline command to display the configuration and statistics about the power that is drawn by connected powered devices and the capacity of the power supply. All VoIP-enabled devices need a source of power. When these devices are handheld or mobile devices, the source of energy is usually a battery. Desktop or wall-mount VoIP phones can be connected to an A/C adapter for power. Although power is easily available in an office environment, using one AC/DC socket per VoIP device might be considered as a waste of physical resources. Because the phone has a cable connection to the Ethernet switch, a logical solution is to use this cable to provide power and connectivity. This setting, called Power over Ethernet (PoE), implies that the power comes through the Ethernet cable. The source of this power can be the switch itself, if the switch supports the PoE feature. If the switch cannot provide power, it is often possible to install an intermediate device between the switch and the VoIP phone. This device will receive power from a power outlet and will connect to the switch with another cable. It connects to the port to which the phone is supposed to connect. A third cable runs from this intermediate device to the phone, providing power along with data transmission to and from the switch. This device is called a power injector. To decrease the cost and complexity of the installation, powering the devices directly from the switch is often seen as the best solution. A great advantage of PoE is that no electrician is required. Anyone qualified to run Category 5e cable can install the cabling required to power PoE enabled devices. The standard Category 5e cable requirements still apply (maximum 328 feet or 100 meters). Two common PoE methods exist: the Cisco inline power and the IEEE 802.3af standard. Cisco inline power is pre-standard because the IEEE standard did not include specifications for PoE. The 802.3af task force amended this omission and a standard was realized in Cisco was actively involved in the 802.3af taskforce and support of the IEEE inline power standard. One of the main differences is that 802.3af uses a power detection mechanism that detects if the connected device needs power. Standard ratification of 802.3af occurred on September 11, 2009. New Cisco devices (switches, access points) support both methods for backward compatibility. No specific configuration is required to choose the Cisco pre-standard or the 802.3af standard. The IEEE 803.2af standard will be enhanced with a new standard 802.3at, which will provide more power in future. Note: Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP) protocol is a new standards-based protocol currently implemented in the Cisco phone and switching products. This protocol provides capability for the switches to recognize and provide power to any vendor phone attached to the network. An interim solution from Cisco called enhanced PoE provides up to 20W of power with the E-series switches. Although most devices can use power supplied by a standard 802.3af source, some new devices require more power. Power requirements for access-points are specific. Cisco IP Phones use less than 15 Watts and can be powered from a standard 802.3af switch. PoE support is done at the port level. The command power inline auto is sufficient to enable PoE and auto-detection of power requirements. A device not needing any PoE can still be connected to that port: Power is supplied only if the device requires it. The amount of power supplied will be automatically detected. You still have to plan for the overall power consumed by all the devices connected to the PoE switch.

Verify PoE S1# show power inline Module Available Used Remaining
(Watts) (Watts) (Watts) Interface Admin Oper Power Device Class Max (Watts) Gi1/0/1 auto off 0.0 n/a n/a 15.4 Gi1/0/2 auto on 15.4 AIR-LAP1142N-E-K Gi1/0/3 auto on 15.4 AIR-LAP1142N-E-K Gi1/0/4 auto on 15.4 AIR-LAP1142N-E-K Gi1/0/5 auto on 15.4 AIR-LAP1142N-E-K Gi1/0/6 auto on 15.4 AIR-LAP1142N-E-K Gi1/0/7 never off 0.0 n/a n/a 15.4 UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed. UDLD messages are sent every 60 seconds. Use these commands to reset an interface shut down by UDLD: The udld reset privileged EXEC command to reset all interfaces shut down by UDLD The shutdown and no shutdown interface configuration commands The no udld enable global configuration command followed by the udld {aggressive | enable} global configuration command to re-enable UDLD globally The no udld port interface configuration command followed by the udld port or udld port aggressive interface configuration command to re-enable UDLD on the specified interface The errdisable recovery cause udld and errdisable recovery interval interval global configuration commands to automatically recover from the UDLD error-disabled state.

SDM Templates SDM Templates 364 Monitoring Features 368
SDM Template Types 365 Choosing the Right SDM Template 367 System Resource Configuration on Other Platforms 367 Monitoring Features 368 SPAN and RSPAN Overview 368 SPAN Configuration 371 RSPAN Configuration 372 The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation. In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions. Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms. Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN. Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+. Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP. Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

SDM Templates The Switching Database Manager (SDM) templates available on some switches (e.g., 2960, 3560, or 3750) can be used to help manage how Layer 2 and Layer 3 switching information is maintained in the CAM and ternary content-addressable memory (TCAM). Cisco SDM templates are used for optimal use of system resources for specific features or feature set combination.

SDM Templates SDM Templates Description Default
Default template that provides for a balanced mix of unicast routes, connected, and host routes. Routing Enable this template if the device is performing IPv4 routing in the distribution or core of the network. Access Enable this template to maximize system resources for access control lists (ACLs) and accommodate a large number of ACLs. VLAN Enable this template to support the maximum number of unicast MAC addresses. Dual IPv4 and IPv6 Enable this template to support IPv4 nd IPv6 capabilities of the device. When enabling this template, you have to choose between default, routing, and VLAN.

SDM Templates The SDM lanbase-routing template can be enabled to allow routing between VLANs and to support static routing. To verify the current template, use the show sdm prefer command. To enable routing, use the sdm prefer lanbase-routing global config command and the reload the router.

Enable SDM Template for Routing
S1# show sdm prefer The current template is "default" template. The selected template optimizes the resources in the switch to support this level of features for 0 routed interfaces and 255 VLANs. number of unicast mac addresses: K number of IPv4 IGMP groups: K number of IPv4/MAC qos aces: k number of IPv4/MAC security aces: k S1# S1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. S1(config)# sdm prefer ? default Default bias dual-ipv4-and-ipv6 Support both IPv4 and IPv6 lanbase-routing Supports both IPv4 and IPv6 Static Routing qos QoS bias

Enable SDM Template for Routing
S1(config)# sdm prefer lanbase-routing Changes to the running SDM preferences have been stored, but cannot take effect until the next reload. Use 'show sdm prefer' to see what SDM preference is currently active. Switch(config)# do reload System configuration has been modified. Save? [yes/no]: yes Building configuration... [OK] Proceed with reload? [confirm] *Mar 20 00:10:24.557: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.

Verify SDM Template for Routing
S1# show sdm prefer The current template is "lanbase-routing" template. The selected template optimizes the resources in the switch to support this level of features for 0 routed interfaces and 255 VLANs. number of unicast mac addresses: K number of IPv4 IGMP groups + multicast routes: K number of IPv4 unicast routes: K number of directly-connected IPv4 hosts: K number of indirect IPv4 routes: number of IPv6 multicast groups: k number of directly-connected IPv6 addresses: K number of indirect IPv6 unicast routes: number of IPv4 policy based routing aces: number of IPv4/MAC qos aces: k number of IPv4/MAC security aces: k number of IPv6 policy based routing aces: number of IPv6 qos aces: k number of IPv6 security aces:

Monitoring Features SDM Templates 364 Monitoring Features 368
SDM Template Types 365 Choosing the Right SDM Template 367 System Resource Configuration on Other Platforms 367 Monitoring Features 368 SPAN and RSPAN Overview 368 SPAN Configuration 371 RSPAN Configuration 372 The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation. In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions. Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms. Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN. Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+. Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP. Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

SPAN Network traffic passing through ports or VLANs can be analyzed by using switched port analyzer (SPAN) or remote SPAN (RSPAN). SPAN can send a copy of traffic from one port to another port on the same switch where a network analyzer or monitoring device is connected. RSPAN can send a copy of traffic to a port on a different switch. SPAN is commonly deployed when an IPS/IDS is added to a network. IPS devices need to read all packets in one or more VLANs, and SPAN can be used to get the packets to the IPS devices.

SPAN Terminology Ingress traffic: Traffic that enters the switch.
Source (SPAN) port : A port that is monitored with use of the SPAN feature. Can be a Layer 2 or Layer 3 port (including VLAN). Ingress traffic: Traffic that enters the switch. Egress traffic: Traffic that leaves the switch. Destination (SPAN) port : A port that monitors source ports, usually where a packet analyzer or IPS is connected. SPAN Session: The association between source port (or VLAN) and a destination port (or VLAN).

Configure SPAN Configure a SPAN source port.
Configure a SPAN destination port. Switch(config)# monitor session number source [interface interface-id | vlan vlan-id] Switch(config)# monitor session number destination [interface interface-id | vlan vlan-id]

Configure SPAN Example
S1(config)# monitor session 1 source interface fa 0/1 S1(config)# monitor session 1 destination interface fa 0/2 S1(config)# exit S1# S1# show monitor Session 1 Type : Local Session Source Ports : Both : Fa0/1 Destination Ports : Fa0/2 Encapsulation : Native Ingress : Disabled

Configuring SPAN – Example #2
S1(config)# monitor session 1 source vlan 10 rx S1(config)# monitor session 1 source vlan 20 tx S1(config)# monitor session 1 destination interface FastEthernet 0/24 S1(config)# exit S1# S1# show monitor session 1 Session 1 Type : Local Session Source VLANs : RX Only : 10 TX Only : 20 Destination Ports : Fa3/4 Encapsulation : Native Ingress : Disabled In this example: Capture the received traffic on VLAN 10 Capture the transmitted traffic for VLAN 20 Forward the output to interface Fa 0/24

Remote Switched Port Analyzer (RSPAN)
RSPAN can copy traffic from ports or VLANs on one switch (i.e., source switch) to a port on a different switch (i.e., destination switch). A VLAN must be designated as the RSPAN VLAN and not be used for any other purposes. Note: SPAN and RSPAN vary by switching platforms.

RSPAN - Example Note: SW1(config)# vlan 100
SW1(config-vlan)# name SPAN-VLAN SW1(config-vlan)# remote-span SW1(config-vlan)# monitor session 2 source interface Fa0/7 SW1(config)# monitor session 2 destination remote vlan 100 Note: RSPAN VLAN numbers must match on both switches. Session numbers do not need to match. SW2(config)# vlan 100 SW2(config-vlan)# name SPAN-VLAN SW2(config-vlan)# remote-span SW2(config-vlan)# monitor session 3 destination interface Fa0/8 SW2(config)# monitor session 3 source remote vlan 100

Verifying RSPAN - Example
SW1# show monitor Session 2 Type : Remote Source Session Source Ports : Both : Fa0/7 Dest RSPAN VLAN : 100 The show monitor command is used to verify the configuration of RSPAN on the source and destination switches. Notice that on the source switch (SW1) the session is identified as a Remote Source Session, while on the destination switch (SW2) it is marked as a Remote Destination Session. SW2# show monitor Session 3 Type : Remote Destination Session Source RSPAN VLAN : 100 Destination Ports : Fa0/8 Encapsulation : Native Ingress : Disabled

IP SLA IP SLA 374 Introduction to IP SLA 375
IP SLA Source and Responder 377 IP SLA Configuration 377 IP SLA Operation with Responder 379 IP SLA Time Stamps 381 Configuring Authentication for IP SLA 382 IP SLA Example for UDP Jitter 383 The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation. In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions. Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms. Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN. Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+. Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP. Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

IP Service Level Agreement (SLA)
The network has become increasingly critical for customers, and any downtime or degradation can adversely impact revenue. Companies need some form of predictability with IP services. An SLA is a contract between the network provider and its customers, or between a network department and internal corporate customers. It provides a form of guarantee to customers about the level of user experience. An SLA specifies connectivity and performance agreements for an end-user service from a service provider. The SLA typically outlines the minimum level of service and the expected level of service. The networking department can use the SLAs to verify that the service provider is meeting its own SLAs or to define service levels for critical business applications. An SLA can also be used as the basis for planning budgets and justifying network expenditures. Administrators can ultimately reduce the mean time to repair (MTTR) by proactively isolating network issues. They can change the network configuration based on optimized performance metrics. Typically, the technical components of an SLA contain a guarantee level for network availability, network performance in terms of round-trip time (RTT), and network response in terms of latency, jitter, and packet loss. The specifics of an SLA vary depending on the applications an organization is supporting in the network. Contract between service provider and customers. Specifies connectivity and performance agreements. Includes guaranteed level of network availability, network performance in terms of round-trip time, and network response in terms of latency, jitter, and packet loss.

Cisco IOS IP SLAs Cisco IOS IP Service Level Agreements (SLAs) uses active traffic monitoring for measuring network performance. IP SLAs sends simulated data across the network and measure performance statistics. The IP SLAs feature can provide performance data between: Cisco devices Cisco device and a host IP SLAs are used for: Edge-to-edge network availability monitoring Network performance monitoring and network performance visibility Voice over IP (VoIP), video, and virtual private network (VPN) monitoring SLA monitoring IP service network health MPLS network monitoring Troubleshooting of network operation Cisco IOS IP SLAs can be used to verify whether a network element (e.g., IP address or an open TCP port), is active and responsive.

Cisco IOS IP SLAs IP SLA provides feedback on these functions (among others): Gather information of VoIP quality. Track interfaces to influence behavior of first-hop redundancy protocols. IP SLA uses probes to measure: Network latency and response time Packet-loss statistics Network jitter and voice quality scoring End-to-end network connectivity Cisco IOS IP SLAs can be used to verify whether a network element (e.g., IP address or an open TCP port), is active and responsive.

IP SLA Measurements IP SLA enables a router to send synthetic traffic to devices to measure performance. One-way travel times and packet loss are gathered. IP SLA can be used for: IP SLA can measure: Supported protocols: Certain measurements also enable jitter data to be collected. Following are several common functions for IP SLA measurements: Edge-to-edge network availability monitoring Network performance monitoring and network performance visibility VoIP, video, and virtual private network (VPN) monitoring IP service network health readiness or assessment Multiprotocol Label Switching (MPLS) network monitoring Troubleshooting of network operation IP SLA measurement uses a variety of operations and actively generated traffic probes to gather many types of measurement statistics: Network latency and response time Packet loss statistics Network jitter and voice quality scoring End-to-end network connectivity Multiple IP SLA operations (measurements) can run in a network at one time. Reporting tools use SNMP to extract the data into a database and then report on it. IP SLA measurements enable the network manager to verify service guarantees, which increases network reliability by validating network performance, proactively identifying network issues, and easing the deployment of new IP services. Generated traffic to measure the network DNS Server R1 R2 IP SLAs Source Generate ICMP traffic to any reaschable device measure to network response R1 R2 IP SLAs Source Responder MIB data retrieved via SNMP

IP SLAs Operations There are two types of IP SLAs operations:
Those in which the target device is not running the IP SLAs responder component (such as a web server or IP host). Mostly ICMP generated traffic. Those in which the target device Cisco router is running the IP SLAs responder component. Measurement accuracy is improved when the target is a responder. Additional statistics can be gathered. Generated ICMP traffic to measure network response IP SLAs Source DNS Server R1 R2 There are two types of IP SLAs operations: Generated traffic to measure the network IP SLAs Source IP SLAs Responder R1 R2 MIB data retrieved via SNMP

Configuring IP SLA To implement IP SLA network performance measurement, perform the following tasks: Enable the IP SLAs responder, if required. Configure the required IP SLA’s operation type. Configure any options available for the specified operation type. Configure threshold conditions, if required. Schedule the operation to run, and then let the operation run for a period of time to gather statistics. Display and interpret the results of the operation using the Cisco IOS CLI or an NMS with SNMP. There are many ways of implementing IP SLA. Different hardware platforms and different IOS versions might have a slightly different approach to IP SLA configuration.

Configuring IP SLA – Example
Switch(config)# ip sla 12 Switch(config-ip-sla)# icmp-echo Switch(config-ip-sla-echo)# frequency 30 Switch(config-ip-sla-echo)# exit Switch(config)# ip sla schedule 5 start-time now life forever Switch(config)# end The device should be configured to answer this message with the ip sla responder command. At this point, the type of message is configured, along with its frequency and target address. The next step is to decide when this test should start. This is configured with the ip sla monitor schedule command. The test is to start immediately and to last forever. When the IP SLA test has been defined, additional configuration is needed to determine what action should be taken when the test result is received. The track command follows the IP SLA test result. Further commands can then be configured to use the track result to decrement interfaces’ priority or activate backup links.

Verifying IP SLA Configuration
When IP SLA is configured, the test is conducted as per the scheduled configuration. The test might succeed or fail. If you do not monitor the test results, it might fail silently. Use the show ip sla statistics command to display information about the test. S1# show ip sla statistics Round Trip Time (RTT) for Index 1 Latest RTT: NoConnection/Busy/Timeout Latest operation start time: 11:11: eastern Thu Jul Latest operation return code: Timeout Over thresholds occurred: FALSE Number of successes: 177 Number of failures: 6 Operation time to live: Forever Operational state of entry: Active Last time this entry was reset: Never The show ip sla statistics command displays, among other parameters, the number of successes and number of failures. It also shows if the test is still being run. Here we see that the test in active state, having succeeded 177 times and failed 6 times when the command was issued. Monitoring these statistics over time can tell you if there is a connection issue discovered through the IP SLA test.

Example: Network Availability
Router(config)# ip route fa0/0 Router(config)# ip route fa0/1 5 fa0/0 fa0/1 Customer A is multihoming to two ISPs. Customer A is not using BGP with the ISPs; but using static default routes. Two default static routes with different administrative distances are configured Link to ISP-1 is the primary link Link to ISP-2 is the backup link The static default route with the lower administrative distance will be preferred and injected into the routing table. However, if there is a problem within the ISP-1 domain but its interface to Customer A is still up, all traffic from Customer A will still go to that ISP The traffic may then get lost within the ISP.

The solution to this issue is the Cisco IOS IP SLAs functionality
fa0/0 fa0/1 The solution to this issue is the Cisco IOS IP SLAs functionality Configure the SLAs to: Continuously check the reachability of a specific destination such as: Provider edge [PE] router interface ISP's DNS server Any other specific destination: and Conditionally announce the default route only if the connectivity is verified.

type echo: specifies that the ICMP echoes are sent:
R1(config)# ip sla 11 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/0 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule schedule 11 life forever start-time now R1(config)# track 1 rtr 11 reachability R1(config)# ip route fa0/0 2 track 1 Probe Tracking Object Status of Tracking Object Defining the Probe ip sla: defines probe 11 type echo: specifies that the ICMP echoes are sent: To destination to check connectivity With the source interface of FastEthernet0/0 frequency 10: schedules the connectivity test to repeat every 10 seconds. ip sla monitor schedule 11 life forever start-time now: defines the start time of now and it will continue forever

Defining the Tracking Object
R1(config)# ip sla 11 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/0 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule schedule 11 life forever start-time now R1(config)# track 1 rtr 11 reachability R1(config)# ip route fa0/0 2 track 1 Probe Tracking Object Status of Tracking Object Defining the Tracking Object track 1 rtr 11 reachability: Specifies that: Object 1 is tracked (next step) Linked to probe 11 (defined in the first step) so that the reachability of the is tracked.

Defining an action based on the status of the tracking object
R1(config)# ip sla 11 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/0 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule schedule 11 life forever start-time now R1(config)# track 1 ip sla 11 reachability R1(config)# ip route fa0/0 2 track 1 Probe Tracking Object Status of Tracking Object AD=2 Defining an action based on the status of the tracking object ip route fa0/0 2 track 1: Conditionally announces the default route, out fa0/0, with an administrative distance 2 if the result of tracking object 1 is true – if the probe is successful. To summarize: If is reachable, a static default route out Fa0/0 with an administrative distance of 2, is installed in the routing table.

type echo: specifies that the ICMP echoes are sent:
R1(config)# ip sla 22 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/1 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule 22 life forever start-time now R1(config)# track 2 ip sla 22 reachability R1(config)# ip route fa0/1 3 track 2 Probe Tracking Object Status of Tracking Object Defining the Probe ip sla: defines probe 22 type echo: specifies that the ICMP echoes are sent: To destination to check connectivity, With the source interface of FastEthernet0/1 frequency 10: schedules the connectivity test to repeat every 10 seconds. ip sla monitor schedule 22 life forever start-time now: defines the start time of now and it will continue forever

Defining the Tracking Object
R1(config)# ip sla monitor 22 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/1 R1(config-rtr)# frequency 10 R1(config)# ip sla monitor schedule 22 life forever start-time now R1(config)# track 2 ip sla 22 reachability R1(config)# ip route fa0/1 3 track 2 Probe Tracking Object Status of Tracking Object Defining the Tracking Object track 1 rtr 22 reachability: Specifies that: Object 2 is tracked (next step) Linked to probe 22 (defined in the first step) so that the reachability of the is tracked.

Defining an action based on the status of the tracking object
R1(config)# ip sla 22 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/1 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule 22 life forever start-time now R1(config)# track 2 ip sla 22 reachability R1(config)# ip route fa0/1 3 track 2 Probe Tracking Object Status of Tracking Object AD=2 AD=3 Defining an action based on the status of the tracking object ip route fa 0/1 3 track 2: Conditionally announces the default route, exit fa0/1, with an administrative distance 3 if the result of tracking object 1 is true – if the probe is successful. To summarize: If is reachable, a static default route exit fa0/1 with an administrative distance of 3 is “offered” to the routing table. Because this default route has a higher AD of 3, if the path via R2 is available, this path will be the backup path.

R1(config)# ip sla 11 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/0 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule 11 life forever start-time now R1(config)# track 1 ip sla 11 reachability R1(config)# ip route fa0/0 2 track 1 Probe Tracking Object Status of Tracking Object R1(config)# ip sla 22 R1(config-rtr)# type echo protocol ipIcmpEcho source-interface fa0/1 R1(config-rtr)# frequency 10 R1(config)# ip sla schedule 22 life forever start-time now R1(config)# track 2 ip sla 22 reachability R1(config)# ip route fa0/1 3 track 2 Probe Tracking Object Status of Tracking Object If is reachable, a static default route via R2 with an administrative distance of 2, is installed in the routing table If is reachable, a static default route via R3 with an administrative distance of 3 is “available” to the routing table as a backup path. AD=2 AD=3

Lab 8-1

Ch. 8 Switching Features and Technologies for Campus Networks

Similar presentations

Presentation on theme: "Ch. 8 Switching Features and Technologies for Campus Networks"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Ch. 8 Switching Features and Technologies for Campus Networks

Similar presentations

Presentation on theme: "Ch. 8 Switching Features and Technologies for Campus Networks"— Presentation transcript:

Similar presentations

About project

Feedback