Tag: cisco

Core Knowledge Questions Removed for CCIE R&S and Voice Lab Exams

Cisco removed the Core Knowledge Questions section from the CCIE R&S and Voice Lab exams.

This sections STILL exist on CCIE Service Provider, CCIE Security, CCIE Storage Networking and  CCIE Wireless Lab.

Please find below the official announcement and the reasons regarding this section removal from R&S and Voice lab exams:

With more than six months of exam results now available, Cisco is able to report that the troubleshooting components of the CCIE R&S v4.0 and CCIE Voice v3.0 lab exams are performing well in validating expert level networking skills.  Considering these results, Cisco has decided to eliminate the Core Knowledge questions from the current CCIE R&S v4.0 and CCIE Voice v3.0 Lab Exams.  Beginning on May 10, 2010, CCIE R&S and CCIE Voice Lab Exams, in all global locations, will no longer include the four open-ended Core Knowledge questions.  The total lab time will remain eight hours.  For the CCIE R&S Lab Exam, this means candidates will begin with the two-hour Troubleshooting section, followed by a six-hour Configuration section.  For CCIE Voice, candidates will have the full eight hours to complete the integrated exam.  At this time, only the R&S and Voice tracks will be eliminating the Core Knowledge questions.
You can read more here:

https://learningnetwork.cisco.com/docs/DOC-6484

You might be interested in:

New Service Provider Operations Track Training and Exams

The Cisco CCNA Service Provider (SP) Operations certification and the written exam for the CCIE Service Provider (SP) Operations certification are now available.
The Cisco CCNA SP Operations certification targets entry-level students with a foundation of network operations skills in SP IP NGN environments required of associate-level operations personnel. Both the Supporting Cisco Service Provider IP NGN Operations (SSPO) course and required # 640-760 exam are now available. Interested students should access the CCNA SP Operations home page for more information.

The Cisco CCIE® SP Operations certification assesses and validates core IP NGN service provider network operations expertise and broad theoretical knowledge of operations management processes, frameworks and network management systems. Registration for the for CCIE SP Operations written exam is now available. In addition, students may download the blueprint for the CCIE SP Operations practical exam from the CCIE SP Operations practical exam overview page. The practical exam for the CCIE SP Operations certification is scheduled to be made available in the third quarter of 2010.

For more info:
https://learningnetwork.cisco.com/community/certifications/ccna_sp_operations
https://learningnetwork.cisco.com/index.jspa?ciscoHome=true
https://learningnetwork.cisco.com/community/certifications/ccie_sp_operations/practical_exam

You might be interested in:

How to emulate ASA in Ubuntu 9.10 and GNS3

Cisco ASA

Brainbump.net has an excellent and very complete how to emulate ASA using just the following components:

  • Ubuntu 9.10 – 32 bit Edition
  • GNS3 v0.7 RC1 tgz
  • Dynamips 0.2.8-RC2 binary for Linux x86 platforms
  • Qemu-0.11.0 tar.gz
  • Qemu-0.11.0 Patch
  • ASA Binary Version 8.0(2) – (asa802-k8.bin)

How-to is divided in 3 video tutorial parts for easy understanding and start with the most basic installation on GNS3 under Ubuntu 9.10 and continue with the actually configuration on the emulation.
If you are interested in security or you just want to test ASA and don’t have access to real hardware you definetely will want to try Brainbump.net tutorial.

READ THE FULL TUTORIAL on Brainbump.net


Cisco tips: Track down communication issues – Part 2

In the 1st Part of this series, I’ve described the most common steps that you should follow to troubleshoot a total lack of communication between a Layer 2 device (Cisco switch) and an end user connected device. As I promised here is the second part, in which I’ll try to show you what you can check when you have no problem with connection, but still you encounter a degradation in service. By this degraded service, I understand a scenario when you have packet loss for example, or intermitent connection which will affect communication and more than sure will make user users not very happy.

We will stick with the same scenario when a end user device is connected to a Cisco switch. Remember that until now, we just troubleshoot at the Layer 1 and Layer 2. Today we will stick in the same area, so nothing directly related to IP, routing protocols or complex networking environment.

Scenario 2: You have an end device connected to a switch and you have degraded communication

a) Check for errors on the interface:


In this example there is no errors, but if you find something there, you may want to keep an eye on this port. Try to issue the above command couple of times to see if the errors are increasing in real time, as this is the worst case possible and you should take action immediately. Error on the interface can be caused by faulty interface on the switch or on the other end, ethernet cable issue or wrong configuration

b) Check the interface queue and drop packets


Interface queue is very important and you should check it during your troubleshooting process. With the above command you can see how many packets are in the input / output queue, which is the transmit and receive rate and very important if you have packets dropped from input and output queue. Usually this happens when there is a lot of load on the switch and it cannot process as quick as it’s needed all the packets. This lead us to the next step.

c) Check the CPU load on the switch


