Network Troubleshooting Chapter 21

Objectives Describe appropriate troubleshooting tools and their functions Analyze and discuss the troubleshooting process Resolve common network issues Describe the Internet of Things

Troubleshooting Tools Test Specific Troubleshooting Tools

Troubleshooting Tools Required tools vary depending on the job type Always consider the safety of your data first Before beginning troubleshooting Many software diagnostic tools are available You may not need any purchased software tools Caution (p. 599): No matter what the problem, always consider the safety of your data first. Ask yourself this question before performing any troubleshooting action: “Can what I’m about to do potentially damage my data?”

Hardware Tools Cable testers, TDRs, and OTDRs Certifiers Voltage event recorders Protocol analyzers Cable strippers Multimeters Tone probes/generators Exam Tip (p. 599): Read this section! The CompTIA Network+ exam is filled with repair scenarios, and you must know what every tool does and when to use it.

Hardware Tools (cont’d.) Line testers Butt sets Punchdown tools

Potential Circuit Problems Open circuit Cable wires do not connect from one end of the cable to the other Short circuit Connection between wires in a cable Wire map problem Wires do not connect to the proper location on the jack or plug Exam Tip (p. 600): The CompTIA Network+ objectives use the terms shorts and opens at the time of this writing. More commonly, techs would refer to these issues as short circuits and open circuits.

Potential Circuit Problems (cont’d.) Crosstalk The electrical signal from one wire pair causes interference in a nearby wire pair Noise Spurious signals typically due to faulty hardware or poorly crimped jacks Impedance mismatch Can occur where cables of different types connect

Cable Testers, TDRs, and ODTRs Help identify continuity or wire map problems TDRs (time domain reflectometers) Locate copper cable breaks OTDRs (optical time domain reflectometers) Locate fiber-optic cable breaks

Figure 21.1 Typical cable tester

Figure 21.2 An EXFO AXS-100 OTDR (photo courtesy of EXFO)

Certifiers Ensure a cable can handle its rated capacity Use when a cable is not moving data as it should Require a loopback on the far end Problems that reduce cable capacity Crosstalk Attenuation Interference

Light Meter Measures light loss in a fiber optic cable Uses a high-powered light source and detector Also called optical power meter Inherent impurities in the glass can reduce light transmission Other causes: dust, poor connections, and light leakage Exam Tip (p. 600): The CompTIA Network+ objectives use the term light meter. The more accurate term in this context is either power meter or optical power meter. You may see any of these terms on the exam.

Figure 21.3 Fiberlink® 6650 Optical Power Meter (photo courtesy of Communications Specialties, Inc.)

Voltage Event Recorder/ Temperature Monitor Detect power and heat problems Symptom: intermittent problems Possible cause: heat problems in server rooms A voltage event recorder can help identify problems with electricity A temperature monitor collects temperature information over time

Protocol Analyzers Monitor protocols running at different layers Application, Session, Transport, Network, and Data Link May be hardware or software tools

Protocol Analyzers (cont’d.) Problem symptoms A session fails to start A DNS server fails to respond Confusing information appears on the network You suspect a rogue DHCP server exists Excess or unexpected traffic slows the network

Cable Strippers/Snips Needed for making UTP cables Also need crimpers Cable stripper and crimper can be combined in a single tool

Figure 21.4 A cable stripping and crimping tool

Multimeters Test AC and DC voltage, resistance, and continuity Often used for continuity testing when a cable tester is not available Tech Tip: Never Buy Cheap Tools (p. 601) There’s an old adage used by carpenters and other craftspeople that goes, “Never buy cheap tools.” Cheap tools save you money at the beginning, but they often break more readily than higher-quality tools and, more importantly, make it harder to get the job done. This adage definitely applies to multimeters! You might be tempted to go for the $10 model that looks pretty much like the $25 model, but chances are the leads will break or the readings will lie on the cheaper model. Buy a decent tool, and you’ll never have to worry about it.

