The default behavior of a SPAN session is to mirror all traffic to the destination port, but NX-OS also provides the capability to perform a filter on the traffic to be mirrored to the destination port. Legend: f = forwarding enabled, l = learning enabled Example 2-2 Verifying SPAN Session NX-1# show monitor session 1 session 1 There is also an option to filter VLANS under the monitor session using the filter vlan vlan-id command. In this example, the rx, tx, and both fields are populated for interface Eth4/1 and Eth4/2, but the interface Eth5/1 is listed only for the rx direction. On FCoE ports, the SPAN destination interface is configured with the command switchport mode SD, which is similar to the command switchport monitor.Įxample 2-2 displays the status of the monitor session. By default, the monitor session is in shutdown state and must be manually un-shut for the SPAN session to function. The destination interface is specified with the command destination interface interface-id. By default, the option is set to both, which captures both ingress and egress traffic on the configured source interface. The rx option is used to capture the ingress (incoming) traffic, whereas the tx option is used to capture the egress (outgoing) traffic. The SPAN session is configured using the command monitor session session-number, under which the source interface is specified with the command source interface interface-id. The destination ports are either an Ethernet or Port-Channel interface configured in access or trunk mode. To enable a port to forward the spanned traffic to the capture PC, the destination interface is enabled for monitoring with the interface parameter command switchport monitor. Be sure to verify relevant Cisco documentation before configuring a SPAN session on any Nexus switch. The number of active sessions and the source and destination interfaces per session vary on different Nexus platforms. These features can vary on each Nexus platform, based on the hardware support.
#Mac address learning is not supported in rspan Pc#
Figure 2-1 shows a Nexus switch connected between two routers and a capture PC that has Wireshark installed to capture the traffic flowing between routers R1 and R2. A mirror copy of the relevant traffic is copied and sent to the destination interface, where it is captured by the packet capture tool and is available for analysis. Performing a network sniffer capture requires a PC with a packet capture tool, such as Wireshark, attached to the switch. Not only does packet sniffing help with troubleshooting packet forwarding issues, but security experts also heavily use it to perform deep analysis of the network and find security holes. Network sniffing is the technique of intercepting the traffic that passes over the transmission medium for the protocol and for deep packet analysis. This is where concept of network sniffing comes into play. Understanding the packet flow between two directly connected devices requires taking three perspectives:ĭetermining whether the originating router is transmitting the packet across the network mediumĭetermining whether the packet is being received on the destination routerĮxamining packets flowing across the network medium Forwarding issues require isolating the direction of the problem and understanding whether the packet is actually reaching the far end device.
In such situations, performing a packet capture helps. However, in some scenarios, the show and debug commands do not yield sufficient information to isolate the problematic direction of the packet flow. NX-OS provides a command-line interface (CLI) that assists with troubleshooting various complex issues. This chapter focuses on the various tools available on the Nexus platform that can help in troubleshooting and day-to-day operation. Proper tools and the right view of the problematic topology can quickly isolate the problem, thereby reducing large-scale network impact. When part of the problematic topology is presented, troubleshooting the network issue becomes much easier.
If a network problem arises and an engineer has a topology of hundreds or thousands of devices, troubleshooting seems difficult at first glance. Troubleshooting is an art that requires both in-depth knowledge on the subject and the ability to verify operations and isolate the incorrect behavior. This chapter covers the following topics: