© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2022
V. JainWireshark Fundamentalshttps://doi.org/10.1007/978-1-4842-8002-7_1

1. Introduction to Wireshark

Vinit Jain1  
(1)
San Jose, CA, USA
 
This chapter covers the following topics:

  • Introduction to network traffic analysis

  • Overview of Wireshark

  • Installing Wireshark

  • Setting up port mirroring

Introduction to Network Traffic Analysis

Modern-day networks and network designs are complex. A network is a graphical representation of how different elements in the network (nodes) are connected. Because every business or organization has its own set of network requirements, network architects come up with designs and solutions that are best suited for the given business requirements. The network design differs between enterprise, service provider, and datacenter networks in various aspects such as scale, redundancy, security, and so on. A few factors are usually considered when designing a network:

  • Simple: A network design should be simple. Most practitioners in the network field are familiar with the KISS principle: Keep It Simple, Stupid. A network is dependent on various technologies, protocols, hardware and software resources, and so on. Even though each of these components might be simple individually, their combination in a network will always add to the complexity. Identifying problems in large-scale networks is often like finding a needle in a haystack. It thus becomes more important that the network design and architecture are kept as simple as possible.

  • Highly available: Almost every network is designed to carry traffic for critical business applications, and a small network event could have a massive impact on the services provided by an organization. Thus, it is important to build redundancy into the network such that in the case of a failure event, the availability of services is maintained. Although redundancy in a network is vital, it is equally important to understand and define how much redundancy is acceptable. More redundant paths in the network result in higher costs.

  • Robust: As stated in the IEEE document “Robust Network Design,” robustness is defined as minimizing variations in network performance, such as average delay and throughput, due to perturbations in the network like topology, demand, and community of interest. If a network design as well as its requirements are not thought through in depth, the network will be affected with increased average delays and throughput or performance issues over a period of time.

  • Scalable: Because the scale of the application and user traffic are constantly growing, the ability to scale the existing network infrastructure holds great importance. While designing computer networks, it is important to choose designs that will allow you to scale the network horizontally as well as vertically as and when required. In other words, the network design should allow the organization to scale the network for east–west as well as north–south traffic on an on-demand basis. One such example is the Clos network design, which primarily focuses on the spine–leaf architecture and has been widely adopted by large-scale datacenter networks to help them cater to the increased traffic demand over the years.

  • Futuristic: In designing networks, it is also important to choose the right set of hardware and software. The right hardware and software choices will allow you to leverage the latest technologies and current innovations in the network industry and will enable you to upgrade the firmware or the network operating system to access the latest available features.

Even when all of these factors are taken into consideration while designing a network, every network still has to undergo changes to overcome dynamic application and resource demands. In addition, every network, irrespective of how carefully it has been designed, is prone to network issues. As the network grows, its complexity also grows. It is only a matter of time before a network problem arises and network engineers are called on to solve the problem. Network problems are usually difficult to manage, and the complexity is even greater when we have multiple features and encapsulations being used in the network.

The main goal of the network operations team is to keep the network as stable as possible and mitigate any problems as quickly as possible while keeping the blast radius of the event to a minimum. Most network outages can be quickly mitigated by following one of several techniques:

  • Shutting down a bad or faulty link

  • Rebooting or shutting down a network device (e.g., router, switch, firewall, etc.)

  • Diverting traffic by adjusting the routing metrics

  • Flapping a routing adjacency

Some issues could take longer time to resolve, especially when it comes to software or hardware defects. Among the different network-related issues faced by network engineers, issues such as continuous or intermittent packet loss, latency, or routing or switching issues require a deeper analysis. Other issues can be quickly mitigated by replacing the hardware or cable or a particular port, for example, but issues related to packet loss or routing problems involve multiple elements in the network that cannot be identified and mitigated quickly. Such issues sometimes require more visibility at the packet level as to what data are being transmitted on the wire. That said, it is now time to understand what network analysis is.

Network traffic analysis (NTA), often referred to as packet sniffing, is the process of collecting (capturing) network traffic and monitoring network activity and events by examining the collected traffic to identify anomalies in the network, including but not limited to operational issues such as packet loss or latency and security issues such as Transmission Control Protocol (TCP) SYN attacks or man-in-the-middle attacks. There are always situations in the network where the show commands or debugs from the network operating system do not yield the actual packet-level information that is being transmitted from one node to another. A tap in the wire allows the network administrators to gain a clear understanding of what packets are being transmitted across the network elements. There are several use cases where NTA techniques could be applied:

  • Understanding network characteristics

  • Analyzing protocol behaviors

  • Troubleshooting slowness in the network

  • Troubleshooting packet forwarding issues

  • Identifying vulnerabilities in the network protocols and ciphers

  • Identifying malicious activities in the network

  • Collecting real-time information on activities between different network elements

