The Correct Login Procedure and Rights

You know by now that if you’ve set up everything correctly, your network’s users absolutely have to follow the proper login procedure to the letter (or number, or symbol) in order to successfully gain access to the network resources they’re after. If they don’t do that, they will be denied access, and considering that there are truly tons of opportunities to blow it, it’s a miracle, or at least very special, that anyone manages to log in to the network correctly at all.

Think about it. First, a user must enter their username and password flawlessly. Sounds easy, but as they say, “in a perfect world . . .” In this one, people mess up, don’t realize it, and freak out at you about the “broken network” or the imaginary IT demon that changed their password on them while they went to lunch and now they can’t log in. (The latter could be true—you may have done exactly that. If you did, just gently remind them about that memo you sent about the upcoming password-change date and time that they must have spaced about due to the tremendous demands on them.)

Anyway, it’s true. By far, the most common problem is bad typing—people accidentally enter the wrong username or password, and they do that a lot. With some operating systems, a slight brush of the Caps Lock key is all it takes: The user’s username and password are case sensitive, and suddenly, they’re trying to log in with what’s now all in uppercase instead—oops.

Plus, if you happen to be running one of the shiny new operating systems around today, you can also restrict the times and conditions under which users can log in, right? So, if your user spent an unusual amount of time in the bathroom upon returning from lunch, or if they got distracted and tried to log in from their BFF’s workstation instead of their own, the network’s operating system would’ve rejected their login request even though they still can type impressively well after two martinis.

And remember—you can also restrict how many times a user can log in to the network simultaneously. If you’ve set that up, and your user tries to establish more connections than you’ve allowed, access will again be denied. Just know that most of the time, if a user is denied access to the network and/or its resources, they’re probably going to interpret that as a network problem even though the network operating system is doing what it should.

Let’s pause for a minute to outline the steps to take during any user-oriented network problem-solving process:

1. Make sure the username and password is being entered correctly.
2. Check that Caps Lock key.
3. Try to log in yourself from another workstation, assuming that doing this doesn’t violate the security policy. If it works, go back to the user-oriented login problems, and go through them again.
4. If none of this solves the problem, check the network documentation to find out whether any of the aforementioned kinds of restrictions are in place; if so, find out whether the user has violated any of them.

Remember, if intruder detection is enabled on your network, a user will get locked out of their account after a specific number of unsuccessful login attempts. If this happens, either they’ll have to wait until a predetermined time period has elapsed before their account will unlock and give them another chance or you’ll have to go in and manually unlock it for them.

Network Connection LED Status Indicators

The link light is that little light-emitting diode (LED) found on both the network interface card (NIC) and the switch. It’s typically green and labeled Link or some abbreviation of that. If you’re running 100BaseT, a link light indicates that the NIC and switch are making a logical (Data Link layer) connection. If the link lights are lit up on both the workstation’s NIC and the switch port to which the workstation is connected, it’s usually safe to assume that the workstation and switch are communicating just fine.

The link lights on some NICs don’t activate until the driver is loaded. So, if the link light isn’t on when the system is first turned on, you’ll just have to wait until the operating system loads the NIC driver. But don’t wait forever!

The collision light is also a small LED, but it’s typically amber in color, and it can usually be found on both Ethernet NICs and hubs. When lit, it indicates that an Ethernet collision has occurred. If you’ve got a busy Ethernet network on which collisions are somewhat common, understand that this light is likely to blink occasionally; if it stays on continuously, though, it could mean that there are way too many collisions happening for legitimate network traffic to get through. Don’t assume this is really what’s happening without first checking that the NIC, or other network device, is working properly because one or both could simply be malfunctioning.

Don’t confuse the collision light with the network-activity or network-traffic light (which is usually green) because the latter just indicates that a device is transmitting. This particular light should be blinking on and off continually as the device transmits and receives data on the network.

The Power Switch

Clearly, to function properly, all computer and network components must be turned on and powered up first. Obvious, yes, but if I had a buck for each time I’ve heard, “My computer is on, but my monitor is all dark,” I’d be rolling in money by now.

When this kind of thing happens, just keep your cool and politely ask, “Is the monitor turned on?” After a little pause, the person calling for help will usually say, “Ohhh . . . ummmm . . . thanks,” and then hang up ASAP. The reason I said to be nice is that, embarrassing as it is, this, or something like it, will probably happen to you, too, eventually.

Most systems include a power indicator (a Power or PWR light). The power switch typically has an On indicator, but the system or device could still be powerless if all the relevant power cables aren’t actually plugged in—including the power strip.

Remember that every cable has two ends, and both must be plugged into something. If you’re thinking something like, “Sheesh—a four-year-old knows that,” you’re probably right. But again, I can’t count the times this has turned out to be the root cause of a “major system failure.”

The best way to go about troubleshooting power problems is to start with the most obvious device and work your way back to the power-service panel. There could be a number of power issues between the device and the service panel, including a bad power cable, bad outlet, bad electrical wire, tripped circuit breaker, or blown fuse, and any of these things could be the actual cause of the problem that appears to be device-death instead.

Operator Error

Or, the problem may be that you’ve got a user who simply doesn’t know how to be one. Maybe you’re dealing with someone who doesn’t have the tiniest clue about the equipment they’re using or about how to perform a certain task correctly—in other words, the problem may be due to something known as operator error (OE). Here’s a short list of the most common types of OEs and their associated acronyms:

• Equipment exceeds operator capability (EEOC)
• Problem exists between chair and keyboard (PEBCAK)
• ID Ten T error (an ID10T)

A word of caution here, though—assuming that all your problems are user related can quickly make an ID10T error out of you.