Tone Probes and Tone Generators Work together to help locate a particular cable A tone generator puts a signal (tone) on a wire A tone probe on opposite end detects the signal Exam Tip (p. 601): The CompTIA Network+ exam and many techs refer to the probe as a toner probe rather than a tone probe or simply a probe. Don’t be surprised by this terminology on the exam. You always need both a probe and a tone generator to use this tool properly.

Butt Sets A telephone person’s best friend Tap into a 66- or 110-block to test a line

Line Testers Simple devices for checking telephone wiring integrity Possible outcomes when checking a twisted pair line Good Dead Reverse wired An AC voltage on the line

Punchdown Tools Put UTP wires into 66- and 110-blocks Repunch a connection to make sure contacts are set Try This! Shopping Spree (p. 602) As more and more people have networks installed in their homes, the big-box hardware stores stock an increasing number of network-specific tools. Everybody loves shopping, right? So try this! Go to your local hardware store—big box, like Home Depot or Lowes, if there’s one near you—and check out their tools. What do they offer? Write down prices and features and compare with what your classmates found.

Figure 21.5 A punchdown tool in action

Software Tools Built-in tools tracert/traceroute ipconfig/ifconfig/ip arp, ping, arping, and pathping nslookup/dig hostname route nbtstat and netstat/ss Try This! Playing Along (p. 602) This section contains many command-line tools that you’ve seen earlier in the book in various places. Now is a great time to refresh your memory about how each one works, so after I review each command, run it yourself. Then type help followed by the command to see the available switches for that command. Run the command with some of the switches to see what they do. Running them is more fun than just reading about it; plus, you’ll solidify the knowledge you need to master.

Software Tools (cont’d.) Third-party tools Packet sniffer Port scanners Throughput testers Looking glass sites

The tracert/traceroute Commands Traces all of the routers between two points Assist in diagnosing where a problem lies For problems in reaching a remote system If traceroute stops at a certain router Problem is the next router or the connection Some routers block ICMP packets containing traceroute information

Sample traceroute output Tracing route to adsl-208-190-121-38.dsl.hstntx.swbell.net [208.190.121.38] over a maximum of 30 hops: 1 1 ms <1 ms 1 ms Router.totalhome [192.168.4.1] 2 38 ms 41 ms 70 ms adsl-208-190-121-38.dsl.hstntx.swbell.net [208.190.121.38] Sample traceroute output (p. 603) Sample traceroute output 29

The ipconfig/ifconfig/ip Commands Displays IP settings ipconfig without parameters Provides basic information only ipconfig /all Gives detailed information (e.g., DNS servers and MAC addresses)

Sample ipconfig output Ethernet adapter Main: Connection-specific DNS Suffix . : IPv6 Address . . . . . . . . . . : 2001:470:bf88:1:fc2d:aeb2:99d2:e2b4 Temporary IPv6 Address . . . . . : 2001:470:bf88:1:5e4:c1ef:7b30:ddd6 Link-local IPv6 Address. . . . . : fe80::fc2d:aeb2:99d2:e2b4%8 IPv4 Address . . . . . . . . . . : 192.168.4.27 Subnet Mask . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . : fe80::223:4ff:fe8c:b720%8 192.168.4.1 Tunnel adapter Local Area Connection* 6: Media State . . . . . . . . . . : Media disconnected Sample ipconfig output (p. 603) Sample ipconfig output

Sample ifconfig output lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=1<PERFORMNUD> gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV> ether 3c:07:54:7a:d4:d8 inet6 fe80::3e07:54ff:fe7a:d4d8%en0 prefixlen 64 scopeid 0x4 inet 192.168.4.78 netmask 0xffffff00 broadcast 192.168.4.255 inet6 2601:e::abcd:3e07:54ff:fe7a:d4d8 prefixlen 64 autoconf inet6 2601:e::abcd:b84e:9fad:3add:c73b prefixlen 64 autoconf temporary media: autoselect (1000baseT <full-duplex,flow-control>) status: active Sample ifconfig output (p. 603) Sample ifconfig output