Better visibility into the network allows the network administrators to optimize performance, enhance the security posture of the network, minimize the blast radius of a network attack, and better analyze the utilization of network resources. The packets collected in the network also give network administrators a better understanding of how the network users are implementing their applications. Techniques such as deep packet inspection (DPI) allow complete network visibility by transforming the raw packet data as well as metadata into a readable format.

Typically, packet analysis or packet sniffing is performed by a packet sniffer, a tool that is used to capture raw network traffic going across the wire (network). There are several tools available, including the free or commercial ones, based on the command-line interface (CLI) as well as the graphical user interface (GUI). These are some of the most popular packet sniffer tools:

  • Tcpdump: This is a powerful CLI-based packet analyzer tool that is freely available and runs on Linux or most UNIX-like operating systems.

  • Omnipeek: This is a GUI-based commercial packet analyzer tool from Savvius, a LiveAction company.

  • Wireshark: Wireshark is a free, open source, GUI-based packet analyzer available for download on various operating systems.

Note

In this book, we primarily focus on Wireshark. Covering different network analyzer tools is outside the scope of the book.

Network Sniffing

As easy as it sounds, network sniffing is actually not easy. Most network engineers think that packet sniffing involves simply plugging a laptop into a network port and capturing traffic, but that is not the case. There are various factors to be considered when tapping into the wire and capturing traffic. Two factors play a vital role when sniffing network traffic:
  1. 1.

    Placement of the sniffer in the network

     
  2. 2.

    The number of sniffer placements

     

We discuss both these points in detail.

Sniffer Placement

Location of the sniffer placement varies based on the network topology. Different network topologies have varied requirements and complexities and identifying the point of sniffer placement in such complex environments is not easy. As we know, networks include different elements, such as routers, switches, wireless controllers, firewalls, and so on. Some of these components might not even have support for enabling traffic mirroring for sniffing purposes. Traffic mirroring on switches can be enabled using a technique known as port mirroring. Port mirroring or port spanning can be configured on the switch using a CLI command or a web management interface of the switch. The best feature of port mirroring is that it leaves no network footprint and does not generate any additional packets. It can be configured without taking any of the active traffic interfaces or host interfaces offline, which makes it an ideal option for mirroring not just switch traffic, but also router or server and host ports. As part of the configuration, you define the source interface(s) along with the direction of the traffic (incoming or outgoing) you want to capture and a destination interface that is connected to a host with a packet capture tool, such as Wireshark, installed on it to collect all the mirrored packets that can later be used for analysis. Once this is set up, the mirrored traffic from all the source ports is sent to a host connected on the destination port. Figure 1-1 illustrates how port mirroring works. In this given topology, traffic sourced from host A and destined for host B is mirrored and sent to the capture device connected on Eth2/0.
Figure 1-1

Port mirroring

For a capture device to be able to capture packets, the network interface card (NIC) should support promiscuous mode. A promiscuous mode driver allows a NIC to view all packets crossing the wire. When tools such as Wireshark are installed on the capture device, they also install a libpcap or WinPcap driver on the device. These drivers allow the NIC to switch to promiscuous mode and capture packets across the network.

Now, we return to the question of what the right place is to locate the sniffer capture in the network. The simple answer is that it depends on the troubleshooting being performed and the relevant network topology between the problematic source and destination. First of all, it should never be a goal of any kind of network troubleshooting to begin with placing sniffer captures at multiple places in the network. The goal should always be to isolate and narrow down the problem as much as possible. In narrowing down, you might find that you do not need to place sniffer captures at all. To troubleshoot a network problem, it is important to first understand the problem and its scope. Unless a problem is clearly understood, troubleshooting cannot move in the right direction and it could take more time and effort to mitigate or resolve a problem. Second, as part of the problem statement, the scope information should also be gathered to understand the blast radius of the problem. In other words, the scope of the network problem can be identified by asking few simple questions such as these:

  • When did the problem start?

  • What is the problematic source and destination?

  • What is the working source and destination?

  • What is the relevant topology between the source and destination?

  • How many users and services are affected?

  • What was the trigger of the problem?