Although it can be really tempting to take the easy way out and blow things off, remember that the network’s well-being and security are ultimately your responsibility. So, before you jump to the operator-error conclusion, ask the user in question to reproduce the problem in your presence, and pay close attention to what they do. Understand that doing this can require a great deal of patience, but it’s worth your time and effort if you can prevent someone who doesn’t know what they’re doing from causing serious harm to pricey devices or leaving a gaping hole in your security. You might even save the help desk crew’s sanity from the relentless calls of a user with the bad habit of flipping off the power switch without following proper shutdown procedures. You just wouldn’t know they always do that if you didn’t see it for yourself, right?

And what about finding out that that pesky user was, in fact, trained really badly by someone and that they aren’t the only one? This is exactly the kind of thing that can turn the best security policy to dust and leave your network and its resources as vulnerable to attack as that goat in Jurassic Park.

The moral here is, always check out the problem thoroughly. If the problem and its solution aren’t immediately clear to you, try the procedure yourself, or ask someone else at another workstation to do so. Don’t just leave the issue unsettled or make the assumption that it is user error or a chance abnormality because that’s exactly what the bad guys out there are hoping you’ll do.

This is only a partial list of super simple stuff. No worries. Rest assured you’ll come up with your own expanded version over time.

Other Important Cable Issues You Need to Know About

They may be basic, but they’re still vital—an understanding of the physical issues that can happen on a network when a user is connected via cable (usually Ethernet) is critical information to have in your troubleshooting repertoire.

Because many of today’s networks still consist of large amounts of copper cable, they suffer from the same physical issues that have plagued networking since the very beginning. Newer technologies and protocols have helped to a degree, but they haven’t made these issues a thing of the past yet. Some physical issues that still affect networks are listed and defined next:

Incorrect Pinout/TX/RX Reverse/Damaged Cable The first things to check when working on cabling are the cable connectors to make sure they haven’t gone bad. After that, look to make sure the wiring is correct on both ends by physically checking the cable pinouts. Important to remember is that if you have two switches, you need a crossover cable where you cross pins 1 and 2 with 3 and 6. On the other hand, if you have a PC going into a switch, you need a straight-through cable where pins 1 and 2 correspondingly connect to pins 1 and 2 on each side—the same with 3 and 6. Finally, make sure the termination pins on both ends are the correct type for the kind of cable you’re using.

Bad Port In some cases, the issue is not the cable but the port into which the cable is connected. On many devices ports have LEDs that can alert you to a bad port. For example, a Cisco router or switch will have an LED for each port and the color of the LED will indicate its current state. In most cases, a lack of any light whatsoever indicates an issue with the port. Loopback plugs can be used to test the functionality of a port. These devices send a signal out and then back in the port to test it.

Transceiver Mismatch Interfaces that send and receive are called transceivers. When a NIC is connected to a port, the two transceivers must have certain settings the same or issues will occur. These settings are the duplex and the speed setting. If the speed settings do not match, there will be no communication. If the duplex settings are incorrect, there may be functionality but the performance will be poor.

Crosstalk Again, looking back to Chapter 3, remember that crosstalk is what happens when there’s signal bleed between two adjacent wires that are carrying a current. Network designers minimize crosstalk inside network cables by twisting the wire pairs together, putting them at a 90-degree angle to each other. The tighter the wires are twisted, the less crosstalk you have, and newer cables like Cat 6 cable really make a difference. But like I said, not completely—crosstalk still exists and affects communications, especially in high-speed networks. This is often caused by using the wrong category of cable or by mismatching the member of one pair with a member of another when terminating a cable.

Near-End/Far-End Crosstalk Near-end crosstalk is a specific type of crosstalk measurement that has to do with the EMI bled from a wire to adjoining wires where the current originates. This particular point has the strongest potential to create crosstalk issues because the crosstalk signal itself degrades as it moves down the wire. If you have a problem with it, it’s probably going to show up in the first part of the wire where it’s connected to a switch or a NIC. Far-end crosstalk is the interference between two pairs of a cable measured at the far end of the cable with respect to the interfering transmitter.

This condition is often caused by improperly terminating a cable. For example, it’s important to maintain the twist right up to the punch-down or crimp connector. In the case of crimp connectors, it’s critical to select the correct grade of connector even though one grade may look identical to another.

Attenuation/Db Loss/Distance Limitation As a signal moves through any medium, the medium itself will degrade the signal—a phenomenon known as attenuation that’s common in all kinds of networks. True, signals traversing fiber-optic cable don’t attenuate as fast as those on copper cable, but they still do eventually. You know that all copper twisted-pair cables have a maximum segment distance of 100 meters before they’ll need to be amplified, or repeated, by a hub or a switch, but single-mode fiber-optic cables can sometimes carry signals for miles before they begin to attenuate (degrade). If you need to go far, use fiber, not copper. Although there is attenuation/Db loss in fiber, it can go much farther distances than copper cabling can before being affected by attenuation.

Latency Latency is the delay typically incurred in the processing of network data. A low-latency network connection is one that generally experiences short delay times, while a high-latency connection generally suffers from long delays. Many security solutions may negatively affect latency. For example, routers take a certain amount of time to process and forward any communication. Configuring additional rules on a router generally increases latency, thereby resulting in longer delays. An organization may decide not to deploy certain security solutions because of the negative effects they will have on network latency.

Auditing is a great example of a security solution that affects latency and performance. When auditing is configured, it records certain actions as they occur. The recording of these actions may affect the latency and performance.

Jitter Jitter occurs when the data flow in a connection is not consistent; that is, it increases and decreases in no discernable pattern. Jitter results from network congestion, timing drift, and route changes. Jitter is especially problematic in real-time communications like IP telephony and videoconferencing.

Collisions A network collision happens when two devices try to communicate on the same physical segment at the same time. Collisions like this were a big problem in the early Ethernet networks, and a tool known as Carrier Sense Multiple Access with Collision Detection (CSMA/CD) was used to detect and respond to them in Ethernet_II. Nowadays, we use switches in place of hubs because they can separate the network into multiple collision domains, learn the Media Access Control (MAC) addresses of the devices attached to them, create a type of permanent virtual circuit between all network devices, and prevent collisions.