Sample Linux’s ip output 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:0c:29:e0:b2:85 brd ff:ff:ff:ff:ff:ff inet 192.168.4.19/24 brd 192.168.4.255 scope global eth0 inet6 2601:e:0:abcd:8cfb:6220:ec23:80a/64 scope global temporary dynamic valid_lft 86221sec preferred_lft 14221sec inet6 2601:e:0:abcd:20c:29ff:fee0:b285/64 scope global dynamic inet6 fe80::20c:29ff:fee0:b285/64 scope link Sample Linux’s ip output (p. 603) Sample Linux’s ip output

The arp Command The ARP table records IP address–MAC address pairs The arp command enables viewing and changing the ARP table on a computer Exam Tip (p. 604): The CompTIA Network+ objectives refer to the ARP table as the mac address lookup table, at least at the time this book went to press. Be prepared for either term.

Sample arp -a output Interface: 192.168.4.57 ––– 0xc Internet Address Physical Address Type 192.168.4.1 b8-9b-c9-7d-e7-76 dynamic 192.168.4.2 00-87-b6-7e-ae-23 dynamic 192.168.4.8 67-ab-cc-aa-fe-ed dynamic 192.168.4.12 23-b5-94-17-d7-33 dynamic 192.168.4.13 4b-4b-4c-4d-4e-46 dynamic 192.168.4.14 55-55-55-55-55-55 dynamic Sample arp -a output (p. 604) Sample arp -a output

The ping Command Queries by name or IP address Uses ICMP packets Works across routers Problem: devices can block ICMP Defaults to IPv4 Use -6 switch for IPv6: ping -6 (Windows) or ping6 (Unix/Linux/OS X) Exam Tip (p. 605): The ping utility has the word Pinging in the output. The arping command has the word ARPING. Don’t assume that the CompTIA Network+ exam will include those words in its sample outputs, however.

Sample ping output Minimum = 0ms, Maximum = 0ms, Average = 0ms Pinging 192.168.4.19 with 32 bytes of data: Reply from 192.168.4.19: bytes=32 time<1ms TTL=64 Ping statistics for 192.168.4.19: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Sample ping output

The arping Command Uses ARP frames rather than ICMP packets Does not work across routers Is supported by UNIX and UNIX-like systems

ARPING 192.168.4.27 from 192.168.4.19 eth0 Unicast reply from 192.168.4.27 [00:1D:60:DD:92:C6] 0.875ms Unicast reply from 192.168.4.27 [00:1D:60:DD:92:C6] 0.897ms Unicast reply from 192.168.4.27 [00:1D:60:DD:92:C6] 0.924ms Unicast reply from 192.168.4.27 [00:1D:60:DD:92:C6] 0.977ms Sample arping output (p. 605) Sample arping output

The pathping Command Combines the functions of ping and tracert Also adds some additional functions

Sample pathping output Tracing route to xeroxpaser.totalhome [182.168.4.17] Over a maximum 30 hops: 0 local-PC.totalhome [192.168.4.53] 1 xrxphsr.totalhome [192.168.4.17] Computing statistics for 25 seconds... Source to Here This Node/Link Hop RTT Lost/Sent – Pct Lost/Sent – Pct Address 0 local-PC.totalhome [192.168.4.53] 0/ 100 – 0% : 0ms 0/ 100 – 0% 0/ 100 – 0% xrxphsr.totalhome [192.168.4.17] Trace complete Sample pathping output (p. 605) Sample pathping output

The nslookup/dig Commands Both diagnose DNS problems nslookup (all operating systems) Only choice by default on Windows systems dig (UNIX/Linux) Provides more verbose output by default than nslookup Example of the dig command: dig mx totalsem.com Exam Tip (p. 606): Running the networking commands several times will help you memorize the functions of the commands as well as the syntax. The CompTIA Network+ exam is also big on the switches available for various commands, such as ipconfig /all.

Output for the dig command ; <<>> DIG 9.5.0-P2 <<>> mx totalsem.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6070 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;totalsem.com. IN MX ;; ANSWER SECTION: totalsem.com. 86400 IN MX 10 mx1c1.megamailservers.com. totalsem.com. 86400 IN MX 100 mx2c1.megamailservers.com. totalsem.com. 86400 IN MX 110 mx3c1.megamailservers.com. Output for the dig command (pp. 605-606) Output for the dig command

