{"id":825,"date":"2012-07-25T23:39:15","date_gmt":"2012-07-25T23:39:15","guid":{"rendered":"http:\/\/microsoftgeek.com\/?p=825"},"modified":"2018-09-06T23:00:52","modified_gmt":"2018-09-06T23:00:52","slug":"router-troubleshooting-primer","status":"publish","type":"post","link":"https:\/\/microsoftgeek.com\/?p=825","title":{"rendered":"Router Troubleshooting Primer"},"content":{"rendered":"

In this article we will take a look at the proper steps to troubleshooting routing problems.<\/p>\n

Although this methodology and approach can be used in just about any troubleshooting scenario, we will focus our exercise on routing. A router is a device that determines the path from a source to a destination. A router is the default gateway for a LAN, the exit point from the LAN to the WAN. The router (or gateway) is what connects more than one network segment together, whether it be two LANs, two separate WANs and so on. A router will (if programmed correctly) know the topology of a network so that if adjacent routers go down (or the lines that attach to them such as DSL, T1 and so on do), the router will be able to find a new path to send the destination data. This is meant to reconverge the network so that data transmissions can continue. To know the topology, a router keeps a table of the routes it has been programmed to know, or it has learned from a neighboring router. Routers create or maintain a table of the available routes and use this information to determine the best route for a given data packet. In this article we will look at what could go wrong and cause instability in your environment, or just outages in general.<\/p>\n

Troubleshooting 101<\/h2>\n

When working in a networked environment, it\u2019s common to have to troubleshoot problems often and quickly. Not only do problems come up often, but they are normally complex, require a lot of abstract thought, involved multiple parties and can be downright confusing. The following flow chart is a quick way to visualize all the steps involved in troubleshooting just about anything:<\/p>\n\n\n\n
\"\"<\/td>\nFirst you want to establish a baseline of normal operation. If you do not know what your router operates like normally, how will you know if it has a problem?<\/p>\n

Next, you want to document what the symptoms are and attempt to define what the problem is. If you have a runny nose, a cough and aches, you may have the flu.
\nMake sure you gather all the facts based on the defined problem.<\/p>\n

In this section you want to consider your possibilities for defining what the problem is. If it\u2019s the Flu, then we have to attack it with rest and medication.<\/p>\n

Make the plan, have a fallback plan in case the main plan fails.<\/p>\n

Test all your plans, see if they work.<\/p>\n

After the test, observe to see if the results show that the problem was resolved\u2026<\/p>\n

Here is where you have choices. If the problem has been solved, then great. If not, then you will want to go back to the step where you started to consider the possibilities. This will allow you to test until resolved.<\/p>\n

Always document the solution to an issue.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Now that you have a general understanding on how to tackle an issue, let\u2019s look at what could happen with a router. Let\u2019s look at how to gather some facts.<\/p>\n

Gather your Facts<\/h2>\n

When gathering facts, consider using some of these pointers when trying to figure out what the problem is, the pointers listed could help you isolate and determine what a possible problem could be:<\/p>\n