Once the problem statement and the scope are clearly defined, the next step is to isolate the direction of the problem. For instance, let’s say there is a complete packet loss between hosts A and B as the traffic is flowing across multiple network devices. To isolate the direction of the problem, we need to identify if the problem is when the packet is sent from A to B or in the reverse direction. It could be, based on the way the network devices are configured, that the traffic from host B to host A might not flow via the same set of devices that it took when flowing from host A to host B. This is known as asymmetrical routing. If direction of the problem is not identified, we would end up placing sniffer captures randomly across multiple devices in the network, which consumes more time. Once the direction of the problem is isolated, then it is important to further narrow down the problem to a minimum set of devices or even interfaces. To understand this in detail, examine the topology shown in Figure 1-2. The topology shows the connectivity between two sites of an enterprise network. In this topology, each site has access, distribution, core, and wide area network (WAN) layers. The WAN routers are connected to the Internet service providers (ISPs) that provide connectivity to the remote site across the Internet. In this topology, the distribution switches, the core switches, and the WAN routers are all connected via an interior gateway protocol (IGP) . The WAN routers at Site 1 are connected to the remote site WAN routers via Border Gateway Protocol (BGP) peering toward the ISP, which is exchanging certain prefixes along with a default route. The BGP prefixes are then redistributed into the Open Shortest Path First (OSPF) database at both sides to provide end-to-end connectivity between both sites.
Figure 1-2

Enterprise network topology

Now, let’s examine a scenario where the network operations team has reported a problem, stating that host H1 is having connectivity issues reaching multiple hosts across the remote site. As a network engineer, you start isolating the problem scope by asking few basic questions as stated previously. Let’s assume that host H1 is having issues reaching host H4 and host H5, but not host H6. Host H1 is not having any issues reaching any of the hosts that are local to the site. Now you have baseline information on what is working and what is broken. As a next step in troubleshooting, there are a few simple steps that you can take:

  • Verify Address Resolution Protocol (ARP) information: Verify if the ARP entry is complete for host H4 or H5 versus host H6.

  • Traffic pattern: Verify if the issue is sending broadcast traffic or unicast traffic. If the ARP table on host H1 shows that the ARP entry is present or is getting completed for host H4 and H5 even after clearing the ARP, then it might be a problem just with the unicast traffic instead of all traffic (broadcast, unicast, or multicast traffic) between H1 and H4 or H5.

  • Path information: Perform traceroutes between working and nonworking hosts to identify any difference in paths taken by each of them. If the network has equal cost multiple paths (ECMP), then most routing and switching platforms perform flow-based hashing to send traffic out on one of the interfaces. If the traceroute fails at one of the hops in the path, that would indicate the problem might be isolated to that segment of the network. Note that it is important to perform traceroutes from both endpoints so that any possibility of asymmetrical routing could be detected.

  • Access control lists (ACLs): Leverage ACLs whenever possible to isolate where the traffic loss is happening. Users can configure both Layer 3 ACLs (standard and extended) and Layer 2 ACLs (media access control [MAC] ACLs) to match Layer 3 as well as Layer 2 traffic at different segments of the network. However, there could be instances where ACLs might not be of any help. For instance, ACLs do not allow users to capture Multiprotocol Label Switching (MPLS) packets. Thus, it becomes important to identify the kind of packets being investigated during troubleshooting.

  • Hop-by-hop ping tests: If a traceroute fails at a segment of the network, it might make sense to check the reachability of the source device to that segment of the network. It is possible that only the transit traffic might be affected and not the traffic destined for those devices in the segment. This usually happens if there is an ACL blocking the traffic in the path or due to a software misprogramming (software defect). In such instances, ping tests should be performed before performing deep-dive troubleshooting.

  • Platform troubleshooting tools: Most routing and switching platforms come with troubleshooting tools as part of the network operating system (OS). These platform troubleshooting tools can help you understand if a packet is being dropped on the device itself or not and why. These tools are primarily helpful when the issue has been isolated to a particular device or a network segment. Note that some network OS’s come with platform-level packet capture tools. These tools can be very useful to perform packet captures to understand if the packet is being received on the device or not and if what action is being taken on the packet by the network OS.

  • Debugs: It might sometimes help to run debugs on the network devices. The debug logs allow you to gain more insight on what is happening on the network device. For instance, if a BGP prefix is not being received, you could run a BGP protocol debug to understand if the prefix is being received or not.