The hostname Command Simplest of all utilities covered here Returns name of host from which it runs hostname sample output: C:\> C:\>hostname mike-win8beta

The mtr Command Dynamic (keeps running) Equivalent to traceroute Not supported by Windows

Sample mtr output My traceroute [v0.73] totaltest (0.0.0.0) Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. Router.totalhome 0.0% 5 0.8 0.8 0.7 0.9 0.1 2. adsl-208-190-121-38.dsl.hstntx.s 0.0% 4 85.7 90.7 69.5 119.2 20.8 Sample mtr output (p. 606) Sample mtr output

The route Command Used to display and edit the local system’s routing table Type route print or netstat -r

Sample route print output =========================================================================== Interface List 8 ...00 1d 60 dd 92 c6 ...... Marvell 88E8056 PCI-E Ethernet Controller 1 ........................... Software Loopback Interface 1 IPv4 Route Table Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.4.1 192.168.4.27 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 169.254.0.0 255.255.0.0 On-link 192.168.4.27 286 169.254.214.185 255.255.255.255 On-link 169.254.214.185 276 169.254.255.255 255.255.255.255 On-link 192.168.4.27 266 192.168.4.0 255.255.255.0 On-link 192.168.4.27 266 192.168.4.27 255.255.255.255 On-link 192.168.4.27 266 192.168.4.255 255.255.255.255 On-link 192.168.4.27 266 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 169.254.214.185 276 224.0.0.0 240.0.0.0 On-link 192.168.4.27 266 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 169.254.214.185 276 255.255.255.255 255.255.255.255 On-link 192.168.4.27 266 Persistent Routes: None Sample route print output (pp. 606-607) Sample route print output

The nbtstat Command Windows-only program Command-line equivalent of Window’s My Network Places or Network icon Always run with a switch nbtstat –n shows the local NetBIOS names

Sample route print output Main: Node IpAddress: [192.168.4.27] Scope Id: [] NetBIOS Local Name Table Name Type Status --------------------------------------------- MIKESPC <00> UNIQUE Registered TOTALHOME <00> GROUP Registered MIKESPC <20> UNIQUE Registered TOTALHOME <1E> GROUP Registered Sample route print output (p. 607) Sample route print output

The netstat Command Comes with Windows systems Displays the current state of running IP processes Shows what sessions are active Provides statistics based on ports or protocols Type netstat to show only current sessions Type netstat –r to show the routing table; identical to route print

Active Connections Proto Local Address Foreign Address State TCP 127 Active Connections Proto Local Address Foreign Address State TCP 127.0.0.1:27015 MikesPC:51090 ESTABLISHED TCP 127.0.0.1:51090 MikesPC:27015 ESTABLISHED TCP 127.0.0.1:52500 MikesPC:52501 ESTABLISHED TCP 192.168.4.27:54731 72-165-61-141:27039 CLOSE_WAIT TCP 192.168.4.27:55080 63-246-140-18:http CLOSE_WAIT TCP 192.168.4.27:56126 acd4129913:https ESTABLISHED TCP 192.168.4.27:62727 TOTALTEST:ssh ESTABLISHED TCP 192.168.4.27:63325 65.54.165.136:https TIME_WAIT TCP 192.168.4.27:63968 209.8.115.129:http ESTABLISHED Sample netstat output (p. 607) Sample netstat output

The ss Command Has eclipsed netstat on the Linux side Faster and more powerful than netstat Sample output (filtered to show only TCP connections): State Recv-Q Send-Q Local Address:Port Peer Address:Port CLOSE-WAIT 28 0 10.0.2.15:52161 91.189.92.24:https CLOSE-WAIT 28 0 10.0.2.15:46117 91.189.92.11:https ESTAB 0 0 10.0.2.15:55542 74.125.239.40:http

