CCIE Blog » Storage http://blog.ipexpert.com CCIE Candidates blog for all technical overviews relating to CCIE R&S, CCIE Voice, CCIE Security & CCIE SP Fri, 03 Feb 2012 21:58:21 +0000 en hourly 1 http://wordpress.org/?v=3.1.2 Introducing IPexpert’s New IPv4/IPv6 Multicast Operation and Troubleshooting Guide http://blog.ipexpert.com/2012/01/13/introducing-ipexperts-new-ipv4ipv6-multicast-operation-and-troubleshooting-guide/ http://blog.ipexpert.com/2012/01/13/introducing-ipexperts-new-ipv4ipv6-multicast-operation-and-troubleshooting-guide/#comments Fri, 13 Jan 2012 15:18:55 +0000 Jessica Scott http://blog.ipexpert.com/?p=9712

IPexpert is thrilled to introduce the first installment in our NEW Protocol Operation and Troubleshooting Series, IPexpert’s IPv4/IPv6 Multicast Operation and Troubleshooting.  This series was designed around CCIE student feedback on specific protocols and technologies that they feel they struggled with most when preparing for the CCIE Lab exam. IPexpert’s IPv4/IPv6 Multicast Operation and Troubleshooting dives deep into the specific operations and troubleshooting technologies for key multicast areas such as IGMP,  PIM Sparse Mode, multicast security and much more.

Developed by the industry’s most recognized Senior Technical Instructors, Editors, and Consultants, this new book series is sure to assist you in better understanding IPv4/IPv6 Multicast operations, troubleshooting methodologies, and time saving fault isolation techniques.

IPexpert’s IPv4/IPv6 Multicast Operation and Troubleshooting Topics:

I. Introduction to Multicast Troubleshooting
II. IGMP
III. PIM Dense Mode
IV. PIM Sparse Mode
V. PIM Sparse-Dense Mode
VI. Bidirectional PIM
VII. Static RPs
VII. AutoRP
IX. BSR
X.  MSDP
XI. Anycast
XII. MP-BGP for Multicast
XIII. Interdomain Multicast
XIV. Multicast Advanced Features
XV. Multicast Security
XVI. IPv6 PIM
XVII. IPv6 MLD

Each section listed above contains an exhaustive technology review, show and debug command tools, review of common issues, sample troubleshooting scenarios and chapter challenge sample Trouble Tickets with solutions. Sample trouble tickets follow Proctor Labs topologies, and have also been fully tested on home racks and the most popular emulators in use today.

Check out the free sample chapter Chapter 9: Bootstrap Router Protocol to examine this incredible new product series. The full IPv4/IPv6 Multicast Operations and Troubleshooting text releases Feb 20, 2012.

 

List Price: $149
Pre-Order Price: $99  

 

Questions? Contact a Training Advisor Today!

Email: sales@ipexpert.com
Telephone: +1.810.326.1444
Live Chat: www.ipexpert.com/chat

]]> http://blog.ipexpert.com/2012/01/13/introducing-ipexperts-new-ipv4ipv6-multicast-operation-and-troubleshooting-guide/feed/ 1 IQ and EQ Required http://blog.ipexpert.com/2011/11/27/iq-and-eq-required/ http://blog.ipexpert.com/2011/11/27/iq-and-eq-required/#comments Sun, 27 Nov 2011 18:22:12 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=9136

A friend told me that I should check out the text Emotional Intelligence 2.0. As I was reading this book, I quickly realized how practical it can be for CCIE candidates. You see Emotional Intelligence is all about your ability to recognize and control your emotions and to understand the impact that they can have on your life.

You see, we are all familiar with IQ. This is a measure that can be assistance to judge how quickly and efficiently we can learn to pass the CCIE. But what about EQ. This is our Emotional Intelligence rating. This can be very important in the pursuit of CCIE. Remember my cornerstones for success?

-Tech Knowledge

- Psychological State

- Physical Wellness

- Strategy

Certainly IQ impacts your technological knowledge, but think about the impact that Emotional Intelligence can have on your psychological state. And remember, the cornerstones all impact each other. For example, if your emotions are out of control and your psychological state is ruined, it can effect all three of the others.