Once all the basic and some advanced-level troubleshooting steps have been performed and you are unable to isolate the issue to one particular device or segment, that’s where external sniffer capture tools come into play. Here are some of the scenarios in which sniffer capture can be useful:

  • When dealing with corrupted packets

  • Gathering more information about the packet headers, as they might be affecting forwarding decision

  • Troubleshooting encapsulated packets

  • Troubleshooting packet loss or retransmission issues

  • Voice or video traffic-related issues

  • Protocol issues such as OSPF not forming adjacency due to wrong information being exchanged or BGP not establishing peering due to TCP or wrong or missing information in BGP packets

If we talk about the problem displayed in Figure 1-2, if the traffic loss is happening between host H1 and host H4 or host H5, then some of the preceding steps could be followed to isolate the problem to a smaller segment of the network and sniffer devices could be attached in those segments to further investigate the issue. For instance, if the issue was narrowed down between the site 2 WAN router and Distribution layer switch(es), then enabling port spanning on core switches will help identify if the issue lies on the WAN router, the core switch, or the distribution switch. If the packet sniffers are to be used to analyze the problem, however, then the network engineers would have to enable the sniffer captures at the following devices:

  • Access switch connected to the source and destination host

  • Core switch(es) at each site

  • WAN routers (if they support enabling port spanning)

The captures taken at each site can easily help determine where the packet loss is happening. Even though the sniffer captures help a lot in investigating the issue, that is not the final step of the troubleshooting process. There are a few more steps that are involved in mitigating and remediating the problem, which we will see in the coming chapters based on different problem scenarios.

Number of Sniffer Placements

Placing sniffers is not always easy. Each organization, be it an enterprise, service provider, or datacenter, has its own set of policies for managing and troubleshooting in its network environment. Most organizations require scheduling a change and maintenance window to perform troubleshooting, let alone performing sniffer captures. Also, when the whole network environment that is under investigation is geographically displaced or made up of remote unmanned sites, it takes a while to get field engineers on site to help with sniffer captures. Further, when the sniffer captures are to be performed at multiple places in the network, the complexity is compounded. When the troubleshooting requires sniffer captures in the network, it is important that the points of placement should be carefully considered before actually enabling port spanning.

Some network environments are also set up in a way that supports remote spanning with specific hosts configured to collect mirrored traffic. Such network deployments allow users to perform port spanning at almost any given node in the network without having to wait for any human to be present on site. The only limitation of such deployments is either the support for the remote span feature on all network devices or the host or the switch performance with higher throughput interfaces.

In the example discussed in Figure 1-2, the ideal process would be to isolate the segment where the problem is and then place sniffer captures in that segment. If there are issues related to voice traffic such as users facing choppy voice or even TCP retransmission issues, it would require sniffer placements at multiple points across the network to determine where the issue is actually happening. For such a huge span of segments to troubleshoot, the approach for performing packet captures should be to isolate between the internal network versus the ISP network. For instance, the sniffer placements between the access and core or WAN layer at each site will allow us to identify if the issue is local to any of the two sites. If the packet sent from one site is not received by the WAN router on the remote site, that means the issue would be isolated to the ISP network instead of the site local networks.

Network Tap

A network tap is a hardware device that creates a copy or mirror of the traffic flowing between two points in your cabling system. The hardware is specially designed for network analysis. When setting up network taps, the hosts or network devices might be temporarily offline. The network taps can be useful in enterprises for performing packet captures and continuous monitoring, as they are reliable and support high-throughput links. There are two primary types of network taps:

  • Aggregated: The aggregated network taps allow bundling of multiple streams of data across multiple ports to one monitoring port. This type of network tap is useful when it is required to monitor bidirectional streams of traffic but only one NIC for monitoring.

  • Nonaggregated: The nonaggregated network taps provide additional flexibility for capturing traffic but also add to complexity when compared to aggregated network taps. In nonaggregated network taps, two ports are required for monitoring purposes, each of them capturing traffic in only one direction.

Based on the monitoring requirements, the choice can be made between aggregated and nonaggregated network taps.

So far, we have learned about the port spanning and network taps that can be used to enable and perform packet captures in the network. Next, we learn about the Wireshark tool that will be used for analyzing the captured traffic.