Shorts Basically, a short circuit, or short, happens when the current flows through a different path within a circuit than it’s supposed to; in networks, they’re usually caused by some type of physical fault in the cable. You can find shorts with circuit-testing equipment, but because sooner is better when it comes to getting a network back up and running, replacing the ailing cable until it can be fixed (if it can be) is your best option.

Open Impedance Mismatch (echo) Open impedance on cable-testing equipment tells you that the cable or wires connect into another cable and there is an impedance mismatch. When that happens, some of the signal will bounce back in the direction it came from, degrading the strength of the signal, which ultimately causes the link to fail.

Interference/Cable Placement EMI and radio frequency interference (RFI) occur when signals interfere with the normal operation of electronic circuits. Computers happen to be really sensitive to sources of this, such as TV and radio transmitters, which create a specific radio frequency as part of their transmission process. Two other common culprits are two-way radios and cellular phones.

Your only way around this is to use shielded network cables like shielded twisted-pair (STP) and coaxial cable (rare today) or to run EMI/RFI-immune but pricey fiber-optic cable throughout your entire network.

Split Pairs A split pair is a wiring error where two connections that are supposed to be connected using the two wires of a twisted pair are instead connected using two wires from different pairs. Such wiring causes errors in high-rate data lines. If you buy your cables precut, you won’t have this problem.

TX/RX Reverse When connecting from a PC-type device into a switch, for the PC use pins 1 and 2 to transmit and 3 and 6 for receiving a digital signal. This means that the pins must be reversed on the switch, using pins 1 and 2 for receiving and 3 and 6 for transmitting the digital signal. If your connection isn’t working, check the cable end pinouts.

Bent Pins Many of the connectors you will encounter have small pins on the end that must go into specific holes on the interface to which they plug. If these pins get bent, either they won’t go into the correct hole or they won’t go into a hole period. When this occurs, the cable either will not work at all or will not work correctly. Taking care not to bend these fragile pins when working with these cable types will prevent this issue from occurring.

Bottlenecks Bottlenecks are areas of the network where the physical infrastructure is not capable of handling the traffic. In some cases, this is a temporary issue caused by an unusual burst of traffic. In other scenarios, it is a wake-up call to upgrade the infrastructure or reorganize the network to alleviate the bottleneck. The obvious result of a bottleneck is poor performance.

Fiber Cable Issues

Fiber is definitely the best kind of wiring to use for long-distance runs because it has the least attenuation at long distances compared to copper. The bad news is that it’s also the hardest to troubleshoot. Here are some common fiber issues to be aware of.

SFP/GBIC (Cable Mismatch) The small form-factor pluggable (SFP) is a compact, hot-pluggable transceiver used for networking and other types of equipment. It interfaces a network device motherboard for a switch, router, media converter, or similar device to a fiber-optic or copper networking cable. Due to its smaller size, SFP obsolesces the formerly ubiquitous gigabit interface converter (GBIC), so SFP is sometimes referred to as a mini-GBIC. Always make sure you have the right cable for each type of connector type and that they are not mismatched.

Bad SFP/GBIC (Cable or Transceiver) If your link is down, verify that your cable or transceiver hasn’t gone bad. I covered the pricey equipment you need to get this done in Chapter 18. It can provide exact locations the problem has originated.

Wavelength Mismatch One of the more confusing terms used regarding fiber networks is wavelength. Though it sounds very complicated and scientific, it’s actually just the term used to define what we think of as the color of light. Wavelength mismatch occurs when two different fiber transmitters at each end of the cable are using either a longer or shorter wavelength. This means you’ve got to make sure your transmitters match on both ends of the cable.

Fiber Type Mismatch Fiber type mismatches, at each of the transceivers, can cause wavelength issues, massive attenuation, and Db loss.

Dirty Connectors It’s important to verify your connectors to make sure no dirt or dust has corrupted the cable end. You need to polish your cable ends with a soft cloth, but do not look into the cable if the other end is transmitting—it could damage your eyes!

Connector Mismatch Just because it fits doesn’t mean it works. Make sure you have precisely the right connectors for each type of cable end or transceiver.

Bend Radius Limitations Fiber, whether it is made of glass or plastic, can break. You need to make sure you understand the bend radius limitations of each type of fiber you purchase and that you don’t exceed the specifications when installing fiber in your rack.

Distance Limitations The pros of fiber are that it’s completely immune to EMI and RFI, and that it can transmit up to 40 kilometers—about 25 miles! Add some repeater stations and you can go between continents. But all fiber types aren’t created equally. For example, single mode can perform at much greater distances than multi-mode can. And again, make sure you have the right cable for the distance you’ll require to run your fiber!

Unbounded Media Issues (Wireless)

Now let’s say your problem-ridden user is telling you they only use a wireless connection. Well, you can definitely take crosstalk and shorts off the list of suspects, but don’t get excited, because with wireless, you’ve got a whole new bunch of possible Physical layer problems to sort through.

Wireless networks are really convenient for the user but not so much for administrators. They can require a lot more configuration, and understand that with wireless networks, you don’t just get to substitute one set of challenges for another—you pretty much add all those fresh new issues on top of the wired challenges you already have on your plate.

The following list includes some of those new wireless challenges:

Interference Because wireless networks rely on radio waves to transmit signals, they’re more subject to interference, even from other wireless devices like Bluetooth keyboards, mice, or cell phones that are all close in frequency ranges. Any of these—even microwave ovens!—can cause signal bleed that can slow down or prevent wireless communications. Factors like the distance between a client and a wireless access point (WAP) and the stuff between the two can also affect signal strength and even intensify the interference from other signals. So, careful placement of that WAP is a must.

