Are debug commands allowed for CCIE lab exam?

dppagc

In a production network I am advised not to use debug commands.

Find more posts tagged with

Comments

routergods

http://i.imgur.com/iWKad22.jpg?fb

Cisco Inferno

routergods wrote: »

http://i.imgur.com/iWKad22.jpg?fb

ah maaaaaan.

Iristheangel

OP: Let's start with why you AREN'T allowed by your superiors to debug on production equipment, do you know why?

dppagc

Because the output will overwhelm and crash the routers but I am asking about the exam.

Iristheangel

Well, it won't necessarily crash the router - it all depends on the debug command, the amount of data it's going to throw into the terminal, the CPU usage, etc. It's the same thing with the exam - you're allowed to do whatever you want within the guidelines they give you. Typically the guidelines are something along the lines of "Don't use static routes," but show and debug commands are fair game - this is how you HAVE to troubleshoot in the exam. "show run" as your main tshoot tool will not do the trick if you want to pass.

Use the same common sense in the lab as you do in production in terms of that debug usage - If you think it might crash the router, use another debug instead or maybe use an ACL to narrow down the output so you don't crash it.

Bardlebee

dppagc wrote: »

Because the output will overwhelm and crash the routers but I am asking about the exam.

It's the same thing man, from my understanding if you wreck your rack or device and you can't get access to it again, the proctor will not assist you and you likely will have a bad day. I would suggest looking up experiences from articles and other information like that. Haven't taken the lab, yet. But this is my understanding.

OctalDump

Iristheangel wrote: »

"show run" as your main tshoot tool will not do the trick if you want to pass.

Could you theoretically just use show run and the physical topology to trouble shoot all issues? I mean, if it's cabled right and the configs are ok, are there other things to worry about?

routergods

OctalDump wrote: »

Could you theoretically just use show run and the physical topology to trouble shoot all issues? I mean, if it's cabled right and the configs are ok, are there other things to worry about?

Nope, you'll run out of time.

Iristheangel

Heh. Also you might not have access to the CLI on all devices and to tshoot an issue on a device you can't connect to, you may need to use debugs to discover the issue (think CE to PE routers)

OctalDump

routergods wrote: »

Nope, you'll run out of time.

But theoretically, if you were fast enough?

Iristheangel wrote: »

Heh. Also you might not have access to the CLI on all devices and to tshoot an issue on a device you can't connect to, you may need to use debugs to discover the issue (think CE to PE routers)

So you could have a situation where you have an "undocumented" device or connection, that you can't log into? Like, in CCNA terms, if you didn't know whether a serial interface should be configured as DTE or DCE, because you don't have access to the upstream device?

Iristheangel

Undocumented? No. More like a device that's considered a SP device that you cannot log into and one of the devices you can log into will be directly attached. You might be given a task that wouldn't work if you're just looking at the "show run" output because it's not necessarily an issue with the config on your side but on the other side of the PE-CE link and you'll have to use a series of show commands and debugs to troubleshoot your way around the issue. An example of this in the real world is maybe you're trying to configure DMVPN tunnels and unknown to you, your ISP is blocking TCP port 500 - looking at your "show run" on both sides wouldn't tell you this but understanding how ISAKMP works and using debugs, you would quickly discover what step it failed at and start to troubleshoot.

This is supposed to be an expert-level exam... You won't pass just by "show running" your way to freedom.

joelsfood

In DC Exam at least (I won't speak for any other tracks), it is unlikely you'll need to use a debug, either to solve a question or even to diagnose an error in the rack (while rare, they do happen with the tracks that have physical hardware). But you will need a lot more than show runs, as Iris said. For instance, on the DC track, Jason Lunde had a set of commonly used show commands that he sent to anyoen who took his bootcamp that he recommended knowing for the exam. The list wasn't inclusive by any means, and still had something like 100+ show commands that you might need to troubleshoot/test/confirm a setup in your DC lab. The test is not going to be solved by just memorizing a ****, or even copying and pasting from the various config guides in DocCD.

I think you need to find the middle ground between show run/topology, and debugging every protocol/interface/etc. The only way to really get there is more practice. Rack time, real life work, etc. The goal is to reach the expert level so you not only know the technologies and equipment, or even the configs, but the principles and theories behind them so that you can configure from scratch, troubleshoot existing, and diagnose when you do something wrong (or right) and get unexpected output.

lostindaylight

OctalDump wrote: »

Could you theoretically just use show run and the physical topology to trouble shoot all issues? I mean, if it's cabled right and the configs are ok, are there other things to worry about?

Hi Octal,

In terms of route/switch, perhaps this will help put it in perspective.

The first link is to a fairly realistic V5 network topology:

https://ccie4all.files.wordpress.com/2015/11/main-topology-linkedin.jpg

The second link is a video of Bruno van de Werve walking through a demo of the troubleshooting section.

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

After taking all that in, and understanding you're going to get 10 tickets that cover a broad array of technologies that have to be solved and verified in 2 hours, tell us if you think dumping the running configs of the devices and staring at them in notepad is a realistic strategy.

(hint: the exam is designed to be overwhelming in size, scope, and the amount of information given in order to ensure the candidate can't use recipes or 'tricks' to pass).

OctalDump

lostindaylight wrote: »

After taking all that in, and understanding you're going to get 10 tickets that cover a broad array of technologies that have to be solved and verified in 2 hours, tell us if you think dumping the running configs of the devices and staring at them in notepad is a realistic strategy.

(hint: the exam is designed to be overwhelming in size, scope, and the amount of information given in order to ensure the candidate can't use recipes or 'tricks' to pass).

Yeah, I get all that. I'm not interested in exam strategy per se, just whether the configs would contain the necessary information - or if there are other factors to come into play.

Like what Iris was talking about with service provider systems which are presented as "black boxes" and might behave in unknown ways, you couldn't use "show run" for those, and would have to rely on other methods (although, in real life you could just ask the service provider and hope they know what they are doing).

Another thought is misbehaving hardware, or over utilisation, which wouldn't necessarily show from a show run. Like an issue which might only present under heavy load, or a WIC or NM which starts failing after running for x hours due to heat.

routergods

OctalDump wrote: »

But theoretically, if you were fast enough?

Typing show run everywhere will give you the ugliest config in history along with dozens/hundreds of lines that don't matter.
If passing the CCIE lab was as simple as show run everywhere, we'd have MANY more CCIEs out in the wild.

Ignoring all that... you're assuming that you'll be faster, more accurate, more calm than the thousands of lab exam takers in history.... seems like a big assumption.

DPG

OctalDump wrote: »

Another thought is misbehaving hardware, or over utilisation, which wouldn't necessarily show from a show run. Like an issue which might only present under heavy load, or a WIC or NM which starts failing after running for x hours due to heat.

Unlikely on the CCIE R&S lab since it is all virtual devices.

gorebrush

I don't recall having to do much debugging in my R&S lab to be honest, especially not in the configuration section.

Iristheangel

DPG wrote: »

Unlikely on the CCIE R&S lab since it is all virtual devices.

You're right. Utilization might not be as important in terms of hardware but troubleshooting VPN is a LOT easier with debug commands. Same with BGP. It's a lot quicker to do it that way than shifting through show run on two sides and staring at configs.