Overview of Wireshark

Wireshark is a widely used open source network protocol analyzer. The first version of the application was called Ethereal and was developed and released by Gerald Combs in 1998 under the GNU Public License (GPL). After some conflicts over the Ethereal brand rights with his employer, Combs, along with the rest of the development team, rebranded the project as Wireshark in mid-2006. Wireshark is freely available for personal, educational, and commercial purposes and is supported and maintained by a community of more than 1,800 developers.

It is the go-to tool for almost every network administrator or network engineer to analyze network traffic patterns, troubleshoot network protocol issues, and perform in-depth analysis of network security loopholes. Wireshark comes with tons of features, supports the most common and uncommon set of protocols and encapsulations, and is supported on all the well-known OSs. It provides an easy-to-use and easy-to-understand GUI and advanced filtering capabilities to search through millions of packets to allow network administrators to quickly analyze the events in the network.

Installing Wireshark

At the time of writing, the latest and stable version of Wireshark is 3.4.4. Wireshark installer is available in both 32-bit and 64-bit versions and have builds available for Windows, Mac, and various Linux OSs. Wireshark installer can be downloaded from https://www.wireshark.org/download.html. Installation of Wireshark is fairly simple. In the section, we cover the installation of Wireshark on different OSs.

Installing Wireshark on Windows

Follow these steps to install Wireshark on Windows:

  • Download the installer (.exe file) from https://www.wireshark.org.

  • Double-click the installer to begin the installation process.

  • Click Next to begin the installation.

  • Acknowledge the License Agreement by clicking Noted.

  • Select the components that you want to install as shown in Figure 1-3 and click Next.

Figure 1-3

Wireshark Installation Choose Components screen

Note

In the component selection you can see an option to install TShark. TShark is a CLI version of Wireshark, which is designed to capture and analyze network traffic. It supports the same options as Wireshark. To view all the options of TShark, use the command man tshark or tshark --help option.

  • Select the different shortcuts that you want to place on your PC and click Next.

  • Select the installation directory for Wireshark and click Next.

  • Select the Npcap or WinPcap version that is currently installed or is available to install and click Next. Note that Npcap or WinPcap is required by Wireshark to capture live network packets.

  • Optionally, you can install USBPcap to capture USB traffic and click Install to begin the installation process.

  • During the installation, another installer window will open for Npcap or WinPcap software. Select the necessary installation options and begin the installation process by clicking Install.

  • Once the installation completes, click Finish.

  • The Wireshark installation will continue further.

  • Once the installation process is completed, click Finish. At this point, Wireshark is now ready to perform packet captures on your system.

Installing Wireshark on Mac

Follow these steps to install Wireshark on MacOS:

  • Download the installer (.dmg file) from https://www.wireshark.org.

  • Double-click the installer file to begin the extraction process.

  • The extraction process will create a volume with all the necessary files on the desktop.

  • Once the extraction is completed, a pop-up window gives you an option to move the Wireshark app into the Applications directory

  • Drag the Wireshark app into the Applications directory to make Wireshark accessible from the launch pad.

Installing Wireshark on Ubuntu

Wireshark can be installed quickly on Ubuntu from the terminal using the apt-get package installer. Follow these steps to install Wireshark on Ubuntu:

  • Update the repository on the Ubuntu machine using the command apt update.

  • Install Wireshark using the command apt install wireshark.

If you just have CLI access to the Ubuntu server or machine, then it might be a better option to install TShark. Users can install TShark using the command apt install tshark as shown in Example 1-1. Once installed, users can review the CLI options for TShark using the tshark command with the --help option or the man tshark command .
root@genie-rnd-server:~# apt install tshark
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  tshark
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 137 kB of archives.
After this operation, 411 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu focal/universe amd64 tshark amd64 3.2.3-1 [137 kB]
Fetched 137 kB in 0s (323 kB/s)
Selecting previously unselected package tshark.
(Reading database ... 279306 files and directories currently installed.)
Preparing to unpack .../tshark_3.2.3-1_amd64.deb ...
Unpacking tshark (3.2.3-1) ...
Setting up tshark (3.2.3-1) ...
Processing triggers for man-db (2.9.1-1) ...
root@genie-rnd-server:~# tshark --help
Running as user "root" and group "root". This could be dangerous.
TShark (Wireshark) 3.2.3 (Git v3.2.3 packaged as 3.2.3-1)
Dump and analyze network traffic.
See https://www.wireshark.org for more information.
Usage: tshark [options] ...
Capture interface:
  -i <interface>, --interface <interface>
                           name or idx of interface (def: first non-loopback)
  -f <capture filter>      packet filter in libpcap filter syntax
  -s <snaplen>, --snapshot-length <snaplen>
                           packet snapshot length (def: appropriate maximum)
  -p, --no-promiscuous-mode
                           don't capture in promiscuous mode
  -I, --monitor-mode       capture in monitor mode, if available
  -B <buffer size>, --buffer-size <buffer size>
                           size of kernel buffer (def: 2MB)
  -y <link type>, --linktype <link type>
                           link layer type (def: first appropriate)