Device Saturation/Bandwidth Saturation Clearly it’s important to design and implement your wireless network correctly. Be sure to understand the number of hosts that will be connecting to each AP that you’ll be installing. If you have too much device saturation on an AP, it will result in low available bandwidth. Just think about when you’re in a hotel and how slow the wireless is. This is directly due to device/bandwidth saturation for each AP. And more APs don’t always solve the problem—you need to design correctly!

Simultaneous Wired/Wireless Connections It’s not unusual to find that a laptop today will have both a wired and wireless connection at the same time. Typically this doesn’t create a problem, but don’t think you get more bandwidth or better results because of it. It’s possible that the configurations can cause a problem, although that’s rare today. For instance, if each provides a DNS server with a different address, it can cause name resolution issues, or even default gateway issues. Most of the time, it just causes confusion in your laptop, which will make it work harder to determine the correct DNS or default gateway address to use. And it’s possible for the laptop to give up and stop communicating completely! Because of this, you need to remind the user to turn off their wireless when they take it into their office and connect it to their dock.

Configurations Mistakes in the configuration of the wireless access point or wireless router or inconsistencies between the settings on the AP and the stations can also be the source of problems. The following list describes some of the main sources of configuration problems.

• Incorrect Encryption/Security Type Mismatch You know that wireless networks can use encryption to secure their communications and that different encryption flavors are used for wireless networks, like Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access 2 (WPA2) with Advanced Encryption Standard (AES). To ensure the tightest security, configure your wireless networks with the highest encryption protocol that both the WAP and the clients can support. Oh, and make sure the AP and its clients are configured with the same type of encryption. This is why it’s a good idea to disable security before troubleshooting client problems, because if the client can connect once you’ve done that, you know you’re dealing with a security configuration error.

  Incorrect, Overlapping, or Mismatched Channels Wireless networks use many different frequencies within the 2.4 GHz or 5 GHz band, and I’ll bet you didn’t know that these frequencies are sometimes combined to provide greater bandwidth for the user. You actually do know about this—has anyone heard of something called a channel? Well, that’s exactly what a channel is, and it’s also the reason some radio stations come in better than others—they have more bandwidth because their channel has more combined frequencies. You also know what happens when the AP and the client aren’t quite matching up. Have you ever hit the scan button on your car’s radio and only kind of gotten a station’s static-ridden broadcast? That’s because the AP (radio station) and the client (your car’s radio) aren’t quite on the same channel. Most of the time, wireless networks use channel 1, 6, or 11, and because clients auto-configure themselves to any channel the AP is broadcasting on, it’s not usually a configuration issue unless someone has forced a client onto an incorrect channel. Also, be sure not to use the same channel on APs within the same area. Overlapping channels cause your signal-to-noise ratio to drop because you’ll get a ton of interference and signal loss!

  Incorrect Frequency/Incompatibilities So, setting the channel sets the frequency or frequencies that wireless devices will use. But some devices, such as an AP running 802.11g/n, allow you to tweak those settings and choose a specific frequency such as 2.4 GHz or 5 GHz. As with any relationship, it works best if things are mutual. So if you do this on one device, you’ve got to configure the same setting on all the devices with which you want to communicate, or they won’t—they’ll argue, and you don’t want that. Incorrect-channel and frequency-setting problems on a client are rare, but if you have multiple APs and they’re in close proximity, you need to make sure they’re on different channels/frequencies to avoid potential interference problems.

  Wrong Passphrase When a passphrase is used as an authentication method, the correct passphrase must be entered when authenticating to the AP or to the controller. When an incorrect passphrase is provided, access will be denied. This is another issue that will impair functionality.

  SSID Mismatch When a wireless device comes up, it scans for service set identifiers (SSIDs) in its immediate area. These can be basic service set identifiers (BSSIDs) that identify an individual access point or extended service set identifiers (ESSIDs) that identify a set of APs. In your own wireless LAN, you clearly want the devices to find the ESSID that you’re broadcasting, which isn’t usually a problem: Your broadcast is closer than the neighbor’s, so it should be stronger—unless you’re in an office building or apartment complex that has lots of different APs assigned to lots of different ESSIDs because they belong to lots of different tenants in the building. This can definitely give you some grief because it’s possible that your neighbor’s ESSID broadcast is stronger than yours, depending on where the clients are in the building. So if a user reports that they’re connected to an AP but still can’t access the resources they need or authenticate to the network, you should verify that they are, in fact, connected to your ESSID and not your neighbor’s. This is very typical in an open security wireless network. You can generally just look at the information tool tip on the wireless software icon to find this out. However, you can easily solve this problem today by making the office SSID the preferred network in the client software.

  Wireless Standard Mismatch As you found out in Chapter 12, “Wireless Networking,” wireless networks have many standards that have evolved over time, like 802.11a, 802.11b, 802.11g, and 802.11n. Standards continue to develop that make wireless networks even faster and more powerful. The catch is that some of these standards are backward compatible and others aren’t. For instance, most devices you buy today can be set to 802.11a/b/g/n, which means they can be used to communicate with other devices of all four standards. So, make sure the standards on the AP match the standards on the client, or that they’re at least backward compatible. It’s either that or tell all your users to buy new cards for their machines. Be sure to understand the throughput, frequency, distance capabilities, and available channels for each standard you use.

  Untested Updates It’s really important to push updates to the APs in your wireless network, but not before you test them. Just like waiting for an update from Microsoft or Apple to become available for weeks or months before you update, you need to wait for the OS or patch updates for your AP. Then, you need to test the updates thoroughly on your bench before pushing them to your live network.

Distance/Signal Strength/Power Levels Location, location, location. You’ve got only two worries with this one: Your clients are either not far enough away or too far from the AP. If your AP doesn’t seem to have enough power to provide a connectivity point for your clients, you can move it closer to them, increase the distance that the AP can transmit by changing the type of antenna it uses, or use multiple APs connected to the same switch or set of switches to solve the problem. If the power level or signal is too strong, and it reaches out into the parking area or farther out to other buildings and businesses, place the AP as close as possible to the center of the area it’s providing service for. And don’t forget to verify that you’ve got the latest security features in place to keep bad guys from authenticating to and using your network.