Packet Sniffer Also called protocol analyzer or packet analyzer Intercepts and logs network packets Many choices Software or dedicated hardware devices Software example: Wireshark Command-line tool: tcpdump Note (p. 608): Sometimes a GUI tool like Wireshark won’t work because a server has no GUI installed. In situations like this, tcpdump is the go-to choice. This great command-line tool not only lets you monitor and filter packets in the terminal, but can also create files you can open in Wireshark for later analysis. Even better, it’s installed by default on most UNIX/Linux systems.

Figure 21.6 Wireshark in action!

Port Scanners Probe ports on another system Log the state of scanned ports Uses Find unintentionally open ports that could make a system vulnerable to attack Hackers can use to break into systems Nmap is available for UNIX and Windows Angry IP Scanner is a Windows port scanner

Figure 21.7 Angry IP Scanner

Throughput Testers Measure the data flow in a network The appropriate tool depends on the type of network throughput you want to test Several speed-test sites are available for checking an Internet connection’s throughput Example: MegaPath’s Speakeasy Speed Test

Figure 21.8 Speed Test results from Speakeasy

Looking Glass Sites Browser-accessible remote servers Contain collections of diagnostic tools Also Border Gateway Protocol (BGP) query tools Allow selection of origination location, target destination, and desired diagnostic May also test IP version

Troubleshooting: Two Basic Rules Do no harm. Always make good backups!

The Troubleshooting Process Identify the problem Gather information Duplicate the problem, if possible Question users Identify symptoms Determine if anything has changed Approach multiple problems individually

The Troubleshooting Process (cont’d.) Establish a theory of probable cause Question the obvious Consider multiple approaches Top-to-bottom/bottom-to-top OSI model Divide and conquer Test theory to determine cause If confirmed, determine next steps If not confirmed, establish new theory or escalate

The Troubleshooting Process (cont’d.) Establish a plan of action to resolve the problem and identify potential effects Implement the solution or escalate as necessary Verify full system functionality Implement preventative measures, if applicable Document findings, actions, and outcomes

Identify the Problem The true problem may be different from what the user tells you The symptom may indicate a larger problem

Gather Information, Duplicate the Problem, Question Users, and Identify Symptoms Direct support Observe what is or is not happening Phone support Use closed-ended or open-ended questions

Gather Information, Duplicate the Problem, Question Users, and Identify Symptoms (cont’d.) Can rule out user error as the cause Determine the scope of the problem Are other users affected? Exam Tip (p. 612): Eliminating variables is one of the first tools in your arsenal of diagnostic techniques.

Determine If Anything Has Changed Example questions to users “What was happening when the problem occurred?” “Has anything changed on the system recently?” “Has the system been moved recently?” Check your documentation Includes system and hardware logs Exam Tip (p. 612): Avoid aggressive or accusatory questions.

Approach Multiple Problems Individually Break down complicated problems into manageable pieces Methodically tackle each sub-problem

Establish a Theory of Probable Cause Based on experience Select the most probable cause from a list of all possible causes Question the obvious Example: check to ensure a printer is powered on Considering multiple approaches can help avoid becoming locked in to a single approach

Example Scenario User cannot access the server Opens database program and clicks on a recent document The document does not open Consider a top-to-bottom or bottom-to-top OSI model approach Application layer: consider whether a problem with the API is the possible cause

OSI Model Approach Presentation layer: consider encryption between the application and database server Session layer: consider whether a port on the server is blocked Transport layer: consider the effect of extreme traffic Network layer: consider whether the IP address of the database server has changed

OSI Model Approach (cont’d.) Data link layer: consider whether the MAC address of the user’s machine or the database server is blacklisted Physical layer: check for a disconnected cable or a bad NIC

Other Options for Tackling Multiple Options Reverse the approach using the OSI model beginning with Layers 1 and 2 Divide and conquer approach Choose the OSI layer starting point based on a general sense of where the problem lies If this starting layer is not the problem, move up or down the OSI model with new theories of probable cause

Test the Theory to Determine Cause Test the theory without changing anything You may not have permission to make the fix The fix may have unanticipated repercussions Escalate the problem Inform other parties for guidance Pass the job to another authority with control over the device or issue

Establish a Plan of Action and Identify Potential Effects Write down the steps of your action plan Identify the potential effects of the actions