<snip>
Example 1-1

Installing tshark on Ubuntu

Once set up, the GUI-based Wireshark app or CLI-based tshark app can be used to capture traffic traversing the network.

It is important to learn how to capture the packets and analyze the network traffic, but it is equally important to know the tools available with different network devices that you can use to set up packet captures.

Setting Up Port Mirroring

As we all know, there are multiple elements in the network such as routers, switches, firewalls, load-balancers, servers, and so on, and troubleshooting a network with multiple elements involved can be complex. Packet capture tools are very handy when investigating issues at the packet level. When a deep-dive investigation is required at the packet level, the issue is usually found in one of the following places:

  • At the transmitting device or the device that initiated the packet

  • At the receiving device or the device for which the packet is destined

  • At the transit device

  • In the transmission media

The packet-level issues require the network engineers to perform packet captures and investigate the issues by analyzing the captured traffic. In most cases, switching devices have the capability of mirroring network traffic and sending it to a mirroring port that is connected to a PC. Let’s see how port mirroring can be enabled on different vendor devices.

SPAN on Cisco IOS/IOS-XE

The port mirroring capability on Cisco devices is known as Switched Port Analyzer (SPAN) . SPAN can be set up on both Layer 2 and Layer 3 interfaces. When setting up SPAN, the source and the destination interfaces are defined. Source ports are a collection of physical ports such as Gigabit Ethernet or TenGig interfaces and virtual interfaces such as virtual local area network (VLAN) switch virtual interfaces (SVIs). In defining the source ports, users can also define the direction of the traffic; that is, rx for incoming direction, tx for outgoing direction, or both, which means mirror both rx and tx traffic. A SPAN session on a Cisco IOS or Cisco IOS-XE switch can be configured using the command monitor session session number. Under the SPAN session configuration, you can define the source and the destination ports along with their direction. Example 1-2 illustrates how to configure a SPAN session on a Cisco IOS-XE switch.
SW1#configure terminal
SW1(config)# monitor session 10 source interface GigabitEthernet1/5 rx
SW1(config)# monitor session 10 source interface GigabitEthernet1/7 tx
SW1(config)# monitor session 10 destination interface GigabitEthernet2/1
SW1#configure terminal
SW1(config)# monitor session 11 source vlan 3 - 5 rx
SW1(config)# monitor session 11 source vlan 20
SW1(config)# monitor session 11 destination interface GigabitEthernet2/2
Example 1-2

Configuring SPAN

Note

As per the Cisco.com documentation, you cannot have two SPAN sessions using the same destination port.

Once the SPAN is set up, you can view the state of the SPAN using the command show monitor session [session-number]. If the command is executed without specifying the session-number element, it displays all the SPANs that are configured on the switch. When the session-number option is specified, the command displays information about only the specified session. It is important to note that the destination interface is the one running in promiscuous mode. Thus, no other protocol or feature will work on that port. Example 1-3 displays how to verify the SPAN session and also displays the destination interface state in monitoring state. The monitoring state indicates that the port is running in promiscuous mode.
SW1#show monitor session 10
Session 10
---------
Type                   : Local Session
Source Ports           :
    rx                 : Gi1/5
    tx                 : Gi1/7
Destination Ports      : Gi2/1
MTU                    : 1464
Egress SPAN Replication State:
Operational mode       : Distributed
Configured mode        : Distributed
SW1#show interface GigabitEthernet1/1
GigabitEthernet2/1 is up, line protocol is down (monitoring)
  Hardware is Gigabit Ethernet, address is 2c54.2d68.1207 (bia 2c54.2d68.1207)
  MTU 1998 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 18/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000BaseTX SFP
<snip>
Example 1-3