Latency and Overcapacity When wireless users complain that the network is slow (latency) or that they are losing their connection to applications during a session, it is usually a capacity or distance issue. Remember, 802.11 is a shared medium, and as more users connect, all user throughput goes down. If this becomes a constant problem as opposed to the occasional issue where 20 guys with laptops gather for a meeting every six months in the conference room, it may be time to consider placing a second AP in the area. When you do this, place the second AP on a different non-overlapping channel from the first and make sure the second AP uses the same SSID as the first. In the 2.4 GHz frequency (802.11b and 802.11g), the three non-overlapping channels are 1, 6, and 11. Now the traffic can be divided between them and users will get better performance. It is also worth noting that when clients move away from the AP, the data rate drops until at some point it is insufficient to maintain the connection.

Bounce For a wireless network spanning large geographical distances, you can install repeaters and reflectors to bounce a signal and boost it to cover about a mile. This can be a good thing, but if you don’t tightly control signal bounce, you could end up with a much bigger network than you wanted. To determine exactly how far and wide the signal will bounce, make sure you conduct a thorough wireless site survey. However, bounce can also refer to multipath issues, where the signal reflects off objects and arrives at the client degraded because it is arriving out of phase. The solution is pretty simple. APs use two antennas, both of which sample the signal and use the strongest signal and ignore the out-of-phase signal. However, 802.11n takes advantage of multipath and can combine the out-of-phase signals to increase the distance hosts can be from the AP.

Incorrect Antenna Type or Switch Placement Most of the time, the best place to put an AP and/or its antenna is as close to the center of your wireless network as possible. But you can position some antennas a distance from the AP and connect to it with a cable—a method used for a lot of the outdoor installations around today. If you want to use multiple APs, you’ve also got to be a little more sophisticated about deciding where to put them all; you can use third-party tools like the packet sniffers Wireshark and AirMagnet on a laptop to survey the site and establish how far your APs are actually transmitting. You can also hire a consultant to do this for you—there are many companies that specialize in assisting organizations with their wireless networks and the placement of antennas and APs. This is important because poor placement can lead to interference and poor performance, or even no performance at all.

Environmental Factors It’s vital to understand your environmental factors when designing and deploying your wireless network. Do you have concrete walls, window film, or metal studs in the walls? All of these will cause a degradation of Db or power level and result in connectivity issues. Again—plan your wireless network carefully!

Reflection When a wave hits a smooth object that is larger than the wave itself, depending on the media the wave may bounce in another direction. This behavior is categorized as reflection.

Reflection can be the cause of serious performance problems in a WLAN. As a wave radiates from an antenna, it broadens and disperses. If portions of this wave are reflected, new wave fronts will appear from the reflection points. If these multiple waves all reach the receiver, the multiple reflected signals cause an effect called multipath.

Multipath can degrade the strength and quality of the received signal or even cause data corruption or canceled signals. APs mitigate this behavior by using multiple antennas and constantly sampling the signal to avoid a degraded signal.

Refraction Refraction is the bending of an RF signal as it passes through a medium with a different density, thus causing the direction of the wave to change. RF refraction most commonly occurs as a result of atmospheric conditions.

In long-distance outdoor wireless bridge links, refraction can be an issue. An RF signal may also refract through certain types of glass and other materials that are found in an indoor environment.

Absorption Some materials will absorb a signal and reduce its strength. While there is not much that can be done about this, this behavior should be noted during a site survey, and measures such as additional APs or additional antenna types may be called for.

Signal-to-Noise Ratio Signal-to-noise ratio (SNR) is the difference in decibels between the received signal and the background noise level (noise floor).

If the amplitude of the noise floor is too close to the amplitude of the received signal, data corruption will occur and result in Layer 2 retransmissions, negatively affecting both throughput and latency. An SNR of 25 dB or greater is considered good signal quality, and an SNR of 10 dB or lower is considered very poor signal quality.

Now that you know all about the possible physical network horrors that can befall you on a typical network, it’s a good time for you to memorize the troubleshooting steps that you’ve got to know to ace the CompTIA Network+ exam.

Gather Information by Questioning Users

A good way to start is by asking the user the following questions:

• Exactly which part of the Internet can’t you access? A particular website? A certain address? A type of website? None of it at all?
• Can you use your web browser?
• Is it possible to duplicate the problem?
• If the hitch has to do with an internal server to the company, ask the user if they can ping the server and talk them through doing that.
• Ask the user to try to telnet or FTP to an internal server to verify local network connectivity; if they don’t know how, talk them through it.
• If there are multiple complaints of problems occurring, look for the big stuff first, then isolate and approach each problem individually.

Here’s another really common trouble ticket that just happens to build on the last scenario: Now let’s say you’ve got a user who’s called you at the help desk. By asking the previous questions, you found out that this user can’t access the corporate intranet or get out to any sites on the Internet. You also established that the user can use their web browser to access the corporate FTP site, but only by IP address, not by the FTP server name. This information tells you two important things: that you can rule out the host and the web browser (application) as the source of the problem and that the physical network is working.

Duplicate the Problem, If Possible

When a user reports an issue, you should attempt to duplicate the issue. When this is possible, it will aid in discovering the problem. When you cannot duplicate the issue, your challenge becomes harder because you are dealing with an intermittent problem. These issues are difficult to solve because they don’t happen consistently.

Determine If Anything Has Changed

Moving right along, if you can reproduce the problem, your next step is to verify what has changed and how. Drawing on your knowledge of networking, you ask yourself and your user questions like these:

Were you ever able to do this? If not, then maybe it just isn’t something the hardware or software is designed to do. You should then tell the user exactly that, as well as advise them that they may need additional hardware or software to pull off what they’re trying do.