What are the emotions that we need to watch out for in this pursuit?

  • Sad – we can feel lonely and isolated from family and friends as we immerse ourselves in study
  • Angry – should we experience a NOT PASS this emotion can be powerful
  • Afraid – we may be paralyzed with fear regarding a NOT PASS
  • Ashamed – many experience this after a NOT PASS event

As I read more of this text, I will be sure to share what tools we should be able to use in our pursuit of CCIE.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

]]> http://blog.ipexpert.com/2011/11/27/iq-and-eq-required/feed/ 0 Attention all CCIEs is Your Name on This List??? http://blog.ipexpert.com/2011/10/29/attention-all-ccies-is-your-name-on-this-list/ http://blog.ipexpert.com/2011/10/29/attention-all-ccies-is-your-name-on-this-list/#comments Sat, 29 Oct 2011 16:19:20 +0000 Matt Just http://blog.ipexpert.com/?p=8787 Is your name on this list of IPexpert Top Guns?

If you have passed your CCIE Lab exam and used any of IPexpert’s training products including Self-study Material, Video on Demand, Audio on Demand, Rack Rental, or even one of our free vLecture’s and you don’t see your name on the list we want to hear from you! It doesn’t matter if you purchased the material from us or borrowed it from a friend just let us know what you thought about the material be visiting http://www.ipexpert.com/products/review or email CCIE@ipexpert.com with your Name and CCIE# and we will send you a free shirt seen below that will have your name and CCIE# in the list of Top Guns!

 

]]> http://blog.ipexpert.com/2011/10/29/attention-all-ccies-is-your-name-on-this-list/feed/ 2 The CCIE Proctor – Part 1:Their Job http://blog.ipexpert.com/2011/10/02/the-ccie-proctor-part-1their-job/ http://blog.ipexpert.com/2011/10/02/the-ccie-proctor-part-1their-job/#comments Sun, 02 Oct 2011 14:00:37 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8410 We are starting a new series here on blog.ipexpert.com that is going to focus on the proctor. In this first post, we are going to explore the question of – “What is the proctor there for?” Why do we care about this? Well, if we understand what their job is, we will know better what to expect from them, and what we can acquire from them during the lab experience.

Proctors consider themselves, and are titled, customer support engineers. They are at the lab exam site to provide a number of support-type functions:

  • Ensure your equipment is functioning properly for the lab exam
  • Ensure that you understand your requirements for completing the exam
  • Ensure that candidates do not intentionally, or inadvertently, cheat or distract other candidates

What about helping with your questions? Well, many proctors will state at the beginning of the exam (orientation), that they are NOT there to help you with the tasks that you will be presented with. They make it clear that everything you need to pass the exam is provided on the printed or on-screen materials.

With that said, proctors WILL typically try and assist with questions that you have about your lab. To quote a famous proctor former proctor, Ben Ng, “Candidates are entitled and encouraged to ask any questions if they feel the wording of the exam content is not clear. However, generally I will decline to answer a question if it is formulated for me to choose or confirm a specific solution. We can’t give candidates a direct reply if they’re trying to narrow down the answer. But we don’t mind clarifying the questions if they ask. The worst that could happen is I tell them I can’t answer.”

Interesting…more on this fact in the next post in this series!

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

]]> http://blog.ipexpert.com/2011/10/02/the-ccie-proctor-part-1their-job/feed/ 0 Spot the Differences Troubleshooting http://blog.ipexpert.com/2011/09/08/spot-the-differences-troubleshooting/ http://blog.ipexpert.com/2011/09/08/spot-the-differences-troubleshooting/#comments Thu, 08 Sep 2011 14:31:18 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8210 “One of these things is not like the other!” This popular children’s exercise can certainly come into play with our various troubleshooting approaches!

When you engage in the The Spot the Differences approach to troubleshooting, you attempt to compare functioning to malfunctioning devices or processes and spot the differences. This might even allow you to implement a solution or a workaround to a problem without even understanding the underlying cause.

By comparing configurations, software versions, hardware or link properties between working and nonworking situations and spotting significant differences between them, you might be able to resolve the problem by changing the nonoperational situation to be consistent with the working situation.

As alluded to above, the biggest disadvantage with this method is that it can lead to a working situation, but not to an understanding of the root cause of the problem.

