© 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_3

3. Analyzing Layer 2 and Layer 3 Traffic

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

  • Layer 2 frames

  • Layer 3 packets

  • Analyzing QoS markings

Layer 2 Frames

Layer 2 of the OSI or TCP/IP model is the Data Link layer. The Data Link layer is responsible for performing encapsulation of the packets. Appropriate addressing is chosen at each of the Transport, Network, and Data Link layers during the encapsulation process. The Transport layer uses port numbers, the network layer uses IP address, and the Data Link layer uses MAC address, as shown in Figure 3-1.
Figure 3-1

Data encapsulation with different headers

At each layer, the data are encapsulated in a specific format known as the packet data unit (PDU). The PDU defines the structure or format in which the data will be shared with the layer above or layer beneath the current layer. The PDU could simply be the data, a segment (at the Transport layer), a packet (at the Network layer), a frame (at the Data Link layer), or even bits.

The Data Link layer encapsulates the outgoing IP datagrams from the network layer and packages them into frames that are transferred between two nodes. This layer is also responsible for correcting any errors that might have occurred at the Physical layer. The Data Link layer has two sublayers:

  • Media Access Control (MAC) : Controls access to the network medium by interfacing with the network adapter. It is responsible for flow control and multiplexing device transmissions over the network.

  • Logical Link Control (LLC) : LLC provides error control and flow control over the physical medium. It is also used for identifying line protocols.

Layer 2 Protocols are required for two devices to communicate over the Layer 2 medium. They provide the communication mechanism between different Layer 2 devices such as NICs, switches, bridges, and more, over a LAN or WAN. There are different types of Layer 2 protocols, some of which are described in Table 3-1.
Table 3-1

Layer 2 Protocols

Protocol

Description

Cisco Discovery Protocol (CDP)

CDP is a Cisco proprietary protocol that is primarily used to exchange information between directly connected Cisco devices.

Link Layer Discovery Protocol (LLDP)

LLDP is a vendor-neutral Layer 2 discovery protocol that is commonly used by devices to advertise information to their directly connected devices.

Point-to-Point Protocol (PPP)

PPP provides the standard mechanism for transmitting data over point-to-point links.

Frame Relay

Frame Relay is a packet-switched WAN protocol that operates over the Physical and Data Link layers.

Asynchronous Transfer Mode (ATM)

ATM is a cell-switched WAN protocol that is designed to facilitate various types of traffic streams.

Ethernet

Ethernet is the most widely used Data Link layer protocol used in both LAN and WAN environments.

There are several other protocols that are used at Layer 2, but most of them are now obsolete or have very limited implementation. In this chapter, we focus on Ethernet frames.

Ethernet Frames

When talking about Ethernet frames, we can start by taking a close look at the IEEE 802.3 standard. The fields within the Ethernet header based on IEEE 802.3 standard are described here and shown in Figure 3-2.

  • Preamble: Ethernet frame starts with a 7-byte Preamble field. Initially this field was introduced to allow for loss of a few bits due to signal delays, but high-speed Ethernet links do not require the Preamble field.

  • Start of frame delimiter (SFD) : SFD is a 1-byte field that is always set to 10101011. This field indicates the start of the frame.

  • Destination Address (DA) : DA is a 6-byte field that holds the destination MAC address of the machine.

  • Source Address (SA) : SA is also a 6-byte field that holds the source MAC address of the machine from which the packet originated.

  • Length: This 2-byte field indicates the length of the entire Ethernet frame.

  • Data: The Data section holds the payload of the frame. Note that both the IP header and data will be inserted into this section if IP is being used over Ethernet. The minimum length of the data field is 46 bytes, and the maximum data can be as long as 1,500 bytes, assuming the interface maximum transmission unit (MTU) is set to 1,500. If the data length is less than the minimum length of 46 bytes, then 0s are padded to meet the minimum possible data length.

  • Cyclic Redundancy Check (CRC) : The checksum is computed based on the 32-bit hash code generated using the destination address, source address, length, and data field of the frame and stored in the CRC field. If the checksum computed by the source or sender is not the same as that of the client or receiving device, the data received seem corrupted.

Figure 3-2

802.3 Ethernet frame

As stated earlier, the 802.3-based Ethernet frame only supported payloads between 46 bytes and 1,500 bytes, which was good enough for 10 Mbps or 100 Mbps ports, but not helpful for Gigabit Ethernet technology. To support payloads greater than 1,500 bytes, an Extended Ethernet frame was introduced. The Extended Ethernet frame, also known as Ethernet II frame, had the following fields:

  • Destination Address

  • Source Address

  • Type (EtherType)

  • Data (Variable size)

  • Frame Checksum (FCS)

Figure 3-3 displays the Wireshark capture packet view of an Ethernet frame for an IP packet. Notice that the EtherType in the Type field is set to 0x0800, which indicates the encapsulated packet is an IPv4 packet.
Figure 3-3

Ethernet II header in IPv4 packet

Note

By default, FCS is not visible in the Wireshark capture. To view the FCS for the Ethernet header, go to Wireshark ➤ Preferences ➤ Protocols ➤ Ethernet and enable Assume Packets Have FCS option. Once that option is enabled, the Wireshark packet detail view will display the FCS field under the Ethernet II header.

When investigating packets at Layer 2, it is important to take note of some well-known EtherTypes that are seen inside most production networks. Some of these well-known EtherTypes are listed in Table 3-2.
Table 3-2

Well-Known EtherTypes

EtherType

Protocol

0x0800

IPv4

0x0806

ARP

0x8100

VLAN-Tagged Frame (IEEE 802.1Q)

0x8847

MPLS

0x86DD

IPv6

When analyzing Layer 2 frames, packets in Wireshark can be filtered by applying filters based on source MAC, destination MAC, or EtherType. Figure 3-4 displays the filtering of Layer 2 ARP broadcast frames coming from a specific MAC address. The filters can be applied on eth.src and eth.type fields on the captured Wireshark packets.
Figure 3-4