Implement the Solution or Escalate as Necessary Examples of implementation Give advice to a user over the phone Install a replacement part Add a software patch Try only one solution at a time Document what you do Test the solution Exam Tip (p. 615): Always test a solution before you walk away from the job!

Verify Full System Functionality and Implement Preventative Measures In the example scenario: Have the user open the database while you are still at the computer Implement preventative measures to avoid a repeat of the problem May involve educating the user to do or not do something

Document Findings, Actions, and Outcomes Purpose of documentation Creates a knowledge database for future reference Eliminates duplication of work Allows tracking problem trends Anticipate future workloads May identify less reliable brands or models Exam Tip (p. 616): Memorize these problem analysis steps: 1. Identify the problem. a. Gather information. b. Duplicate the problem, if possible c. Question users. d. Identify symptoms. e. Determine if anything has changed. f. Approach multiple problems individually 2. Establish a theory of probable cause. a. Question the obvious. b. Consider multiple approaches i. Top-to-bottom/bottom-to-top OSI model ii. Divide and conquer 3. Test the theory to determine cause. a. Once theory is confirmed, determine next steps to resolve problem. b. If theory is not confirmed, reestablish new theory or escalate. 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 preventative measures. 7. Document findings, actions, and outcomes.

Resolving Common Network Issues Basic categories of network issues Fixing problems at a user’s workstation, work area, or a server Connecting to resources on the LAN Or WAN, but these may need to be escalated Stumbling block Observed symptom may be the same for a variety of root causes

“We Can’t Access Our Web Server in Istanbul!” Example scenario Everyone has local and Internet Web site access The firewall configuration was recently changed Technician’s theories The remote server is down The remote site is inaccessible The local firewall is preventing communication

“We Can’t Access Our Web Server in Istanbul!” (cont’d.) Quickest to test approach Confirm all local office workstations cannot reach the remote server Using different hosts, try ping and ping6 utilities Traceroute shows functional path to the router, but no server response Run the mtr utility from a Linux box and simultaneously run pathping on a Windows system Call the remote site to ask about the status

“We Can’t Access Our Web Server in Istanbul!” (cont’d.) Determine whether the site is reachable from outside the local office Would confirm or eliminate the theory of a local firewall configuration issue Using a looking glass site tool, perform a ping test No pings receive a response from the server in question Other servers at the remote site do respond Conclusion: the remote server is down

“We Can’t Access Our Web Server in Istanbul!” (cont’d.) Possible causes of an unresponsive server Local power outage or blown circuit breaker Failed NIC on the server Network cable disconnected Improper network configuration on the server A changed patch cable location in the rack Failed component in the server Server shutdown

Hands-On Problems Problems you can fix at the workstation, work area, or server Include physical and configuration problems Possible causes of an unreachable network device Power failure or power anomalies Hardware failure

Possible Causes of Unreachable Network Device EMI or RFI disrupting signals on copper cable Interface errors, such as improper wall jack installation Incorrect termination Cable to the workstation might be bad Crossover versus straight-through cable Cross Check: Interference at the Demarc (p. 618) You read about interference causing problems at the demarc in an office building back in Chapter 14, “Remote Connectivity,” so cross check your knowledge now. What kind of interference could cause problems? How would you avoid the problems?

Other Types of Hands-On Problems Incorrect IP configuration Incorrect default gateway IP address information Out of date DNS entry Simultaneous wireless/wired connections Can create a network failure

Figure 21.9 TCP/IP settings in Windows Server

Figure 21.10 Network Connections Advanced Settings

LAN Problems Issues can arise when duplicating machines and using static IP addresses A solution is to change the IP address on the new machine to an unused static IP or to DHCP Exam Tip (p. 619): CompTIA continues to include speed and duplex mismatch as a common network issue, although that’s not how networks work today. Every NIC, switch, and router features autosensing and autonegotiating ports. You plug two devices in and, as long as they’re not otherwise misconfigured, they’ll run at the same speed—most likely at full duplex. It’s important to note that if the speeds on the two NICs are mismatched, the link will not come up, but if it’s just the duplex that’s mismatched, the link will come up but the connection will be erratic. Look for this “common error” on the exam, but not in the real world.