The command output is longer but most interesting for this example are the first 2 rows which show load in 60 seconds and in 60 minutes. If you have there peaks up to 100, then it’s bad and the device is having some issues that need to be fixed.

d) Identify what process is keeping the CPU busy


Most of the time, this is easy to read and to see what process is taking all your CPU power. When you see there Fifo Error Detection with 100% than you have to think that maybe there is something wrong with the queue on one of the interfaces and try to find which one is having problem. This is not straighforward and you have to check a lot of things, but can be helpful. To be honest, I see a lot of engineers just reloading the device and then problem is solved (if it was due to a hardware issue and not a configuration mistake).

e) Check for memory issue on the switch


Again, if you run out of memory, bad things can happend to your device and as well to the communication with device connected to the switch. Reloading of the device solved about 90% of this kind of problems. I don’t recommend just unplug the power cable as soon as you see a memory problem. First have a look, maybe there is something you can fix without reloading the device.

f) Check for problems with storm-control implementation


In one of previous posts I have explained how you can use storm-control to limit the available bandwidth on a Cisco switch interface. In the example above I set this bandwidth to 1 % from the available one gigabit (I know is stupid, but imagine a typo mistake). Imagine what effect will this have on the traffic. Everything above 1 % is keeped in the queue until this is full and then silent discarded.

e) As a general rule, have a look into the logs (maybe this should be first step!)

If there are a lot of Spanning-tree reconfiguration, interface flapping or anything else that looks suspicious, be sure to check on this as you can find there the root cause for your problems.

Do you have any other tips in regard to this topic? Anything else you check and can be added here? Be sure to comment below and your suggestion will be taken into consideration.

Cisco tips: Track down communication issues – Part 1

You know how sometimes you plug in everything, configure device / ports and then the un-expected result is “not working”. Then you start to troubleshoot, which is a good point, but very important is where are you looking for the root cause of your issue.

A lot of people who have communication issue start by issuing a ping from one end to the other one. This is a good approach when somebody is reporting service issue (e.g. my webserver doesn’t work) as with the ping you can see immediately if is a communication issue or a server one. This scenario ussualy occurs when you already have a working environment and after a while somebody encounter a service issue.

Instead when you just deployed a new connection and you are having issue with it, ping is not the best approach. In the following article I will try to show you some good steps proven to be effective when you start troubleshooting. For today I will take as example a faulty communication between a Cisco switch and an end device (server or user device). This involes in the first step basic Layer 2 troubleshooting.

Scenario 1: You have an end device connected to a switch and you have no communication

a) Check the interface connection status:

OK – port is connected and protocol shows up status

Not OK – check the faulty port as it is in shutdown state

Not OK – port is not connected, protocol shows down status
You can check for cable error (damage, faulty plug, unplugged) or ask the owner of the remote device to check it.

If you found any error in the above step, try to fix them now. If the interface is connected, but still not working, follow on to the next steps.

b) Check speed and duplex settings
-if you have auto-negotiation here and it fails, you will end with an interface in down status
-again if you have static settings here, check to be the same on both sides.
-for more pro and cons regarding auto-negotiation vs static, please see Greg Ferro’s article

c) Check the interface switchport configuration:


There is no right and wrong configuration here, but I can point you to check the following:
– very important, check if the access VLAN is the right one
– if you have switchport auto-negotiation enabled, check to see that this is correctly achieved
– if you have switchport static configuration, check to have the correct settings for your needs
– if you need trunking (to an end device), check to allow the necessary VLANs on that trunk
– if you use private VLANs, pay attention to the configuration of primary and secondary vlan and right association

d) Check security on the Access port (BPDU guard, port-security, mac-address access-list…):


– port is in shutdown state due to Security Violation (1); The mac-address that you see there is the one coming to the port from the other end, but also you can see that there is a Configured Mac Address (1) on the port; Most probably the one configured on the port does not match the one from the network.


-if the result is like above one, you may want to check if that mac-address access-list allow communication from end device mac-address


– if your interface status is like this, you might have an issue with spanning-tree BPDUguard being enabled on the interface; I know I said that this is end device connected, but what if the user needed an extra port, and he connected there a switch? You always have to assume what’s the worst and check for possible issue.

f) Check the Spanning-tree protocol on the switch port


– your output might look different than the above one, but be sure to have there FWD (Forwarding) status if the port is connected to an end device.
– again it is very rare not to be in FWD status, but if the device has some strange bridging capabilities or user added another device in the middle, like a switch than you can identify a problem with Spanning-tree.

This are the basic stuff that I checked in regard to Layer 2 topology when I have no communication to the end host. In the next part, I will do a short presentation of the scenario when you have communication to end device, but the connection encounter traffic deprecation.

Check the 2nd Part of this series which deals with communication deprecation at Layer 2.

Do you have any other tips in regard to this topic? Anything else you check and can be added here? Be sure to comment below and your suggestion will be taken into consideration.