If so, when did you become unable to do it? If, once upon a time, the computer was able to do the job and then suddenly could not, whatever conditions surrounded and were involved in this turn of events become extremely important. You have a really good shot at unearthing the root of the problem if you know what happened right before things changed. Just know that there’s a high level of probability that the cause of the problem is directly related to the conditions surrounding the change when it occurred.

Has anything changed since the last time you could do this? This question can lead you right to the problem’s cause. Seriously—the thing that changed right before the problem began happening is almost always what caused it. It’s so important that if you ask it and your user tells you, “Nothing changed…it just happened,” you should rephrase the question and say something like, “Did anyone add anything to your computer?” or “Are you doing anything differently from the way you usually do it?”

Were any error messages displayed? These are basically arrows that point directly at the problem’s origin; error messages are designed by programmers for the purpose of pointing them to exactly what it is that isn’t working properly in computer systems. Sometimes error messages are crystal clear, like Disk Full, or they can be cryptically annoying little puzzles in and of themselves. If you pulled the short straw and got the latter variety, it’s probably best to hit the software or hardware vendor’s support site, where you can usually score a translation from the “programmerese” in which the error message is written into plain English so you can get back to solving your riddle.

Are other people experiencing this problem? You’ve got to ask this one because the answer will definitely help you target the cause of the problem. First, try to duplicate the problem from your own workstation because if you can’t, it’s likely that the issue is related to only one user or group of users—possibly their workstations. (A solid hint that this is the case is if you’re being inundated with calls from a bunch of people from the same workgroup.)

Is the problem always the same? It’s good to know that when problems crop up, they’re almost always the same each time they occur. But their symptoms can change slightly as the conditions surrounding them change. A related question would be, “If you do x, does the problem get better or worse?” For example, ask a user, “If you use a different file, does the problem get better or worse?” If the symptoms lighten up, it’s an indication that the problem is related to the original file that’s being used. It’s important to try to duplicate the problem to find the source of the issue as soon as possible!

Understand that these are just a few of the questions you can use to get to the source of a problem.

Okay, so let’s get back to our sample scenario. So far, you’ve determined that the problem is unique to one user, which tells you that the problem is specific to this one host. Confirming that is the fact that you haven’t received any other calls from other users on the network.

And when watching the user attempt to reproduce the problem, you note that they’re typing the address correctly. Plus, you’ve got an error message that leads you to believe that the problem has something to with Domain Name Service (DNS) lookups on the user’s host. Time to go deeper…

Identify Symptoms

I probably don’t need to tell you that computers and networks can be really fickle—they can hum along fine for months, suddenly crash, and then continue to work fine again without ever seizing in that way again. That’s why it’s so important to be able to reproduce the problem and identify the affected area to narrow things down so you can cut to the chase and fix the issue fast. This really helps—when something isn’t working, try it again, and write down exactly what is and is not happening.

Most users’ knee-jerk reaction is to straight up call the help desk the minute they have a problem. This is not only annoying but also inefficient, because you’re going to ask them exactly what they were doing when the problem occurred and most users have no idea what they were doing with the computer at the time because they were focused on doing their jobs instead. This is why if you train users to reproduce the problem and jot down some notes about it before calling you, they’ll be much better prepared to give you the information you need to start troubleshooting it and help them.

So with that, here we go. The problem you’ve identified results in coughing out an error message to your user when they try to access the corporate intranet. It looks like Figure 19.1.

And when this user tries to ping the server using the server’s hierarchical web name, it fails, too (see Figure 19.2).

You’re going to respond by checking to see whether the server is up by pinging the server by its IP address (see Figure 19.3).

Nice—that worked, so the server is up, but you could still have a server problem. Just because you can ping a host, it doesn’t mean that host is 100 percent up and running, but in this case, it’s a good start.

And you’re in luck because you’ve been able to re-create this problem from this user’s host machine. By doing that, you now know that the URL name is not being resolved from Internet Explorer, and you can’t ping it by the name either. But you can ping the server IP address from your limping host, and when you try this same connection to the internal .lammle.com server from another host nearby, it works fine, meaning the server is working fine. So, you’ve succeeded in isolating the problem to this specific host—yes!

It is a huge advantage if you can watch the user try to reproduce the problem themselves because then you know for sure whether the user is performing the operation correctly. It’s a really bad idea to assume the user is typing in what they say they are.

Approach Multiple Problems Individually

You should never mix possible solutions when troubleshooting. When multiple changes are made, interactions can occur that muddy the results. Always attack one issue at a time and make only a single change at a time. When a change does not have a beneficial effect, reverse the change before making another change.

Great—now you’ve nailed down the problem. This leads us to step 2

Question the Obvious

The probable causes that you’ve got to thoroughly understand to meet the Network+ objectives are as follows:

• Port speed
• Port duplex mismatch
• Mismatched MTU
• Incorrect virtual local area network (VLAN)
• Incorrect IP address/duplicate IP address
• Wrong gateway
• Wrong DNS
• Wrong subnet mask
• Incorrect interface/interface misconfiguration
• Duplicate MAC addresses
• Expired IP address
• Rogue DHCP server
• Untrusted SSL certificate
• Incorrect time
• Exhausted DHCP scope
• Blocked TCP/UDP ports
• Incorrect host-based firewall settings
• Incorrect ACL settings
• Unresponsive service

Let’s talk about these logical issues, which can cause an abundance of network problems. Most of these happen because a device has been improperly configured.

Port Speed Because networks have been evolving for many years, there are various levels of speed and sophistication mixed into them—often within the same network. Most of the newest NICs can be used at 10 Mbps, 100 Mbps, and 1,000 Mbps. Most switches can support at least 10 Mbps and 100 Mbps, and an increasing number of switches can also support 1,000 Mbps. Plus, many switches can also autosense the speed of the NIC that’s connected and use different speeds on various ports. As long as the switches are allowed to autosense the port speed, it’s rare to have a problem develop that results in a complete lack of communication. But if you decide to set the port speed manually, make positively sure to set the same speed on both sides of a link.