Filtering of broadcast frames sourced from a specific MAC address

Layer 3 Packets

When troubleshooting issues within a single broadcast domain or local LAN environments, Layer-2-based captures are more relevant, but when investigating issues that span multiple network segments that might be residing in different geographical location, we primarily focus on looking at Layer 3 and upper layer information in the packet captures. When talking about Layer 3 packets, we are primarily referring to either IPv4 packets or IPv6 packets. The protocols at Layer 3 provide logical addressing in a network (Internet or intranet) and ensure routing of data across different network segments. Even when dealing with tunneling technologies, the logical addressing of the tunnel interfaces and routing traffic across tunnel interfaces is still required. Before diving into IPv4 or IPv6 packets, let’s first understand ARP and its importance for establishing network communication.

Address Resolution Protocol

It is important to remember that both physical and logical addresses are required to establish communication in the network. Logical addresses allow users to establish communication across multiple network segments, and physical addresses are used for establishing communication within the same network segment. To forward traffic within the same broadcast segment, MAC addresses are required by the switch. Unless the switch knows about the MAC address of the host, it will not be able to forward the traffic toward the port where the destination host is connected. The MAC addresses of all the hosts connected to a switch within the same broadcast domain are stored in a Content Addressable Memory (CAM) table. If the MAC address of the destination address is not known, the switch will first perform a lookup in its cache. If the address is not found even in the cache, then a request is flooded to all the ports within the same broadcast domain until the MAC address is identified.

TCP/IP uses ARP to map the IPv4 address with the MAC address. The ARP protocol functionality, defined in RFC 826, relies on primarily two packets:

  • ARP request: An ARP request is basically a broadcast packet that is initiated by the sender or source host when it does not know the MAC address of the destination host or receiver.

  • ARP response: When a host with the destination IP address for which the ARP request was sent receives the ARP request, it replies with an ARP response, which is basically a unicast packet directed toward the sender or the source host.

To understand how ARP works, examine the topology shown in Figure 3-5. In this topology, Host 1, Host 2, Host 3, and Host 4 are connected to an L2 switch and Host 1 wishes to send data toward Host 2. Because Host 1 does not know the MAC address of Host 2, it broadcasts an ARP request toward the switch.
Figure 3-5

ARP request

On receiving the ARP request, the switch first updates its MAC address table with the MAC address of Host 1 (if it doesn’t already know about the MAC address) and then broadcasts the ARP request to all the hosts within the same VLAN. All three hosts receive the ARP request. Because Host 2 holds the destination IP address in the ARP request, it updates its MAC ARP cache and sends an ARP response toward Host 1 as shown in Figure 3-6. The reply is a unicast reply because Host 2 knows its own MAC address but it also knows about the MAC address of Host 1, which it learned via the ARP request.
Figure 3-6

ARP response

Any further communication between Host 1 and Host 2 will be unicast unless one of them has its ARP entry time out. Figure 3-7 and Figure 3-8 show the Wireshark capture of the ARP request and ARP response.
Figure 3-7

Wireshark capture ARP request

Figure 3-8

Wireshark capture ARP response

IPv4 Packets

Defined in RFC 791, The Internet Protocol version 4 (IPv4) address is a 32-bit address that could allow anywhere from two to hundreds and thousands of hosts to be in each network segment. The way subnets are implemented in organizations allow them to scale quickly without having to make much change in routing. As stated before, the purpose of IP was to deliver logical addressing for various network elements and to provide routing capability across different network segments. Because there was not much advancement that happened in the early 1980s and there were limited bandwidth options available, when IPv4 addressing was standardized in 1983, one of the foci was solving the fragmentation problem that would allow the packets to be broken into smaller chunks. Today, with Gigabit Ethernet technologies in place and support for jumbo MTUs, we rarely have to deal with fragmentation in the network. All the fields of the IPv4 header are shown in Figure 3-9.
Figure 3-9

IPv4 header

