Network

Troubleshooting
NETWORK + N10-009 MODULE 5
Topics
5.1 Troubleshooting Methodology
5.2 Common Cabling and Physical Interface Issues
5.3 Network Service Issues
5.4 Performance Issues
5.5 Troubleshooting Tools and Protocols
 General Troubleshooting Methodology
Troubleshooting Methodology Review
5.1
Troubleshooting
Methodology
Network + N10-009 Module 5
General Troubleshooting Methodology
1. Identify the Problem
2. Establish a Theory of Probable Cause
3. Test the Theory to Determine the Cause
4. Establish a Plan of Action to Resolve the Problem and
Identify Potential Effects
5. Implement the Solution or Escalate as Necessary
6. Verify Full System Functionality and, if Applicable, Implement
Preventive Measures
7. Document Findings, Actions, and Outcomes
1. Identify the Problem
Gather information
Question users
Identify symptoms
Determine if anything has changed
Duplicate the problem, if possible
Approach multiple problems individually
Identify Symptoms
What symptoms are observed?
◦ Could this be a hardware issue, connectivity issue, or policies applied to devices or software?

Consider symptoms and pinpoint what areas are being affected

◦ Is this a:
◦ Problem that points to a single device or user?
◦ Is this user error, device error, or a combination of both?
◦ Problem that points to a particular server?
◦ Directory Services problem?
◦ Security problem?
◦ Firewall problem?
◦ Cable or wireless problem?
Gather Information
Get a general description of the problem
◦ Time, symptoms, involved systems

