Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Troubleshooting the Broadcast IP Network

A structured approach to IP troubleshooting will result in faster results and less downtime

The author is director of engineering at Educational Broadcast Services at Texas A&M University.

IP networks have become an integral aspect of the broadcast technical plant. Integration with the legacy broadcast infrastructure can range from minimal control functions to a complete IP-based content transport facility. Regardless of the integration level or complexity, the IP network is yet another critical system for the broadcast engineer to understand and maintain.

Over the past years, many networking schemes and protocols have come and gone. Today, the Ethernet-based Internet Protocol (IP) network has become the de facto standard of the IT industry, and in turn the broadcast plant.

When abnormalities do occur within the network, how does the broadcast engineer isolate and resolve IP network issues in a timely manner? Too often, “shooting from the hip” troubleshooting approaches occur under the pressure of quickly resolving the problem.

A structured approach to IP network troubleshooting can be developed by using a layered approach modeled after the industry standard “OSI Networking” model [see Reference 1 at the end of the story]. The layer design of the OSI model provides the framework in which to build a structured troubleshooting process focused upon the Data Flow layer functionality of the OSI Model to quickly isolate the root cause issue.


An understanding of IP Networking fundamentals is yet another essential knowledge area for the broadcast engineer to master. Five components are required to build a network. These components include:

● A send host device
● A receive host device
● A message or data to be sent between the host devices
● A medium to provide connectivity between the host devices
● A set of rules or “protocol” to govern the behavior of the host devices

Communications occurs between hosts in one of three forms; unicast, broadcast or multicast.

Unicast is the basic one-to-one host communications scheme. Broadcast communications represents a one-to-many approach whose scope is all host devices that are members of a specific network.

Fig. 1: The five major components of a network

Multicast is similar to broadcast, except the scope is to selected host devices or devices that desire to receive the multicast information. Fig. 1 illustrates a simplistic conceptual “unicast” network model. Such a simplistic network model is often discounted as useless information, as the real world is comprised of networks of tens, hundreds and even thousands of network devices. In reality, this basic network model is often useful to troubleshoot the network with multiple host devices to isolate individual hosts or maybe groups of hosts exhibiting similar if not identical issues.

IP networking consists of “standards” that govern interoperability and practices that allow systems to be implemented, which are built with products from many different manufacturers. It should be noted that proprietary as opposed to open standards do exist from many manufacturers, and may bring some unique and essential capability to the system design, but the use of open standards-based devices allows for a flexible system today and tomorrow.

Several international organizations come into play when networking standards are discussed. Some of the standards or practices fall into the “de jure” category and others into the “de facto” category. Three significant organizations that provide the bulk of the industry networking standards include:

● The Internet Engineering Task Force — IETF
● The Institute of Electrical & Electronic Engineers — IEEE
● The International Standards Organization — ISO

IETF is considered the foundation standards group for Internet Protocol-based networking. The “Request-for-Comments” series (RFC-xxx) of documents form the bible of IP networking with all aspects of protocol functionality defined.

IEEE is the governing body for the Ethernet standard. Ethernet was developed over 40 years ago and is the “standard” physical networking medium in use today. Ethernet standards are described as “Project 802” standards and are organized under an 802.xx nomenclature system. Ethernet standards range from the legacy 10 Mbps coaxial bus networks to the more common 100/1000/10000 Mbps twisted-pair and fiber optic network infrastructures.


Fig. 2: The OSI model

In the early 80s, ISO brought a fundamental model concept to the networking industry that has become the language of the networking industry today, even 35+ years after its introduction. The Open System Interconnection or OSI model is a layered abstract model that describes the process of a host application communicating with the network. The model describes how data traverses each of the 7 layers of the model from the Application layer (7) to reach the Physical layer (1). Fig. 2 illustrates the OSI Model [see Reference 2].

Fig. 3: The Data Flow layers of the OSI model

Each layer of the model describes a functional aspect of a host application communicating with the network. The first four layers (1–4), illustrated in Fig. 3, of the seven-layer model are considered the “Data Flow” layers, and these layers are of primary interest to the understanding of networking and the terminology used within the industry. The upper three layers (5–7) are considered Application layers. The upper layers are not considered to be an active component of networking.

The Data Flow layers of the OSI Model become the basics of formulating a structured approach to network troubleshooting by beginning at the Physical layer (Layer 1) and working your way up the “stack” by verification of the respective functionality of each layer. Each of the Data Flow layers has an associated Protocol Data Unit (PDU) that defines how the information is packaged at the respective level.