To understand the capabilities of IPv4, let’s examine the IPv4 header in detail. The IPv4 address has several fields as shown in Figure 3-9:

  • Version: This 4-bit field indicates the IP version being used. There are devices that could be dual stack (support for IPv4 and IPv6 address) and the version field helps the device understand how to treat the traffic.

  • Internet Header Length (IHL) : This is a 4-bit field that contains the size of the IPv4 header. The 4 bits are used to specify the number of 32-bit words in the header. The minimum value of this field is 5 and the maximum value is 15, which basically indicates that the minimum IPv4 header length can be 20 bytes and the maximum can be 60 bytes.

  • Differentiated Services Code Point (DSCP) : This is a 6-bit field that was previously known as a Type of Service (ToS) field. This field specifies differentiated services (DiffServ), defined in RFC 2474, and it is used to provide service quality features such as Voice over IP (VoIP) calls or data streaming. Based on the values assigned in this field, different traffic streams are given different priority in the network and treated differently by routers and switches.

  • Explicit Congestion Notification (ECN) : ECN is a 2-bit field that allows for end-to-end network congestion notification without dropping packets. For the ECN feature to work, both endpoints are required to support this feature.

  • Total Length: This is a 16-bit field that defines the entire packet size in bytes including the header and payload. The minimum size is 20 bytes and the maximum size is 65,535 bytes.

  • Identification: The Identification field is used to identify a group of IP datagram packets uniquely and is also widely used for packet tracing purposes.

  • Flags: This 3-bit field is used to control and identify fragments of an IP datagram. There are three possible values that are set in the Flags field:

    • Bit 0: Reserved

    • Bit 1: Do not fragment (also known as DF bit)

    • Bit 2: More fragments

  • Fragment Offset: This 13-bit field specifies the fragment offset relative to the start of the original unfragmented IP datagram in blocks. Each block is measured in units of 8 bytes. The maximum possible offset is 65,528 ((213 – 1) * 8).

  • Time to Live (TTL) : TTL is an 8-bit field that indicates the maximum time that a packet can live in an Internet system. The maximum value of TTL is 255 seconds and it is decremented when a packet is processed at each routed hop and forwarded to the next hop. If the TTL value is zero (0), the packet is discarded or dropped. This is to ensure that the packets do not keep looping in the Internet system.

  • Protocol: The 8-bit Protocol field is used to denote which protocol will be used in the data section of the datagram. For instance, the two most common protocol numbers that are usually seen in the network are protocol number 6, which is used to represent TCP, and protocol number 17, which represents a UDP packet. The protocol numbers are assigned and maintained by the Internet Assigned Numbers Authority (IANA).

  • Header Checksum: The 16-bit Header Checksum field in the IPv4 header is used for validating the integrity of the packet. When an IPv4 packet arrives at the router, the router calculates the checksum of the packet and compares it with the value in the this field. If the value matches, the packet is forwarded; otherwise, the packet is dropped.

  • Source Address (SA) : The 32-bit Source Address is used to specify the IPv4 address of the source device that originated the packet.

  • Destination Address (DA) : The 32-bit Destination Address field is used to specify the IPv4 address of the destination device to which the packet is destined.

  • Options: The Options field is an optional field that is only set when the IHL value is greater than 5 (i.e., between 6 and 15). The Options field contains values and settings for security-related options and might be considered dangerous by some routers and dropped. You might see the Options field set when using the Record Route option with extended ICMP pings or for Timestamps. Table 3-3 shows the list of options that can be used in an IPv4 header and Table 3-4 displays the defined options for IPv4.
    Table 3-3

    IPv4 Header Options

    Field

    Size (Bits)

    Description

    Copied

    1

    Set to 1 if the options need to be copied across all fragments of a fragmented packet

    Option Class

    2

    0 – Control Options

    1 – Reserved

    2 – Debugging and Measurement

    3 – Reserved

    Option Number

    5

    Specifies an option

    Option Length

    8

    Indicates the size of the entire option; might not be set for simple options

    Option Data

    Variable

    Holds option specific data; might not be set for simple options

  • Data: The data or payload in the Data field is based on the value set in the Protocol field of IPv4 header. For instance, if the protocol number is set to 1, then the payload will contain ICMP-related data.

Table 3-4

Defined Options for IPv4

Option Type (Decimal/Hexadecimal)

Option Name

Description

0/0x00

EOOL

End of Option List

1/0x01

NOP

No Operation

2/0x02

SEC

Security (defunct)

7/0x07

RR

Record Route

10/0x0A

ZSU

Experimental Measurement

11/0x0B

MTUP

MTU Probe

12/0x0C

MTUR

MTU Reply

15/0x0F

ENCODE

ENCODE

25/0x19

QS

Quick-Start

30/0x1E

EXP

RFC 3692-style Experiment

68/0x44

TS

Timestamp

82/0x52

TR

Traceroute

94/0x5E

EXP

RFC 3692-style Experiment

130/0x82

SEC

Security (RIPSO)

131/0x83

LSR

Loose Source Route

133/0x85

E-SEC

Extended Security (RIPSO)

134/0x86

CIPSO

Commercial IP Security Option

136/0x88

SID

Stream ID

137/0x89

SSR

Strict Source Route

142/0x8E

VISA

Experimental Access Control

144/0x90

IMITD

IMI Traffic Descriptor

145/0x91

EIP

Extended Internet Protocol

147/0x93

ADDEXT

Address Extension

148/0x94

RTRALT

Router Alert

149/0x95

SDB

Selective Directed Broadcast

151/0x97

DPS

Dynamic Packet State

152/0x98

UMP

Upstream Multicast Packet

158/0x9E

EXP

RFC 3692-style Experiment

205/0xCD

FINN

Experimental Flow Control

222/0xDE

EXP

RFC 3692-style Experiment

Examine Figure 3-10, which displays the Wireshark capture of an IPv4 packet detailing all the IPv4 header fields. Notice that the Options field is not present in this capture.
Figure 3-10

IPv4 header in Wireshark capture

IPv4 Addressing

Based on the understanding from the IPv4 header, the Source Address and the Destination Address fields store the source and destination IPv4 addresses, respectively. Although these fields are important, it is equally important to understand different types of IPv4 addresses. Primarily, IPv4 addressing is divided into five different classes:

  • Class A: 0.0.0.0 to 127.255.255.255

  • Class B: 128.0.0.0 to 191.255.255.255

  • Class C: 192.0.0.0 to 223.255.255.255

  • Class D (multicast addresses): 224.0.0.0 to 239.255.255.255

  • Class E (experimental addresses): 240.0.0.0 to 255.255.255.255

Within Classes A, B, and C, the IPv4 addresses are further divided into public and private addresses.

  • Public address: Public IPv4 addresses are the addresses that are uniquely identified on the Internet and are usually allocated to organizations by IANA.

  • Private addresses: Private IPv4 addresses are primarily used in almost every organization for managing hosts in LAN environments. These addresses are not advertised in the global Internet routing table. The private IPv4 address range is shown here:

    • Class A private IP: 10.0.0.0 to 10.255.255.255

    • Class B private IP: 172.16.0.0 to 172.31.255.255

    • Class C private IP: 192.168.0.0 to 192.168.255.255

RFC 1918 defines the range of private addresses that can be used by organizations within their LAN environments. Because the private addresses are inherently private, multiple organizations could have the same addressing schemes within their organizations. They communicate to outside networks (Internet) through their public IPv4 addresses, which are allocated to their Internet Gateway routers. Even a home broadband connection works on the same concept. The local network sits behind a modem and the hosts that are part of that network are allocated private IPv4 addresses. These hosts have their default gateway set to the modem and when the hosts want to communicate to the Internet, they use the default route pointing to the gateway. The modem has a dynamically learned or statically assigned IPv4 address that allows the broadband user to access the Internet. Figure 3-11 illustrates how a simple broadband connection is set up.
Figure 3-11

Home broadband Internet connection

