Tags: ccna, CCNA Simulator, Kaplan IT CCNA simulator
At Transcender, we sometimes get customer emails with a subject line that resembles the title of this blog post. These emails come from longtime customers who want to know what happened to the simulation items that “used to be” in our CCNA practice tests. Those items haven’t appeared in our products for some time, and we’ve blogged about this topic before, but since we’ve just released updates to our CCNA products, I thought this was the perfect time to revisit the topic.
First, you need to know that there are simulation items in Cisco’s CCNA exam(s). Let me say that again a little louder:
There are simulation items in the Cisco CCNA exams!
You will definitely have to know how to use the command line to get configuration information from a device and configure devices. But before I discuss the kinds of simulation items we include in our Transcender practice test, let’s define what is and is NOT a simulation item, and discuss how they show up on the live exam. Here’s a complete rundown of the item types you are told you may see in the CCNA exams (as per the CCNA web site): Continue Reading Hey! Who moved my CCNA simulations?…
Tags: jam sessions, TechEd
A number of years ago, I attended Microsoft TechEd in Boston and noticed something on the agenda called “Jam Sessions.” Now, being a former professional musician, this caught my eye, but I said to myself , “What would an actual jam session be doing on the agenda at Tech*Ed?” I figured Nah, it must mean some sort of Rock Band game thing.
Nevertheless, Josh, George, and I set out that night to see what it was all about. Boy, were we in for a surprise. Microsoft had rented out an entire nightclub in Boston, provided top-notch sound and light equipment, and set up instruments of all types on the stage. What followed was an entire night of techies climbing onstage in random pairings playing tunes.
As soon as we saw what was going on, my buddies started needling me to get up and play, but I was a bit apprehensive because I have too often been drawn into “jamming” with the guy who professed to play drums in high school and the singer who made William Hung sound good, and I tell you, it’s not fun to be trapped onstage with these guys. But to my amazement, the people on stage could actually play! There was a few times when the guitar player zigged while the bass player zagged, but no more than I’ve seen with professionals jamming (which can also be pretty horrible, especially if adult beverages are involved). Anyway, I ended up playing and having a great time. So next time around when I saw Jam Sessions on the agenda at Tech*Ed in L.A., I immediately said, “I’m there!” Having an idea of how it worked, I had an even better time because I came prepared with a few songs everyone knows, so it went much better. (Below is a horrible shot taken from a cell phone at L.A.)
So where I’m going with all of this? Consider this post a call to all Tech*Head musicians. The Jam Session will be at The Tabernacle (which is an awesome venue if you’re not familiar) on Tuesday night from 9PM to 1AM. If you’re going to Tech*Ed, comment to this post or contact me through this blog and let’s arrange to play something together on Tuesday night! There’s also this musicians-seeking-musicians thread on the Tech*Ed Discussions page: http://northamerica.msteched.com/discussion/thread/?threadid=7b367434-f049-e011-86d4-001ec953730b&fbid=KQaT2VB9GDy
Oh, by the way, it would help for you to know that I play bass. And no, I DON’T play bass like it’s a lead guitar, I play it like it’s meant to played. (Ok, I’m off my soapbox, just wanted that off my chest.)
Let’s have some rock n’ roll at Tech*Ed!
Tags: Hands-On Labs, TechEd
In 2009, during Tech*Ed in Los Angeles, I helped Microsoft out in the Hands-on Lab area. If you’re unfamiliar with the concept, HOL is an area set up with workstations using virtual machines, loaded with labs to let you try out all the new and upcoming technologies. There are also MCTs, like myself, present to help if you have any questions about the labs.
The Hands-on Labs have proven to be one of the more popular destinations at Tech*Ed. Most of the sessions are very good, but let’s face it, at some point you don’t want to see any more PowerPoint presentations — you’re ready to actually get your hands dirty. Well, you can do that in the Hands-on Labs — there are over 250 scheduled for next week.
Apparently all is now forgiven between Microsoft and myself concerning that little incident in L.A. with the erased hard drives (I swear I didn’t know that magnet was in my pocket!), because this year I’ll be back in the Hands-on Lab. Come by and say hello! I will have on the same T-shirt as all the other MCTs in that area, but just look for the shortest guy there and it’s likely to be me. (I used to be the shortest guy with the longest ponytail, but that’s one of the problems with having cut my hair off – I lost my most recognizable feature.)
I’ll be proctoring for the 200-level and 300-level labs in the Security, Identity & Management lab track (filter here to pull 41 of the sessions and times). Here’s my schedule (as always, check for last-minute changes):
Sunday 3:00 PM to 6:00 PM
Monday 2:45 PM to 6:00 PM
Tuesday 4:45 PM to 8:00 PM
Wednesday 7:00 AM to 10:00 AM
Thursday 12:15 PM to 2:30 PM
Before Tech*Ed even starts, I’ll be kicking off my weekend on Saturday, May 14th, at the MCT Day Zero meetup at the Mariott Marquis. It’s a free (donations are suggested) mini-conference that will cover topics of interest to certified trainers, including the Microsoft Learning Quality and Roadmap for 2011-2012. Pre-registration ends tonight at midnight (Wednesday, May 11) if you’re interested.
As a reminder, Transcender will be exhibiting at Booth #1904, and we’ll be giving away puzzles, games, and a chance to win a $250 Amazon.com Gift Card (no purchase necessary). Something else I did in L.A. was participate in the Jam Sessions. I plan to issue a call for all Tech*head musicians to come out on Tuesday night and play some music. Stay tuned for details on that later this week!
Tags: test-pass guarantee
Those of you on our mailing list already are aware of this, but it’s worth repeating here: the Transcender Practice Test Pass Guarantee has been improved, extended, and generally expanded. While it was already the best in the business with a three-month coverage period, it now reads:
If you buy a Transcender practice test and fail the corresponding exam within 6 months of activating the product, simply return the product to us for a full, no-hassle refund.
That’s it. Clear. Simple. Easy to understand.
There is no reason to hurry and cram to take your exam before the window of opportunity passes. We invite you to take your time to really learn the concepts covered in the practice test and be armed with the knowledge you’ll need to pass your exam. You now have six months to use our product to help you prepare for the exam. If our product does NOT help you pass, then you contact us for a refund of your payment (everything except shipping costs for physical media is refundable).
So how does our competition stack up on their test pass guarantees? Well, here are a few examples (with the names removed to protect the guilty).
Competitor #1: The testing date for the failed exam may be no sooner than 30 days after and no later than 180 days after the original purchase date.
(No sooner than 30 days? I’m ready now. Why should I have to wait for my pass guarantee?)
Competitor #2: The individual person licensed for the product must provide proof of failing the actual corresponding vendor’s exam TWICE and must notify us within 90 days of the software purchase. Exam failures must be between 10 to 90 days after the license registration to qualify.
(Okay, you have to fail twice to cash in AND you have to take both of those tests in only 90 days, after waiting for 10 days to take your first attempt? That’s pretty labor-intensive.)
Yes, we’re confident that we have the best guarantee in the business – even though we hope you never have to use it!
Tags: ccnp, Cisco
As most of you know already, Cisco has retired the exams in the old CCNP track and released three new exams that comprise the new CCNP. As covered in an earlier post here and elsewhere, the new exams are called ROUTE, SWITCH and TSHOOT. Today I would like to discuss the ROUTE exam; specifically, I would like to discuss a topic that has generated many questions among test candidates.
A quick examination of the exam objectives (found here) will reveal that almost every objective has the following structure:
- Create an (insert main objective topic) implementation plan.
- Create an (insert the main objective topic) verification plan.
So the question that I keep hearing about the exam is, “What kinds of information will be tested in this sub-objective, and how will it come at me”? In today’s post, I would like to try to fill in the blanks for you.
First, Cisco design practices call for creating an implementation plan and a verification plan for all types of implementations. Exam questions about implementation and verification will probably take one of two approaches: a conceptual approach, and a command-specific approach.
The steps that are included can seem somewhat subjective. You should drink the Cisco Kool-Aid and study the “Cisco steps.” The best references I can offer for that are the following links to information about PPDIOO and best practices:
PPDIOO stands for Prepare, Plan, Design, Implement, Operate, and Optimize. If you are familiar with the CCDP, this will not be a foreign concept to you. It is a design framework that Cisco uses and is the best source for getting a handle on these conceptual questions. When reviewing this document, pay close attention to and learn the bulleted lists such as the following from the section on Implementation steps (taken from the article verbatim)
Each phase consists of several steps, and each step should contain, but be not limited to, the following documentation:
- Description of the step
- Reference to design documents
- Detailed implementation guidelines
- Detailed roll-back guidelines in case of failure
- Estimated time needed for implementation
An example item of this type might be:
Which of the following is NOT a step to include in an implementation plan?
- Description of the step
- Reference to design documents
- Detailed implementation guidelines
- Cost of the step
So obviously (although it won’t be so obvious on the real exam) the answer is Cost of the step.
A higher-level resource is here:
Step-specific implementation questions
Obviously, these types of questions will ask about the commands or actions that should be performed at a given step in the implementation or verification plans. Here is a sample question from our new Cert 642-902 exam showing this type of implementation question.
A new portion of your OSPF network is in the design phase. You have been presented with a network diagram, a list of implementation steps, and a requirement that transmissions across all routers must be authenticated. The complete implementation plan is as follows:
- Enable OSPF process 1 on all routers.
- Enable area 0 on routers R2 and R3.
- Enable area 1 on routers R1 and R2.
- Enable area 10 on routers R4 and R5.
- Verify that all routers contain a complete routing table.
- Verify that you can ping from one end of the network to the other.
- Enable OSPF authentication on all routers.
Which of the following statements is TRUE about this plan?
A. It is complete as written.
B. Router R5 should have area 1 enabled.
C. Router R4 should have area 0 enabled.
D. Router R2 should not have area 0 enabled.
Above you see that the question is less conceptual and has more of its focus on OSPF. Steps are given in the item scenario, and you decide whether the steps are complete or if a vital step is missing. Don’t be afraid to answer that the given implementation steps are complete if, in fact, they are. It’s not a trick!
The same document located at the link I gave you covers verification steps as well as implementation steps. The same approach works for those types of questions.
- Learn the Cisco verification steps conceptually.
- Know how to verify a specific implementation.
Good luck on the exam, and see you next time!
Tags: ccnp, tshoot
Topic 1 in our TSHOOT series: Get a Game Plan!
As was reported earlier, both here and in many other places on the Internet (though I don’t know why you would ever look anywhere else on the Internet, because everything you need to know is here on our blog, by the way), the new Cisco TSHOOT exam is not the same test from years past. Yes, there will be a token number of multiple-choice questions to answer, but the bulk of the exam will be presented to you as “trouble tickets”. This post is the first in a series where I will cover some of the topics that you may see on this exam, and — the important part — how you need to approach these topics in your study plan.
On the exam, you will be presented with a set of diagrams representing the network for which the problem tickets are based. Just like in the real world, your job is to find where the problem lies within this thicket of devices, and then to decide how to fix it. As we explained in our previous post on TSHOOT, you will have to answer three questions on each ticket:
- Which device is causing the problem?
- What is the nature of the problem?
- What command would fix the problem?
In every scenario, there is a user at one end of the network trying to communicate with a device at the other end. That means that the problem could be located at 5 or 6 different links along the way. Some of the devices are routers, some are switches, and some are Layer 3 switches.
(If you’re not getting a good picture of what I mean, then this would be a good time to go and look at Cisco’s online demo for the TSHOOT, http://www.cisco.com/web/learning/le3/le2/le37/le10/tshoot_tutorial.html, and then return to this post.)
Before you even start working the first ticket, you should adopt a plan of attack. Don’t take a scattershot approach. Be organized. Let’s look at the tried and true approaches to this type of troubleshooting. You have two issues to consider as you work:
1. Where is the problem (on which device)?
2. At what layer of the OSI model is the problem located?
Where is the problem?
Let’s start with the possible approaches for the first issue.
Tactic 1: Start at the source
With this approach, you would start with the user device and attempt to ping the IP address of the next device on the path to the destination device. If that works, then ping from the second device to the third, and so on. At some point in the process, a ping will fail, and now you know which connection has a problem. So make sure you know how to determine the IP address of an interface and how to ping an interface.
Tactic 2: Start at the destination
With this approach, you ping from the source device to the destination. Of course, it will fail (otherwise there would not be a trouble ticket, right?). Then you work back toward the source, pinging next from the source to the next closest device in the path. When your ping is successful, the problem will then be identified as residing on the last connection that failed before the one that worked.
Tactic 3: Start in the middle
Are you a gambler? Then you would understand that the odds of finding the problem the quickest are best with this approach. Here, you ping to the middle of the path, and if that works, continue to ping toward the destination. If pinging to the middle of the path doesn’t work, start to ping back toward the source. Mathematically speaking (please do not ask me to explain it, ask George, he went to Georgia Tech with the rest of the smart kids), this will find the problem the quickest.
Realize that when a device is connected to a Layer 2 switch there is no need to ping the IP address of the switch. It does not come into play in the switching or routing process. If it’s a Layer 3 switch, then that’s different, but even then you will be concerned with the router part of the Layer 3 switch and not the switch side. So that means you should ping from the device to the next router interface in the path, and skip the switch.
What type of problem is it?
Now that you have determined where the problem is, you must determine the type of problem it is. There are three approaches to this.
Tactic 1: Top down
This approach starts by troubleshooting application issues (Layer 7), and then working down the OSI model to the transport and network layers, and from there to the physical layer (Layer 1). I would not recommend this approach since the problem is connectivity, which is most likely to be a lower layer. Application issues usually result in performance issues, not connectivity issues.
Tactic 2: Bottom up
With this approach, you start with the physical layer (cabling), then proceed to Layer 2, which would encompass VLAN issues and DLCIs. If the problem is not discovered, you would move to Layer 3 to investigate routing protocol issues, DHCP problems, and NAT. This is a better approach than top down for this scenario, and one I recommend.
Tactic 3: Divide and Conquer
This approach plays the odds and starts in the middle of the OSI model, at the network layer, and then proceeds up or down based on the results of your investigation. For example, if you see no routing protocol issues, NAT issues, or DHCP issues, then move down to Layer 2.
Whatever approach you adopt, you should stick with it for the duration of the ticket. Be methodical and keep working until you find the problem. You have plenty of time to finish if you know your commands, although you should do some quick math from time to time and ensure you don’t spend too much time on one ticket. If there are 16 tickets and you spent 20 minutes on the multiple-choice questions (let’s say there are about 10), then you have 115 minutes left for 16 tickets. That’s 7 minutes per ticket. Keep that in mind and if you find yourself crunched for time, don’t skip any answers, but make a guess and move on.
I’ll go into more depth on specific issues, such as issues with BGP, DHCP, IPV6, EIGRP, and HSRP in my next post.
Tags: tips & how-to's, Windows 7
Have you ever had an exchange like this when trying to assist a user with a technical support issue?
User: My Frizzapp is not working.
You: Okay, tell me how it happened.
User: Well, I got this ugly error message and then it froze up and when I tried to close it I got another message and then it all just went away.
You: What did the error message say?
User: I dunno, something about a .dll or something. I’m not a technical guy, you know.
You: I guess I’ll have to come over there and help you.
About this time you are thinking, I wish this guy could just tell me accurately what the heck happened, and maybe I wouldn’t have to go all the way to his computer to fix this. Okay, maybe you’re thinking something a little more explicit, but there are entire web sites devoted to IT horror stories (“No, it is NOT a coffee cup holder!”) and you’ve probably got them bookmarked, so you don’t need my help there.
I’m happy to report that the Windows 7 developers must have worked the trenches of the help desk front lines, because the IT support tool you’ve been waiting for is built right into Windows 7! It called the Problem Steps Recorder, and it’s very simple to teach the end users how to work it. You can even use the tool to create a tutorial for the tool itself. In a nutshell, the user starts the recorder and then duplicates the steps that caused the problem. The tool doesn’t just record all the steps taken by the user, but also records information about the files and applications used during the process, and creates a zip file that the user can send to you. Then you can view the file with no special software (uses Internet Explorer) and get a precise snapshot of the issue.
To open the tool, just hover over the Windows 7 orb in the lower left-hand corner. In the Search box, type “Recorder.”
From the search results, choose “Record steps to reproduce a problem” under Control Panel. Continue Reading Help for help desks and beyond: the amazing Windows 7 Problem Recorder tool…
Tags: ccna, study tips
CatOS commands on the CCNA – Tell me it ain’t so!!
Several of the Transcender Cisco practice tests, including 640-802 and 642-812, include some Catalyst OS command questions as well as the standard Cisco IOS. At least once a week I get emails from customers taking me to task over this issue and asking why we have “deprecated commands” on our current tests. Many customers have the impression that because Cisco is phasing out the Catalyst operating system on its switches, there is no need to study CatOS commands for the exams. Adding fuel to this fire, many popular Cisco study guides omit any information on CatOS commands.
So I’d like to address this issue and explain the reasons why we have deliberately chosen to leave a small percentage of CatOS commands in our practice tests; yes, even the most recent practice tests:
- Out there in the real world, there are a lot of older switches still in production environments running the Catalyst OS, and you may well encounter them in your job.
- Cisco still supports the Catalyst OS, and will continue to support it until January 2013 (see this End-of-Sale and End-of-Life Announcement for the Cisco Catalyst OS Release 8.x).
- If you look at the stated objectives for the CCNA and CCNP exams, you will notice that it does not say “IOS only” anywhere. In fact, at the top of each list of exam objectives, you’ll see this disclaimer:
The following information provides general guidelines for the content likely to be included on the exam. However, other related topics may also appear on any specific delivery of the exam. In order to better reflect the contents of the exam and for clarity purposes the guidelines below may change at any time without notice.
Given that Cisco exams have a huge question pool, we think it may be possible to encounter a Catalyst OS-related question, or a question that includes a CatOS command as a distractor (wrong answer), on a current exam. Therefore we will continue to include some CatOS commands on the practice test until Cisco definitively says “No more.”
CatOS commands – all the info that you’re likely to need.
I’ll start with some information about the two OS systems.
Configuration changes in the CatOS software are written to NVRAM immediately after a change is made. No intervention by the user is required.
All configurations in CatOS are done via a set command sequence executed from the enabled-mode prompt. Issuing the clear command from the same prompt will erase a particular command.
In contrast, IOS does not save configuration changes to NVRAM unless the copy run start (or write memory) command is executed. If the configuration is not explicitly saved, any changes to the configuration will be lost should the system be reloaded.
All command-line configuration in IOS (whether on the Supervisor or the MSFC) is done from the configuration mode, commonly known as “config-t”.
Commands can be removed with the no or default form of the original command.
Below is a comparison of the common commands on user ports.
This list is provided just to give you a flavor for the differences in the two command sets. For more information use the links below:
Tags: ccna, study checklist
Thanks for returning for the final installment of my review checklist for the CCNA exam. In this session we will cover the topics included in Objective 8: Implement and Verify WAN links. Let’s get started!
You should be able to describe the differences between the categories of data transfer between physical locations. These include:
- Cell switching – Cell switching is a WAN switching technology that is used by ATM. ATM is an International Telecommunication Union-Telecommunications (ITU-T) standard for the transmission of data, voice, or video traffic. It uses a fixed size frame of 53 bytes, known as cells. Out of these 53 bytes, the initial five bytes are header information and the rest of the 48 bytes are the payload.
- Packet switching – Packet switching is popularly used for data transfer, as data is not delay-sensitive like voice traffic is, and it does not require real-time transfer from a sender to a receiver. With packet switching, the data is broken into labeled packets and transmitted using packet-switching networks.
- Circuit switching – Circuit switching dynamically establishes a virtual connection between a source and destination. The virtual connection cannot be used by other callers unless the circuit is released. Circuit switching is the most common method used by the Public Switched Telephone Network (PSTN) to make phone calls. A dedicated circuit is temporarily established for the duration of call between caller and receiver. Once the caller or receiver hangs up the phone, the circuit is released and is available for other users.
You should how to configure a serial link for a WAN connection. Make sure that you know how to use these commands: Continue Reading Troy’s checklist for preparing for the CCNA: Objective 8…
Tags: ccna, study checklist, wildcard mask
I am just back from spending a week teaching security to our nation’s finest at an Air Force base in central Georgia, so I am all ready to dive into this week’s security-related objective for the CCNA exam. This week’s topic is Implement, verify, and troubleshoot NAT and ACLs in a medium-sized Enterprise branch office network.
(Here’s the previous coverage of Objective 1, Objective 2, Objective 3, Objective 4 Part 1, Objective 4 Part II, Objective 5, and Objective 6. The full list of CCNA objectives is at https://cisco.hosted.jivesoftware.com/community/certifications/ccna/ccna_exam?view=overview.)
To begin with, let’s make sure everyone knows what these two concepts are all about. Network Address Translation (NAT) is a service that can run on a server or on a router that converts private IP addresses to public IP addresses. This provides two advantages:
- It conserves address space on the Internet and allows an enterprise to use private IP addresses inside the network, instead of having to register public IP addresses for all computers that need Internet access.
- It ‘hides’ the real IP addresses of the internal computers , which makes the first step in the hacking process (discovery) more difficult.
Be able to identify the types of NAT:
- Static NAT – uses a one to one mapping from public to private. Doesn’t save any IP addresses, but does provide the security of hiding the private addresses.
- Dynamic – uses a pool of public addresses and dynamically uses the pool to create mappings. Same as static NAT, except that the address mappings keep changing.
- NAT overload – describes any situation where there are fewer public addresses than private addresses. In this case, the same public address(s) is used over and over and the NAT device identifies each computer by the port number it uses to connect to the router using port address translation (or PAT).
Be able to identify the most appropriate router in a diagram on which to configure NAT. This will usually be the last router before connecting to the Internet.
Understand which interface on the router to apply the following commands:
- ip nat inside – should be applied on the interface connected to the LAN
- ip nat outside – should be applied on the interface connected to the Internet
NOTE – You must be able to perform a complete NAT configuration, up to and including a static mapping and NAT overload. Don’t take the exam if you can’t do that!