Scenario 10-1: Using IP and LAN Connectivity Tools
| An important feature of Cisco Catalyst switches is the troubleshooting tools that are provided as part of the operating system, which enable you to quickly diagnose problems that might arise in your switched environment. Cisco Catalyst switches provide the following troubleshooting tools:
In this scenario, you learn about the IP and LAN connectivity tools. The use of debugging has been demonstrated throughout this book; monitoring tools are covered later in Scenario 10-6. Understanding IP and LAN Connectivity ToolsThe tools provided for verifying connectivity to the network are important features of any networking device. As a network engineer, when you install networking equipment and attach it to the network, you want confirmation that the equipment is configured correctly and is communicating with the network. Cisco Catalyst switches provide traditional IP connectivity tools, such as ping and traceroute, which are used for verifying management communications on Layer 2 switches and are useful for verifying Layer 3 routing on Layer 3 switches. Cisco Catalyst switches also provide LAN (Layer 2) connectivity tools, such as the Cisco Discovery Protocol (CDP) and Layer 2 traceroute (l2trace), which are useful for verifying interswitch communications and the Layer 2 transmission paths within a Layer 2 domain. In summary, the following tools are provided on Cisco Catalyst switches for verifying Layer 2 and Layer 3 (IP) connectivity:
Each of these tools is now discussed and demonstrated. IP Connectivity Toolsthe ping UtilityThe ping utility represents the most fundamental tool used for verifying Layer 3 connectivity. ping can quickly provide you with information indicating whether or not a remote device is alive, as well as the end-to-end delay of the network path to the remote device. In this book, you have used the ping utility numerous times to verify basic IP connectivity between systems; as a network engineer you will probably use ping on a daily basis to ensure networks that you are configuring are working as expected or to aid in the diagnosis of faults that are affecting connectivity. On Cisco IOS-based Catalyst switches, you can use either the basic ping or extended ping utilities for testing connectivity. The basic ping sends just five ICMP echo requests to a remote destination and indicates whether or not an ICMP echo reply was received and how long it took for each reply to be received. The extended ping allows you much more flexibility, by allowing you to send a configurable number of ICMP echo requests, with the packet size of your choice along with many other parameters. Example 10-1 demonstrates the use of the extended ping utility on Cisco IOS: Example 10-1. Using the extended ping UtilitySwitch# ping Protocol [ip]: ip Target IP address: 192.168.1.1 Repeat count [5]: 10 Datagram size [100]: 1500 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: VLAN 1 Type of service [0]: 7 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: n Type escape sequence to abort. Sending 10, 1500-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 1/2/4 ms In Example 10-1, you just initially specify the command ping to invoke the interactive extended ping utility. If you are using extended ping for testing IP connectivity, you can also use the ping ip command to invoke an extended IP ping. Notice the round-trip time statistics, which provide an indication of the current end-to-end latency in the network. NOTE If you specify an IP address after the ping command, a basic ping is assumed, and five 100-byte ICMP echo request packets are sent. By using the extended ping utility, you can modify the parameters of the ping test such as increasing the number of packets sent and the size of each packet sent. You can also specify the source IP address used in each packet, which is useful if you want to ensure that the return path from the destination being tested has the necessary routing information to reach the source IP address specified. NOTE The source IP address specified must be a valid IP address on the local switch itself; you can't use extended ping to spoof (masquerade) a source IP address of another device. You can configure other advanced features such as setting the type of service (useful for testing quality of service), setting the don't fragment (DF) bit (useful for determining the lowest maximum transmission unit [MTU] of a transmission path by testing whether or not IP packets of a particular length can reach a destination), and more. On CatOS, the ping utility is much simpler than the extended ping available on Cisco IOS because Cisco IOS was originally designed for Layer 3 routers rather than Layer 2 switches that essentially act only like an end device in terms of IP. You can use the s switch with the ping command to send a continuous stream of Internet Control Message Protocol (ICMP) traffic until you interrupt the utility. Example 10-2 shows the syntax of the ping utility on CatOS. Example 10-2. Using the ping utility on CatOSConsole> (enable) ping <host> Console> (enable) ping s <host> [packet_size] [packet_count] In Example 10-2, if you use the ping command with no options, a basic ping is assumed and five 56-byte ICMP echo requests are sent to the host specified. If you use the s option, you can optionally specify a custom packet size and packet count. If you do not specify a custom packet size and packet count with the s option, an almost infinite amount (2,147,483,647) of 56-byte ICMP echo requests are sent to the host specified. NOTE To interrupt the ping s command, use the Ctrl-C key sequence. Example 10-3 shows an example of using the different methods available to the ping utility on a CatOS-based Catalyst switch. Example 10-3. Using the ping utility on CatOSConsole> (enable) ping 192.168.1.1 !!!!! -----192.168.1.1 PING Statistics------ 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 1/1/1 Console> (enable) ping s 192.168.1.1 1400 2 PING 192.168.1.1: 1400 data bytes 1408 bytes from 192.168.1.1: icmp_seq=0. time=18 ms 1408 bytes from 192.168.1.1: icmp_seq=1. time=10 ms ----192.168.1.1 PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/14/18 Console> (enable) ping s 192.168.1.1 PING 192.168.1.1: 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0. time=7 ms 64 bytes from 192.168.1.1: icmp_seq=1. time=11 ms 64 bytes from 192.168.1.1: icmp_seq=2. time=10 ms 64 bytes from 192.168.1.1: icmp_seq=3. time=6 ms 64 bytes from 192.168.1.1: icmp_seq=4. time=10 ms 64 bytes from 192.168.1.1: icmp_seq=5. time=9 ms 64 bytes from 192.168.1.1: icmp_seq=6. time=8 ms 64 bytes from 192.168.1.1: icmp_seq=7. time=7 ms 64 bytes from 192.168.1.1: icmp_seq=8. time=9 ms ^C ----192.168.1.1 PING Statistics---- 9 packets transmitted, 9 packets received, 0% packet loss round-trip (ms) min/avg/max = 6/8/11 In Example 10-3, the base ping utility with no options is first demonstrated. Next, the ping s 192.168.1.1 1400 2 command is executed, which generates two 1400-byte ICMP echo requests (1400 bytes represents the data payload of the ICMP. Notice that the ICMP header adds an additional 8 bytes to the packet). Finally, the ping s 192.168.1.1 command is executed, which generates continuous ICMP echo requests every second, until the Ctrl-C break sequence (^C) is executed. The traceroute UtilityThe traceroute utility is a useful tool that is used to determine the Layer 3 path taken to reach a destination host from a source host. Figure 10-1 illustrates what is meant by the path between a source and destination host. Figure 10-1. Network Path to a Destination Host
In Figure 10-1, the source and destination "hosts" are routers. The arrows indicate the path that traffic takes from the source host to the destination host. In Figure 10-1, you might think that it does not matter which path is taken. However, the links between Switch-A and Switch-B might be faster and more reliable; hence, the path via Switch-B should be preferred. On the other hand, the dual paths via Switch-B and Switch-C might be equal-cost paths, designed for redundancy and load sharing; hence, traffic should alternate over each path. The traceroute utility allows you to verify that IP traffic is flowing over the correct and desired path(s) in your network. NOTE The traceroute utility verifies the network path only from the source to destination (as indicated by the arrows in Figure 10-1), but does not verify return traffic from the destination to source. When the return path is different from the forward path, this is described as asymmetric routing (as opposed to symmetric routing). Asymmetric routing can be undesirable because although traffic might take the most optimum path to a destination, return traffic takes a less optimum path back. Asymmetric routing also causes issues for firewalls, as most firewalls classify traffic in terms of connections and must see both the forward and return traffic on a connection (for example, if a firewall receives a return packet associated with a connection, but has not seen the connection setup packets sent in the forward direction, the firewall rejects the packet as part of an invalid connection). Traditionally, because the traceroute utility is useful only for routed IP networks, it has not been used too often on Layer 2 devices such as switches. However, with the growing number of Layer 3 switched networks, the traceroute utility has become a useful troubleshooting utility for L3 switched LAN networks. The traceroute utility works by using the time-to-live (TTL) field inside an IP packet header. Every IP packet header has a TTL field, which specifies how long the packet should "live," and this field is used to prevent IP packets from continuously circulating around routing loops. A routing loop exists when a packet bounces back and forth between two or more routers and can be present due to the convergence behavior of older distance-vector routing protocols after a network failure. Each router that routes an IP packet decrements the TTL field; if a routing loop exists in the network, the TTL field is eventually decremented to 0 and the IP packet is dropped. When an IP packet is dropped due to the TTL field reaching zero (or expiring), the router that drops the packet sends an ICMP TTL expired in transit message back to the source of the IP packet, to inform the source that the packet never reached its destination. The source IP address of the ICMP message is the router that dropped the packet, which therefore indicates to the sender that the router is part of the network path to the destination The goal of traceroute is to determine the network path taken, hop-by-hop to reach a destination IP address. traceroute works by generating ICMP echo request packets addressed to the desired destination, initially starting with a TTL of 1 and then generating subsequent ICMP echo request packets with an incrementing TTL (i.e., 1,2,3,4 and so on). This has the effect of causing each router in turn along the transmission path to the destination to receive an ICMP echo request packet with a TTL of 1, which each switch discards and then generates an ICMP TTL Expired in Transit message that is sent back to the source. Figure 10-2 demonstrates how traceroute works in the network of Figure 10-1. Figure 10-2. How the traceroute Utility Works
In Figure 10-2, the following events occur:
NOTE In the case of using traceroute on Windows-based hosts, where ICMP echo replies are used for probes, an ICMP Echo Reply message is sent back from the destination host. Example 10-4 demonstrates the use of the traceroute utility on the source in Figure 10-2, assuming the source is a CatOS-based Catalyst switch. Example 10-4. Using the traceroute UtilityConsole> (enable) traceroute 192.168.2.100 traceroute to 192.168.2.100 (192.168.2.100), 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 12 ms 8 ms 12 ms 2 172.16.1.2 (172.16.1.2) 24 ms 20 ms 23 ms 3 172.17.1.1 (172.17.1.1) 28 ms 23 ms 28 ms 4 192.168.2.100 (192.168.2.100) 32 ms 30 ms 31 ms In Example 10-4, you can see that each hop to the destination is indicated, as described in Figure 10-2. Notice that three response times are listed for each hop; this is because the traceroute utility actually generates three probes for determining each hop. Example 10-5 demonstrates the use of the traceroute utility on the source in Figure 10-2, assuming the source is a Cisco IOS-based Catalyst switch. Example 10-5. Using the traceroute UtilitySwitch# traceroute 192.168.2.100 Type escape sequence to abort. Tracing the route to 192.168.2.100 1 192.168.1.1 12 msec 8 msec 12 msec 2 172.16.1.2 24 msec 20 msec 23 msec 3 172.17.1.1 28 msec 23 msec 28 msec 4 192.168.2.100 32 msec 30 msec 31 msec NOTE Remember that the traceroute utility verifies only the Layer 3 path throughout the network and has no visibility of the Layer 2 switches a packet might traverse. In other words, only Layer 3 routers decrement the TTL of traceroute probes and only Layer 3 routers generate TTL Expired in Transit messages, which allow a source to collect transmission path information. The Layer 2 traceroute utility (l2trace) enables you to determine the Layer 2 hops a frame takes to reach a particular destination within a Layer 2 domain. Using Cisco Discovery Protocol (CDP)Cisco Discovery Protocol (CDP) is a proprietary protocol that is useful for troubleshooting networks that use Cisco devices. All Cisco routers and switches support CDP, which is used to discover other directly connected Cisco devices. CDP runs on top of the Layer 2 protocol for a connection, relying on the underlying Layer 2 protocol for transport of CDP messages. Within a LAN environment, CDP messages are sent in Ethernet frames, with a multicast destination address of 01-00-0C-CC-CC-CC. A Cisco device receiving CDP messages processes each CDP message but does not propagate the message, instead discarding it after the appropriate information has been retrieved from the message. In this way, CDP is a protocol that can be used to verify connectivity to other directly connected devices onlyit cannot provide information about remotely connected devices. Figure 10-3 demonstrates the generation of CDP messages. Figure 10-3. CDP Message Propagation
In Figure 10-3, each Cisco device generates CDP messages that are periodically sent out each interface over the appropriate Layer 2 encapsulation. Any receiving Cisco device passes the CDP message to the main CPU, where the contents are read and the CDP packet discarded (i.e., CDP packets received by Cisco devices are never propagated). This means that even though Router-A and Router-B are on the same VLAN, they never see CDP messages from each other because Switch-A is a Cisco device and hence absorbs the CDP messages generated by each router. If Switch-A were a non-Cisco device, because CDP is a proprietary protocol and uses multicast addressing, any CDP messages received would be flooded based upon the destination multicast MAC address, meaning Router-A and Router-B would see CDP messages advertised by each other. Of course, you might be wondering exactly what these periodic CDP messages contain and what they are used for. CDP is used primarily for two main functions:
CDP is essential for some inter-device communications. For example, in the case of Cisco IP phones that are attached to Catalyst switches the IP phone can learn the virtual LAN (VLAN) ID that should be used to tag voice traffic via CDP messages sent by the switch; this means that you have to program only your switch, and all Cisco IP phones auto-learn the correct voice VLAN ID. Again on IP phones, some Catalyst switches support inline power, which allows an IP phone to be powered over the RJ-45 Ethernet cables. CDP messages are used by the IP phones to indicate to the switch the power requirements of the phone. CDP also provides an effective troubleshooting tool, especially in pure Cisco environments. If you need to troubleshoot problems with connectivity to locally connected Cisco devices, CDP can be used to confirm that devices can actually see each other. CDP can also be used to find out more details about locally connected devices such as Layer 3 protocol (e.g., IP or IPX) addressing, host name, Cisco device type and model and serial number. In LAN environments, CDP messages also pass information about the speed, duplex, and VLAN configuration of the interface over which the CDP message is sent, which allows remotely connected devices to detect if a duplex or native VLAN mismatch is present; this is particularly useful in switched LAN network. The following shows an example of a SYSLOG message that is generated when a duplex mismatch is detected on a Cisco Catalyst switch: 2002 Jul 09 01:10:43 %CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected on port 2/1 The preceding message is useful for detecting duplex mismatches, which do not affect LAN connectivity but do affect the performance of the connection significantly. Notice that the message even indicates the port that you should be investigating. CDP is also useful for detecting native VLAN mismatches. As you learned in Chapter 3, "Trunking and Bandwidth Aggregation," the 802.1Q trunking protocol supports the concept of a native VLAN. Frames belonging to the native VLAN do not have an 802.1Q tag attached, meaning it is very important that both ends of a trunk are configured with the same native VLAN. If a native VLAN mismatch occurs, one side of the trunk believes untagged frames belong to a different VLAN than the other side. This situation causes spanning tree to shut down both of the conflicting native VLANs on both sides of the trunk to avoid possible bridging loops. The following shows an example of a SYSLOG message that is generated when a native VLAN mismatch is detected on a Cisco Catalyst switch: 2003 Apr 26 01:01:39 %CDP-4-NVLANMISMATCH:Native vlan mismatch detected on port 2/1 CDP is enabled by default and periodically sends messages every 60 seconds by default. A CDP neighbor represents a remote device from which CDP messages have been received; if a CDP message is not heard from a neighbor for more than 180 seconds, the device is considered down and removed from the list of neighbors. On both CatOS and Cisco IOS, the show cdp neighbors command provides a summary of each CDP neighbor. The show cdp neighbors detail command allows you to view detailed information about each neighbor. Example 10-6 demonstrates the show cdp neighbors command on a Catalyst 4000 switch. Example 10-6. Using the show cdp neighbors CommandConsole> (enable) show cdp neighbors * - indicates vlan mismatch. # - indicates duplex mismatch. Port Device-ID Port-ID Platform -------- ------------------------- ------------------------- ------------ 2/1 Switch-A FastEthernet0/1* cisco WS-C3550-24 In Example 10-6, notice that the shaded entry indicates a Cisco Catalyst 3550-24 switch (WS-C3550-24) is attached to port 2/1 on the local switch. The interface on the remote switch that attaches to the local switch is FastEthernet0/1, and the * character after this interface indicates a native VLAN mismatch. Example 10-7 demonstrates the show cdp neighbors detail command on the same Catalyst 4000 switch in Example 10-6. Example 10-7. Using the show cdp neighbors detail CommandConsole> (enable) show cdp neighbors detail Port (Our Port): 2/1 Device-ID: Switch-A Device Addresses: IP Address: 192.168.1.1 Holdtime: 173 sec Capabilities: ROUTER SWITCH IGMP Version: Cisco Internetwork Operating System Software IOS (tm) C3550 Software (C3550-I5K2L2Q3-M), Version 12.1(13)EA1a, RELEASE SOFTWARE (fc1) Copyright 1986-2003 by cisco Systems, Inc. Compiled Tue 25-Mar-03 23:56 by yenanh Platform: cisco WS-C3550-24 Port-ID (Port on Neighbors's Device): FastEthernet0/1 VTP Management Domain: LANPS Native VLAN: 10 (Mismatch) Duplex: full System Name: unknown System Object ID: unknown Management Addresses: unknown Physical Location: unknown In Example 10-7, you can see several useful pieces of information transmitted in CDP messages from the remote device. Notice that you can see the IP address of the remote switch (192.168.1.1); you also can see that the switch is running Cisco IOS 12.1(13)EA1a software. The command output also displays the VTP domain configured on a neighbor, as well as native VLAN and duplex information. WARNING CDP messages are unencrypted and as such pose a security risk by potentially transmitting device configuration parameters to unauthorized parties attached to the LAN. CDP should be disabled in any secure LAN environment. See Chapter 8, "Traffic Filtering and Security," for more details. Layer 2 TracerouteThe Layer 2 traceroute utility (l2trace) is an extremely useful utility that is supported on the following Cisco Catalyst switch platforms:
The l2trace utility is similar in functionality to the IP traceroute utility; instead of indicating the router hops in the path to a destination IP address, the l2trace utility indicates the switch hops in the path to a destination MAC address within a Layer 2 network. This is very useful if you want to verify that traffic is flowing over the correct paths in a complex switched network and is most commonly used to verify spanning-tree topologies are being generated as planned. The only limitations of the l2trace utility are that all switches in the l2trace path must support the utility, CDP must be enabled on all switches, and it is supported only between devices in the same VLAN. To demonstrate the use of Layer 2 traceroute, consider the following redundant LAN topology illustrated in Figure 10-4. Figure 10-4. Redundant LAN Topology
In Figure 10-4, a redundant LAN topology includes three Catalyst switches that are connected in a looped Layer 2 topology. The Catalyst 4000 switch (Switch-A) is configured as the root bridge for spanning tree and Figure 10-4 shows each of the spanning tree port roles (RP = root port, DP = designated port, and BP = blocked port). Interface FastEthernet0/2 on Switch-C is placed in a blocking state to remove the loop from the Layer 2 topology. The expected Layer 2 transmission path between Host-A and Host-B is indicated in Figure 10-4. To verify this is indeed the path taken through the network, the Layer 2 traceroute utility can be used. Before the use of the Layer 2 traceroute utility is demonstrated in Figure 10-4, you need to understand the configuration prerequisites that must be implemented before the Layer 2 traceroute works:
In Figure 10-4, assume that CDP is running on all switches. You can use the show cdp neighbors command on each switch to verify this. Each switch in Figure 10-4 supports the Layer 2 traceroute, and assuming the indicated IP addressing for each switch is in place, all switches should be reachable from each other via IP (this should be tested using ping). Host-A and Host-B are active hosts on the network; therefore, their MAC addresses can be populated in the CAM tables of the appropriate switches by simply generating traffic between the two hosts. On Cisco IOS, the same traceroute command used to perform Layer 3 traceroutes is also used to perform Layer 2 traceroutes when configured with the following syntax: Switch# traceroute mac [interface interface-type interface-id] source-mac [interface interface-type interface-id] destination-mac [vlan vlan-id] [detail] Switch# traceroute mac ip source-ip destination-ip [detail] Notice that the mac or mac ip keywords are used to indicate a Layer 2 traceroute as opposed to a Layer 3 traceroute. If you use the traceroute mac command, you must specify the source MAC address and destination MAC address for the traffic flow between the hosts that you want to trace. The optional interface parameters are used to define the interfaces on the source and destination switches, the optional vlan keyword allows to specify the VLAN through which the Layer 2 traceroute should be performed, and the optional detail keyword enables more detail trace information. NOTE A useful feature of the Layer 2 traceroute is that you don't have to execute the command from the switch that is connected to the source specified in the trace. For example in Figure 10-4, you can execute a Layer 2 traceroute between Host-A and Host-B from any switch in the network, not just Switch-B. If you use the traceroute mac ip command, you need to specify only the source IP address and destination IP address for the traffic flow between the hosts that you want to trace. Because a Layer 2 traceroute works only for paths within a Layer 2 network (i.e., VLAN), you must ensure the source and destination IP address represent hosts within the same IP subnet/VLAN. The switch executing the trace consults its local ARP cache to determine the MAC addresses of the source and destination. If no Address Resolution Protocol (ARP) entries are cached, then the switch issues ARP requests for each IP address and begins the trace once the required source and destination MAC address information is known. It is very important that you understand that the bridge tables on each switch contain entries for at least the destination MAC address specified in the Layer 2 traceroute. If this is not the case, the Layer 2 traceroute fails with a message indicating the MAC address could not be found on one of the switches in the transmission path. To ensure the appropriate bridge table entries are populated on all switches, generate traffic between the source and destination hosts (preferably a continuous stream of traffic). Example 10-8 demonstrates generating a continuous ping between Host-A and Host-B, which ensures all switches in the network contain bridge table entries for both hosts. Example 10-8. Generating Traffic Between Host-A and Host-Bc:\> ping t 192.168.1.101 Pinging 192.168.1.101 with 32 bytes of data: Reply from 192.168.1.101: bytes=32 time=2ms TTL=255 Reply from 192.168.1.101: bytes=32 time=1ms TTL=255 Reply from 192.168.1.101: bytes=32 time=1ms TTL=255 etc... (Output truncated) etc... Now that the appropriate bridge table entries are populated on each switch, Example 10-9 demonstrates using the traceroute mac command on Switch-B to trace the path used for traffic sent between Host-A (00a0.d1d0.20b9) and Host-B (0001.0200.d81d). Example 10-9. Using the traceroute mac Command on Cisco IOSSwitch-B# traceroute mac 00a0.d1d0.20b9 0001.0200.d81d detail Source 00a0.d1d0.20b9 found on Switch-B[WS-C3550-24] (192.168.1.2) Switch-B / WS-C3550-24 / 192.168.1.2 : Fa0/3 [auto, auto] => Fa0/1 [full, 100M] Switch-A / WS-C4006 / 192.168.1.1 : 2/1 [full, 100M] => 2/2 [full, 100M] Switch-C / WS-C3550-24 / 192.168.1.3 : Fa0/1 [full, 100M] => Fa0/3 [auto, auto] Destination 0001.0200.d81d found on Switch-C[WS-C3550-24] (192.168.1.3) Layer 2 trace completed. In Example 10-9, notice that each switch in the transmission path between the specified source and destination MAC address is specified, with ingress and egress port information included. The first entry reads as follows: Switch-B / WS-C3550-24 / 192.168.1.2 : Fa0/3 [auto, auto] => Fa0/1 [full, 100M] This entry means that Switch-B is the first hop in the Layer 2 path between Host-A and Host-B and that the ingress port is Fa0/3 (attached to Host-A) and the egress port is Fa0/1 (attached to the next hop switch, Switch-A) In other words, traffic from Host-A enters interface Fa0/3 and exits interface Fa0/1. Notice also that speed and duplex settings are indicated for each ingress/egress port in the format [duplex, speed]. From the first entry in the preceding entry, you can see that Host-A is connected to an auto-sensing port (as indicated by the output [auto, auto]), while each of the interswitch trunks are configured as 100 Mbps full-duplex (as indicated by the output [full, 100M]). Example 10-9 verifies that the spanning-tree topology of Figure 10-4 is working correctly. The transmission path between Host-A and Host-B is Switch-B Example 10-10 demonstrates using the traceroute mac ip command on Switch-B to trace the path used for return traffic sent between Host-B and Host-A. Example 10-10. Using the traceroute mac ip Command on Cisco IOSSwitch-B# traceroute mac ip 192.168.1.101 192.168.1.100 detail Translating IP to mac ..... 192.168.1.101 => 0001.0200.d81d 192.168.1.100 => 00a0.d1d0.20b9 Source not directly connected, tracing source ..... Source 0001.0200.d81d found on Switch-C[WS-C3550-24] (192.168.1.3) Switch-C / WS-C3550-24 / 192.168.1.3 : Fa0/3 [auto, auto] => Fa0/1 [full, 100M] Switch-A / WS-C4006 / 192.168.1.1 : 2/2 [full, 100M] => 2/1 [full, 100M] Switch-B / WS-C3550-24 / 192.168.1.2 : Fa0/1 [full, 100M] => Fa0/3 [auto, auto] Destination 00a0.d1d0.20b9 found on Switch-B[WS-C3550-24] (192.168.1.2) Layer 2 trace completed. In Example 10-10, notice that because the traceroute mac ip command is used, the switch first determines the MAC addresses associated with the specified IP addresses. Once these MAC addresses are known, notice that because the specified source (192.168.1.101 or Host-B) is not directly connected to Switch-B, Switch-B traces the switch to which Host-B is connected. This is found to be Switch-C, and the Layer 2 traceroute begins. As you can see from Example 10-9 and Example 10-10, traffic between Host-A and Host-B is taking the same forward and return path through the network (as it should, since spanning tree always provides symmetrical forwarding paths in the network). On CatOS, the l2trace command is used to perform Layer 2 traceroutes, which has the following syntax options: Console> (enable) l2trace source-mac-address destination-mac-address [vlan] [detail] Console> (enable) l2trace source-ip-address destination-ip-address [detail] If you use the l2trace command where you specify source and destination IP addresses, the switch checks its local ARP cache to allow the IP addresses to be mapped to MAC addresses or issues ARP requests if no mappings are present in the ARP cache. Example 10-11 demonstrates using the l2trace command with MAC addresses on Switch-A to trace the path used for traffic sent between Host-A (00a0.d1d0.20b9) and Host-B (0001.0200.d81d), while Example 10-12 demonstrates using the l2trace command to trace the return path for traffic sent from Host-B to Host-A, specifying IP addresses instead of MAC addresses. Example 10-11. Using the l2trace command with MAC Addresses on CatOS Switch-B> (enable) l2trace 00-a0-d1-d0-20-b9 00-01-02-00-d8-1d detail Starting L2 Trace l2trace vlan number is 1. Attention: Source 00-a0-d1-d0-20-b9 is not directly attached to this system. Tracing the Source... Completed Source Tracing. Source 00-a0-d1-d0-20-b9 found in WS-C3550-24 : 192.168.1.2 WS-C3550-24 : Switch-B : 192.168.1.2: Fa0/3 -> Fa0/1 100MB full duplex WS-C4006 : Switch-A : 192.168.1.1: 2/1 100MB full duplex -> 2/2 100MB full duplex WS-C3550-24 : Switch-C : 192.168.1.3: Fa0/1 100BM full duplex -> Fa0/3 Destination 00-01-02-00-d8-1d found in WS-C3550-24 named Switch-C on port Fa0/3 Example 10-12. Using the l2trace Command with IP Addresses on CatOS Switch-B> (enable) l2trace 192.168.1.101 192.168.1.100 detail Mapping IP address to MAC address 192.168.1.101 -> 00-01-02-00-d8-1d 192.168.1.100 -> 00-a0-d1-d0-20-b9 Starting L2 Trace l2trace vlan number is 1. Attention: Source 00-01-02-00-d8-1d is not directly attached to this system. Tracing the Source... Completed Source Tracing. Source 00-01-02-00-d8-1d found in WS-C3550-24 : 192.168.1.3 WS-C3550-24 : Switch-C : 192.168.1.3: Fa0/3 -> Fa0/1 100MB full duplex WS-C4006 : Switch-A : 192.168.1.1: 2/2 100MB full duplex -> 2/1 100MB full duplex WS-C3550-24 : Switch-B : 192.168.1.2: Fa0/1 full duplex -> Fa0/3 Destination 00-01-02-00-d8-1d found in WS-C3550-24 named Switch-B on port fa0/3 As you can see from Example 10-11 and Example 10-12, the same functionality and similar output is provided by the l2trace utility on CatOS. Example 10-11 and Example 10-12 verify the spanning-tree topology of Figure 10-4, as traffic between Host-A and Host-B travels from Switch-B |
Switch-A 
EAN: 2147483647
Pages: 135