There are other addresses, too, apart from the public and private IPv4 addresses, listed here:

  • Loopback addresses: 127.0.0.0 to 127.255.255.255

  • APIPA: 169.254.0.0 to 169.254.255.255

  • Limited broadcast: 255.255.255.255

ICMP

ICMP is one of the key protocols that is used for validating connectivity in the network and for network troubleshooting. ICMP was initially published in RFC 777, which was later deprecated by RFC 792 and was later updated by RFC 4884, RFC 6633, RFC 6918, and so on. Because IP is a best-effort and an unreliable connectionless protocol, ICMP allows identifying and communicating issues that prevent data delivery. Network engineers frequently use the ICMP ping utility, which relies on an ICMP request and ICMP reply to identify reachability between source and destination. There are two versions of ICMP that are used by both the IP versions:

  • ICMPv4 used for IPv4

  • ICMPv6 used for IPv6

To communicate errors or reachability information, ICMP relies on ICMP messages that are set within the ICMP header. The ICMP header has the following fields, shown in Figure 3-12:

  • Type: 8-bit

  • Code: 8-bit

  • Checksum: 16-bit

Figure 3-12

ICMP header

Note

When sending an ICMP packet, the Protocol field within the IP header is set to a value of 1.

Some of the most commonly used ICMP messages are as follows:

  • ICMP Echo Request and Echo Reply: The ICMP Echo Request has the Type/Code value of 8/0 and the ICMP Echo Reply has the Type/Code value of 0/0. The Echo Request and Echo Reply messages are used to validate the connectivity between the source and destination device in the network and are commonly used via the ICMP Packet InterNet Grouper (PING) tool. When the source device tries to verify the connectivity toward the destination device using the PING tool, it sends an ICMP request, and if the destination device is reachable, it responds back with the ICMP reply message.

  • ICMP Redirect message: ICMP Redirect messages are used by routers on nonoptimal paths to notify hosts about the availability of an optimal path between the source and the destination. An ICMP Redirect message has the ICMP Type value of 5 and has four codes:

    • Code 0: Redirect datagram for the network

    • Code 1: Redirect datagram for the host

    • Code 2: Redirect datagram for the type of service and network

    • Code 3: Redirect datagram for the type of service and host

  • ICMP Destination Unreachable message: If a router receives a datagram that it is unable to forward or deliver to the destination, it replies with an ICMP Destination Unreachable message. There can be multiple reasons for the router being unable to deliver the packet. The different reasons are covered under various ICMP codes. The ICMP Destination Unreachable message has the Type value of 3 and the following code options:

    • Code 0: Destination network unreachable

    • Code 1: Destination host unreachable

    • Code 2: Destination protocol unreachable

    • Code 3: Destination port unreachable

    • Code 4: Fragmentation required, and DF set

    • Code 5: Source route failed

    • Code 6: Destination network unknown

    • Code 7: Destination host unknown

    • Code 8: Source host isolated

    • Code 9: Network administratively prohibited

    • Code 10: Host administratively prohibited

    • Code 11: Network unreachable for type of service

    • Code 12: Host unreachable for type of service

    • Code 13: Administratively prohibited

  • ICMP Time Exceeded message: This message is sent by the router to the source device or host if the TTL value reaches 0 before it reaches the destination. One reason that could cause the TTL to expire is that the destination router is more than 255 hops away or, alternatively, there is a routing loop in the network that has caused the TTL value to reach 0. The ICMP Time Exceeded message has the Type value of 11 and has the following codes:

    • Code 0: TTL expired

    • Code 1: Fragment reassembly time exceeded

  • ICMP Source Quench message: If a router receives a large amount of data that it can handle and it can send an ICMP Source Quench message to the sender asking it to slow down the rate at which it is sending the traffic. The ICMP Source Quench message has the Type and Code value set to 0/0.

To see what ICMP packets look like, let’s examine the network topology shown in Figure 3-13. In this topology, there are three routers—R1, R2, and R3—each configured with loopback interfaces.
Figure 3-13

Network topology

The goal is to test the connectivity between the R1 and R3 loopback address. To exchange the routing information, the device is running the OSPF routing protocol. To verify connectivity, the network engineers will initiate a ping request destined to R3 loopback 0 interface IP (i.e., 3.3.3.3) sourcing loopback 0 interface IP (i.e., 1.1.1.1). Figure 3-14 and Figure 3-15 display the ICMP request and ICMP reply packets between 1.1.1.1 and 3.3.3.3.
Figure 3-14

Wireshark capture for ICMP request

Figure 3-15

Wireshark capture for ICMP reply

Although in most cases you might not want to perform a packet capture for ICMP request and ICMP reply packets, in scenarios where even the ICMP packets are unreachable, you might want to perform packet capture to isolate the node that might be dropping the packets.