SPAN Session Verification

Note

Refer to the Cisco online product documentation to verify how many SPAN sessions can be configured. The supported number of SPAN sessions varies from platform to platform and from vendor to vendor.

SPAN on Cisco Nexus Switches

The Cisco Nexus OS (NX-OS) SPAN feature is pretty similar to the SPAN feature on Cisco IOS-XE software. Different Nexus series switches might vary on the number of monitor sessions they support. Before configuring the monitor session on NX-OS, the destination switchport should be configured with the command switchport monitor. Nexus supports hierarchical configuration, thus the source ports and destination port configuration are defined under the monitor configuration mode. Example 1-4 illustrates how to configure SPAN session on Nexus switches. Note that a monitor session on NX-OS does not become active unless a no shut command is configured under the monitor session.
NX-2(config)# interface Etherner1/5-6
NX-2(config-if)# switchport
NX-2(config-if)# switchport monitor
NX-2(config-if)# no shut
NX-2(config)# monitor session 1
NX-2(config-monitor)# source interface ethernet 1/1
NX-2(config-monitor)# source interface ethernet 1/2 tx
NX-2(config-monitor)# destination interface ethernet 1/5
NX-2(config-monitor)# no shut
Example 1-4

Configuring SPAN Session on Cisco NX-OS

Once the monitor session is configured, the session state can be verified using the command show monitor session session-number. Example 1-5 displays the output of the command show monitor session 1. Notice that in the output, the type is set to local. When defining the monitor session, if the type is not specified, then by default the monitor session is configured as a local SPAN session. The output shown in Example 1-5 displays the source rx and tx interfaces that are configured in the SPAN along with the destination interface. In NX-OS, the show interface command does not show the state of the interface as monitoring, but rather has another line in the output indicating that the switchport monitor is enabled on the port.
NX-2# show monitor session 1
   session 1
---------------
type              : local
state             : up
acl-name          : acl-name not specified
source intf       :
    rx            : Eth1/1
    tx            : Eth1/1        Eth1/2
    both          : Eth1/1
source VLANs      :
    rx            :
    tx            :
    both          :
filter VLANs      : filter not specified
source fwd drops  :
destination ports : Eth1/5
PFC On Interfaces :
source VSANs      :
    rx            :
NX-2# show interface ethernet 1/5
Ethernet1/5 is up
admin state is up, Dedicated Interface
  Hardware: 100/1000/10000 Ethernet, address: 0c5f.3d16.260d (bia 0c5f.3d16.260d
)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, medium is broadcast
  Port mode is access
  full-duplex, 1000 Mb/s
  Beacon is turned off
  Auto-Negotiation is turned on  FEC mode is Auto
  Input flow-control is off, output flow-control is off
  Auto-mdix is turned off
  Switchport monitor is on
  EtherType is 0x8100
  EEE (efficient-ethernet) : n/a
    admin fec state is auto, oper fec state is off
  Last link flapped 00:13:37
<snip>
Example 1-5

Verifying SPAN Session on Cisco NX-OS

Nexus 9000 series switches also support filtering of spanned traffic at the VLAN level or by applying an ACL. Only one type of filtering is supported on a given monitor session and filtering can only be applied when the source interfaces are configured in the rx direction. Example 1-6 illustrates how to set up a monitor session with VLAN as well as ACL-based filtering and also how the show monitor session output differs between the monitor sessions when different filtering methods are applied. Also, as shown in this example, a monitor session can be deleted using the command no monitor session session-number.
NX-2(config)# ip access-list TEST-ACL
NX-2(config-acl)# permit icmp any any
NX-2(config-acl)# exit
NX-2(config)# no monitor session 1
NX-2(config)# monitor session 1
NX-2(config-monitor)# source interface ethernet 1/1 rx
NX-2(config-monitor)# destination interface eth1/5
NX-2(config-monitor)# filter access-group TEST-ACL
NX-2(config-monitor)# exit
NX-2(config-if)# monitor session 2
NX-2(config-monitor)# source interface eth1/3 rx
NX-2(config-monitor)# destination interface eth1/5
NX-2(config-monitor)# filter ?
  access-group  Access control group
  vlan          Vlan type
NX-2(config-monitor)# filter vlan 100
NX-2(config-monitor)# no shut
NX-2# show monitor session 1
   session 1
---------------
type              : local
state             : up
acl-name          : TEST-ACL (Rx only)
source intf       :
    rx            : Eth1/1
    tx            :
    both          :