You should notice that the effectiveness of this method depends on how easy it is to compare working and nonworking devices, situations, or processes. Having a good baseline of what constitutes normal behavior on the network makes it easier to spot abnormal behavior. Also, the use of consistent configuration templates makes it easier to spot the significant differences between functioning and malfunctioning devices. As a result of all of these factors, the effectiveness of this method does typically depend on the quality of the overall network maintenance process.

Finally, you should also take note that like the follow-the-path method, this approach is best used as a supporting method in combination with other methods such as top-down or bottom-up troubleshooting.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

 

]]> http://blog.ipexpert.com/2011/09/08/spot-the-differences-troubleshooting/feed/ 0 Follow the Path Troubleshooting http://blog.ipexpert.com/2011/09/07/follow-the-path-troubleshooting/ http://blog.ipexpert.com/2011/09/07/follow-the-path-troubleshooting/#comments Wed, 07 Sep 2011 14:31:46 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8199

Another important and basic troubleshooting technique that you should be aware of is called Follow the Path. This method is typically used in conjunction with another of the troubleshooting techniques that we have discussed in previous posts. For example, following the path might be used in conjunction with the top down or bottom up troubleshooting approaches.

What do we do when we engage in follow the path troubleshooting? We engage in tracing the path of packets through the network in order to eliminate irrelevant links and devices from the troubleshooting process. Notice that the objective of this method of troubleshooting is to isolate the problem by eliminating potential problem areas from the scope of the troubleshooting process. When you analyze and verify the path that packets take through the network as they travel from a source to a destination, you can reduce the scope of your troubleshooting to just those links and devices that are actually in the forwarding path.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

 

]]> http://blog.ipexpert.com/2011/09/07/follow-the-path-troubleshooting/feed/ 1 The Divide and Conquer Troubleshooting Approach http://blog.ipexpert.com/2011/09/06/the-divide-and-conquer-troubleshooting-approach/ http://blog.ipexpert.com/2011/09/06/the-divide-and-conquer-troubleshooting-approach/#comments Tue, 06 Sep 2011 14:21:15 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8148 Are you looking for the most efficient method possible when it comes to using the OSI model as a guide for your Troubleshooting approach? Well then you have arrived at the correct place.

This method has you do your fact gathering (as usual), and then based on the information you have gathered, it has you dive right into to the most likely layer of the OSI model.

Divide and Conquer

Please keep in mind that you might be dead wrong, of course. Be very ready to move up or down in the OSI model with your troubleshooting based on the information you gather at the particular layer that you started at.

Ready for an example? Let’s say you are working with a Trouble Ticket that states you are not receiving a particular prefix from your RIP peer. This certainly sounds like you are receiving other prefixes for RIP from the device. A great idea would be do dive right into the Network layer and check for any filtering mechanisms that might be in place. You could also start with a debug ip rip as well at this Network layer. Based on what you discover, you might be moving up or down in the OSI.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

]]> http://blog.ipexpert.com/2011/09/06/the-divide-and-conquer-troubleshooting-approach/feed/ 0 The Bottom-Up Troubleshooting Approach http://blog.ipexpert.com/2011/09/04/the-bottom-up-troubleshooting-approach/ http://blog.ipexpert.com/2011/09/04/the-bottom-up-troubleshooting-approach/#comments Sun, 04 Sep 2011 14:00:51 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8145 Did you read the previous post in this series regarding the Top-Down Troubleshooting approach? If you did, then you already have a great understanding for this Troubleshooting approach. Once again, we are going to rely on the OSI model as a guide as we troubleshoot. This time, however, we are going to start that physical layer and work our way up the layers. Hey, do you need a review of what those layers are? Here you go:

  • Application
  • Presentation
  • Session
  • Transport
  • Network
  • Data Link
  • Physical

When you engage in the Bottom-Up Troubleshooting approach, you are eliminating more and more potential problems as you move up each layer. It is fun! I rely on this Troubleshooting approach when in doubt, that is for sure.

It tends to work great in a CCIE or CCNP lab environment since it is going to cause us to focus on the lower layers, and these layers are the focus of these exams. In production networks, it has you working with the devices in your control (routers, switches, firewalls, etc).