Interview Users
◦ Understand the symptoms from the user’s perspective
◦ Helps narrow down potential causes and prioritize troubleshooting efforts
◦ What is not working? (e.g., can't access the internet, slow speeds, application error)
◦ When did the issue start?
◦ How widespread is the problem? (One user, a department, or the entire network)
◦ Are there specific error messages

Troubleshooting History
◦ Avoid duplicating effort and build on prior knowledge
◦ Have similar issues occurred in the past?
◦ What steps have already been taken to resolve this issue?
◦ Have any temporary fixes been applied (e.g., bypassing a router or firewall)?
Gather Information (cont’d)
Affected Scope
◦ Determine if the issue is localized or systemic
◦ Which devices, users, or services are affected?
◦ Is the issue specific to a single device, VLAN, or subnet?
◦ Are there commonalities among affected devices (e.g., same application, same switch)?
◦ Are other users/devices on the same network functioning normally?

Network Environment
◦ Many issues arise from recent changes or external factors
◦ Are there any recent changes to the network or configuration? (E.g., updates, maintenance, new devices added)
◦ Are there known outages in the ISP or upstream provider?
◦ Are environmental factors a concern (e.g., power outages, high temperature, or physical damage to cables)?
Gather Information (cont’d)
Device-Specific Information
◦ Identify any compatibility or configuration issues
◦ Device type (PC, router, switch, server, IoT, etc.)
◦ IP and MAC addresses of affected devices
◦ Operating system and software versions (e.g., firmware, drivers)
◦ Connection type (wired vs. wireless)

Network Configuration
◦ Misconfigurations in these areas are common causes of network problems
◦ IP addressing (static vs. dynamic, correct subnet, and gateway)
◦ DNS server settings
◦ VLAN membership or segment for affected devices
◦ Routing tables and firewall rules
◦ Wireless SSID, channel, and signal strength for Wi-Fi issues
Gather Information (cont’d)
Symptoms in the Network Stack (OSI Model)
◦ Pinpoint the layer where the issue begins
◦ Can the device communicate at Layer 1 (link lights, cable connectivity)?
◦ Is Layer 2 functioning? (MAC address in ARP table or switch table)
◦ Can the device ping the gateway or DNS server? (Layer 3 testing)
◦ Are specific services or ports failing? (Layer 4 testing with telnet or netcat)

Logs and Monitoring Data

◦ Logs can reveal errors, warnings, or trends leading to the issue
◦ Network device logs (e.g., switch, router, firewall logs)
◦ Event logs from client devices (e.g., system or application logs)
◦ Alerts from network monitoring systems (e.g., SNMP traps, Nagios, or SolarWinds)
◦ Performance metrics such as bandwidth utilization or latency
Gather Information (cont’d)
Application-Specific Information
◦ Identifies if the problem is network-related or application-specific
◦ Is the issue with a single application or multiple services?
◦ Application settings, including server IP, port numbers, and protocols
◦ Is there high latency, packet loss, or timeouts affecting the application?

External Dependencies
◦ Many issues can originate from third-party dependencies
◦ Are external services (e.g., cloud apps, SaaS platforms) experiencing outages?
◦ Is the ISP or upstream provider functional?
◦ Are critical services like DNS or DHCP operational?

Tools and Baselines

◦ Tools provide data-driven insights, and baselines help identify deviations
◦ Use network tools like ping, traceroute, Wireshark, and netstat to gather data
◦ Compare current performance with baseline metrics (latency, throughput, error rates)
Determine If Anything Has Changed
When considering symptoms of the problem, find out if:
◦ It worked before
◦ Anything has changed since it last worked

Are the symptoms of the problem occurring on a single machine that has recently been changed
or replaced?
Was there a change in:
◦ Any configuration of switches, routers, firewalls
◦ Directory Services
◦ DHCP
◦ DNS
◦ Policies applies to users or computer
Duplicate the Problem, Including with Users
Work with users and observe problem
◦ Carefully ask users questions and listen to their responses
◦ Observe each step that is taken to cause the problem
◦ Does the problem happen to a single user, group of users, entire
building or organization

Replicate the problem as an administrator detective

◦ Use same steps as observed
◦ Try a completely different method to complete a task to see if
problem continues to exist
Approach Multiple Problems Individually
If during observations, multiple problems seem to be occurring:
◦ Address only one problem at a time
◦ At times, fixing the most common problems can fix the other observed problems

Attempting to fix multiple problems can add confusion and possibly make things worse
◦ If you do manage to resolve the problem, you won’t know which fix worked
2. Establish a Theory of Probably Cause
Question the obvious
Often the best first step is to eliminate the obvious
◦ Go for the easiest fix

Consider multiple approaches

◦ Top-to-bottom/bottom-to-top OSI model
◦ Divide and conquer

Sometimes the first step is not the correct answer

◦ But it still helps with the solution

Each step usually takes you closer to the solution of the problem
Question the Obvious
Investigate simple, common, and often overlooked causes of an issue before moving on to more
complex troubleshooting steps
Rule out basic problems to avoid unnecessary time spent diagnosing more intricate issues
By "questioning the obvious," you can often identify and resolve issues more efficiently, avoiding
unnecessary escalation or complex diagnostics
Check the Basics:
◦ Start with straightforward possibilities such as:
◦ Is the device powered on?
◦ Are cables connected properly?
◦ Is the network adapter enabled?
◦ Are they connected to the right network (Wi-Fi or Ethernet)?
◦ Is the user entering the correct password?
Question the Obvious (cont’d)
Verify Assumptions:
◦ Avoid making assumptions about the state of the system or network
◦ For example:
◦ If someone says the cable is fine, check it yourself
◦ Confirm that all software or firmware versions are compatible

Eliminate User Errors:

◦ Often, the problem might stem from user mistakes, such as incorrect settings or configuration changes

Look for Common Symptoms:

◦ Intermittent connectivity issues may point to a loose cable or faulty hardware
◦ A slow network could be caused by high traffic or a misconfigured Quality of Service (QoS) setting
Question the Obvious Examples
A user reports that they cannot connect to the Internet. Before checking routers or firewalls,
"question the obvious" by ensuring:
◦ The user's Wi-Fi is turned on
◦ They are connected to the correct network
◦ Their Ethernet cable is plugged in securely

An entire department reports slow network speeds. Before diving into bandwidth analysis,
ensure:
◦ There isn’t a large file download occurring on the network
◦ The switches and routers are powered on and operational
Consider Various Approaches
There are two standard approaches:
◦ Top-to-Bottom/Bottom-to-Top OSI Model
◦ Divide and conquer
OSI Model Bottom-to-Top / Top-to-Bottom
Aspect Bottom-to-Top Top-to-Bottom
• Starting with a single host, moving out to the • Starting with the general network/services,
Scope
larger network narrowing down to individual hosts
• Begins with the physical components (OSI • Starts at the user-facing application (OSI
Starting Point
Layer 1) and works up the OSI model Layer 7) and works down the OSI model
Focus • Focuses on physical and foundational Focuses on the user experience and high-level
network connectivity first application-related issues first
Advantages • Catches hardware or physical issues early • Quickly identifies user-facing issues
• Ensures the foundation of the network is • Avoids time spent on lower layers when the
operational before moving up issue is high-level
Disadvantages • May overlook higher-layer problems like • Can waste time on application
misconfigurations in the application. troubleshooting if the issue is at lower layers
Common Use Cases • When the issue is likely infrastructure-related • When the issue is likely user-facing (e.g.,
(e.g., cables, switches, connectivity) application bugs, session timeouts)
• When there is complete network failure • When users report specific application issues
Bottom-to-Top Examples
Test Procedure Validates Comments
Link lights Check for a link light on the • Layer 1 likely ok Does not guaranteed signal
device NIC and/or switchport quality, only that the device or
switchport is receiving carrier on
the link
ARP 1. Clear your arp cache • Layers 2 and 1 ok • Open command prompt as
C:\> arp -d * 2. Ping your default gateway or administrator
C:\> ping <def gw IP> another local neighbor • If you don’t have admin
C:\> arp -a 3. Check to see if you have an privilege, skip step 1 by
ARP entry for that node rebooting
DHCP lease Release and renew your DHCP • Layers 1 and 2 are ok If you can reach the DHCP server
C:\> ipconfig /release lease • DHCP server is responsive to renew your lease, Layers 1 & 2
C:\> ipconfig /renew and DHCP are fine
Try connecting using 1. Ping by name • All layers plus DNS • If one activity is successful,
different protocols 2. Open a browser • “” HTTP / HTTPS then all OSI layers are fine
3. Connect to a shared folder • “”SMB (or FTP, NFS, etc.) • Focus on non-working tests
Top-to-Bottom Examples
Test Procedure Validates Comments
Connect to your own • Open webserver, open a browser • Service itself is running • Make a connection using
service to localhost localhost (loopback) address
• On file server, open Windows run • No need to involve DNS or
line or file client to localhost create a socket
Service listening on a At a command prompt, enter • Service is listening on • Service is ready to accept
port netstat –na its port clients
Verify that you see the open port: • Ensure no local or
0.0.0.0:<port number> intermediate device firewall
rules are blocking inbound
connections
Connect using Attempt to make a normal • Network connectivity at If some device can connect, you
various devices connection from different devices on the server itself is ok can then focus on why others
different networks cannot
Divide and Conquer
Usually a time saver
Requires that you have a sense of where to start
Select an OSI layer (typically Layer 3)
Try a test that validates that layer plus all layers either above or below that layer
◦ Example: If you can successfully ping a destination, there is nothing wrong with Layers 1, 2, or 3
◦ You can generally validate the lower layers more easily than the upper layers with one test

Be careful that you do not attribute a symptom to the wrong layer

◦ Example: When you open a browser to a website, the page cannot be displayed
◦ This does not automatically mean the Internet link is down
◦ The problem could be with DNS name resolution or a firewall
◦ Try pinging by IP address or other using other connectivity tests
 Divide and Conquer Test Examples
Test Procedure Validates Comments
Open a browser to a Go to a website you • All OSI layers are ok • Make sure the site is not in your browser
different website have never visited • DNS is working cache or a local proxy server cache
before • Internet is working • If successful, you can then narrow focus to
specific hosts or issues such as firewall rules
Ping by name: Ping the name of • All OSI layers are ok If the IP address (IPv4 or IPv6) is returned, even if
some website on the • DNS is working the ping itself is not successful, DNS is ok and your
ping www.time.gov Internet that you have • Internet is likely working network at least has connectivity to your ISP
ping neverssl.com not been to in awhile You can then broaden focus to firewall, proxy,
ping example.com (or ever) certificate, specific hosts, sites or browsers
Ping neighbor IP Ping the IP address of • Layer 3, 2, 1 are ok • Start with local neighbor
any neighboring node • Perform progressive pings to identify where
on the same subnet routing fails
• Move to browsing and using other protocols
 Progressive Pings
Try pinging locally, then progressively past your network to see where the failure lies
1. Ping your own TCP/IP stack:
◦ ping 127.0.0.1
◦ ping ::1

2. Ping a neighbor IP on the same subnet:

◦ ping -4 192.168.1.103
◦ ping -6 2601:140:8500:d3d0::cd7d Include the interface index
◦ ping -6 fe80::966a:77ff:fe0c:3ef9%14 for faster response
3. Ping your default gateway
4. Ping the “other side” of your default gateway (IP address of the router’s other interface)
5. Ping a node on another subnet in your private network (not on the Internet)
If IP address is returned, then
6. Ping 8.8.8.8, 8.8.4.4 (your firewall might block ICMP)
DNS (and likely Internet) are
7. Ping by name: neverssl.com, google.com, time.gov, example.com ok, even if ping fails
3. Test the Theory to Determine the Cause
If theory is confirmed, determine next steps to resolve
problem
If theory is not confirmed, establish a new theory or
escalate
If your solution does not fix the problem, BE SURE to
restore the original configuration
◦ You do not want to introduce new problems/variables
If the Theory Is Not Confirmed, Establish a New
Theory or Escalate
If the first theory and steps do not resolve the problem, formulate another theory and steps
You might need to escalate if you cannot think of another theory
◦ When and how to escalate is sometimes decided by an organization’s policies and procedures
◦ In a typical Help Desk, Tier 1 support goes through a script to catch the most common problems
◦ If that does not resolve the issue, then the problem is escalated
4. Establish a Plan of Action to Resolve the
Problem and Identify the Potential Effects
Once you’re sure of the solution, plan on how to roll it out to the affected devices
◦ You might have to roll out solution to the entire network
◦ Consider rolling the solution out in controlled stages

Your plan should include how to roll back to the original state if something goes awry
You will also want to monitor the effects of your solution to ensure it does not create another
problem
5. Implement the Solution or Escalate as Necessary
When you have applied the solution, evaluate the full functionality of the network
Document:
◦ Cause of failure
◦ Solution steps
◦ Recommendations for preventing a future occurrence of this problem

If the solution is found to affect other network operations, consider rolling back and trying
another solution, as well as escalating the problem
6. Verify Full System Functionality and, if
Applicable, Implement Preventive Measures
Run regression tests to uncover any changes to the system or network
◦ Regression tests are a re-run of any original functionality/security tests

The new system may be different, but it should provide the same output as the previous system
7. Document Findings, Actions, and Outcomes
This step is sometimes avoided and is one of the most important in the troubleshooting process
This can be used in the future by other network administrators
◦ Including yourself
Documentation should include:
◦ When the problem occurred and when the solution was implemented
◦ Why the particular solution was used
◦ What changes or fixes were made
◦ Other fixes that might have been considered and why they were not used
◦ Who documented and applied the solution
Build on your initial documentation from Step 5
Establish a searchable knowledge base of problems and solutions for all IT staff to refer to
Troubleshooting
Methodology
Review
Review
Troubleshooting methodology has seven steps:
1. Identify the Problem
2. Establish a Theory of Probable Cause
3. Test the Theory to Determine the Cause
4. Establish a Plan of Action to Resolve the Problem and Identify Potential Effects
5. Implement the Solution or Escalate as Necessary
6. Verify Full System Functionality and, if Applicable, Implement Preventive Measures
7. Document Findings, Actions, and Outcomes
Review (cont’d)
When performing step 1, Identify the Problem, include the following substeps:
◦ Gather information
◦ Question users
◦ Identify symptoms
◦ Determine if anything has changed
◦ Duplicate the problem, if possible
◦ Approach multiple problems individually
When performing step 2, Establish a Theory of Probable Cause, question the obvious and consider
using a standard approach such as:
◦ OSI Top-to-Bottom
◦ Bottom-to-Top
◦ Divide and conquer
Try pinging locally, then progressively ping farther and farther out, moving past your network and
even out into the Internet, to see where the failure lies
Review (cont’d)
When performing step 3, Test the Theory to Determine the Cause, keep in mind the following:
If theory is confirmed, determine next steps to resolve problem
If theory is not confirmed, establish a new theory or escalate
If your solution does not fix the problem, BE SURE to restore the original configuration
◦ You do not want to introduce new problems/variables

Once you’re sure of the solution, perform step 4 by planning on how to roll the solution out to
the affected devices
Your plan should include how to roll back to the original state if something goes awry
You will also want to monitor the effects of your solution to ensure it does not create another
problem
Review (cont’d)
When you are ready, perform Step 5 by implementing the solution or escalating as necessary
For Step 6, perform regression testing to ensure that the network now functions as it should
Finally, document everything, creating a knowledge base that you and others can refer to later
 Common Twisted Pair Issues
Common Interface Issues
5.2 Common Power Over Ethernet (PoE) Issues
Cabling and Fiber Optic Cable and Transceiver Issues
Interface Issues Common Cabling and Interface Issues Review
Network + N10-009 Module 5
Common Twisted
Pair Issues
Common Cable Issues
Cable too long – exceeds the recommended length for speed or use case
Incorrect cable type – cable has the wrong specification for the use case
Damaged UTP/STP cable
◦ One or more of the wires in twisted pair cable is broken
◦ If you see a link light, that only guarantees that you hear carrier, not that signal is clean or you can transmit
Bad plug/port
◦ Dirty/corroded/bent/broken pins
◦ One or more of the wires came loose inside the plug
EMI / RFI interference
◦ Cable too close to electromagnetic noise sources
◦ Insufficient shielding or twists-per-foot to resist the amount of electromagnetic/radio interference in the
environment
Incorrect or Inadequate Cable Type
Using a lower cable category when a higher one is needed
◦ Unable to deliver required speed, noise rejection, distance, or PoE at a distance
◦ The deployed cable category is too low for the use case
◦ The cable length is too long for the speed/use case

Using a cable type that is not standards compliant

◦ You should use EIA/TIA 568A or 568B (most people use B)
◦ Someone bought very cheap cable!
Incorrect or Inadequate Cable Type (cont’d)
Using unshielded twisted pair in an environment that is “noisy” (EMI / RFI)
◦ Insufficient shielding or twists-per-foot to resist the amount of electromagnetic/radio interference in
the environment
◦ Should be using shielded twisted pair or even fiber optic cable

Using a cable with the wrong pinout

◦ Miswired
◦ Using a straight through cable when you need a crossover cable (transposed Tx / Rx)
◦ Using a crossover cable when you need a straight through cable
◦ Using a half-crossover cable when you need a full crossover or vice versa
◦ Using a straight through or crossover cable when you need a rollover (console) cable
Twisted Pair Cable Category Reference

Category Data Rate Application

CAT 5 100 Mb/s Fast Ethernet
CAT 5e 1000 Mb/s Gigabit Ethernet
CAT 6 Up to 10 Gb/s Gigabit Ethernet
10 gb @ 55 meters
CAT 6a Up to 10 Gb/s Gigabit Ethernet
Especially for IP cameras & WAPS at longer distance
CAT 7 Up to 10 Gb/s ScTP up to 100 meters
CAT 8 Up to 40 Gb/s Short distance – 5 – 30 meters
Signal Degradation
Crosstalk
◦ The unwanted transfer of signals between adjacent wires within a cable
◦ Can cause signal degradation, leading to reduced performance and data transmission errors
◦ Was a significant issue in older Ethernet standards (e.g., Cat 3, Cat 5) because of less advanced construction
and shielding
◦ Can still occur in networks with inadequate cable type, poor-quality cables, improper terminations, or dense
cable bundling
◦ Rarely an issue in 1gb/s or faster modern networks
◦ Modern cabling features significantly reject crosstalk (more twists per foot, wire pair separation, individual
wire pair foil wraps)
Interference
◦ Cable is near EMI/RFI noise inducing components (motors, lights, fans, elevator shafts, radiology equipment,
microwave ovens, high power radio transmitters, etc.)
◦ If you can’t avoid electrical wiring, keep data cable as far away as possible, avoid running data cable parallel to
other wiring
Signal Attenuation
The gradual weakening of the electrical signal as it travels over the length of the cable
Occurs naturally over longer distances
Twisted pair should be repeated (re-amplified) at the 85% max recommended distance mark
For PTZ cameras and high-power WAPs, repeat at 50%
◦ The repeater will have to be able to inject power on the line
◦ If PoE not available at the switch, place a separate power injector inline near the end device
Ethernet Cable Do Nots!
DO NOT do the following to Ethernet cables:
 Deform
 Bend
 Stretch
 Staple
 Run parallel with power cables
 Run near EMI/RFI noise inducing components (motors, lights, fans, elevator shafts, radiology
equipment, microwave ovens, high power radio transmitters, etc.)
Damaged Cable / Dirty or Bent Contacts

Put a new end on Pins bent

Clean with down
electronic contact
cleaner spray
Incorrect Pin-out
Pin-out is a term that describes how wires in cables are connected at/on an end
◦ Not a problem if purchasing from a reputable vendor
◦ If a network technician makes custom cables, ensure they use the correct pinouts
◦ Problems can include:
◦ No connectivity, improper/problematic connectivity, very short distance connectivity

Can be detected by visual inspection or by using a cable checker

◦ A connector that has been crimped with the wrong pin-out will have to be cut off, and a new connector
crimped on properly
Locating Pin 1 on an RJ-45 Plug and Jack

RJ-45 Plug RJ-45 Port

RJ-45 Straight-Through Cable Pinouts
Ethernet Crossover Cables
Half-Cross
◦ Some equipment that carries power on the non-data wires needs those wires to remain “straight
through” (un-crossed)
◦ Two pairs (orange and green) are crossed
◦ Pins 1, 2, 3, 6
◦ Two pairs (blue and brown) are un-crossed
◦ Pins 4, 5, 7, 8
◦ In this case, you can simply wire one end as T-568A, and the other end as T-568B

Full-Cross
◦ Now a legacy standard
◦ All four wire pairs are crossed
◦ Only needed for legacy hardware that does not support Auto MDI-X (crossover auto-adjust)
Half-Cross Crossover Cable Pinout
One End
Works in most cases

Other End
Full-Cross Crossover Cable
Might be necessary in some legacy installations
Rollover (Console) Cable Pinout
Used for console connections to Cisco, NetApp, Juniper,
HP, Dell, Ubiquiti, TP-Link, Arista and other devices
Improper Termination
Incorrect termination can include:
Punching down the wrong twisted pair wires to a 110 block
Incorrectly wiring a cable drop to an RJ-45 wall outlet
Incorrectly splicing a fiber optic pigtail
Plugging a spliced pigtail into the wrong fiber optic pass-through jack on a patch panel
Mixing up the pins when crimping an RJ-45 end on a patch cable
Wires too short or too long when crimping an end on a patch cable
Not fully crimping an end when making a patch cable
Inadequate or incorrect strain relief of a bundled fiber optic cable on a patch panel
Bad Termination Examples
Can You Spot the Problem?

Crimping is on the Pinout is completely Orange pair is

wires, not the jacket reversed reversed
Ethernet Cable Pinout Tips
Looking at the RJ-45 with the clip facing away from you, brown is always on the right, and pin 1 is on the left
No more than 1/2" of the Ethernet cable should be untwisted otherwise it will be susceptible to crosstalk
Straight-thru cable:
◦ Is used as a patch cord in Ethernet connections
◦ Has identically-wired ends
◦ Odd-numbered pins are always striped, even numbered pins are always solid colored

Crossover cable:
◦ Has differently-wired ends
◦ Is used to connect two Ethernet devices without a switch/hub
◦ Is used to connect two legacy switches/hubs that don’t support Auto MDI-X (crossover auto adjust)
◦ Has one end with the orange set of wires switched with the green set

Rollover (console) cable:

◦ Has pins on one end exactly reversed from the other end (1 – 8, 2 – 7, 3 – 6, 4 – 5)
RJ-45 Heads

CAT 5e
CAT 7

CAT 6 CAT 8
Crimping an RJ-45 Head

2 3 4
1

5 6
Nice Crimp Job!
Crimp is on the jacket
No extra wire length
No bare wires
All wires have good contact
Keystone Jack
Used to terminate a network drop in the wall
Wire the back
Snap jack into wall plate
Not All Keystone Jacks are Wired the Same Way

Seems ok... Except browns are reversed!

Common Interface
Issues
Interface Statistics
Displays information about the router or switch interface including:
◦ Port status (up / down)
◦ L2 & L3 addresses
◦ MTU, max bandwidth (BW), delay
◦ Reliability, Tx and Rx load
◦ 1/255 – almost no load
◦ 255/255 – 100% utilization
◦ Encapsulation type
◦ Duplex / Speed
◦ Media type
Example commands:
◦ SW1# show interface
◦ SW1# show interface g0/1
Speed Mismatch
Routers and switches can usually negotiate link speed and duplex
◦ If they fail to negotiate, you may have to manually set the speed and duplex

If there is a speed mismatch, in most cases there will be no connection

◦ Interface will show line protocol down
◦ You might see other errors in interface statistics

If there is a connection, it will be unstable with high error rates

◦ The faster device may overwhelm the slower device's buffers
◦ This leads to dropped packets and significant degradation in network performance
Duplex Mismatch
Results in interface errors: collisions, late collisions
One device is in full-duplex mode, and the other device is in half-duplex mode:
◦ The full-duplex device:
◦ May transmit data while the half-duplex device is also trying to transmit, leading to a collision
◦ Since the full-duplex device is not expecting any collisions, it continues transmitting without detecting the collision
◦ The half-duplex device:
◦ Detects the collision, stops transmitting and waits for a random backoff period before trying again
◦ Because the collision is detected late (after the first 64 bytes of the frame), it is classified as a late collision
Interface Input Errors
Count of errors encountered while receiving packets on an interface
Runts
◦ Ethernet frames that are smaller than the minimum allowed size of 64 bytes
◦ Have a malformed or incomplete payload
◦ Caused by duplex mismatches and collisions due to network congestion (node that detects collision abruptly stops
transmitting)
Giants
◦ Frames that exceed the MTU
◦ Caused by MTU mismatch and collisions (a partial frame “attaches” itself to a normal frame)
CRC (Cyclical Redundancy Check)
◦ Indicate data corruption during transmission
◦ Could result from bad cables, interference, or faulty hardware
Unknown protocol drops (Drops)
◦ Incoming packets that are discarded due to unsupported protocols
◦ Note: this counter is actually an input error counter, though it is often listed under output errors
Interface Input Errors Example
Interface Output Errors
The total number of errors encountered when the interface attempts to send packets
Caused by misconfigurations, congestion, hardware failures, duplex mismatch, collisions
Collisions:
◦ Transmitted frame collides with another
◦ Indicate the link is on a shared Ethernet segment
◦ Another device is trying to transmit at the same time

Late Collisions:
◦ Mismatched duplex or cable too long
◦ Late collision counter increments after 64 bytes are received
Port Status
Port status shows administrative state / line protocol state – either can be up or down
Port is up / up:

Port is up / down:
Admin enabled the link, but there is something is wrong at Layer 1 or 2:

Port is down / down:

Admin shut the interface, administratively disabling it:
Port Status – Administratively Down
Administrator deliberately shut down the port
◦ Typically for security or troubleshooting purposes

Can occur on router ports and switchports

Port status will display as down / down
In the port configuration prompt, issue the no shutdown command to bring the port back up

R1#show interface status g0/0

Line Protocol Down Causes
Indicates there is a problem at Layer 1 or 2 including:
Administrative shutdown
Cable disconnection or failure
Poor line/signal quality
Speed or Duplex mismatch
EtherChannel negotiation failure
Encapsulation (Layer 2 protocol) mismatch
VLAN mismatch
Spanning-tree Protocol (STP) port blocking
PoE overload
◦ End device pulls more power than switchport can deliver
Port Status - Suspended
Across various vendors, a switchport status of "suspended" generally refers to:
◦ Link Aggregation Issues - The most common cause for most vendors
◦ Administrative Actions - Port explicitly disabled for operational or security reasons (Juniper, HP, Aruba)
◦ Policy Violations - Port failure due to mismatched settings or policy rules (Extreme Networks, Netgear)
◦ Error Thresholds or Violations - Port suspended due to exceeding error limits or triggering security features

S1# show interface status

S1# show etherchannel summary

Port Status – Error Disabled
The error disabled state is a protective mechanism to prevent potential network issues
Port status will display as err-disabled
Causes:
◦ BPDU Guard violation S1#show interface status

◦ Port security violation

◦ Loop detection S1#show interface status err-disabled
◦ Link / MAC address flapping
◦ Duplex mismatch
◦ EtherChannel misconfiguration
◦ PoE errors
◦ DHCP snooping / ARP inspection violation
◦ Broadcast/Unicast/Multicast storm violation
Power over Ethernet
(PoE) Issues
Power over Ethernet (PoE)
Some switches can provide PoE on their ports
◦ Provides DC power to WAPs, IP phones, cameras, networked industrial controls, alarms, etc.
◦ PoE-capable switches are also referred to as Power Sourcing Equipment (PSE) devices

PoE is useful when there is no convenient power source near the end device
Note: If the switch does not support PoE, you can insert a separate power injector between the switch and
the end device
PoE Power Budget
PoE Budget is the total amount of electrical power in watts that the switch can supply to connected devices
◦ Such as IP phones, wireless access points, security cameras, and other PoE-compatible equipment
◦ The PoE budget is typically less than the sum of all ports operating at their maximum capacity

The budget is shared across all PoE-enabled ports on the switch

◦ Each port can deliver a specific amount of power based on the PoE standard it supports (e.g., IEEE 802.3af, 802.3at,
or 802.3bt)

Most switches implement power allocation strategies

◦ Prioritize certain ports or devices based on administrative settings
◦ If the total power demand exceeds the budget, lower-priority devices may lose power
◦ Configure port priorities to ensure critical devices (e.g., access points, IP phones) receive power first if the budget is
exceeded
◦ For high-demand environments, consider switches with higher budgets, modular power supplies, or external PoE
injectors for specific devices
PoE Power Budget Example
A 24-port PoE+ switch has a total power budget of 320W
Each PoE+ port can deliver up to 30W
If 10 ports are connected to devices requiring 25W each, the total usage will be 250W, leaving
70W for other devices
If more devices are connected and the total demand exceeds 320W, the switch may disable PoE
on lower-priority ports
Common PoE Issues
Power budget exceeded
◦ Be mindful of the switch’s overall power budget
◦ You do not want to overload the switch past its capability
◦ That would cause some ports to not provide power, or require you to prioritize certain ports

Incorrect PoE standard

◦ The PoE-enabled device requires one standard, but the switch only supports a lower standard
◦ Example:
◦ A PTZ (pan-tilt-zoom) IP camera requiring 25.5W from PoE+ will not work with a PoE switch that provides only 15.4W

Incorrect cabling
◦ Use high-quality Ethernet cables (Cat 5e or higher) for PoE+ or PoE++ to ensure efficient power delivery
◦ Use CAT 6a or higher for distances over 50 meters
 PoE Standards
PoE 15.4 watts (802.3af) PoE+ 30 watts 802.3at PoE++ 90 watts (802.3bt)
Uses 2 pairs to carry power Uses 2 pairs to carry power Aka 4PPoE - uses all 4 pairs
Cisco Universal Power over Ethernet
(UPOE) enhances PoE+ at 60 watts Digital Signage
VoIP
Pan/Tilt/Zoom Cameras
Advanced
Wi-Fi
Video IP
Video IP Phones Phones

Networked
Industrial
Alarm Systems Control Systems
 PoE Standards
PoE 15.4 watts (802.3af) PoE+ 30 watts 802.3at PoE++ 90 watts (802.3bt)
Uses 2 pairs to carry power Uses 2 pairs to carry power Aka 4PPoE - uses all 4 pairs
Cisco Universal Power over Ethernet
(UPOE) enhances PoE+ at 60 watts Digital Signage
VoIP
Pan/Tilt/Zoom Cameras
Advanced
Wi-Fi
Video IP
Video IP Phones Phones

Networked
Industrial
Alarm Systems Control Systems
 PoE Standards
PoE 15.4 watts (802.3af) PoE+ 30 watts 802.3at PoE++ 90 watts (802.3bt)
Uses 2 pairs to carry power Uses 2 pairs to carry power Aka 4PPoE - uses all 4 pairs
Cisco Universal Power over Ethernet
(UPOE) enhances PoE+ at 60 watts Digital Signage
VoIP
Pan/Tilt/Zoom Cameras
Advanced
Wi-Fi
Video IP
Video IP Phones Phones

Networked
Industrial
Alarm Systems Control Systems
PoE Considerations
Be mindful of the switch’s overall power budget
◦ You do not want to overload the switch past its capability
◦ That would cause some ports to not provide power, or require you to prioritize certain ports.

Remember that only twisted pair cable carries PoE

◦ Use CAT 6a or higher for distances over 50 meters
◦ For supplying PTZ cameras or high-powered wireless access points, boost the cable at the 50 meter
mark using an Ethernet with PoE repeater
◦ Don’t be surprised at 25% power loss by the time PoE reaches the end device
PoE Considerations (cont’d)
The PoE port must be directly connected to the PoE device
◦ Do not insert another switch or hub between the PoE switchport and its end device
◦ Regular non-PoE switches and hubs cannot “relay” or “pass through” PoE power

Most PoE switches can autosense if the end device requires PoE
◦ Will automatically turn the power on or off

You can buy a PoE extender to boost both Ethernet signal and PoE power
◦ Place between the PoE switchport and the end device

If your switch does not support PoE, then use a power injector
◦ Place the injector as close as possible to the end device

PoE extender
Monitoring PoE
Enable SNMP to track PoE statistics
Issue switch commands to obtain PoE status

show power inline (Cisco) show poe controller (Juniper)

Fiber Optic Cable
and Transceiver
Issues
Common Fiber Optic Cable Issues
Mixed single mode and multimode fiber optic cables and transceivers
◦ You have a mix of single and multimode fiber optic cable and transceivers
◦ Ensure that, from end to end of a connection, the fiber optic transceivers and all cables are matched in
terms of mode, speed and distance

Your fiber optic cable ends are plugged into the wrong ports
◦ Transmit (you will see a light) should be plugged into receive (no light)
◦ Won’t happen with dual (ganged) plugs that have the transmit and receive properly keyed
◦ Unless you mis-wired the pigtail at the fiber optic patch panel

Fiber optic cable light leakage

◦ Cable has a bend that exceeds its specified bend radius
Use Your Phone Camera to “See” the Light
Fiber Optic Leakage Example
Visual fault locator shows where
leakage occurs in cable
About Transceiver Issues
Most transceiver issues relate to fiber optic transmission media
◦ It’s easy to mix them up
◦ Ensure that, from end to end of a connection, the fiber optic transceivers and all cables are matched in
terms of mode (SMF, MMF), wavelength, speed and distance

DAC Twinax and twisted pair RJ-45 transceivers do not

have the same types of mismatch problems that fiber
optic transceivers have
◦ DAC cables have transceivers built into their cables
◦ DAC transceivers do not negotiate speed with the switchport
◦ If the switchport is multi-speed and can go faster, you may have to RJ-45
manually set the switchport speed down to match the DAC speed Transceiver
◦ RJ-45 transceivers can typically negotiate speed with the
switchport
DAC Transceiver
Fiber Optic Transceiver-Cable Issues
It’s easy to inadvertently mix fiber optic transceiver and cable types
◦ Most switchports are fiber mode agnostic – it doesn’t matter if it’s single or multimode
◦ SMF and MMF often use the same connector types (e.g., LC, SC, MPO)
◦ It's physically possible to plug an MMF cable into an SMF transceiver or vice versa
◦ The physical connection appears correct, but components are electrically mismatched

Incorrect cable-transceiver pairing can lead to significant issues including:

◦ Signal Loss/Attenuation
◦ Poor coupling of light due to different core sizes
◦ Overpowered Receiver
◦ Single-mode transceivers may emit higher power, potentially damaging MMF equipment
◦ Limited Connectivity
◦ Suboptimal performance or no connectivity at all

Test/diagnose using:
◦ Visual fault locators (VFLs), OTDRs or power meters
◦ Visual inspection to detect mismatched component types
◦ Performance monitoring for poor signal strength / dropped connections
Preventing Transceiver/Cable Mismatches
Inspect Labels and Color Codes:
◦ SMF: Yellow (common jacket color)
◦ MMF: Orange (OM1 or 2), Aqua (OM3, OM4), Heather Violet (OM4) or Lime Green (OM5)

Verify Transceiver Specifications:

◦ Match transceiver type (e.g., LR for SMF, SR for MMF)

If necessary, manually set the switchport speed to match the fiber optic transceiver speed
Use Proper Documentation: Label cables, ports, and transceivers for clarity
Educate team members on identifying and matching fiber types
Multimode Fiber Reference
Ethernet Speed Max Distance Wavelength Cable Type Form Factor
Standard
1000BASE-SX 1 Gbps OM1: 275 m, OM2: 550m, 850 nm OM1, OM2, SFP
OM3: 1 km OM3, OM4 Same
physical
10GBASE-SR 10 Gbps OM1: 33 m, OM2: 82 m, 850 nm OM1, OM2, SFP+ form
OM3: 300 m, OM4: 400 m OM3, OM4 factor
25GBASE-SR 25 Gbps OM3: 70 m, OM4: 100 m 850 nm OM3, OM4 SFP28
40GBASE-SR4 40 Gbps OM3: 100 m, OM4: 150 m 850 nm OM3, OM4 QSFP+ Same
physical
100GBASE-SR4 100 Gbps OM3: 70 m, OM4: 100 m 850 nm OM3, OM4 QSFP28
form
100GBASE-SR10 100 Gbps OM3: 100 m, OM4: 150 m 850 nm OM3, OM4 CFP factor
400GBASE-SR8 400 Gbps OM3: 70 m, OM4: 100 m 850 nm OM3, OM4 QSFP-DD or OSFP Distinct
400GBASE-SR4.2 400 Gbps OM4: 150 m, OM5: 150 m 850 nm + 910 nm OM4, OM5 QSFP-DD or OSFP form
factors
Single Mode Fiber Reference
Ethernet Speed Max Distance Wavelength Cable Type Form Factor
Standard
10GBASE-LR 10 Gbps Up to 10 km 1310 nm OS1, OS2 SFP+
10GBASE-ER 10 Gbps Up to 40 km 1550 nm OS1, OS2 SFP+
10GBASE-ZR 10 Gbps Up to 80 km 1550 nm OS2 (recommended) SFP+
25GBASE-LR 25 Gbps Up to 10 km 1310 nm OS1, OS2 SFP28
40GBASE-LR4 40 Gbps Up to 10 km 4 x 1310 nm OS1, OS2 QSFP+
100GBASE-LR4 100 Gbps Up to 10 km 4 x 1310 nm OS1, OS2 QSFP28
100GBASE-ER4 100 Gbps Up to 40 km 4 x 1550 nm OS2 (recommended) QSFP28
400GBASE-LR8 400 Gbps Up to 10 km 8 x 1310 nm OS1, OS2 QSFP-DD or OSFP
Transceiver Signal Strength Issues
Signal strength issues in transceivers can significantly affect the performance of a network link
◦ These issues arise from factors related to the transmitter, receiver, and the physical medium

Insufficient Transmitter Power

◦ The transmitter does not emit enough optical or electrical power to reach the receiver at the other end of the link:
◦ A low-power transceiver (e.g., short-range transceiver used for long distances)
◦ Aging or degraded laser diodes in optical transceivers
◦ Impact: Data loss, high packet error rates, or inability to establish a link

Excessive Receiver Power (Overloading)

◦ The receiver gets more power than it can handle, often referred to as receiver saturation:
◦ Using a high-power transceiver (e.g., long-range transceiver) on a short-distance link without attenuation
◦ No optical attenuator in place for short links
◦ Impact: Signal distortion, data corruption, or dropped connections
Transceiver Signal Strength Issues (cont’d)
Attenuation (Loss of Signal Strength)
◦ Signal power decreases as it travels over the medium due to absorption, scattering, dispersion or physical defects:
◦ Fiber splicing losses, dirty connectors, or faulty cabling
◦ Long cable runs exceeding the transceiver’s maximum distance

Connector and Cable Issues

◦ Problems with connectors or cables can disrupt the signal, causing increased attenuation, reflection, or signal loss:
◦ Dirty or damaged fiber optic connectors
◦ Incorrect or poorly installed connectors
◦ Bent or kinked cables (fiber or copper)

External factors that influence signal strength:

◦ Temperature extremes causing intermittent transceiver connection issues or permanent degradation
◦ Physical stress on cables due to improper installation, movement, or animals chewing cables
Fiber Optic Signal Attenuation Example
Troubleshooting Signal Strength Issues
Check Signal Levels:
◦ Use monitoring tools or commands (e.g., show interfaces transceiver detail on Cisco switches) to view Tx
power, Rx power, and thresholds
◦ Example thresholds for a typical optical transceiver:
◦ Tx Power: -5 dBm to 0 dBm
◦ Rx Power: -12 dBm to -3 dBm

Inspect Connectors and Cables:

◦ Clean fiber optic connectors using appropriate tools
◦ Inspect for bends, kinks, or physical damage in cables
◦ Use a Visual Fault Locator (VFL) to look for light leakage due to cable damage

https://www.chemtronics.com/how-to-clean-and-how-not-to-clean-fiber-optic-connectors
Troubleshooting Signal Strength Issues (cont’d)
Verify Transceiver and Cable Match:
◦ Ensure transceivers and cables are compatible in terms of wavelength, type (single-mode vs. multi-mode), and range

Measure Distance:
◦ Confirm the cable run is within the transceiver’s specified range
◦ Use optical attenuators for short distances with long-range transceivers

Test Components:
◦ Replace transceivers, cables, or connectors with known good components to isolate the issue

Check Dispersion and Loss:

◦ Use an optical time-domain reflectometer (OTDR) to measure fiber loss and pinpoint issues like splicing
problems
Common Cabling
and Interface Issues
Review
Review
Common cabling issues include:
◦ Cable too long – exceeds the recommended length for speed or use case
◦ Incorrect cable type – cable has the wrong specification (length, shielding, noise rejection) for the use
case
◦ Damaged UTP/STP cable
◦ Incorrect pinout / incorrect choice of straight-through, crossover, or rollover cable
◦ Bad plug/port
◦ EMI / RFI interference
Verify that the cabling used adheres to IEEE recommendations and EIA/TIA 568A or B pinouts
When terminating cable, either by crimping a head (plug) on it, punching it down or wiring a
keystone jack, remember that no more than 1/2" of the Ethernet cable should be untwisted
otherwise it will be susceptible to crosstalk
Review (cont’d)
A speed mismatch between switchport and device usually results in no connection at all
A duplex mismatch usually results in collisions / late collisions interface errors
Runts are caused by duplex mismatches and collisions due to network congestion
Giants are caused by MTU mismatches
CRC (Cyclical Redundancy Check) errors indicate data corruption during transmission
CRC errors are typically the result of bad cables, interference, or faulty hardware
Unknown protocol drops (Drops) are incoming packets that are discarded due to unsupported
protocols
Review (cont’d)
Port status of “down” could be the result of administrative action, line protocol errors, the port
being suspended due to link aggregation issues or policy violations, or err-disabled due to port
security violations, loop detection, misconfiguration and PoE errors
A switch’s PoE budget is the total amount of electrical power in watts that the switch can supply
to connected devices
The PoE budget is shared across all PoE-enabled ports on the switch
Most switches implement power allocation strategies, prioritizing certain ports or devices based
on administrative settings
If the total power demand exceeds the budget, lower-priority devices may lose power
For high-demand environments, consider switches with higher budgets, modular power
supplies, or external PoE injectors for specific devices
Review (cont’d)
It’s easy to inadvertently mix incorrect fiber optic transceivers and cables along a single run
Ensure that, from end to end of a connection, the fiber optic transceivers and all cables are matched
in terms of mode (SMF, MMF), wavelength, speed and distance
Signal strength issues in transceivers can include insufficient transmit power, excessive power
overloading the receiver, attenuation over distance or from bad splicing and damaged cable,
damaged connectors and external factors such as mechanical stress
Use a Visual Fault Locator (VFL) to look for light leakage on fiber optic cable
Use an Optical Time Delay Reflectometer (OTDR) to confirm the cable run is within the transceiver’s
specified range, measure fiber loss and pinpoint issues like splicing problems
 Switching Issues
Access Control Lists (ACLs)
Route Selection
5.3 Network Address Pool Exhaustion
Service Issues Incorrect IP Settings
Network + N10-009 Module 5
Network Service Issues Review
Switching Issues
Uplink / Trunk Link Cabling
Legacy switches or hubs might not be able autodetect and change Tx – Rx pairs
◦ You connect them using a straight-through cable, but they do not autoswap Tx - Rx
◦ There will be no link light on either side
◦ You might have to use an actual crossover cable to connect older switches and hubs together

Modern switches and hubs do not have this problem

Green VLAN Green VLAN

Orange VLAN Orange VLAN

Blue VLAN Blue VLAN

Incorrect VLAN Assignment
An access layer switchport might be assigned to the wrong VLAN
Since a VLAN is also a subnet, a device in the wrong VLAN may also have the wrong IP settings
◦ Devices have no concept of the VLAN they are in
◦ They only know the subnet they are in

Ensure that: VLAN 1 VLAN 2

• The switchport that the device is on is in the correct VLAN
• The device has the correct IP address, subnet mask, and
default gateway for the VLAN
• A VLAN interface has been set up on the distribution layer
switch to act as default gateway for the VLAN
• All devices in the VLAN can ping their default gateway
VLAN 3 VLAN 4
VLAN Mismatch
Native VLAN mismatch on trunk links
◦ Ensure that Native VLAN matches on all trunk links
◦ Better yet, set the Native VLAN to be the same on all switchports on all switches

VLAN membership mismatch on any port using an uplink

◦ Ensure that the assigned VLAN membership is the same for ANY port that will use an uplink
◦ Typically means all ports in the downstream switch, as well as the uplink port on the upstream switch
◦ Consider removing VLAN assignment to all ports involved in an uplink (just use the default VLAN
◦ Make sure default is the same on both switches!

VLAN 1 VLAN 2
Switching Loop Recap
Switching loops are caused by redundant links
Can be trunk links or uplinks
Very likely to result in:
◦ Frames travelling continuously through the loop
◦ Broadcast storm (broadcast frames enter the loop and
are amplified by continuous replication)
◦ Very high switch CPU utilization
◦ MAC table instability
Spanning-Tree Protocol (STP) Recap
STP prevents switching loops by:
◦ Temporarily disabling redundant links to a central reference (root bridge)

Root bridge selection

◦ Switches compare priorities, and then MAC addresses, to elect a root bridge (lowest is best)
◦ Redundant links back to the root bridge are put into a blocking state until needed
◦ You can influence the root bridge election
◦ Configure your preferred switch (usually core switch) to have the best (lowest) priority
STP Port States
STP transitions a port through several states prior to forwarding data
Non-designated ports remain in a blocking state until needed
◦ Port is not disabled, but is not passing user traffic either
◦ Light remains amber

Rapid PVST+ port states are:

• Discarding Link light
• Learning
• Forwarding is amber

Light turns green

STP Port Roles
Root port – connects to the root bridge
◦ One per non-root bridge

Designated – on and forwarding

◦ All ports on root bridge are designated
◦ On non-root bridges, one per segment

Nondesignated – redundant and left in a blocking state

◦ On standby to take over for failed designated port
◦ Will go through STP states before forwarding
In the Rapid PVST+ (update to STP) port roles are:
• Root port
• Alternate port (backup to Root port)
• Designated port
• Backup port (alternate to Designated port)
• Disabled port (administratively shut)
STP Issues
Switching loops caused by:
◦ STP disabled on switches with redundant links
 Enable STP, or preferably the newer version Rapid PVST+ (backward compatible with STP)
◦ Redundant links added to ports configured for PortFast
◦ Port comes on immediately, does not go through STP states, does not protect against loops
 Disable PortFast or remove the offending link
◦ PortFast port configured with BPDU Guard detects a loop and put self in err-disabled state
 Remove the offending redundant link, wherever it is

Non-optimal switch elected as root

 Lower the bridge priority on the desired switch (lower is better)
◦ The switches will elect the new root bridge and update the STP topology accordingly
Access Control Lists
(ACLs)
ACL Issues
You might have good Layer 3 connectivity, but a firewall or ACL is preventing certain types of
traffic
◦ Firewalls can be placed:
◦ On the network edge, as an appliance
◦ Back-to-back, forming a DMZ
◦ On a host, as software
◦ Router ACLs can be placed:
◦ On a hardware-based router
◦ On a multilayer switch SVI (VLAN interface)

Firewalls often block ICMP (ping and traceroute)

◦ Ping might not work past your default gateway
Troubleshooting ACLs
Try connecting to a different site, or with a different protocol:
◦ Outbound HTTP / HTTPS is usually allowed on most firewalls

Temporarily disable the firewall rule to see if connectivity is restored

◦ Then examine the firewall rule for misconfiguration

Most ACLs follow a syntax similar to this:

<ACL #> {permit|deny} <protocol> <source> <port> <destination> <port>
Troubleshooting ACL Rule Order
View the access list to examine its rules order
◦ Keep in mind that ACLs compare incoming packets to each rule in the list, starting from the top
◦ Once the packet matches a rule, the action is applied and the packet is not checked against any other
rule
◦ Make sure that the rule order in an ACL does not inadvertently conflict with another rule
◦ If there are two conflicting rules, put the more specific (targeted) rule first, followed by the more
general rule
◦ Most ACLs have an implicit “deny all” at the end
◦ If your ACL only has deny statements, be sure to add an explicit “permit any” rule at the end to allow all
other traffic
Keep in mind that inbound rules are separate from outbound rules
◦ On a firewall, they will be listed as “in” or “out”
◦ On a router, there will be two ACLs, one for inbound traffic and one for outbound traffic
Misconfigured ACL Examples

The entire subnet is allowed

access-list 100 permit ip 192.168.1.0/24 any before this one host can be denied
access-list 100 deny ip host 192.168.1.100 any

access-list 101 permit icmp any any

Which one do you want?
access-list 101 deny icmp any any

access-list 101 deny udp host 192.168.3.5 any All traffic is denied
access-list 101 deny icmp any any What can they do?
access-list 101 deny tcp any host 10.10.10.10 eq telnet
What’s Strange Here?
access-list 101 permit tcp host 10.0.0.20 host 10.0.1.20 eq 3389
access-list 101 deny tcp any host 10.0.1.20 eq 3389
access-list 101 deny tcp any any eq 23
access-list 101 deny tcp any host 200.200.200.200 eq 23

• The end result of this ACL is that only one host can RDP
• With the implicit deny all at the end, no other traffic of any type is allowed
• If you want to allow traffic that is not specifically listed, add an explicit permit ip any any at the bottom
Do You See It?
access-list 110 permit tcp any any eq 443
access-list 110 permit udp any any eq 53
• Rules are applied top to bottom
access-list 110 permit ip any any
• Look for any conflicts
access-list 110 deny udp host 192.168.1.150 any eq 53
• Pay attention to the scope of the
access-list 110 deny icmp 10.0.0.0/24 any echo
IP – a single host, an entire
access-list 110 deny ip any 192.168.2.0/24
subnet, or everyone?
access-list 110 permit tcp 192.168.2.0/24 any eq 80
access-list 110 permit icmp 10.0.0.0/24 any echo
access-list 110 deny ip any any
Do You See It?
access-list 110 permit tcp any any eq 443
access-list 110 permit udp any any eq 53
access-list 110 permit ip any any
access-list 110 deny udp host 192.168.1.150 any eq 53
access-list 110 deny icmp 10.0.0.0/24 any echo
access-list 110 deny ip any 192.168.2.0/24
access-list 110 permit tcp 192.168.2.0/24 any eq 80
access-list 110 permit icmp 10.0.0.0/24 any echo
access-list 110 deny ip any any

• Two conflicting DNS statements

• Put the specific one before the general one
Do You See It?
access-list 110 permit tcp any any eq 443
access-list 110 permit udp any any eq 53
access-list 110 permit ip any any
access-list 110 deny udp host 192.168.1.150 any eq 53
access-list 110 deny icmp 10.0.0.0/24 any echo
access-list 110 deny ip any 192.168.2.0/24
access-list 110 permit tcp 192.168.2.0/24 any eq 80
access-list 110 permit icmp 10.0.0.0/24 any echo
access-list 110 deny ip any any
• One of these should be the catch-all at the bottom
• Permit ip any any covers everything, invalidating any deny statements after it
• If you want to permit all other IP, move permit ip any any to the bottom
• Deny ip any any is redundant, as there is an implicit deny all at the bottom of any ACL
• You can remove the deny ip any any statement
Do You See It?
access-list 110 permit tcp any any eq 443
access-list 110 permit udp any any eq 53
access-list 110 permit ip any any
access-list 110 deny udp host 192.168.1.150 any eq 53
access-list 110 deny icmp 10.0.0.0/24 any echo
access-list 110 deny ip any 192.168.2.0/24
access-list 110 permit tcp 192.168.2.0/24 any eq 80
access-list 110 permit icmp 10.0.0.0/24 any echo
access-list 110 deny ip any any

• Do you want to let them ping, or not?

• If allow, replace the deny statement with the permit statement
• If not allow, simply remove the permit statement
• Of course, neither statement stops or allows any other ICMP messages ;-)
Do You See It?
access-list 110 permit tcp any any eq 443
access-list 110 permit udp any any eq 53
access-list 110 permit ip any any
access-list 110 deny udp host 192.168.1.150 any eq 53
access-list 110 deny icmp 10.0.0.0/24 any echo
access-list 110 deny ip any 192.168.2.0/24
access-list 110 permit tcp 192.168.2.0/24 any eq 80
access-list 110 permit icmp 10.0.0.0/24 any echo
access-list 110 deny ip any any

• Don’t be thrown off by seeing the same the subnet ID:

• it is the destination in the first statement
• and the source in the next statement
• Deny ip any overrides permit for a specific subnet
• Put the broader deny statement below the narrower permit statement
Corrected ACL
access-list 110 permit tcp any any eq 443 access-list 110 permit tcp any any eq 443
access-list 110 permit udp any any eq 53 access-list 110 deny udp host 192.168.1.50 any eq 53
access-list 110 permit ip any any access-list 110 permit udp any any eq 53
access-list 110 deny udp host 192.168.1.150 any eq 53 access-list 110 deny icmp 10.0.0.0/24 any echo
access-list 110 deny icmp 10.0.0.0/24 any echo access-list 110 permit tcp 192.168.2.0/24 any eq 80
access-list 110 deny ip any 192.168.2.0/24 access-list 110 deny ip any 192.168.2.0/24
access-list 110 permit tcp 192.168.2.0/24 any eq 80 access-list 110 permit ip any any
access-list 110 permit icmp 10.0.0.0/24 any echo
access-list 110 deny ip any any

• Related statements have been grouped together to create an easier visual

• Narrower deny statements are put before broader permits statements
• 10.0.0.0/24 is disallowed from pinging
• There is no confusion over 192.168.2.0/24 as a source, then destination
• There is no conflict anywhere
• All other traffic, not explicitly denied, is permitted at the end
Route Selection
Routing Issues
If a router does not know what to do with a packet, it will discard it
A router must either have a route for every network, or a default route (gateway of last resort – 0.0.0.0/0)
Slow / no convergence between routers causes routing black holes
◦ Network topology changes are not replicated/not replicated quickly enough to all routers, causing some routers to send
packets along dead paths
Mismatched routing protocols between routers
◦ Routers speaking different languages fail to share routes
Remember that routers select routes
Misconfigured routing protocol within a router from their routing table in this order:
◦ Routers not forming neighbor relationships 1. Longest prefix match (most specific
◦ Wrong metric applied destination is chosen first)
◦ Wrong area or autonomous system applied
2. Administrative distance
Redundant static routes cause a routing loop 3. Routing protocol metric
Overlapping IP addresses on either side of a link or VPN
causes the router to not forward traffic to the remote location
Troubleshooting Route Selection
Keep in mind the route select order of precedence
1. Longest prefix match
2. Administrative Distance
3. Routing protocol metric

Use tracert/traceroute to find where the path fails

◦ Keep in mind that a firewall or ACL blocking ICMP might yield an unexpected result

View the router’s route table to ensure that all destination networks have either:
◦ An explicit route (learned by routing protocol or statically entered)
◦ Default route
◦ All routers must know how to get to every destination
◦ They must either have an actual route to the destination or a default route
Troubleshooting Route Selection (cont’d)
Ensure that no networks have overlapping IP addresses, especially across a site-to-site VPN
View the router’s routing protocol configuration to ensure that all routers have complementary
configurations and are able to establish neighbor relations with other routers
If you have static routes, see if a link has failed or the topology has changed
◦ If so, update the static routes

Commands:
◦ Cisco: show ip route, show ip protocols
◦ Juniper: show route, show configuration protocols
Address Pool
Exhaustion
DHCP Address Pool Exhaustion
Occurs when a DHCP server's available pool of IP addresses is depleted
◦ Leaves it unable to assign IP addresses to new devices requesting them

Causes:
◦ Insufficient pool size / bad design
◦ Rogue devices or malicious activity consuming leases Note: if clients are not
◦ Network growth (such as adding mobile devices to the LAN) receiving DHCP leases,
◦ Leases not expiring due to misconfiguration it might also be that
the DHCP service has
Symptoms: stopped or the server
◦ Devices unable to obtain an IP address is unreachable
◦ Windows and macOS devices displaying APIPA (169.254.x.y) addresses
◦ Linux devices displaying 0.0.0.0 addresses
DHCP Address Pool Tests
Ensure that the DHCP server is reachable and its service is running
◦ Ping the server by IP address to ensure it is online
◦ Check to make sure the DHCP service is started – if necessary, restart the service
Attempt to obtain a lease or offer:
◦ On a device that does not have an IP address, reboot and see if you get a DHCP lease
◦ Ensure that the device TCP/IP settings are set to “DHCP” or “Auto”, and not static or manual
◦ Alternative to rebooting, “bounce” the NIC by disabling and re-enabling it
◦ Or set the NIC to some static IP address then set it back to DHCP
◦ Run the nmap script broadcast-dhcp-discover to see if the DHCP server offers an IP address
◦ C:\Program Files (x86)\Nmap>nmap --script broadcast-dhcp-discover
◦ If desired, run Wireshark on the testing machine to see what DHCP messages you get
◦ A DHCP NACK (negative acknowledgement) or no response at all (less common) from a server likely indicates an exhausted scope

Check the DHCP server’s logs:

◦ Check the DHCP server’s leased addresses list to see if the scope is depleted
◦ Check the DHCP server log for messages like "No available IP addresses in scope.“ or "Scope exhausted.“
Nmap Script Example
C:\Program Files (x86)\Nmap>nmap --script broadcast-dhcp-discover
Starting Nmap 7.95 ( https://nmap.org ) at 2024-12-05 22:07 Eastern Standard Time
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| Interface: eth3
| IP Offered: 10.0.0.175
| DHCP Message Type: DHCPOFFER
| Server Identifier: 10.0.0.1
| IP Address Lease Time: 2d00h00m00s
| Renewal Time Value: 1d00h00m00s
| Rebinding Time Value: 1d18h00m00s
| Subnet Mask: 255.255.255.0
| Broadcast Address: 10.0.0.255
| Router: 10.0.0.1
| Domain Name: hsd1.va.comcast.net
|_ Domain Name Server: 75.75.75.75, 75.75.76.76
Nmap Script Wireshark Capture Example
DHCP Address Pool Resolution Options
1. Attempt to scavenge stale DHCP records on the server
◦ Stale records typically occur when devices no longer need their assigned IP addresses but fail to
release them properly, leaving the DHCP server unaware that these addresses can be reassigned
◦ See if scavenging frees up enough unused addresses for your current needs
◦ Note: The procedure varies by vendor. For Microsoft, in the DHCP server scope, identify address leases with a status of
“inactive” and then delete them

2. If applicable, expand the existing address pool by reclaiming excluded or reserved addresses
3. Consider implementing IP Address Management (IPAM) for better tracking and allocation
4. Create a DHCP superscope (group two scopes together)
◦ Add a second IP address to the default gateway
◦ Create another scope with the second default gateway address as Scope Option 003
◦ Group the two scopes together
◦ Note: any communications between the member scopes will be routed through the router
 DHCP Address Pool Resolution Options
5. IF feasible, shorten the subnet mask for the subnet
◦ Be careful not to overlap some other subnet ID
◦ Example: Change from /24 (254 hosts) to /23 (510 hosts)
◦ Will require an entire new scope on the DHCP server with the new subnet mask – delete the old scope
◦ Will also require the router to change its subnet mask
◦ Might also require route updates within your network
◦ On every client, release and renew the DHCP lease:
◦ Windows: ipconfig /release, ipconfig /renew
◦ Linux: sudo dhclient –r, sudo dhclient
◦ macOS: sudo ifconfig <interface> down, sudo ifconfig <interface> up
6. Consider moving some devices to a different VLAN with its own subnet ID and DHCP scope
◦ Will require setting up a VLAN interface to route that VLAN
◦ May also require adding/modifying firewall rules and NAT rules to allow that new subnet to go to the
Internet
Incorrect IP Settings
Required IP Settings
Most end devices require four IP settings to communicate on a network:
IP address
◦ Must be unique on the network and appropriate for the subnet
Subnet mask
◦ Must be the same for all devices (including the router) on the same subnet
◦ All devices on a subnet must use the same subnet mask to determine whether traffic should be sent to the default gateway
◦ Note: Other subnets can use different subnet masks, but their IP ranges must not overlap with any other subnet
Default gateway
◦ Should be the same for all devices on the same subnet (in rare cases you might split clients between two default gateways)
◦ If you are using a First Hop Redundancy Protocol (FHRP) the router’s virtual IP should be the default gateway address
◦ If you are using a Switch Virtual Interface (aka SVI, VLAN interfaces) all devices on that VLAN should use the SVI as gateway
◦ Ensure that all devices can reach the SVI across however many switches and trunk links that exist

DNS server(s)
◦ If client devices are joined to an Active Directory domain, use the domain’s DNS server(s)
◦ If client devices are in a workgroup, DNS can be set to ISP, or public DNS such as Google 8.8.8.8 or Verizon 4.2.2.2
Incorrect Default Gateway
Occurs when a device’s IP settings have the wrong IP address for the default gateway
Devices can communicate on the same subnet, but not with any outside network
If only one or a few devices have the problem, check to see if it was a manual misconfiguration
If all or most devices on the subnet have the problem:
◦ Verify that the router itself is properly configured, on the same VLAN, and is reachable
◦ Ensure that DHCP clients are getting the correct default gateway address (scope option 003) from the DHCP
server
Incorrect Default Gateway Tests
Verify that both the router and client are on the correct VLAN
Verify that the router has the correct IP address and subnet mask
Verify that the client has an appropriate IP address, correct subnet mask, and correct default gateway
Try pinging in this order:
1. Another host on your own subnet
2. Your own default gateway
3. Another IP address (interface) on the same router
4. Another host on a different subnet in the same private network
 What is Wrong Here?
Can Host A, B, C or D send traffic to Host E?
Why or why not?

Host A Host B Host C Host D Host E

IP - 192.168.1.103 IP - 192.168.1.103 IP - 192.168.1.102 IP - 192.168.1.101 IP - 192.168.2.200
SM - 255.255.255.0 SM - 255.255.255.0 SM - 255.255.0.0 SM - 255.255.255.0 SM - 255.255.255.0
DG - 192.168.1.1 DG - 192.168.1.1 DG - 192.168.1.1 DG - 192.168.2.1 DG - 192.168.2.1

1.1 2.1

192.168.1.0 192.168.2.0
 What is Wrong Here?
IP address conflict: one Wrong subnet mask –
probably can, but the host will think This host is configured
Wrong default gateway
other will not be able to destination is on the correctly
same network

Host A Host B Host C Host D Host E

IP - 192.168.1.103 IP - 192.168.1.103 IP - 192.168.1.102 IP - 192.168.1.101 IP - 192.168.2.200
SM - 255.255.255.0 SM - 255.255.255.0 SM - 255.255.0.0 SM - 255.255.255.0 Router is SM - 255.255.255.0
DG - 192.168.1.1 DG - 192.168.1.1 DG - 192.168.1.1 DG - 192.168.2.1 configured DG - 192.168.2.1
correctly

1.1 2.1

192.168.1.0 192.168.2.0
 Resolved! All Nodes are Configured Correctly
Changed the subnet
Changed Host A IP to a mask to /24, to conform Corrected the default This host is configured
unique address with the rest of the gateway address correctly
subnet

Host A Host B Host C Host D Host E

IP - 192.168.1.104 IP - 192.168.1.103 IP - 192.168.1.102 IP - 192.168.1.101 IP - 192.168.2.200
SM - 255.255.255.0 SM - 255.255.255.0 SM - 255.255.255.0 SM - 255.255.255.0 Router is SM - 255.255.255.0
DG - 192.168.1.1 DG - 192.168.1.1 DG - 192.168.1.1 DG - 192.168.1.1 configured DG - 192.168.2.1
correctly

1.1 2.1

192.168.1.0 192.168.2.0
Network Service
Issues Review
Review
Legacy switches or hubs might not be able autodetect and change Tx – Rx pairs
You might have to use an actual crossover cable to connect older switches and hubs together
When troubleshooting VLAN assignment, ensure that:
◦ The switchport that the device is on is in the correct VLAN
◦ The device has the correct IP address, subnet mask, and default gateway for the VLAN
◦ A VLAN interface has been set up on the distribution layer switch to act as default gateway for the VLAN
◦ All devices in the VLAN can ping their default gateway
When troubleshooting VLAN mismatches, ensure that the Native VLAN is the same on both
sides of a trunk link
If you connect two switches using a simple uplink, ensure that the assigned VLAN membership is
the same for ANY port (upstream or downstream) that will use the uplink
Review (cont’d)
Spanning-Tree Protocol (STP) automatically blocks redundant links that can cause switching
loops
Switching loops often occur because STP was disabled or misconfigured
STP goes through a 50-second process to identify and disable loops
Rapid PVST+ is a new replacement for STP, and is also backward compatible with STP
If a non-optimal switch is elected as the root bridge, go to the preferred switch and lower its
bridge priority
The switches will elect the new root bridge and update the STP topology accordingly
Review (cont’d)
You might think that there is a connectivity problem when in actuality you have a firewall or ACL blocking certain
types of traffic
When troubleshooting ACLs, try connecting to a different site, or with a different protocol
Outbound HTTP / HTTPS is usually allowed on most firewalls
Temporarily disable the firewall rule to see if connectivity is restored
View the access list to examine its rules order
Keep in mind that ACLs compare incoming packets to each rule in the list, starting from the top
Once the packet matches a rule, the permit/deny action is applied and the packet is not checked against any other rule
Make sure that the rule order in an ACL does not inadvertently conflict with another rule
Most ACLs have an implicit “deny all” at the end
If your ACL only has deny statements, be sure to add an explicit “permit any” rule at the end to allow all other traffic
Review (cont’d)
When troubleshooting routing, use tracert/traceroute to find where the path fails
◦ Keep in mind that a firewall or ACL blocking ICMP might make the path seem to end before it actually does
If a router does not know what to do with a packet, it will discard it
A router must either have a route for every network, or a default route (gateway of last resort –
0.0.0.0/0)
Examine the router’s route table to ensure it has a route for every destination
Ensure that no networks have overlapping IP addresses, especially across a site-to-site VPN
View the router’s routing protocol configuration to ensure that all routers have complementary
configurations and are able to establish neighbor relations with other routers
Update static routes on all routers if a link has failed or the network topology has changed
Remember that routers select routes by:
◦ 1. Longest prefix match, 2. Administrative distance, 3. Routing protocol metric
Review (cont’d)
DHCP address pool exhaustion occurs when a DHCP server's available pool of IP addresses is
depleted, leaving it unable to assign IP addresses to new devices requesting them
Windows and macOS devices that cannot obtain a DHCP lease will display an APIPA (169.254.x.y)
address as their IP address
Linux devices that cannot obtain a DHCP lease will display 0.0.0.0 as their IP address
You can use ipconfig /release and ipconfig /renew to attempt to communicate with the DHCP
server
You can also view the DHCP server’s logs or use an nmap script to troubleshoot DHCP
Make sure that the DHCP service itself is running, and that the server is reachable across the
network
Review (cont’d)
Solutions for resolving DHCP scope exhaustion include:
Attempting to scavenge stale leases
Increasing the scope size by reclaiming excluded or reserved addresses
Implementing IPAM for better management and tracking
Creating a superscope of two scopes grouped together
Recreating the scope with a larger address pool (you will need to use a shorter subnet mask)
Moving some devices to another subnet / VLAN
Review (cont’d)
Most end devices require four IP settings to communicate on a network: IP address, subnet mask, default gateway, and
DNS server(s) IPs
The IP address must be unique on the network and appropriate for the subnet
The subnet mask must be the same for all devices (including the router) on the same subnet
The default gateway should be the same for all devices on the same subnet (in rare cases you might split clients between
two default gateways)
If you are using a First Hop Redundancy Protocol (FHRP) the router’s virtual IP should be the default gateway address
If you are using a Switch Virtual Interface (aka SVI, VLAN interface) all devices on that VLAN should use the SVI as
gateway
Ensure that all devices can reach the SVI across however many switches and trunk links that exist
If client devices are joined to an Active Directory domain, use the domain’s DNS server(s)
If client devices are in a workgroup, DNS can be set to the ISP DNS, or public DNS such as Google 8.8.8.8 or Verizon
4.2.2.2
 Device Uptime / Downtime
Network Conditions
Wireless Signal Issues
5.4 Performance Disassociation Issues
Issues Roaming Issues
Network + N10-009 Module 5
Addressing a Common Problem with Public Wi-Fi Hotspots
Performance Issues Review
Device Uptime / Downtime
The most basic metric you can track on a device, link or system
How long something has been down or up is a very common starting point for other
investigations
You can use outside systems to regularly ping a device or service and log any failures to respond
You can also check timestamps in a system log to see time gaps, as well as when a system or
service restarted
To view device uptime, use the following command:
◦ show version (Cisco)
◦ show system uptime (Juniper)
Network Conditions
Network Performance-Related Issues
Bandwidth
◦ Refers to the maximum data transfer rate of a network or internet connection, measured in bits per
second (e.g., Mbps, Gbps)
◦ Determines how much data can be transmitted simultaneously
◦ High bandwidth enables faster file transfers, higher-quality streaming, and better support for multiple users
◦ Affected by:
◦ Infrastructure limitations (e.g., cable type, router capacity)
◦ Network traffic and contention levels
◦ Protocol overhead reducing the effective bandwidth

Congestion
◦ Caused when excessive traffic overwhelms
the network's capacity
Network Performance-Related Issues (cont’d)
Contention
◦ Occurs when multiple devices compete for the same network resources, such as bandwidth or access to the
transmission medium
◦ In modern switched networks, contention is avoided through microsegmentation at the switchport level
◦ Contention is rare unless uplinks/trunk links to switches become saturated, or devices exist on shared segments (hubs)
◦ Contention in WLANs is inherent because multiple devices share the same radio spectrum
◦ Can be managed through:
◦ Using 5 GHz or 6 GHz bands
◦ Deploying multiple Access Points (APs)
◦ Spreading devices across channels
◦ Limiting the number of devices per AP, and implementing QoS

Bottlenecks
◦ Occurs when one part of the network has a lower capacity than the rest, limiting overall performance
◦ Caused by mismatched hardware capacities, outdated network devices or interfaces, and insufficient
bandwidth on critical links
Real-time Traffic Performance Metrics
Bandwidth
◦ Must be sufficient for the traffic load
Packet Loss:
◦ Packets that never arrive
◦ Causes interruptions in audio or video streams, leading to degraded call quality (e.g., missing words or video frames)
◦ Excessive packet loss can make real-time applications like VoIP or video conferencing unusable
Latency:
◦ Delay between transmission and reception
◦ High latency results in noticeable delays in communication
◦ Causes awkward pauses in Video or VoIP calls, or lag in online gaming
Steady stream of packets
◦ Impacts interactivity, making real-time collaboration frustrating
Jitter:
◦ Variable delay
◦ Inconsistent packet arrival times
◦ Creates distortion or "choppiness" in audio and video streams
◦ Worst impact is on audio
◦ Hardest to compensate for Same packet stream after congestion or improper queueing (causes jitter)
Impact of Network Conditions on Real-time Traffic

Factor Packet Loss Latency Jitter

Packet drops from buffer Queuing delays at Varies with traffic

Congestion
overflows overloaded devices volume
Varies with
Collisions/dropouts in Waiting for transmission
Contention device/channel
shared resources access
competition
Dropped packets at slow Processing/transmission Varies with bottleneck
Bottlenecks
links/devices delays intensity
Acceptable Loss/Latency/Jitter Thresholds
Managing Real-time Traffic Performance
Optimize the Network:
◦ Use QoS to prioritize real-time traffic and reduce latency and jitter

Configure Jitter Buffers:

◦ Ensure real-time applications have adequately sized jitter buffers

Monitor Performance:
◦ Regularly test and monitor network performance to stay within acceptable thresholds

Upgrade Infrastructure:
◦ Invest in high-quality hardware and faster network connections for critical applications
Wireless Signal
Issues
Wireless Signal Degradation and Loss
Channel overlap, channel crowding
EMI, RFI
Attenuation
◦ WAP is too far away
◦ Dead spots / insufficient coverage

Physical obstruction
◦ absorption, reflection

Multi-path interference
◦ Reflected signal amplifies itself or
cancels itself out (phase cancellation)
Common Wi-Fi Interference Sources
RFI/EMI
◦ Microwave ovens
◦ Motors, fans, lights, elevator shafts
◦ Manufacturing equipment/factory machines
◦ Hospital radiology equipment
Channel Crowding / Channel Overlap
◦ Too many devices on one channel
◦ Neighboring wireless networks that overlap part of yours
Frequency Crowding
◦ Other wireless sources such as:
◦ LTE, Bluetooth, unlicensed equipment such as smart home devices,
◦ radar/meteorological equipment, medical instruments, etc.

Obstructions that interfere with coverage by:

◦ Absorbing the signal so it loses all its energy at that point
◦ Reflecting the signal so it can’t pass through
◦ Refracting the signal so it changes its path away from the intended target
Common Physical Obstructions to Wireless
Cabinets or drawers
Mirrors, drinking glasses
Metal Objects
Metal shelves
Furnaces
Elevator shafts
Thick walls and ceilings
Heavy building materials
Aquariums
Wi-Fi Signal Obstruction by Materials Type
Material Effect on Wi-Fi Signal Impact
Metal (steel, aluminum) Reflects/blocks Severe signal loss or dead zones
Concrete/Brick Absorbs/blocks Significant signal loss; thick walls can block entirely
Wood Minor absorption Slight signal attenuation; fairly Wi-Fi friendly
Glass (plain) Minor refraction Minimal signal loss unless it’s thick
Glass (low-E, tinted) Reflects/blocks Can cause significant signal loss
Drywall Slight absorption Minimal signal loss; common in homes
Plastics/Acrylics Minor refraction Negligible signal loss
Water (liquid) Absorbs/reflects Strong absorption and signal weakening
Human bodies Absorbs Noticeable loss in crowded environments
Watch for Dead Spots Caused by Obstructions
Consider Signal Propagation and AP Placement

BAD Better
Consider Antenna Angle and Signal Coverage
Multi-story AP Coverage Example
Troubleshooting Wireless Signal Issues
Conduct a site survey / visual inspection
If possible, supplement your walkthrough with architectural/floor plans
Identify elevator shafts, stairwells, other possible obstructions and distances
Look For Anything That Might Obstruct Signal
Heavy equipment including furnaces, HVAC and water heating
Heavy furniture including steel racks/shelves/desks
Concrete or steel-reinforced walls, doors, ceilings and floors
Armored electrical cables, thinwall conduit, electrical breaker boxes
Fluorescent lighting reflectors
Thick glass and mirrors
Faraday cages (completely shielded enclosures)
◦ Government/military classified areas
◦ Radiation-shielded walls (hospitals)
Large bodies of water
Mounds of earth
Buildings and other structures
Use a Spectrum Analyzer
Use a spectrum analyzer to identify:
◦ Frequency crowding
◦ RFI/EMI
◦ Dead or weak zones

Prefer to use an analyzer that:

◦ Can generate heat maps
◦ Uses more precise signal strength reporting
than just showing “bars”
Consider WAP and Antenna Configuration
Verify that WAPs and antennas are installed/configured using best practices and manufacturer
recommendations
Consider whether or not changing the antenna type/location/orientation on an existing WAP
might solve some coverage issues
Disassociation Issues
Wi-Fi Client Disassociation Issues
Disassociation occurs when a connected device is unexpectedly disconnected from a Wi-Fi
network
Can lead to interruptions in connectivity and degraded user experience
Symptoms of Disassociation:
◦ Frequent disconnections or drops from the Wi-Fi network
◦ Reduced throughput or slower speeds when reconnecting
◦ Difficulty maintaining a stable connection
◦ Log entries on APs showing repeated disassociation events
Causes of Wi-Fi Client Disassociation
Poor or misconfigured roaming between APs in the same network
Overlapping channels or congested frequencies can cause instability
Dynamic AP load balancing - some APs may force disassociation to redistribute clients
Environmental changes - movement of objects or people can alter the RF environment
Client-side power saving modes, outdated or buggy drivers/firmware
Authentication key mismatch or session timeout
Interference and obstructions
Denial-of-Service (DoS) attacks
Network congestion
Weak signal
Client inactivity
Troubleshooting Wi-Fi Client Disassociation
Check AP Logs for disassociation or deauthentication messages and reasons provided
Conduct a site survey to assess signal strength, channel overlap, and interference
Test with multiple devices to determine if the issue is client-specific or affects all devices
Monitor the RF Environment to identify and mitigate sources of interference
Verify that client devices and APs are configured correctly with matching security settings
Verify that APs are configured to manage client load on each channel and band
Capture network traffic
◦ Filter output for Deauthentication / Disassociation frames to identify reasons for disassociation
Roaming Issues
Wi-Fi Client Roaming Misconfiguration
Roaming misconfiguration occurs when clients do not seamlessly transition between APs in a
wireless network, leading to issues such as:
◦ Latency spikes or packet loss during transitions
◦ Clients staying connected to a distant AP (sticky clients) instead of switching to a closer, stronger one
◦ Frequent disconnections when switching APs due to mismatched configurations

Roaming misconfiguration symptoms:

◦ Clients experience frequent disconnections or performance degradation when moving around.
◦ Devices "stick" to an AP with weak signal despite stronger alternatives being available
◦ Delays in transitioning from one AP to another, resulting in interrupted services (e.g., VoIP or video
streaming)
Wi-Fi Roaming Example
Troubleshooting Client Roaming Issues
Conduct a survey to identify areas with weak signals, AP overlaps, or excessive interference that
could contribute to roaming issues
Test / simulate roaming scenarios by walking with a device across the network and monitoring
signal handoff and connectivity
Use non-overlapping channels in the 2.4 GHz band (1, 6, 11)
For 5 GHz, avoid using adjacent channels within the same AP coverage area
If available, use Band Steering to encourage clients to use the 5 GHz band
Configure APs to load balance clients
Ensure that AP coverage areas only overlap by 15-25% for seamless handoffs without excessive
contention
Troubleshooting Client Roaming Issues (cont’d)
If available, tune the minimum Received Signal Strength Indicator (RSSI) threshold for each AP to
force clients to roam when their signal strength drops below -70dbm
Configure clients to prioritize performance over power saving
Keep client device firmware updated to ensure compatibility with newer roaming protocols
Enable Roaming Protocols on APs to assist clients:
◦ 802.11k (Neighbor Reports)
◦ Allows clients to receive a list of nearby APs to make better roaming decisions
◦ Ensure APs support and advertise 802.11k
◦ 802.11v (Network-Assisted Roaming)
◦ Provides clients with information about network conditions, such as AP loads and channel quality
◦ Helps clients decide when to roam
◦ 802.11r (Fast Transition or FT)
◦ Reduces the time required for reauthentication during roaming by pre-sharing credentials between APs
◦ Essential for latency-sensitive applications like VoIP
Addressing a
Common Problem
with Public Wi-Fi
Hotspots
Public Wi-Fi Login Issue
You connect to a public Wi-Fi but cannot reach the captive portal page because your browser
defaults to HTTPS
How Captive Portals Work:
◦ Public Wi-Fi networks (e.g., at hotels, airports or cafes) often use a captive portal to display a login
page, accept terms of service, or require payment before allowing full Internet access
◦ The portal works by intercepting the first web request and redirecting the user to a custom login page

HTTPS Causes a Redirection Problem:

◦ Modern web browsers prioritize HTTPS (encrypted connections) over HTTP (unencrypted)
◦ When you try to access an HTTPS site, the encryption prevents the captive portal from redirecting you
to the login page because the browser blocks the interception as a security risk

Solution: NeverSSL.com
Public Wi-Fi Login Issue - Solution
Open a connection to neverssl.com
Provides an HTTP-only website to trigger captive portal login pages on public Wi-Fi
Allows public Wi-Fi networks to intercept and redirect requests to their login portal
Ensures users can access Wi-Fi authentication pages when HTTPS websites are blocked from redirection
A simple workaround for modern encrypted web browsing that may hinder captive portal detection
How to Use Neverssl.com
1. Join a public Wi-Fi network, which typically requires authentication through a captive portal
2. Open any web browser on your device
3. Manually type http://neverssl.com into the browser's address bar
4. Since NeverSSL.com operates over unencrypted HTTP, the Wi-Fi network intercepts the
request
5. The network redirects you to its captive portal page for authentication
6. Follow the Wi-Fi provider's instructions (e.g., agree to terms, enter login credentials) to gain
full Internet access
7. Voila! You’re on!
Performance Issues
Review
Review
Device uptime / downtime is the most basic metric you can track on a device, link or system
You can use outside systems to regularly ping a device or service and log any failures to respond
You can also check timestamps in a system’s log to see time gaps, as well as when a system or
service restarted
Bandwidth refers to the maximum data transfer rate of a network or internet connection,
measured in bits per second (e.g., Mbps, Gbps)
Bandwidth is affected by:
◦ Infrastructure limitations (e.g., cable type, router capacity)
◦ Network traffic and contention levels
◦ Protocol overhead reducing the effective bandwidth
Congestion is caused when excessive traffic overwhelms the network's capacity
Review (cont’d)
Contention occurs when multiple devices compete for the same network resources, such as
bandwidth or access to the transmission medium
In modern switched networks, contention is avoided through microsegmentation at the
switchport level
Contention in WLANs is inherent because multiple devices share the same radio spectrum
WLAN contention is managed through using 5 GHz and 6 GHz bands, deploying more WAPs,
spreading devices among WAPs, limiting the number of devices per WAP, and implementing QoS
Bottlenecks occur when one part of the network has a lower capacity than the rest, limiting
overall performance
Bottlenecks are caused by mismatched hardware capacities, outdated network devices or
interfaces, and insufficient bandwidth on critical links
Review (cont’d)
Real-time traffic performance is measured using the following metrics:
◦ Bandwidth - Must be sufficient for the traffic load
◦ Packet Loss - Packets that never arrive
◦ Latency - Delay between transmission and reception
◦ Jitter - Variable delay

You can manage real-time traffic performance issues by:

◦ Using QoS to prioritize real-time traffic and reduce latency and jitter
◦ Ensuring that real-time applications have adequately sized jitter buffers
◦ Regularly testing and monitoring network performance to stay within acceptable thresholds
◦ Investing in high-quality hardware and faster network connections for critical applications
Review (cont’d)
Wireless signal degradation and loss is caused by:
◦ Channel overlap, channel crowding
◦ EMI, RFI
◦ Attenuation from insufficient coverage
◦ Physical obstruction
◦ Multi-path interference
Conduct a site survey / visual inspection to look for anything that might obstruct Wi-Fi signal
If possible, supplement your walkthrough with architectural/floor plans to help you identify obstructions in the
building construction
Use a spectrum analyzer to identify frequency crowding, channel overlap, RFI/EMI, and dead or weak coverage areas
Verify that WAPs and antennas are installed/configured using best practices and manufacturer recommendations
Consider whether or not changing the antenna type/location/orientation on an existing WAP might solve some
coverage issues
Review (cont’d)
Roaming misconfiguration occurs when clients do not seamlessly transition between APs in a wireless
network
Troubleshoot roaming issues by:
◦ Tuning the minimum Received Signal Strength Indicator (RSSI) threshold for each AP to force clients to roam
when their signal strength drops below -70dbm
◦ Configure clients to prioritize performance over power saving
◦ Keeping client device firmware updated to ensure compatibility with newer roaming protocols
◦ Enabling Roaming Protocols on APs such as 802.11k (Neighbor Reports), 802.11v (Network-Assisted Roaming),
and 802.11r (Fast Transition)
A common public Wi-Fi hotspot login problem is when the user connects to a hotspot but cannot
reach the captive portal page because their browser defaults to HTTPS and cannot be redirected to
the login registration page
If you encounter this issue, you can connect to neverssl.com to make an HTTP connection that will
trigger the hotspot to redirect you its login registration page
 Software Tools
5.5 Hardware Tools
Troubleshooting Basic Networking Device Commands
Tools and Troubleshooting Tools and Protocols Review
Protocols
Network + N10-009 Module 5
Software Tools
Protocol Analyzer
A hardware/software tool that captures and analyzes network traffic
Can identify:
◦ Protocols used on the network
◦ Percentage of protocol use
◦ Bandwidth utilization by protocol or host
◦ Unauthorized, unknown, or potentially malicious traffic (by protocol)
◦ Peak times of utilization
◦ Hosts with network interfaces in promiscuous mode
◦ Mostly used by sniffers

Examples include:
◦ SolarWinds Deep Packet Inspection and Analysis Tool
◦ NetFlow
◦ sFlow
Protocol Analyzer Example
Bandwidth Speed Tester
Software that allows you to check the bandwidth (speed) of an Internet
connection
Measures download and upload speed
Helps identify performance issues with your ISP
◦ Only measures speed to a particular site, not to all websites on the Internet
◦ Vendors offer this service as a part of their website
◦ Some software vendors also offer line quality checks
◦ Looking-glass sites run a software that allows viewing of routing data as well

Popular sites include:

◦ Speedtest.net, testmy.net, dslreports.com, speed.cloudflare.com
Command Line Commands
Command Description Examples
ping Send an ICMP echo to a remote host to prove ping 8.8.8.8
Layer 3 connectivity ping www.example.com
traceroute / tracert Discover the Layer 3 path to a remote host tracert www.example.com
Can use IP address or DNS FQDN as target traceroute 8.8.8.8
nslookup Manually query a DNS server (Windows) nslookup example.com
dig Manually query a DNS server (Linux) dig example.com
netstat Display listening ports and sockets netstat
netstat -na
netstat -nao
ip / ifconfig / ipconfig Display host IP settings ip addr (Linux)
ifconfig (Linux)
ipconfig (Windows)
arp Display host arp cache arp -a
Nmap
A powerful, open-source tool widely used for network discovery, security auditing, and
troubleshooting
◦ Sends specially crafted packets to target hosts and analyzes the responses
◦ Has a graphical user interface (GUI) named Zenmap that simplifies scanning and visualization
Key features:
◦ Host discovery
◦ Port scanning
◦ OS, service, and version detection
◦ Packet crafting / firewall and IDS testing
◦ Scriptable interactions
◦ Network topology mapping
◦ Stealth scanning
◦ IPv6 support
Common Nmap Command Examples
Test Command Example
Basic Host Discovery nmap -sn 192.168.1.0/24
Discover active hosts in the 192.168.1.0/24 subnet
Port Scanning – top 1000 ports nmap 192.168.1.0/24
Scan ports 80 and 443 on the target nmap -p 80,443 192.168.1.10
Scans all 65,535 ports on the target nmap -p- 192.168.1.10
Service and Version Detection nmap -sV 192.168.1.10
OS Detection nmap -O 192.168.1.10
Scripted Scans nmap --script vuln 192.168.1.10
Run vulnerability scan using NSE script
Aggressive Scanning nmap -A 192.168.1.10
OS & version detection, script scanning, and traceroute

For more information see https://nmap.org/

Cisco Discovery Protocol (CDP)
A Cisco proprietary protocol
◦ Also used by a few other switch, IP phone, and network management vendors
Used to discover information about directly connected devices
◦ Operates at Layer 2 (Data Link Layer) of the OSI model
◦ Enables topology discovery
◦ Verifies Layer 2 connectivity
◦ Provides: neighbor device identifiers, neighbor IP addresses, port identifiers, capabilities (e.g., router,
switch), and platform information
◦ Does not extend past the neighbor – you must connect to the neighbor to see ITS CDP neighbors
It is independent of any Layer 3 protocol
◦ You do not need an IP address to be configured for it travel across a link
◦ You DO need Layer 2 connectivity (e.g. Ethernet, PPP, HDLC, etc.) the link must be “up”
Link Layer Discovery Protocol (LLDP)
Vendor neutral alternative to CDP
Enables network topology mapping and device communication
Information includes chassis ID, port ID, system name, capabilities, and other generic data
Ideal for environments with network hardware from multiple vendors
Preferred in situations where adherence to open standards is required or where interoperability
is critical
Often used with Cisco IP phones for VLAN assignment and other configurations
CDP and LLDP Commands
Command Description
show cdp, show lldp Displays general statistics
show cdp interface Displays the status of CDP/LLDP on each device interface
show lldp interface
show cdp neighbors Provides a quick overview of connected devices, including their
Show lldp neighbors capabilities, platform, and the interfaces
show cdp neighbors detail Provides detailed information of connected devices including IP
show lldp neighbors detail address and software version
CDP Output Examples
Hardware Tools
Telephone Toner
Used to locate a cable
◦ On a patch panel / jack
◦ In a group of installed cables
Very useful when you don’t know which is the cable in question or where the cable leads to
◦ Use the toner to inject a warbling signal
◦ Use the wand to locate which cable/jack has the signal
◦ Be careful: crosstalk between cables can be misleading
◦ Check all surrounding cables – listen for the LOUDEST signal
◦ When using on a patch panel, touch the wand tip to the wires inside the port
Prefer to use this on non-live circuits
Also known as:
◦ Fox and hound
◦ Telephone tracer
◦ Cable tracer / tracker
◦ Toner
Cable Tester
Tests a cable for:
◦ Open/broken wires/connections
◦ Shorts
◦ Incorrect pin-out
Typically includes a main unit and a loopback adapter
High-end testers also:
◦ Report signal loss on cable and at connectors
◦ Identify where cable breaks are
◦ Certify cable runs

Note: Be sure to move the cable around while testing to check for loose/intermittent connections!
Light Meter / Fiber Optic Cable Tester
Certify and troubleshoot fiber-optic cable
Can measure loss/breakage by sending light through a
fiber optic cable
Network Tap
A Network Tap is specialized hardware that allows passive monitoring of traffic without
interrupting the flow, often used for security analysis and forensics
A physical tap is inserted between two devices (e.g., switch-to-switch or switch-to-router) to
capture traffic as it flows between them
These devices can be used to intercept traffic over both fiber optic and copper Ethernet links,
providing access to all packets traveling between network devices
Wi-Fi Analyzer
A Wi-Fi analyzer is similar to a network analyzer except it is used for wireless networks
Collects packets from the wireless networks and detects:
◦ Acceptable networks, hidden networks, interference by other networks, devices, and other machinery

Use for wireless surveys, wireless access point placement, and troubleshooting
Can be a standalone device or an app on a PC or phone
Phone App Wi-Fi Analyzer Example
Spectrum Analyzer
Measures the level of signal (including noise) across a range of frequencies
Used to find:
◦ Congested wireless channels and frequencies
◦ Interference levels at different frequencies

Usually requires:
◦ A specialized hardware receiver that can process ANY signal type, not just Wi-Fi
◦ Software that can interpret the reading

Some devices are self-contained

Some devices require a PC
Visual Fault Locator
A visible laser light source used to check continuity,
locate breaks, poor mechanical splices and damaged
connectors in fiber optic cabling
Inexpensive and easy to use
Requires that you can see the entire cable
Time Delay Reflectometer (TDR)
Finds faults along a cable
Good for long cables, or cables that you cannot fully see
Sends a signal through a cable to check continuity
◦ Signal bounces back at the break / end
◦ The reflected signal is analyzed
◦ Time it took
◦ Level of signal/light
◦ Very useful for finding:
◦ The break/open point in installed cable (you cannot see along its entire run)
◦ The amount of insertion loss at a splice, patch panel, or connection

Optical time domain reflectometer (OTDR) is used for fiber-optic cables

Time Delay Reflectometer Example
OTDR Test Example
Launch cable connects
to cable being tested

OTDR Trace
Typical Features of an OTDR Trace
Basic Networking
Device Commands
Network Device Commands
Command Description Comment
show mac-address-table Display a switch’s MAC table Cisco commands for older and
show mac address-table current switches
show route Display router’s route table Juniper
show ip route Cisco
show interface Display interface statistics Juniper, Cisco
show config Display device’s running or saved configuration Juniper, HP, Aruba
show running-config Cisco
show startup-config Cisco
show arp Display the ARP cache Universal
show ip arp
show vlan Display VLANs and their ports on the switch Universal
show power Display power information Cisco and some Juniper
show power inline Display PoE information
Troubleshooting
Tools and Protocols
Review
Review
A protocol analyzer is a hardware or software tool that captures and analyzes network traffic
You can use a protocol analyzer to:
◦ Measure bandwidth utilization by protocol or host
◦ Identify unauthorized, unknown, or potentially malicious traffic (by protocol)
◦ Identify peak times of utilization
◦ Detect sniffers on your network (hosts with network interfaces in promiscuous mode)

A bandwidth speed tester is software that allows you to check the bandwidth (speed) of an
Internet connection
The speed tester measures download and upload speed, helping you identify performance
issues with your ISP
Review (cont’d)
Command Description Examples
ping Send an ICMP echo to a remote host to prove ping 8.8.8.8
Layer 3 connectivity ping www.example.com
traceroute / tracert Discover the Layer 3 path to a remote host tracert www.example.com
Can use IP address or DNS FQDN as target traceroute 8.8.8.8
nslookup Manually query a DNS server (Windows) nslookup example.com
dig Manually query a DNS server (Linux) dig example.com
netstat Display listening ports and sockets netstat
netstat -na
netstat -nao
ip / ifconfig / ipconfig Display host IP settings ip addr (Linux)
Ifconfig (Linux)
ipconfig (Windows)
arp Display host arp cache arp -a
Review (cont’d)
Nmap sends specially crafted packets to target hosts and analyzes the responses
Nmap can be used for host discovery, port and vulnerability scanning, OS/service version
detection, firewall and IDS testing, and network topology mapping
Nmap has a graphical user interface (GUI) named Zenmap that simplifies scanning and
visualization
Review (cont’d)
Cisco Discovery Protocol (CDP) is used to discover information about directly connected devices
CDP verifies Layer 2 connectivity and can provide information about neighbors such as device
identifiers, IP addresses, port identifiers, capabilities (e.g., router, switch), and platform
information
Link Layer Discovery Protocol (LLDP) is a vendor-neutral alternative to CDP
LLDP is useful when neighbor devices (such as VoIP phones) are non-Cisco
Review (cont’d)
A telephone toner is used to locate a cable on a patch panel or wall jack
A cable tester checks for broken wires or connections, shorts, and incorrect pin-outs
A light meter / fiber optic cable tester is used to certify and troubleshoot fiber-optic cable
The light meter can measure loss/breakage by sending light through a fiber optic cable
A network tap is a specialized hardware device that allows passive monitoring of traffic without
interrupting the flow
Network taps are often used for security analysis and forensics
A Wi-Fi analyzer is a network analyzer for wireless networks
A Wi-Fi analyzer collects packets from the wireless networks and detects acceptable networks, hidden
networks, interference by other networks, devices, and other machinery
Wi-Fi analyzers are used for wireless surveys, wireless access point placement, and troubleshooting
Review (cont’d)
A spectrum analyzer is a specialized tool that measures the level of any type of signal, including Wi-Fi,
RFI and EMI, across a range of frequencies
A spectrum analyzer is used to find:
◦ Congested wireless channels and frequencies
◦ Interference levels at different frequencies
A visual fault locator uses a laser to check continuity, locate fiber breaks, poor mechanical splices and
damaged connectors in fiber optic cabling
◦ Finds faults along a cable
◦ You must be able to fully see the cable
A time delay reflectometer (TDR) is used to check cable continuity
◦ The TDR sends a signal down the cable, which bounces back at a break in the cable or at the end
◦ The time taken for the reflected signal to return is then calculated to determine where the break or end is
An Optical time domain reflectometer (OTDR) is used to check continuity in fiber-optic cables
Review (cont’d)
Command Description Comment
show mac-address-table Display a switch’s MAC table Cisco commands for older and
show mac address-table current switches
show route Display router’s route table Juniper
show ip route Cisco
show interface Display interface statistics Juniper, Cisco
show config Display device’s running or saved configuration Juniper, HP, Aruba
show running-config Cisco
show startup-config Cisco
show arp Display the ARP cache Universal
show ip arp
show vlan Display VLANs and their ports on the switch Universal
show power Display power information Cisco and some Juniper
show power inline Display PoE information