The Physical layer is often the simplest layer to understand since it deals with “bits” or placing a “1” or “0” onto or taking off of the network medium. The terminology “placing bits onto or taking off the wire” is often used to describe this process. The PDU at Layer 1 is the “bit.” Common network devices found at Layer 1 include hubs and repeaters.

The Data Link Layer provides the host device physical hardware address by means of a Media Access Control (MAC) address, provides network access control, and error detection. The Ethernet hardware address is fixed by embedding the MAC address within the network adapter firmware. The PDU at Layer 2 is the “frame.” Common network devices found at Layer 2 include switches and bridges.

The Network layer provides a virtual address for the host device in the form of an IPv4 or an IPv6 address. The IP address as a virtual address will vary depending upon the network address that the host device is attached to and must be unique if global routing on the Public Internet is intended. Layer 3 also provides “Internetworking” by interconnecting different Layer 3 networks by means of routing to determine the best path to a distant network. The PDU at Layer 3 is the “packet.” Common network devices found at Layer 3 include routers.

Fig. 4: The Protocol Data Unit (PDU) at Layers 1–4

The Session layer is focused on providing an end-to-end control of communications flow between host devices. Protocols such as TCP, UDP and RTP are typically utilized in the flow control process with the network application and associated information content determining the best approach. Real-time content will often utilize non-guaranteed UDP flow control in order to minimize the latency occurring in guaranteed TCP flow control handshaking. The PDU at Layer 4 is the “segment.” Fig. 4 summarizes the Protocol Data Unit (PDU) for each of the Data Flow layers.


Troubleshooting is often described as an “art” and a “science.” The science aspect brings technical facts to the process and the art is gained from practical experience. Troubleshooting efforts are often more productive where a structured approach is utilized rather than random applications of “let’s try this” approaches.

A device “re-boot” is often the first step in resolving or attempting to resolve many network-related problems. This approach may be practical in a small network infrastructure, but is often not practical in a network with multiple host performing strategic production services such as a broadcast plant.

Fig. 5: Simplified troubleshooting steps

Formal processes are often defined for network troubleshooting such as the eight-step CompTIA A+ process found in many certification training courses [3]. The troubleshooting process can be summarized in three steps. Fig. 5 illustrates a simplified troubleshooting approach.

These simplified steps can be combined with the OSI model to form a structured approach by beginning with the Physical layer functionality and working up through the Data Flow layers. In general terms, network abnormalities can be classified as no connectivity, intermittent connectivity and working but exhibiting poor performance. The troubleshooting goal is to isolate the specific root cause that could be occurring within Data Flow layers.

The Physical Layer

Beginning at the Physical layer, you should be focused upon verification that the physical medium of the network is functional. Often faults in this area consist of cabling issues where twisted-pair copper cable is the physical medium.

Fig. 6: Twisted-pair cable verification

Whereas a basic ohmmeter can be used to verify continuity of wiring pairs, a cable scanner offers a quick method to verify cable issues or detect mis-wiring. Common twisted-pair cable faults include Reversed Pair, Split Pair and Transposed Pair wiring mishaps. Many cable scanner devices also offer additional capability by providing cable verification, certification and qualification. Fig. 6 illustrates a typical industry cable scanning device display verifying a twisted-pair cable.

When higher bandwidth Ethernet standards are deployed, fiber optic cabling becomes the norm especially in the 1000 Mbps infrastructures. Verification of a fiber optic network infrastructure calls for some basic optical test equipment, such as an optical power meter to more advanced test equipment providing Optical Time Domain Reflectometry (OTDR) measurements.

Optical network path design is similar in concept to RF path design. You begin with a desired receive optical level and work back to the source, accommodating for various path loss factors. Or you begin with a source launch power and work towards the receiver, accounting for loss factors throughout the path.

Small Form-factor Pluggable (SFP) optical transceivers are chosen based upon the fiber type (multi-mode or single-mode) and launch optical power expressed in dBm. An LED or laser emitter device will be found based upon the specified power. Loss factors that should be accommodated for include fiber path loss, connector loss and fusion splice loss.

Do not forget to design some margin into the optical path. Fiber loss will range from 3 dB/km (multi-mode fiber at 850 nm) to 0.4 dB/km (single-mode fiber @ 1510 nm). Best practice designs recommend utilizing a connector loss and splice loss of 0.3 dB. Keep in mind the TIA/EIA specification for maximum fiber connector loss is 0.75 dB.