Server Misconfigurations Misconfigured DHCP settings On a host: effect is limited to that host On a DHCP server: many more machines affected Misconfigured DNS settings On a DNS server: the server might direct hosts to incorrect sites or no sites at all On a client: name resolution stops and the user experiences a downed network Cross Check: DNS Settings (p. 619) You learned about DNS in detail in Chapter 10, so dust off those memories and see if you can answer these questions. What might cause a DNS server to go down? What’s a DNS root server? What are the authoritative top-level domain servers? Does DNS use a flat name space or a hierarchical name space? What’s the difference?

Server Misconfigurations (cont’d.) Clues to server misconfiguration Success in pinging a file server by address but not by name ► points to a DNS issue Failure to discover neighboring devices/nodes ► may point to DHCP or DNS misconfiguration To fix misconfiguration Go into the network configuration for the client or the server and look for problems

Adding VLANs Example: Figure 21.11 Bill intended to assign 6 ports to each VLAN Instead assigned 7 ports to VLAN 1 and 5 ports to VLAN 2 Result: interface misconfiguration producing an incorrect VLAN assignment Patch cable placement errors can also occur Keep proper records of patch cable assignments

Figure 21.11 Bill’s VLAN assignments

Link Aggregation Problems Scaling an Ethernet network Bandwidth issues: one choice is to upgrade the switch and server NIC to the next higher Ethernet standard Other approach: link aggregation or NIC teaming Protocols Link Aggregation Control Protocol (LACP) Cisco’s Port Aggregation Protocol (PAgP)

Link Aggregation Problems (cont’d.) Enabling LACP Need two or more interconnected network interfaces configured for LACP Devices communicate over multiple ports at the same speeds and form a single logical port

Figure 21.12 LACP

Link Aggregation Problems (cont’d.) Active ports Default to using LACP, if possible Passive ports Wait for active ports to initiate conversation Common network error with LACP setups Both sides of the connection set to passive ► an example of NIC teaming misconfiguration Exam Tip (p. 621): CompTIA Network refers to this subset of NIC teaming misconfiguration as simply multicast vs. broadcast. It’s not really one against the other, but there you have it.

WAN Problems Possible origination points Local machines LAN switches Routers that interconnect the WAN Switches within the distant network Distant machines

Router Problems Nonfunctioning connections between networks Potential causes Physical problems with the router or router interface modules Loss of power Problems with the Access Control List A misconfiguration can lead to missing IP routes Exam Tip (p. 622): As you’ll recall from Chapter 18, “Managing Risk,” if you want to prevent downtime due to a failure on your default gateway, you should consider implementing Virtual Router Redundancy Protocol (VRRP) or, if you are a Cisco shop, Hot Standby Router Protocol (HSRP).

Router Problems (cont’d.) Key tool for determining a router problem beyond the local LAN is traceroute Run traceroute to the default gateway A failed traceroute indicates a local issue If the traceroute comes back positive, run it to an Internet site

Figure 21.13 Good connection

ISPs and MTUs MTU mismatch Ways to remedy MTU mismatch A network’s packets are so large that they must be fragmented to fit into the ISP’s packets Ways to remedy MTU mismatch Techs can tweak the MTU settings to improve throughput Path MTU Discovery (PMTU) determines the best MTU setting automatically PMTU runs under ICMP

Appliance Problems Network appliances Complex boxes with multiple features, e.g., routing, NAT, switching, IDS, firewall, and more NAT rules take precedence over appliance’s routing table entries Tech must set the NAT rule order correctly Fix a NAT interface misconfiguration by setting up the network appliance correctly

Company Security Policy Example Amount of traffic between two company locations on a dedicated connection is causing huge bandwidth issues Cause: sales department is sending large video files Need to limit bandwidth for a single department Need a blocking policy to enforce the limit Need a company fair use policy to state limits

Beyond Local—Escalate Problems to escalate Problem that exceeds the tech’s skill level Problem that involves third-party equipment Large organizations typically have clear escalation procedures CompTIA-recognized escalation situations Broadcast storms, switching loops, routing problems, routing loops, and proxy ARP

