I wanted to write a quick post to brain wash myself with right before I walk into the exam room tomorrow to Pass TSHOOT, as this theory has a very good chance of being on the exam in some format, and I have a habit of forgetting things I can’t lab.
So to cover these topics quick and concise!
The 8 warning levels, mnemonic to remember them, and how to identify them!
You can identify a console messages warning level by the # contained within it:
*Mar 1 00:26:28.961: %CDP-4-NATIVE_VLAN_MISMATCH:
Warning level 4, this means when it is actually the 5th level of warning, because the warnings are numbered 0 – 8 and go in this order:
0 – Emergency – Every
1 – Alert – Animal
2 – Critical – Can
3 – Error – Easily
4 – Warning – Walk
5 – Notification – Near
6 – Informational – Indias
7 – Debugging – Dunes
Every Animal Can Easily Walk Near Indias Dunes!
So the CDP console message seen indicates it is a Walk (Warning) level notification!
Once you have the Mnemonic down, just like Please Do Not Throw Sausage Pizza Away, its very easy to map the actual layers / levels along with the phrase – Your welcome! 🙂
Troubleshooting Methods you will be asked about, and then the rest of them
There are troubleshooting methods that should be actually used, then there are other ones that can be used but are not a best practice approach.
First the well known methods:
Bottom Up Troubleshooting
Starting at Layer 1 and moving up, confirmed cables are plugged in and the correct VLANs are in use (and configured), this would be appropriate for a situation such as a PC not getting a DHCP Address.
Top Down Troubleshooting
Starting at Layer 7 and working your way down the OSI model from the Application layer, this would be used if a user is having trouble getting a specific webpage to load, or if the problem report revolves around a specific application not working
Divide and Conquer Troubleshooting
Pictured at the top of this post, this starts at the Network Layer 3 via ping to an IP.
This is also used in “Follow the Path” method of troubleshooting, as if PC1 cannot reach the Web Server, I will generally go backwards from the Webserver to see where PC1 can get ping replies from.
Note unlike on Cisco IOS, windows ping response will tell you which device IP is sending the “Unreachable” response if the output is not just “…..” and this can save you Following the Path, as you can jump right to the IP / Device sending the “Unreachable” response!
Its difficult to say exactly where this is deployed because its so universal, but if you cannot reach a device say by a management protocol such as SSH or Telnet, my first step is to ping the IP I am trying to reach to see if it is even alive.
Follow the Path troubleshooting
As mentioned this is generally done by pinging device to device, this necessarily mean checking each device in the path for issues, however it CAN mean that.
For example if RSPAN is being used across 8 switches, but the traffic from the “Source” port is not making it to the final “Destination” interface 8 switches later, you will need to jump on every switch in the data path to verify there is a remote-span vlan configured properly to get that traffic from Point A all the way to Point B 8 switches away!
Comparing the Configuration troubleshooting
This method is as it sounds, putting two configurations side by side, and finding the difference in them to find the issue between them.
Uses for this method is for Redundant Devices not working (any FHRP failing), if there is an issue at the Distribution Layer 3 switches in the Boson exam sim, while going through TSHOOT practice exam sims I would often put two CLI windows next to each other to compare the configurations to make sure they are they same (especially authentication).
This is also helpful if your just not familiar with a type of configuration, for example IPv6, as the entire Topology won’t be misconfigured (I don’t expect) as the TSHOOT has in training materials been described as mainly diagnosing but not configuring issues to fix, so some segments of the network should be configured correctly.
So I’ve admittedly used this to understand Topology configs for IPv6 / OSPFv3, Frame-Relay working connection configurations, etc.
Component Swap troubleshooting
If there is a commonality between a group of users, like everyone connected to a single switch (or at least sounds like a commonality to a single device), then the Component Swap troubleshooting method may be what is needed.
Shoot from the Hip troubleshooting
This is basically looking at a problem report, gathering minimal information, throwing a random fix at the problem report to see if it resolves the issue.
This is what you do when you don’t have a good methodology, which outside of the exam room is maybe ok if you feel you are familiar with a particular issue type, but on TSHOOT exam day there is literally a clock ticking down so methodically troubleshooting is going to be key to weeding out the correct answer as quickly as possible.
The two different kinds of network maintenance
- Structured Tasks – Planned, proactive maintenance
- Interrupt-Driven Tasks – Maintenance done as a fix to an issue unexpectedly, such as upgrading firmware to fix an issue on a device
That’s it, just these two, remember them!
The 3 well known maintenance models to absolutely know for exam day!
- FCAPS (Fault management, Configuration management, Accounting management, Performance management, and Security Management) – Defined by the International Organization for Standardization (ISO), which you might think should be “IOS” for the acronym but “ISO” is the correct acronym for this model
- ITIL (IT Infrastructure Library) – Defines best practice recommendations driven to meet an organizations IT business management goals
- Cisco Lifecycle Services (PPDIOO) – Defines the “life” of a Cisco device in the network in phases including: Prepare / Plan / Design / Implement / Operate / Optimize (Hence the acronym PPDIOO)
The FCAPS model is robust maintenance model to cover all bases of network operation, from auditing phone billing to certain departments (Accounting) to setting up QoS (Performance), along with updating network device Firmware versions regularly to mitigate possible bugs / security threats (Configuration / Security).
The ITIL model is not a one-size-fits-all model in the way that what I define as my companies needs will probably not be the same as your companies needs, because it is defined specifically by an organizations business goals, which drives the how the Network Management is performed, maintained, troubleshot, and documented.
Cisco’s Lifecycle Services is a very straight forward deployment strategy that begins before a network device is even purchased within the plan and design phases, which then leads to network device implementation and finally optimization or fine tuning of a device once in production to meet the companies needs.
That is it for my posts before TSHOOT exam attempt #1 !!!
For full explanations to above discussion, links are here for Maintenance and here for Troubleshooting for exam day!
I am going to force myself to stop studying for the night, hopefully will be posting a picture of a Pass grade tomorrow to complete my CCNP Grind! 🙂
The DEVNET GRIND! 