Port Duplex Mismatch There are generally three duplex settings on each port of a network switch: full, half, and auto. In order for two devices to connect effectively, the duplex setting has to match on both sides of the connection. If one side of a connection is set to full and the other is set to half, they’re mismatched. More elusively, if both sides are set to auto but the devices are different, you can also end up with a mismatch because the device on one side defaults to full and the other one defaults to half.

Duplex mismatches can cause lots of network and interface errors, and even the lack of a network connection. This is partially because setting the interfaces to full duplex disables the CSMA/CD protocol. This is definitely not a problem in a network that has no hubs (and therefore no shared segments in which there could be collisions), but it can make things really ugly in a network where hubs are still being used. This means the settings you choose are based on the type of devices you have populating your network. If you have all switches and no hubs, feel free to set all interfaces to full duplex, but if you’ve got hubs in the mix, you have shared networks, so you’re forced to keep the settings at half duplex. With all new switches produced today, leaving the speed and duplex setting to auto (the default on both switches and hosts) is the recommended way to go.

Mismatched MTU Ethernet LANs enforce what is called a maximum transmission unit (MTU). This is the largest size packet that is allowed across a segment. In most cases, this is 1,500 bytes. Left alone this is usually not a problem, but it is possible to set the MTU on a router interface, which means it is possible for a mismatch to be present between two router interfaces. This can cause problems with communications between the routers, resulting in the link failing to pass traffic. To check the MTU on an interface, execute the command show interface.

Incorrect VLAN Switches can have multiple VLANs each, and they can be connected to other switches using trunk links. As you now know, VLANs are often used to represent departments or the occupations of a group of users. This makes the configurations of security policies and network access lists much easier to manage and control. On the other hand, if a port is accidentally assigned to the wrong VLAN in a switch, it’s as if that client was magically transported to another place in the network. If that happens, the security policies that should apply to the client won’t anymore, and other policies will be applied to the client that never should have been. The correct VLAN port assignment of a client is as important as air; when I’m troubleshooting a single-host problem, this is the first place I look.

It’s pretty easy to tell if you have a port configured with a wrong VLAN assignment. If this is the case, it won’t be long before you’ll get a call from some user screaming something at you that makes the building shake, like, “I can get to the Internet but I can’t get to the Sales server, and I’m about to lose a huge sale. DO SOMETHING!” When you check the switch, you will invariably see that this user’s port has a membership in another VLAN like Marketing, which has no access to the Sales server.

Incorrect IP Address/Duplicate IP Address The most common addressing protocol in use today is IPv4, which provides a unique IP address for each host on a network. Client computers usually get their addresses from Dynamic Host Configuration Protocol (DHCP) servers. But sometimes, especially in smaller networks, IP addresses for servers and router interfaces are statically assigned by the network’s administrator. An incorrect or duplicate IP address on a client will keep that client from being able to communicate and may even cause a conflict with another client on the network, and a bad address on a server or router interface can be disastrous and affect a multitude of users. This is exactly why you need to be super careful to set up DHCP servers correctly and also when configuring the static IP addresses assigned to servers and router interfaces.

Wrong Gateway A gateway, sometimes called a default gateway or an IP default gateway, is a router interface’s address that’s configured to forward traffic with a destination IP address that’s not in the same subnet as the device itself. Let me clarify that one for you: If a device compares where a packet wants to go with the network it’s currently on and finds that the packet needs to go to a remote network, the device will send that packet to the gateway to be forwarded to the remote network. Because every device needs a valid gateway to obtain communication outside its own network, it’s going to require some careful planning when considering the gateway configuration of devices in your network.

If you’re configuring a static IP address and default gateway, you need to verify the router’s address. Not doing so is a really common “wrong gateway” problem that I see all the time.

Wrong DNS DNS servers are used by networks and their clients to resolve a computer’s hostname to its IP addresses and to enable clients to find the server they need to provide the resources they require, like a domain controller during the login and authentication process. Most of the time, DNS addresses are automatically configured by a DHCP server, but sometimes these addresses are statically configured instead. Because lots of applications rely on hostname resolution, a botched DNS configuration usually causes a computer’s network applications to fail just like the user’s applications in our example scenario.

If you can ping a host using its IP address but not its name, you probably have some type of name-resolution issue. It’s probably lurking somewhere within a DNS configuration.

Wrong Subnet Mask When network devices look at an IP address configuration, they see a combination of the IP address and the subnet mask. The device uses the subnet mask to establish which part of the address represents the network address and which part represents the host address. So clearly, a subnet mask that is configured wrong has the same nasty effect as a wrong IP address configuration does on communications. Again, a subnet mask is generally configured by the DHCP server; if you’re going to enter it manually, make sure the subnet mask is tight or you’ll end up tangling with the fallout caused by the entire address’s misconfiguration.

Incorrect Interface/Interface Misconfiguration If a host is plugged into a misconfigured switch port, or if it’s plugged into the wrong switch port that’s configured for the wrong VLAN, the host won’t function correctly. Make sure the speed, duplex, and correct Ethernet cable is used. Get any of that wrong and either you’ll get interface errors on the host and switch port or, worse, things just won’t work at all!

Duplicate MAC Addresses There should never be duplicate MAC addresses in your environment. Each interface vendor is issued an organizationally unique identifier (OUI), which will match on all interfaces produced by that vendor, and then the vendor is responsible for ensuring unique MAC addresses. That means duplicate MAC addresses usually indicate a MAC spoofing attack, in which some malicious individual changes their MAC address, which can be done quite easily in the properties of the NIC.