Broadcast Storms Result of one or more devices sending nonstop broadcast frames onto the network Symptom: every computer on the broadcast domain cannot connect to network Many users contact you simultaneously Call a supervisor to get support Isolate devices until the problem device is identified

Switching Loops Multiple switches inadvertently connected together to form a loop Also called bridging loops Symptoms are identical to a broadcast storm Rarely take place on a well-running network Most switches use the Spanning Tree Protocol Escalate the problem to discover the person making switch changes

Routing Loops Occur when interconnected routers loop traffic Cause routers to respond slowly or not at all Clue: a huge amount of traffic—far more than the usual traffic—on the links between the routers Exam Tip (p. 625): In ancient times, when RIP ruled the routing roost, routers potentially could communicate a route back out the same interface it was learned through. So Router C might tell Router D that it was two hops away from Router A. Router D would pass along the information to Router E, saying it was three hops away from Router A. Because RIP was a pretty dumb protocol, Router E could respond back to Router D with the information that Router A was four hops away. Router D would then be pretty confused, thinking it was simultaneously three and five hops away from Router A! That’s where split horizon comes in: when a router learns a route through a certain interface, it will not communicate that route out the same interface. RIP has been gone a long time, but for some reason CompTIA keeps split horizon on the objectives. This is not a real-world issue; it’s only a CompTIA Network+ exam issue.

Proxy ARP Process of making remotely connected computers act as if they are on local LAN VPN is the classic example Almost all proxy ARP problems involve the VPN concentrator With misconfigured proxy ARP settings, the VPN concentrator sends what looks like a DoS attack on the LAN

End-to-End Connectivity End-to-end principle Applications and work should happen only at endpoints in a network The Internet was founded on this principle Modern networks Much activity happens at intermediate devices reflects the current state of the Internet

End-to-End Connectivity (cont’d.) Connecting users with essential resources within a smaller network, e.g., aLAN or a private WAN A tech’s job includes ensuring connections happen fully

Troubleshooting Is Fun! Apply good troubleshooting methodology Constantly increase your network knowledge Become a troubleshooting artist Benefit: Easier to deal with a network disaster

Internet of Things (IoT) Everyday objects capable of communicating with each other A large-scale idea Changes promised by IoT Challenges involved with IoT Technologies making IoT possible

Utopia of things Vast array of real-world smart objects Collecting sensor data Communicating that data with other objects or computers Making decisions based on it Examples of smart objects in the home and at the gym Larger scale applications, e.g., the power grid

Challenges? Bugs Hacking Feedback loops Interoperability Waste and obsolescence Power Scale

Supporting Technologies IPv6 is essential for enough address space Ultra-low-power wireless radios Communications with vast networks of sensors IEEE 1905.1 is a hybrid networking standard MoCA provides Ethernet access through existing coaxial cabling HomePlug (IEEE 1901) provides high-speed home networking—Ethernet over power (EoP) Exam Tip (p. 629): CompTIA may refer to the IEEE 1905.1 standard, which was ratified in 2013, as IEEE 1905.1-2013. Exam Tip (p. 630): CompTIA uses the term Ethernet over power line— don’t let this small difference trip you up.

Supporting Technologies (cont’d.) nVoy: the branding for IEEE 1905.1 nVoy-certified networking equipment: Will create a single network for devices spread across Ethernet, Wi-Fi, MoCA, and HomePlug connections Can make intelligent decisions when communicating with devices that use more than one connection type Exam Tip (p. 630): As of HDMI 1.4, the HDMI standard also creates HDMI Ethernet Channel (HEC), or Ethernet-enabled HDMI ports that combine video, audio, and data on a single cable. The important thing about HEC—which CompTIA refers to as Ethernet over HDMI—is that it can allow two-way communication and connection-sharing between a TV and set-top boxes, providing yet another option for making sure all of your video equipment is networked.

Looking Ahead There is no clear finish line to mark the arrival of IoT The networking requirements leading to IoT will be incremental One day communications between smart devices may overtake the traffic generated by human users