In most environments your desktop Operating System will probably be Windows so it’s useful to know the inbuilt network troubleshooting tools.
A summary of the commands in this post are:
In the past I have had to investigate wireless channel information on corporate SOE computers that did not have any useful wireless tools such as inSSIDer or Netstumbler installed. After some research I found out you can use the inbuilt windows netsh command to display information about wireless networks that the client can see.
This post is about extending your OSPF routing domain through a VRF in a MPLS backbone. If you are unfamiliar with the MPLS side of things check the previous post out. This post only focuses on the PE/CE side of things, it assumes that a working MPLS backbone has been set up.
Then you have the choice of if you plan on using the MPLS link as a primary link or as a backup.
Here is a step by step example of how to set up a very simple MPLS-VPN. Like last time I am doing this entirely in GNS3 using 2691s running 12.4(25d).
Fault finding is an incredibly subjective topic, I can’t think of the perfect fault finding process but there are a number of hints and best practices that a network engineer will pick up over time. From my recent TSHOOT studies, Cisco defines the fault finding process as:
- Define the Problem
- Gather Information
- Analyse Information
- Eliminate Possible Problem Causes
- Formulate a Hypothesis
- Test Hypothesis
- Solve the Problem
This is a good position to start discussing my thoughts about fault finding issues in a network.