Expired IP Address In almost all cases, when DHCP is used to allocate IP configurations to devices, the configuration is supplied to the DHCP client is on a temporary basis. The lease period is configurable, and when the lease period and a grace period transpire, the lease is expired. The effect of an expired lease is the next time that client computer starts, it must enter the initialization state and obtain new TCP/IP configuration information from a DHCP server. There is nothing, however, to prevent the client from obtaining a new lease for the same IP address.

Rogue DHCP Server Dynamic Host Configuration Protocol (DHCP) is used to automate the process of assigning IP configurations to hosts. When configured properly, it reduces administrative overload, reduces the human error inherent in manual assignment, and enhances device mobility. But it introduces a vulnerability that when leveraged by a malicious individual can result in an inability of hosts to communicate (constituting a DoS attack) and peer-to-peer attacks.

When an illegitimate DHCP server (called a rogue DHCP server) is introduced to the network, unsuspecting hosts may accept DHCP Offer packets from the illegitimate DHCP server rather than the legitimate DHCP server. When this occurs, the rogue DHCP server will not only issue the host an incorrect IP address, subnet mask, and default gateway address (which makes a peer-to-peer attack possible), it can also issue an incorrect DNS server address, which will lead to the host relying on the attacker’s DNS server for the IP addresses of websites (such as major banks) that lead to phishing attacks. An example of how this can occur is shown in Figure 19.4.

In Figure 19.4, after receiving an incorrect IP address, subnet mask, default gateway, and DNS server address from the rogue DHCP server, the DHCP client uses the attacker’s DNS server to obtain the IP address of his bank. This leads the client to unwittingly connect to the attacker’s copy of the bank’s website. When the client enters his credentials to log in, the attacker now has the client’s bank credentials and can proceed to empty out his account.

Untrusted SSL Certificate Reception of an untrusted SSL certificate error message can be for several reasons. In Figure 19.5, the possible reasons for the warning message are shown. The first reason, “The Security certificate presented by this website was not issued by a trusted certificate authority,” means the CA that issued the certificate is not trusted by the local machine. This will occur if the certificate of the CA that issued the certificate is not found in the Trusted Root Certification Authorities Folder on the local machine.

The second reason this might occur is that the certificate is not valid. It may be that the certificate was presented before the validity period begins, or it may have expired, meaning the validity period is over.

The third reason is that the name on the certificate does not match the name listed on the certificate.

Incorrect Time Incorrect time on a device can be the cause of several issues. First, in a Windows environment using Active Directory, a clock skew of more than 5 minutes between a client and server will prevent communication between the two.

Second, when certificates are in use, proper time synchronization is critical for successful operation.

Finally, when system logs are sent to a central server such as a Syslog server, proper time synchronization is critical to understand the order of events.

Exhausted DHCP Scope When a DHCP server is implemented, it is configured with a limited number of IP addresses. When the IP addresses in a scope are exhausted, any new DHCP clients will be unable to obtain an IP address and will be unable to function on the network.

DHCP servers can be set up to provide backup to another DHCP server for a scope. When this is done, it is important to ensure that while the two DHCP servers service the same scope, they do not have any duplicate IP addresses.

Blocked TCP/UDP Ports When the ports used by common services and applications are blocked, either on the network firewall or on the personal firewall of a device, it will be impossible to make use of the service or application. One easy way to verify the open ports on a device is to execute the netstat command. An example of the output is shown in Figure 19.6.

Incorrect Host-Based Firewall Settings As you saw in the explanation of blocked TCP/UDP ports, incorrect host-based firewall settings can either prevent transmissions or allow unwanted communications. Neither of these outcomes is desirable. One of the best ways to ensure that firewall settings are consistent and correct all the time is to control these settings with a group policy. When you do this, the settings will be checked and reset at every policy refresh interval.

Incorrect ACL Settings Access control lists are used to control which traffic types can enter and exit ports on the router. When mistakes are made either in the construction of the ACLs or in their application, many devices may be affected. The creation and application of these tools should only be done by those who have been trained in their syntax and in the logic ACLs use in their operation.

Unresponsive Service Services can fail for several reasons. Many services depend on other services for their operation. Therefore, the failure of one service sometimes causes a domino effect, taking down other services that depend on it. You can use the Services applet in Control Panel to identify these dependencies as well as start and stop services. To identify the services upon which a particular service depends, use the Dependencies tab on the Services applet, as shown in Figure 19.7.

In Figure 19.7, the spooler service is selected and the Dependencies tab is displayed. Here we see that the spooler service depends on the HTTP and the RPC services. Therefore, if the spooler service will not start, we may need to restart one of these two services first.

With all that in mind, let’s move on with our troubleshooting steps.

Consider Multiple Approaches

There are two standard approaches that you can use to establish a theory of probable cause. Let’s take a look at them next.

Top-to-Bottom/Bottom-to-Top OSI Model As its name implies, when you apply a top-down approach to troubleshooting a networking problem, you start with the user application and work your way down the layers of the OSI model. If a layer is not in good working condition, you inspect the layer below it. When you know that the current layer is not in working condition and you discover that a lower layer works, you can conclude that the problem is within the layer above the lower working layer. Once you’ve determined which layer is the lowest layer with problems, you can begin identifying the cause of them from within that layer.

The bottom-up approach to troubleshooting a networking problem starts with the physical components of the network and works its way up the layers of the OSI model. If you conclude that all the elements associated with a particular layer are in good working order, move on to inspect the elements associated with the next layer up until the cause(s) of the problem is/are identified. The downside to the bottom-up approach is that it requires you to check every device, interface, and so on. In other words, regardless of the nature of the problem, the bottom-up approach starts with an exhaustive check of all the elements of each layer, starting with the physical layer and working its way up from there.

Divide and Conquer Unlike when opting for the top-down and bottom-up troubleshooting strategies, the divide-and-conquer approach to network troubleshooting doesn’t always begin the investigation at a particular OSI layer. When using the divide-and-conquer approach, you select a layer, test its health, and based on the results, you can move up or down through the model from the layer you began scrutinizing.