Recognize that too much optical light level at the receiver can produce data errors. Most optical receivers require a light level within the range of –27 to –8 dBm. Best practical designs recommend that you design for a “sweet spot” or a receiver light level between –23 and –17 dBm. When too much signal is found, optical attenuators are used to decrease the optical light level to a suitable level.

Optical power meter measurements are essential to troubleshooting. A handheld optical power meter is the common tool utilized. A typical device allows an optical light level to be measured at various optical wavelengths accommodating the common ITU wavelengths found in products.

Common wavelengths include 850 nm and 1300 nm for multi-mode fiber and 1310 nm and 1510 nm for single-mode fiber. In a similar manner to twisted-pair cabling test devices, OTDR capability can be found in more expensive test products and is useful to certify an installed fiber optical path or provide detailed fault location distance measurements.

Fig. 7: Physical layer fault summarization

Research has shown that 80 percent of network problems are based upon problems in the Physical layer infrastructure with standards and guidelines not properly adhered to. This is common place when host migration from 100 Mbps to 1000 Mbps occurs. Common copper and optical Physical Layer faults are summarized in Fig. 7.

The Data Link Layer

Once the Physical layer infrastructure is verified, Layer 2 or the Data Link layer functionality is investigated. At Layer 2, the Ethernet II switch is the basic building block of a modern network. The Ethernet switch is based upon an early network device: the “bridge.” Ethernet bridging or Ethernet switching terminology is often used interchangeably [4].

The Managed Ethernet switch is typically used in a professional network environment such as the broadcast technical plant. A Managed switch allows for custom configuration of the switch operating parameters, configuration and monitoring of individual switch ports and the establishment of VLANs. The individual switch port monitoring capability becomes a useful feature to aid in Layer 2 troubleshooting efforts. The Ethernet switch provides four basic functions and includes:

��� Learning MAC Addresses
● Filtering Ethernet Frames
● Forwarding Ethernet Frames
● Flooding of Frames Throughout the Network

Learning MAC addresses is a major function of an Ethernet switch. The switch listens to traffic occurring on each port and captures the source MAC address of any incoming frames on each port. The frame and port information is maintained in an internal table within the switch. This internal MAC address table is automatically created by the normal traffic flow process in the network.

Fig. 8: The Ethernet II or “DIX” frame

Today, the Ethernet II frame is often referenced as the “DIX” frame format as illustrated in Fig. 8. The Ethernet II or DIX Frame is widely in use today in IP-based networks. The “DIX” acronym refers to the industry developers: Digital Equipment Corp., Intel and Xerox. Multiple Ethernet frame types can exist on a network, but it is important to recognize that a host device can only transmit or receive a single frame type. Thus, all host devices must be configured for the same frame format for communications to occur.

The Ethernet frame payload length can vary within minimum and maximum limits within the Ethernet frame. If a frame is less than 64 bytes (46 payload bytes + 18 header bytes) the frame is referred to as a “runt” frame. Likewise, a frame greater than 1518 bytes is considered a “giant” frame. Runt or giant frames occur due to some type of error condition, which is often a collision between send host devices. A “giant” frame should not be confused with a “jumbo” Ethernet frame, which is a valid frame often used in advanced networking applications where all network hardware offers support for such frame formats.

Ethernet frame “filtering” is a common function of an Ethernet switch. If the frame is errored as detected by the Cyclic Redundancy Check (CRC) process, the frame is dropped by the Ethernet switch. When a managed switch is utilized, the port monitoring feature allows this action to be monitored, and thus the Ethernet switch becomes a useful diagnostic device. “CRC” errors occurring on an individual switch port is an indication of abnormalities occurring.

The “Auto-Negotiation” feature of many network devices is often found to be a source of CRC errors within a network infrastructure. The goal of Auto-Negotiation is to automatically set the host device port parameters with regards to port speed and duplex configuration. This automatic process is based upon use of the Ethernet 802.3 standard Fast Link Pulse (FLP) and Normal Link Pulse (NLP) features enabling a host device to determine port configuration.

Unfortunately, the practical reality that this process often does not work correctly and the end result is mismatched host port configurations causing CRC errors and degrading network performance. A conservative approach is to hard-set host devices within the broadcast infrastructure rather than allow for auto-negotiation.