source VLANs      :
    rx            :
    tx            :
    both          :
filter VLANs      : filter not specified
source fwd drops  :
destination ports : Eth1/5
PFC On Interfaces :
source VSANs      :
    rx            :
NX-2# show monitor session 2
   session 2
---------------
type              : local
state             : up
acl-name          : acl-name not specified
source intf       :
    rx            : Eth1/3
    tx            :
    both          :
source VLANs      :
    rx            :
    tx            :
    both          :
filter VLANs      : 100
source fwd drops  :
destination ports : Eth1/6
PFC On Interfaces :
source VSANs      :
    rx            :
Example 1-6

SPAN Sessions with Filtering

Enabling Port Mirroring on Arista EOS

Port mirroring on Arista can be enabled by configuring one or more mirroring sessions. Port mirroring configuration of Arista EOS is very similar to that for Cisco IOS-XE devices. You can enable port mirroring sessions using the command monitor session with the difference that instead of specifying the session number, you specify the name of the monitor session. Example 1-7 demonstrates how to configure port mirroring on Arista devices. Once configured, use the command show monitor session to verify the state of the monitor session and the show interface interface-name status command to verify the state of the interface. The destination port on the Arista device also displays in monitoring state.
eos-1(config)# monitor session test1 source ethernet 1,7-9 rx
eos-1(config)# monitor session test1 source ethernet 4 tx
eos-1(config)# monitor session test1 destination ethernet 20
eos-1# show monitor session
Session test1
------------------------
Source Ports
Rx Only:     Et1, Et7, Et8, Et9
Tx Only:     Et4
Destination Port: Et20
eos-1# show int et20 status
Port   Name   Status    Vlan         Duplex   Speed   Type
Et20          connect   monitoring   full     10G     Not Present
Example 1-7

Configuring Port Mirroring on Arista

Enabling Port Mirroring on JunOS

On JunOS, we use the term analyzers to set up port mirroring. JunOS also supports configuring of port mirroring to capture bridged packets (Layer 2 packets) as well as routed packets (Layer 3 packets). On a JunOS device, the following packets can be mirrored:

  • Packets entering or exiting a port

  • Packets entering or exiting a VLAN or a bridge domain

  • Policy-based sample packets

For policy-based sample packets, a firewall filter with a policy is configured to mirror the packets. The sample traffic based on the firewall filter can be sent to the port-mirroring instance for further analysis.

Analyzers on JunOS can be set up in few simple steps:

  • Get into forwarding-options configuration mode.

  • Define a name for the analyzer and specify the input interface along with the direction of the traffic you wish to capture.

  • Choose the destination interface.

  • Commit the configuration.

In JunOS, you can also configure firewall filters to limit the amount of traffic being mirrored. Example 1-8 displays a sample configuration of analyzer and the use of the command show forwarding-options analyzer analyzer-name to verify the state of the analyzer.
root> show configuration forwarding-options
analyzer {
    testCapture {
        input {
            ingress {
                interface ge-0/0/1.0;
            }
            egress {
                interface ge-0/0/1.0;
            }
        }
        output {
            interface ge-0/0/4.0;
        }
    }
}
root> show forwarding-options analyzer testCapture
  Analyzer name                    : testCapture
  Mirror rate                      : 1
  Maximum packet length            : 0
  State                            : up
  Ingress monitored interfaces     : ge-0/0/1.0
  Egress monitored interfaces      : ge-0/0/1.0
Example 1-8

Configuring Port Mirroring on JunOS

So far, we have seen how to configure local port mirroring on various vendor devices running their respective network OS. Similarly, you can also set up remote port mirroring. In remote port mirroring, the configuration is pretty much the same as local port mirroring with the minute difference that the destination interface does not reside on the local device, but is multiple hops away. Each vendor has its own method of implementing remote port mirroring. Unless necessary, it is not required to set up remote port mirroring.

Summary

In this chapter, we learned what NTA is and why it is important in the network. We also learned the factors that should be considered when implementing port mirroring and how we can set up the minimum number of capture points in the network to isolate a problem in the network. Unless it is necessary, one should avoid enabling port mirroring on network devices. Further, we learned what Wireshark is and how to install it on various OSs. Finally, we concluded the chapter by seeing how port mirroring can be enabled on network devices from different vendors.

References in This Chapter

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.102.223