This approach certainly tends to be thorough and easy to carry out for more engineers. Since they often default to it, they get very, very trained with it and very efficient. Even though many times they are starting at the bottom which might be far away from the problem, they are so speedy with the approach, there really is little time wasted.

Remember, the best approach would be to gather some evidence, and then narrow things down to decide if Bottom-Up is the way to go!

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

]]> http://blog.ipexpert.com/2011/09/04/the-bottom-up-troubleshooting-approach/feed/ 0 The Top-Down Troubleshooting Approach http://blog.ipexpert.com/2011/08/31/the-top-down-troubleshooting-approach/ http://blog.ipexpert.com/2011/08/31/the-top-down-troubleshooting-approach/#comments Wed, 31 Aug 2011 14:26:51 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8125 When you engage in the Top Down troubleshooting approach, you are using the OSI reference model as a guide, and you are hoping that the problem is one of the higher layers! You are beginning your troubleshooting in the higher layers, trying to find the highest layer that is working. You see, the way the OSI reference model works, if we can determine that a particular layer works, then it is a pretty safe assumption that all the layers below it are functional. Notice I say “pretty” safe. There might indeed be problems at a lower layer that are so specific, they are not showing up in your initial evidence collection.

What is an example of a Trouble Ticket where we might immediately latch on to the Top-Down Troubleshooting approach? Well, how about this…

TROUBLE TICKET 4

Users in Subnet 101 are reporting that they can access Web content from Subnet 201, but they are unable to transfer files to or from an FTP server in that subnet.

Here we can see that a Top Down Troubleshooting approach certainly makes sense. Especially when we balance this against starting with a Bottom Up approach (covered in the next blog post). It is quite clear that we do not have a physical layer issue, since the Web connectivity would not work.

Following your Top Down approach in this trouble ticket, you might first attempt to reach the FTP ports on the target system, and if you can, begin troubleshooting the FTP server application settings.

Notice the key to adopting this approach straight-away is the gathering of evidence that points to the problem being at a higher layer of the OSI model. This approach would not make sense if the evidence points to a lower layer.

Since many real world Trouble Tickets involve the report of application layer issues, this is indeed one of the most popular troubleshooting approaches that is used in enterprise networks today. Keep in mind, however, that it will NOT be this way in your CCIE exams. This is because we thrive (as Cisco engineers) at Layers 1 through 4 of the OSI model, and Cisco will structure most of our exam troubleshooting around these layers.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

]]> http://blog.ipexpert.com/2011/08/31/the-top-down-troubleshooting-approach/feed/ 0 “Shoot from the Hip” Troubleshooting http://blog.ipexpert.com/2011/08/30/shoot-from-the-hip-troubleshooting/ http://blog.ipexpert.com/2011/08/30/shoot-from-the-hip-troubleshooting/#comments Tue, 30 Aug 2011 14:24:20 +0000 Anthony Sequeira http://blog.ipexpert.com/?p=8016 One troubleshooting methodology that we want to discuss is the “Shoot from the Hip” method. This is often done by very experienced troubleshooters. Here, the engineer gathers quick information on the issue, and immediately proposes a hypothesis and tries a configuration change and test. If you are in the R&S Cisco Lab Exam and you are running out of time in the Troubleshooting section, this is one YOU MIGHT HAVE TO EMPLOY! Notice that if we can avoid this approach, often times we do. You see the issue lies in the fact that we are no closer to solving the problem if what we changed had no effect. If we follow one of the other methodologies that we are going to cover in this series, we have a bunch of excellent facts and data that we can re-analyze in order to eventually solve the problem.

The Shoot from the Hip approach just might be perfect for some Lab Exam trouble tickets, however. For example, if the trouble ticket is VERY specific about the issue, and there is a very small number of issues that could cause the problem, you might want to just pick the most likely issue and see if that is indeed your problem. If you miss the mark, just be ready to quickly slide into one of the more “robust” troubleshooting methodologies we are going to present here at blog.ipexpert.com.

By the way, what are those methods? In future posts, we will examine:

  • Top Down
  • Bottom Up
  • Divide and Conquer
  • Following the Path
  • Spot the Differences
  • Moving the Problem

We hope you will join us!

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

]]> http://blog.ipexpert.com/2011/08/30/shoot-from-the-hip-troubleshooting/feed/ 0