Common Layer 2 faults include failed or intermittent host device network interface adapters, failed or intermittent Ethernet switch ports, host-switch port configuration mismatch, and excessive CRC errors impacting performance. In summary, the managed Ethernet switch port diagnostic features become a valuable troubleshooting resource.

The Network Layer

At the Network layer or Layer 3, The IP address is a key component of the Layer 3 functionality, whether IPv4 or the newer IPv6 format. Inter-network connectivity or “routing” is performed at the Network layer as well. Several key points should be kept in mind with regards to IP addressing, and these points should be considered as rules to observe and verify in the troubleshooting process:

● Each network must have a unique network ID
● Each host must have a unique host ID
● Every IP address must have a Subnet Mask
● An IP address must be unique if global routing is required

An important step in troubleshooting is to ensure that the IP address and subnet mask are correct for the host or hosts experiencing abnormalities. An error can occur in network IP address design and allocation or an error can be easily made in entering host configuration information. Often these errors go undetected and arise as additional hosts are added to the network or changes occur.

Fig. 9: IPv4 address and address subnet mask

An IP address, whether an IPv4 or IPv6 address, is a two-part address, in practice comprised of a “network” address and a “host” address portion. Fig. 9 illustrates the subnet mask impact upon an IPv4 address. The subnet mask determines where the separation point between the network and host addresses occur. The subnet mask determines the position of the dividing line between the network address and the host addresses. Bits to the left of the dividing line represent the network address. This is often referred to as the “wire address.” Bits to the right represent the host address.