For basic ICMP packets, there is no special Options field that must be set in the IP header, but when performing a ping test with the Record Route (RR) option, the Options field is set to enable the RR feature. But what is the RR feature? It is used mostly with the ping tool. When the RR option is set in the Options field of an IPv4 header, it forces every router that handles the IP datagram to add its outgoing interface IP to a list in the Options field. When the datagram reaches the destination, the list of IP addresses is copied into the ICMP reply, which is then returned to the sender. Example 3-1 illustrates how the RR option is used with the ping request on a Cisco IOS device.
R1#ping
Protocol [ip]:
Target IP address: 3.3.3.3
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Ingress ping [n]:
Source address or interface: 1.1.1.1
DSCP Value [0]:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0x0000ABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: Record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
Reply to request 0 (71 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (10.1.2.1)
   (10.2.3.2)
   (3.3.3.3)
   (10.1.2.2) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list
Example 3-1

ICMP Ping with Record Route Option

When examining the ICMP packet in Wireshark as shown in Figure 3-16, you will also notice that the IPv4 header now has the Options field with the Record Route option set and the list of IP addresses.
Figure 3-16

Wireshark capture of ping packet with Record Route option

IP Fragmentation and Reassembly

Fragmentation allows the larger sized packets to be broken down into smaller chunks to be sent across network segments that do not support large packets. When traffic is routed across the network devices, the devices in the path might encounter a segment with an interface MTU value that is smaller than the incoming packet size. For such situations, IP fragmentation can be used. It allows a datagram to be divided into smaller chunks so that it can be transmitted across a segments that have a lower interface MTU. When talking about fragmentation, two terms are widely used:

  • Maximum segment size (MSS): Data payload

  • MTU – MSS + IP header (20 bytes) + TCP header (20 bytes)

So, if an interface MTU is set to a default valie of 1500, then the MSS will be calculated as follows:

MSS = 1500 (MTU) – 20 bytes (IP header) – 20 bytes (TCP header)

For a better understanding of how fragmentation works, examine topology shown earlier in Figure 3-13. In this topology, the link between R1 and R2 has an interface MTU value set to 9200, whereas the link between R2 and R3 has the interface MTU value set to the default of 1500. When a ping packet is initiated from R1 sourcing 1.1.1.1 destined to R3 loopback 3.3.3.3 with packet size set to 9140, the packet will be fragmented because the network segment between R2 and R3 has a lower MTU value. In such a case, the more fragments bit will be set in the IPv4 header Flags field as shown in Figure 3-17. In Figure 3-17, we can see the more fragments bit is set but also notice that the Fragment Offset field shows 0. This is because the first datagram packet in the fragmented packets will not have any offset, thus it begins from 0. Any other packet after this packet will have incremental fragment offset values.
Figure 3-17

Wireshark capture of first fragmented packets

Similarly, if we notice the last fragment of the fragmented packets, we can see that the more fragments bit is not set anymore, but the Fragment Offset field is set to 8880, as shown in Figure 3-18. This means that the all the previous fragments cumulatively hold 8880 bytes of data in the payload. Note that the IP Identification field will have the same value across all the fragmented packets of the single large packet. Wireshark also displays all the packets that will be used for fragment reassembly, which will combine to form the final packet of payload size 9140 bytes.
Figure 3-18

Wireshark capture of last fragmented packet

For simplicity and ease of remembering, the IP packets can be categorized into three types:

  • Nonfragmented

  • Initial fragment

  • Noninitial fragment

Based on these packet types, the more fragments bit and Fragment Offset field are set as shown in Table 3-5.
Table 3-5

Fragment Settings in IP Header

Packet Type

More Fragments Flag

Fragment Offset Field

Nonfragmented

0

0

Initial fragment

1

0

Noninitial fragment (not last)

1

Nonzero

Noninitial fragment (last)

0

Nonzero

In today’s networks, we rarely notice fragmentation as most networks these days are designed with support for jumbo MTU (MTU values higher than 1500 bytes). All the Gigabit Ethernet networks support up to 9216 bytes to be set as the MTU value and to leverage the benefit of higher MTU sizes, most applications send the packets with the don’t fragment (do not fragment or DF) bit set. When this bit is set, the router processing the packet will not fragment the packet and will try to send the packet out as is. When a packet is forwarded across a network segment with the DF bit set and the router encounters a next hop interface having lower MTU or IP MTU settings, the router will send an ICMP Destination Unreachable message back with type 3 and code 4, which basically means fragmentation is needed and the DF bit is set. Along with the ICMP Destination Unreachable message, the router also sends the MTU settings of the next hop device to let the source know that it needs to send the packet with a smaller data payload if it wants to send the packet with the DF bit set. Figure 3-19 displays the Wireshark capture of the ICMP Destination Unreachable message along with the MTU settings of the next hop device.
Figure 3-19

Wireshark capture of ICMP Destination Unreachable message

IPv6 Packets

When IPv4 was introduced by DARPA, the 32-bit address space would allow for 232 (4.3 billion) addresses, which seemed sufficient at the time. As networks and the number of devices grew, however, it became evident that the IPv4 address space would not be sufficient based on the number of devices per person. Scientists then developed the IPv6 addressing scheme and increased the address size limit from 32 bits to 128 bits. In 1998, IPv6 addressing was standardized in RFC 2460. IPv6 addressing had a number of enhancements over IPv4:

  • Streamlined header: Although the IPv6 header is much larger than the IPv4 header, several fields from the IPv4 header were removed in the IPv6 header, making it more streamlined.

  • Revised fields: Some of the fields in the IPv6 header were revised when compared to Ipv4:

    • The TTL field in IPv4 was converted to the Hop Limit field in IPv6.

    • The Precedence and ToS fields were moved to the Traffic Class field.

    • The Protocol field was covered under the Next Header field.

    • The 32-bit Source Address and Destination Address fields were now converted to 128-bit Source Address and Destination Address fields.

  • Flow label: Flow label was introduced in the IPv6 header for identifying streams such as real-time traffic that required special treatment in the network.

Figure 3-20 shows the comparison between an IPv4 and an IPv6 header. Notice that even though the the IPv4 header has more field, the IPv6 header looks more streamlined.
Figure 3-20

IPv4 and IPv6 headers

Figure 3-21 shows the Wireshark capture of an IPv6 packet exchange between two devices. The highlighted section of the Wireshark capture shows the IPv6 header. Let’s now examine the fields of an IPv6 header in detail:

  • Version: This 4-bit field indicates the IP version that is in use. For IPv6 packets, you will see the value set to 6.

  • Traffic Class: This 8-bit field is used for allowing special treatment to a packet in the network based on the DSCP values assigned to an IPv6 packet. It is a combination of two fields:

    • TOS: The first 6 bits are used to set the DSCP value of a packet similar to an IPv4 packet. The DSCP value defaults to 0.

    • ECN: The last 2 bits of this field are used for congestion notification similar to how it is done in an IPv4 packet.

  • Flow Label: The 20-bit Flow Label field is used by a source to group a set of packets belonging to the same flow. It is usually used for QoS and to ensure the packets of same flow take the same path.

  • Payload Length: This 16-bit field represents the packet’s payload. The payload may not exceed 216 (65,535) bytes of data except in situations where extension headers are being used. When extension headers are used, the field value is set to 0.

  • Next Header: This 8-bit field indicates the higher layer protocol that follows the IPv6 header.

  • Hop Limit: The 8-bit Hop Limit field is similar to the TTL field in an IPv4 header. The value of this field represents the number of routed hops a packet can traverse before getting dropped or reaching the destination. The maximum value of this field is 255. At every routed hop, the value of the Hop Limit field is decreased by 1 and when the value reaches 0, the packet is dropped.

  • Source Address: The 128-bit Source Address field represents the IPv6 address of the sender from which the packet originated.

  • Destination Address: The 128-bit Destination Address field represents the IPv6 address of the packet’s destination.

Figure 3-21

Wireshark capture of IPv6 header

Note

There is no option for fragmentation in the IPv6 header similar to the Flags or Fragment Offset fields in the IPv4 header. If fragmentation is required on Ipv6 packets, the Extensions header is used.

IPv6 Addressing

Because IPv6 addresses support 128-bit addressing, the protocol supports undecillions (a trillion trillion trillion) addressable spaces, or simply put, 3.4 × 1038 unique IPv6 addresses can be allocated. IPv6 addresses are represented in hexadecimal format written in eight groups of 2 bytes each, with each group separated by a colon. For instance, an IPv6 address would look something like the following address, making it virtually impossible to memorize.
1111:2222:3333:4444:aaaa:bbbb:cccc:0abc
One of the best features of IPv6 address notation is that some groups of zeros can be collapsed using a double colon to form a shorter address. Note, however, that in any given address, only a single collapsible group is allowed. Consider the IPv6 address shown here:
1111:2222:3333:0000:aaaa:0000:cccc:0abc
This address can either be written as:
1111:2222:3333::aaaa:0000:cccc:0abc
or as:
1111:2222:3333:0000:aaaa::cccc:0abc
Note

A deep dive on IPv6 addressing is outside the scope of this book. To learn more about IPv6 addressing, refer to RFC 4291.

There are several types of IPv6 addresses that are supported:

  • Link local address: Link local addresses are automatically assigned to the interfaces on which IPv6 is enabled. These addresses are used to communicate with hosts on the same subnet. This address always starts with FE80.

  • Global unicast: These addresses are public IPv6 addresses that are uniquely recognized and are routable over the Internet.

  • Unicast address: A unicast address is used for a single host on a network.

  • Unique local: These addresses are routable within the administrative domain.

  • Multicast address: Multicast addresses are used to send data to multiple receivers who are subscribed to the multicast group address.

  • Anycast address: Anycast addresses are used to send data to multiple locations using the same IPv6 address. An anycast address is allocated for a set of interfaces that typically belong to different nodes.

Following are the IPv6 address subnet ranges for different IPv6 addresses:

  • Global unicast: 2000::/3

  • Unique local: FC00::/7

  • Link local: FE80::/10

  • Multicast: FF00::/8

Extension Headers

In IPv4, a lot of capabilities were added using the Options field and similar functionalities and those capabilities had to be preserved in IPv6. Having an additional Options field added a bit of an overhead in processing IPv4 headers, though. Taking that into consideration, IPv6 Extension Headers (EH) was introduced, as defined in RFC 2460. The EH are added to the IPv6 headers as needed and the main header of 40 bytes remains as is. Figure 3-22 illustrates what an IPv6 header with EH would look like.
Figure 3-22

IPv6 header with Extension Headers

Table 3-6 lists the various Extension Headers and their mapping for next header values.
Table 3-6

IPv6 Extension Headers and Next Header Values

Order

Header Type

Next Header Code

1

Basic IPv6 header

-

2

Hop-by-Hop options

0

3

Destination options (with Routing options)

60

4

Routing header

43

5

Fragment header

44

6

Authentication header

51

7

Encapsulation Security Payload header

50

8

Destination options

60

9

Mobility header

135

 

No next header

59

Upper layer

TCP

6

Upper layer

UDP

17

Upper layer

ICMPv6

58

ICMPv6

ICMPv6 is a very crucial protocol when it comes to the working of IPv6. Although IPv4 and IPv6 are similar in terms of their overall functionality, ICMPv6 has multiple use cases when it comes to the functioning of IPv6. ICMPv6 provides additional benefits such as these:

  • Improved multicast routing

  • Extensions

  • Stateless Autoconfiguration (SLAAC)

The ICMPv6 header is similar an IPv4 header. It contains the Type, Code, and Checksum fields, followed by ICMPv6 options and contents that are based on type and code values.

In the previous section, you likely noticed that when we were talking about IPv6 addressing, we did not talk about broadcast. That is because there is no concept of broadcast in IPv6, as it is considered an inefficient mechanism. Because there is no broadcast, ARP cannot work for IPv6. This is where ICMPv6 comes into play. We talk about the IPv6 neighbor discovery process in the next section, but for now, let’s focus on the different ICMPv6 messages and their Type and Code values. The ICMPv6 messages are divided into two categories, error messages and informational messages.

Table 3-7 displays a list of the most commonly used error messages in ICMPv6.
Table 3-7

ICMPv6 Error Messages

Type

Header Type

Code

Definition

1

Destination unreachable

0

No route to destination

1

Communication with destination administratively prohibited

2

Beyond scope of source address

3

Address unreachable

4

Port unreachable

5

Source address failed ingress/egress policy

6

Reject route to destination

7

Error in source routing header

2

Packet too big

0

 

3

Time exceeded

0

Hop limit exceeded in transit

1

Fragment reassembly time exceeded

4

Parameter problem

0

Erroneous header field encountered

1

Unrecognized next header type encountered

2

Unrecognized IPv6 option encountered

Table 3-8 displays a list of most commonly used informational messages in ICMPv6.
Table 3-8

ICMPv6 Informational Messages

Type

Header Type

Code

Definition

128

Echo Request

0

 

129

Echo Reply

0

 

130

Multicast Listener Query (MLD)

0

• General query: Used to learn which multicast addresses have listeners on an attached link

• Multicast-address-specific query: Used to learn if a particular multicast address has any listeners on an attached link

131

Multicast Listener Report (MLD)

0

 

132

Multicast Listener Done (MLD)

0

 

133

Router Solicitation (NDP)

0

 

134

Router Advertisement (NDP)

0

 

135

Neighbor Solicitation (NDP)

0

 

136

Neighbor Advertisement (NDP)

0

 

137

Redirect Message (NDP)

0

 

138

Router Renumbering

0

Router Renumbering command

1

Router Renumbering result

255

Sequence number reset

139

ICMP Node Information Query

0

The Data field contains an IPv6 address that is the subject of this query.

1

The Data field contains a name that is the subject of this query, or is empty, as in the case of a NOOP.

2

The Data field contains an IPv4 address that is the subject of this query.

140

ICMP Node Information Response

0

A successful reply. The Reply Data field may or may not be empty.

1

The responder refuses to supply the answer; the Reply Data field will be empty.

2

The Qtype of the query is unknown to the responder. The Reply Data field will be empty.

Note

There are other ICMPv6 informational messages, too. Table 3-8 does not provide an exhaustive list.

IPv6 Neighbor Discovery

To learn about the connected neighbor in IPv6, we have Neighbor Discovery Protocol (NDP). NDP uses the link local address (fe80::/64) as its source and the hop limit is set to 255. IPv6 neighbor discovery relies primarily on two functions, neighbor solicitation and neighbor advertisement.

A Neighbor Solicitation (NS) message is primarily used for three purposes:

  • Determining the link-layer address of a neighbor.

  • Checking the validity of an already defined address.

  • Validating if an IPv6 address generated via auto-config is unique.

Let’s assume we have two hosts or two devices, say A and B, connected to each other and interested in communicating with each other. When Host A wants to form an IPv6 neighborship with Host B, it will send an NS packet. An NS packet is basically a Type 135 ICMPv6 packet. The originating device sends the NS packet to every device on the network via multicast, which basically communicates to the receiver, “What is the MAC address of 2001:db8:12:2? My MAC address is 01:01:01:01:01:01.” When the device that is assigned the destination IPv6 address receives the multicast NS packet, it responds back with a Neighbor Advertisement (NA) packet, which is an ICMPv6 Type 136 packet. This packet basically tells the source, “Hi. My network address is 2001:db8:12:2 and my MAC address is 02:02:02:02:02:02.” This neighbor discovery process is explained visually in Figure 3-23.
Figure 3-23

IPv6 neighbor discovery

Figures 3-24 and 3-25 demonstrate the NDP though the Wireshark capture. Notice that in Figure 3-24 the NS packet has generated sourcing the client machine’s unicast address with the destination set to the solicited node multicast address. The solicited node multicast address is created by taking the least significant 24 bits of the unicast or anycast address and appending it to the FF02::1:FF00:0/104 address.
Figure 3-24

ICMPv6 Neighbor Solicitation packet

Figure 3-25

ICMPv6 Neighbor Advertisement packet

Apart from the NS and NA messages, other ICMPv6 messages are used as part of the NDP:

  • Router Solicitation (ICMPv6 Type 133): The Router Solicitation (RS) messages are sent by nodes at bootup to find a router in the local segment. These messages are sent by the hosts to the All Router Multicast Address (FF02::2). On receiving this message, an IPv6 router will generate an RA message immediately rather than waiting for the next scheduled interval. Because the destination address is a multicast address, the corresponding Layer 2 address will be in the format 33:33:xx:xx:xx:xx, where xx:xx:xx:xx:xx is the last 24 bits of the destination IPv6 address.

  • Router Advertisement (ICMPv6 Type 134): The RA messages are sent in response to the RS messages or periodically. The RA messages are sent to All Nodes Multicast Address. These messages consist of certain flags and options that contain the information that the interfaces on the links use to configure themselves. IPv6 routers send RA messages periodically at random intervals to reduce synchronization issues when there are multiple IPv6 routers on the segment.

  • Redirect (ICMPv6 Type 137): Redirects are used by IPv6 routers to inform the hosts of a better first hop for a destination.

Analyzing QoS Markings

Almost every organization utilizes time-sensitive applications such as VoIP or streaming media, routing protocols, and so on. Because the global Internet is unpredictable, there are chances that such critical and time-sensitive applications could be dropped. The traffic for such applications should be given higher priority and treated differently in the network than the usual data traffic. To do that, the IPv4 header has the Type of Service (DSCP + ECN) field and the IPv6 header has the Traffic Class field, which allow the user to set DSCP values that will categorize different application traffic. The network devices such as routers and switches can then be configured to treat the traffic based on their DSCP values.

Although we deal with QoS settings mostly at Layer 3, there is still the possibility of frame prioritization at the Layer 2 level. This is done using Class of Service (CoS) bits in Layer 2 frames. If we talk about a regular packet, at the outermost layer we have the Layer 2 header, then the IP header, and then the data or payload. From the Layer 2 frame perspective, we usually have an 802.1Q or 802.1p frame. Figure 3-26 highlights the Tag field in the 802.1Q header, which is used for setting CoS bits.
Figure 3-26

QoS at Layer 2

The 802.1Q frame header has a 16-bit Tag control information field that has the following subfields:

  • Priority code point (PCP): 3-bit

  • Drop Eligible Indicator (DEI): 1-bit

  • VLAN Identifier (VID): 12-bit

The PCP field refers to the IEEE 802.1p CoS and maps to the frame priority level. The values of this field are used to prioritize different classes of traffic.

When talking about QoS at Layer 3, ToS (DiffServ field) or Traffic Class is an 8-bit field, out of which the initial 6 bits make up the DSCP field and the last 2 bits are for ECN as shown in Figure 3-27.
Figure 3-27

DiffServ field

Based on the 6-bit DSCP values, the traffic is given different treatments in the network and these values are categorized as explained here:

  • Default Forwarding (DF) : Any traffic that does not meet the criteria of any of the defined classes falls under the category of Default Forwarding. The default and recommended DSCP value of this class is 0.

  • Expedited Forwarding (EF) : RFC 3246 defines the EF per-hop behavior (PHB) for traffic that has low delay, low loss, and low jitter requirements. This class is suitable for voice, video, and real-time service traffic. The recommended DSCP value of EF is 46.

  • Assured Forwarding (AF) : RFC 2597 and RFC 3260 define the behavior for the AF class. This class assures delivery of traffic if the traffic does not exceed some subscribed rate. Within AF, four separate classes are defined and packets within each class are given drop precedence (low, medium, and high). Note that the traffic within one class has the same priority. Table 3-9 shows the different AF classes categorized based on their drop probability.
    Table 3-9

    Assured Forwarding Classes Based on Drop Probability

    Drop Probability

    Class 1

    Class 2

    Class 3

    Class 4

    Low

    AF11 (DSCP 10)

    AF21 (DSCP 18)

    AF31 (DSCP 26)

    AF41 (DSCP 34)

    Med

    AF12 (DSCP 12)

    AF22 (DSCP 20)

    AF32 (DSCP 28)

    AF42 (DSCP 36)

    High

    AF13 (DSCP 14)

    AF23 (DSCP 22)

    AF33 (DSCP 30)

    AF43 (DSCP 38)

  • Class Selector: Before DiffServ, IP networks used the IP Precedence field in the ToS byte to prioritize the traffic to maintain backward compatibility with devices that still use IP Precedence, and the Class Selector PHB was defined. Table 3-10 lists all the IP Precedence values.

Table 3-10

IP Precedence Values

Value

IP Precedence Bits

IP Precedence Name

0

000

Routine

1

001

Priority

2

010

Immediate

3

011

Flash

4

100

Flash Override

5

101

Critical

6

110

Internetwork Control

7

111

Network Control

To sum up, the different DSCP values and their corresponding IP Precedence values are shown in Table 3-11.
Table 3-11

DSCP and IP Precedence Values

DSCP Value

Decimal Value

Meaning

IP Precedence Value

101 110

46

Expedited Forwarding (EF)

101 – Critical

000 000

0

Best Effort/Default

000 – Routine

001 010

10

AF11

001 – Priority

001 100

12

AF12

001 110

14

AF13

010 010

18

AF21

010 – Immediate

010 100

20

AF22

010 110

22

AF23

011 010

26

AF31

011 – Flash

011 100

28

AF32

011 110

30

AF33

100 010

34

AF41

100 – Flash Override

100 100

36

AF42

100 110

38

AF43

001 000

8

CS1

1

010 000

16

CS2

2

011 000

24

CS3

3

100 000

32

CS4

4

101 000

40

CS5

5

110 000

48

CS6

6

111 000

56

CS7

7

Based on Table 3-11, it can be understood that traffic such as voice, video, and network protocols are given a higher priority in the network. All the routing protocols traffic is sent with the DSCP value of CS6. To deal with all other traffic such as voice, video, or application traffic, QoS needs to be configured on a per-hop basis so that each device can treat the traffic accordingly. Figure 3-28 shows the Wireshark capture of a BGP keepalive message that is marked with a DSCP value of CS6 under the DiffServ field in the IP header.
Figure 3-28

Wireshark capture of BGP packet

When performing network QoS testing and validation, network operators can simply use the PING tool to mimic different application traffic. Example 3-2 demonstrates how to use this tool on Cisco IOS-XE software and Mac OS to simulate traffic with different ToS and DSCP settings. Although the traffic can be initiated, it is important to note that the network devices should be configured accordingly to perform further classification of the traffic. Note that when initiating the ping on Mac OS, use the -z option to specify the ToS value. Note that the binary for 184 is 1011 1000. This means that the packet will be sent with the DSCP value of 46 (101 110 in binary) and with the ECN field set to 0 (00 in binary).
! Ping on Cisco IOS-XE Software
R1#ping
Protocol [ip]:
Target IP address: 2.2.2.2
Repeat count [5]: 100
Datagram size [100]: 1400
Timeout in seconds [2]:
Extended commands [n]: y
Ingress ping [n]:
Source address or interface: 1.1.1.1
DSCP Value [0]: 46
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0x0000ABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 1400-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/46 ms
! Ping on MAC OS with DSCP value 46
vinit@Hackers-Box ~ % ping -z 184 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=125.217 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.200 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=2.703 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=49.220 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=1.386 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=1.347 ms
Example 3-2

Using PING for Traffic Simulation with DSCP Settings

Note

ECN bits in the DiffServ field will be covered in the next chapter.

Summary

By now, you should understand the Layer 2 and Layer 3 concepts as well as have a solid foundation about the different fields in Ethernet, IPv4, and IPv6 headers. In this chapter, we covered in detail the Layer 2 header, specifically the Ethernet header, and learned about various EtherTypes. We also learned about the IPv4 header, including how the packets get encapsulated inside the IP header and uses of various fields in the IP header. We also covered the ICMP header and how it can be used for troubleshooting purposes, and how ICMP messages can be used to notify the network about incorrect network MTU settings.

We then moved on to IPv6 headers, which helped network operators transition from 32-bit addressing to 128-bit addressing. We discovered some of the benefits of IPv6 over IPv4 headers and how they reduce the need for having broadcast packets by performing neighbor discovery using ICMPv6 headers. We learned that in IPv6, NDP leverages different ICMPv6 messages such as Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, and Redirect message.

We also learned that the ICMPv6 messages are sent to different IPv6 multicast addresses. Finally, we ended this chapter learning about how QoS can be used in the network and how the DSCP values can be used to treat each type of application traffic differently.

Reference 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.223.108.105