Fig. 10: IPv4 subnet calculation tool (

It is important to remember that the first address and the last address of an IP network or subnet are not useable for host assignment. The first IP address of the network range represents “wire address” and the last IP address of the range represents the broadcast address for the network. The network address range can be easily determined with an IP address and associated address mask. Manual calculation techniques or one of many subnet calculation tools can be found to quickly verify the IP addressing scheme and ensure that a host device is addressed properly for a given IP network. Fig. 10 illustrates one such subnet calculator.

IP address subnet masks may be represented in one of two formats. Dotted decimal notation may be used when specifying an IPv4 address mask, such as “” or the same mask may be represented in a shorthand notation referred to as “CIDR” notation in the format of “/19” to represent the same dotted-decimal mask. The “/” indicates the CIDR notation and “19” represents the number of bits. CIDR notion is exclusively used to represent an IPv6 subnet mask. In summary, “” or “/19” indicate the same subnet mask.

The Network layer or Layer 3 also provides a unique protocol that is often utilized to create troubleshooting applications. IETF RFC 1256 defines the Internet Control Message Protocol or “ICMP” [5]. ICMP is a Layer 3 protocol used to exchange diagnostic messages between host devices on an IP network. ICMP is the underlying basis for common IP network utilities such as “ping” and “traceroute.”

Fig. 11: Use of the “ping” command to verify connectivity between IP hosts

The Packet Internet Groper or “ping” utility is probably the most common IP network utility to verify host connectivity. A send IP host device transmits an ICMP “echo request” to the destination IP host device. The destination IP host device returns an ICMP “echo reply” to the sending IP host. The round-trip time or latency is also provided by the ping utility. Fig. 11 illustrates this process.

A common practice is to “ping” the loop-back interface of an IP host device. The common IPv4 loop-back address of “” verifies that the local host device IP network stack is functional. For an IPv6 network, the loopback address or “::1” is utilized.

Fig. 12: Use of the “traceroute” command to observe network performance

The “traceroute” utility is another popular IP network diagnostic tool. IETF RFC 1812 defines the operation of this utility, which is also based upon ICMP commands [6]. The send IP host transmits a packet to the destination IP host with the IP header Time-to-Live (TTL) value of 1 and a random IP port number. If unable to reach the desired IP host, a ICMP TTL “exceeded” response is sent to the send host. The send host then transmits a packet to the destination IP host with a TTL of 2. Still unable to reach the desired IP host, another ICMP TTL “exceeded” response is sent to the send IP host. This process repeats until the desired IP host is reached. Once the destination host address is reached, a “destination host port unreachable” reply is returned. Latency values or times are compiled to provide an indication of network performance. Fig. 12 illustrates this process.

These utilities are common to all IP host devices and operating systems. It should be noted that some host devices do not provide the user ready access to these tools. Especially in the case of embedded system IP host devices, these tools are reached via diagnostic menus or a command lines-based interface. These utilities also have some limitations that should be noted that can impact use and returned results.

In some networks, ICMP may be blocked at a network’s edge as a security measure to prevent outside network probing. Network routers may limit ICMP command processing to preserve resources for packet forwarding. And since ICMP is a Layer 3-based protocol, Layer 2 devices such as an Ethernet switch will not be seen in the returned traceroute display results.

Thus an understanding of ICMP limitations and an understanding of returned traceroute results can greatly impact the accuracy of the provided information. With adequate understanding, these utilities can be very useful in network connectivity troubleshooting.

The Transport Layer

Fig. 13: Transport layer “TCP” handshake between IP host devices

The final layer of the Data Flow layers is Layer 4 or the Transport layer. At the Transport Layer, the Transport Control Protocol (TCP) or User Datagram Protocol (UDP) is commonly found. TCP provides reliable or guaranteed communications between IP host devices by a “handshake” process between the IP hosts. A “3-way” handshake is utilized to establish communications between two IP hosts devices. Once this handshake is established, the hosts exchange information and receipt is confirmed by a handshake acknowledgement of “ACK.” Fig. 13 illustrates this handshake operation.

A UDP session between two IP hosts begins with a TCP 3-way handshake, but once established, information is simply sent without the acknowledgement from the receive host. The lack of an acknowledgment creates an unreliable information exchange. Any missing information or data errors are addressed by a higher layer protocol. UDP is commonly used in “real-time” IP applications such as VoIP or AoIP where the latency of the TCP process is more detrimental than the potential data loss.


Network troubleshooting is often complicated by the fact that you cannot readily view network activity. A flickering green LED on a device commonly indicates activity, but what the activity actually is becomes difficult to view or see. As a result, it is extremely difficult to fix what you cannot see. This is common once connectivity has been determined to be present between IP host devices, but performance abnormalities are present. Protocol analysis then becomes the practical method to view network activity.

“Wireshark” is the most common IP network protocol analysis tool available today. Wireshark is a popular open-source protocol analysis application. Developed in 1998 by Gerald Combs as “Ethereal,” the Wireshark name was adopted in 2006 due to copyright issues. The application provides analysis and visibility of live or recorded network activity. Common uses include network benchmarking, performance analysis and a troubleshooting tool to isolate network abnormalities [7].

Wireshark is a packet-based protocol analyzer applications that utilizes packet-capture APIs or “pcap” libraries to capture Layer 2 frames from the Data Link layer of a Network Interface Adapter (NIC). Normal functions of a NIC allow only frames containing that hosts MAC address or the broadcast MAC address to be passed to other layers. For protocol analysis, the host NIC must be placed in a “promiscuous” mode to allow capture of all frames in and out of the host device.

“Tapping” today’s switched Ethernet network is often the first challenge in network protocol analysis. In the earlier network days, the common bus-based Ethernet was easy to “tap” with a protocol analyzer often referred to as a “Sniffer©,” which refers to an early protocol analyzer manufactured by Network General in the mid-’80s.

Fig. 14: Passive Ethernet tap device

Today it is common to “tap” a network via a passive tap device, an active tap device or utilizing the port monitor features found in a managed Ethernet switch. Passive and active tap devices can be found for twisted-pair and optical physical networks. An example of a common passive 100BaseT Ethernet tap is shown in Fig. 14.

The normal action of an Ethernet switch confines data to only those ports involved in the connectivity of two host devices. The normal function of an Ethernet switch prevents simply plugging into an Ethernet switch port to monitor or view data flow between host devices.

A managed Ethernet switch offers a useful feature for the network engineer to access the data flow between switch ports. “Port mirroring” allows ingress and egress data from an individual Ethernet switch port to be “mirrored” to another switch port. The mirrored port can then be attached to an IP host with the Wireshark protocol analysis software.

Fig. 15: Managed Ethernet switch “SPAN” port configuration

Fig. 15 illustrates the process to mirror host port(s) whose frames are desired to be monitored. In this example, a Cisco-managed Ethernet switch is shown. The Switched Port Analyzer or “SPAN” port is designated such that the analyzer can “see” frames exchanged between desired hosts [8].

Fig. 16: Possible network tap points

The next challenge is to determine where to “tap” the network. The specific nature of the problem you are investigating determines the optimum point within the network. Fig. 16 expands the basic network model to include typical Layer 2 and 3 network devices such as an Ethernet switch and a router. Possible points of interest in which to observe network traffic includes at the problem host, at the destination host, or at a mid-network location. In many cases, accessibility determines where the tap can occur. You may not have access to all devices within an end-to-end network infrastructure.

Fig. 17: Typical Wireshark view

Once Wireshark is installed, you have a suitable method to tap into the network, and you have identified a suitable location within the network to tap, you are ready to capture network traffic for live observation or record network activity for future analysis. Within the Wireshark application, a host network interface is selected, and enabling or starting capture begins the process. As network traffic is captured, the Wireshark application displays information in various windows. You will see a resemblance of the OSI Model layer structure and the Wireshark application window views. Fig. 17 shows a typical Wireshark view.

The upper window displays captured packets found at the network layer. The selected packet can be displayed, frame data is displayed next, and finally the decoder payload data displayed in hexadecimal and ASCII formats.

Another challenge to overcome is the analysis of a considerable amount of data captured even within a few seconds for a small network environment. Recall the basic network model presented earlier in this paper. It is desirable to focus attention to two or more specific hosts. The filtering capability in Wireshark is essential to minimizing the sheer amount of captured data to be analyzed. Filters can be applied as a capture filter or as a post analysis filter. Applying a capture filter can also minimize the amount of captured data and is useful if desired data is specific to any parameters contained in a Layer 3 packet header or a Layer 2 frame header.

Fig. 18: Wireshark filter(s) enabled

A post analysis filter allows all captured data to be available for analysis, but minimizes the amount of screen data to be analyzed. In practice, a combination of capture and post analysis filters are used to focus upon specific areas of interest. Fig. 18 illustrates the use of a filter to display only data exchanges between two specific IP host devices. The filter was created such to display only packets associated with the two IP addresses of the hosts.

Wireshark has features and capabilities far beyond the scope of this troubleshooting paper. The information displayed within a screen view can be customized to accommodate the preferences of an individual user and/or customized to fit the data monitored. It is often useful to add a “time delta” column to display the time difference between individual packets when troubleshooting real-time applications. The network is often pointed to first as the blame for network performance issues. Tools such as protocol analysis quickly can indicate the true source of performance degradation.


A structured approach to your IP network troubleshooting efforts provides the most efficient and effective techniques. The layer design of the OSI model provides the perfect framework in which to build a structured IP network troubleshooting approach by beginning at the Physical layer (Layer 1) and working your way up through the Data Flow layers. Tools such as a cable scanner or optical power meter are often used to quickly isolate physical layer problems where most network abnormalities occur.

Features such as error counters within a managed Ethernet switch provide real-time performance metrics with regards to errors often caused by duplex mismatch between IP hosts. IP network utilities such as ping and traceroute can provide connectivity and performance information.

And finally, protocol analysis can provide insight to actual network activity in real-time enabling one to “see” actual host device interaction at various PDU levels. The visibility of seeing network activity and protocol action can greatly enhance one’s understanding of network device interaction.

Knowledge of the OSI model, IP protocol actions, Ethernet fundamentals, and maybe a little luck can provide the broadcast engineer with the ability to resolve network issues in the broadcast technical plant. As more technical plants utilize IP network transport, the IP network is yet another critical system for the broadcast engineer to understand, effectively maintain and quickly restore when abnormalities occur.

Wayne M. Pecena, CPBE, CBNE, is a Fellow of the Society of Broadcast Engineers, secretary of SBE and chair of its Education Committee. He was named 2012 SBE Educator of the Year and 2014 Radio World Excellence in Engineering Award honoree. He is a frequent industry speaker on IP networking topics for the broadcast engineer.

Comment on this or any story. Write to[email protected].


[1] Allen, N., “Network Maintenance & Troubleshooting Guide,” Second Edition, 2010

[2] Solomon, M., “Fundamentals of Communications & Networking,” 2014

[3] Meyers, M., “CompTIA A+ Certification All-in-One-Exam Guide,” Eighth Edition, 2012

[4] Spurgeon, C., “Ethernet: The Definitive Guide,” Second Edition, 2014

[5] Deering, S. IETF RFC 1256, “ICMP Router Discovery Messages,” 1991

[6] Baker, F., IETF RFC 1812, “Requirements for IP Version 4 Routers,” 1995

[7] Shimonski, R. “The Wireshark Field Guide,” 2013

[8] Balchunas, A., “The Router Alley — Switching Guide,” v1.11