Say you are running RIP, & you wish to debug ip rip.

Typically you will see every 30 seconds a barrage of output from the debug.

If you are only interested in seeing the debug on a particular interface/subinterface, this is where debug condition helps.

So say we have R1 with the following interfaces all running RIP:

R1#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            100.1.111.1     YES manual up                    up
Serial0/0                  unassigned      YES unset  up                    up
Serial0/0.12               10.1.12.1       YES manual up                    up
Serial0/0.13               10.1.13.1       YES manual up                    up
Serial0/0.14               10.1.14.1       YES manual up                    up
FastEthernet0/1            unassigned      YES unset  up                    up
Serial0/1                  10.1.100.1      YES manual up                    up

If we are only interested in debug ip rip for s0/0.14 we can do this:

R1#debug condition interface s0/0.14
Condition 1 set
R1#

R1#debug ip rip
RIP protocol debugging is on
R1#
RIP: received v2 update from 10.1.14.4 on Serial0/0.14
10.1.45.0/24 via 0.0.0.0 in 1 hops
10.1.46.0/24 via 0.0.0.0 in 1 hops
10.1.56.0/24 via 0.0.0.0 in 2 hops

Cool we can see debug condition working its magic.

You can select multiple interfaces/subinterfaces with debug condition.

To view the current list of interfaces with debug condition:

R1#sh debug condition

Condition 1: interface Se0/0.14 (1 flags triggered)
Flags: Se0/0.14

Something to bear in mind here, is that doing: undebug all does NOT remove debug condition.

So if you want to remove the debug condition on your interfaces you need to do (in this case)

no debug condition interface s0/0.14

If s0/0.14 was the only remaining interface with the debug condition you’ll see the following:

R1#no debug condition int s0/0.14
This condition is the last interface condition set.
Removing all conditions may cause a flood of debugging
messages to result, unless specific debugging flags
are first removed.

Proceed with removal? [yes/no]: yes

NB. As s0/0.14 had condition id of 1, you could have also done: no debug condition 1 instead of no debug int s0/0.14.

Finally, debug condition can be used in quite a varied no of ways as seen below:

R1#debug condition ?
application  Application
called       called number
calling      calling
card         card
glbp         interface group
interface    interface
ip           IP address
mac-address  MAC address
match-list   apply the match-list
standby      interface group
username     username
vcid         VC ID
vlan         vlan

Hi all

Studying for the R&S, at times has had to take a back seat to my job hunting.

My contract is ending somewhat shortly so I am on the lookout.

Anyway, I am continuing to progress through Narbik’s workbooks.

Progress is slow, but sure. Like Nickelby I am making sure I understand what I am doing.

I am also at times coming up with different solutions to Narbik’s; it’s certainly good to know one’s options.

However, in the midst of all this, I didn’t book my lab date. With all the version 3 lab dates pretty much taken, I’ve resigned myself to version 4.

This is not a big deal for me as such…I’ve spent a large amount of my career troubleshooting, and I am CCIP, plus the network I currently manage has an MPLS backbone, so I’m by far no stranger to MPLS.

So I am looking at version 4 in a positive light.

Sure, more work will be needed, but I will be a better engineer for it.

So my plan still stands in that I will study until I feel I am ready, and only at that point will I book the lab for the earliest available date.

Additionally for me, with time being taken on the job hunting aspect, for me it’s better that I do not have a lab date booked.

Narbik will, at some point, be returning to our UK shores, with his new spangled “best of the best” bootcamp . Having attended his bootcamp previously I am very interested in seeing how his new bootcamp will differ, seeing that he is also incorporating the 360 program into the bootcamp…

Narbik also mentions the new bootcamp will be more intense.

I found it pretty intense the 1st time around, and sometimes had to rely on red bull (it gives u wings) to keep focused. I think even after awhile red bull stopped doing its thing

Anyway back to studies.

To start off with, I’d like to give thanks to Stuart Juggins of Networks Inc, who helped make this possible.
Stuart approached Narbik and managed to get him to come over to the UK and teach here.
Thanks Stuart!

I had always wanted to attend Narbiks bootcamp due to all the great things I had heard about it, but once I found out it was just over an hour from my home, I just HAD to attend.

This was the 1st of what will probably be many times that Narbik visits our shores for bootcamp purposes.

As has been mentioned before, Narbik uses a whiteboard, some coloured pens, & his insane memory of the cli.
The commands he was able to write on the whiteboard from memory were quite frankly, staggering at times.

I mean, to be able to list all the options under match, under a class-map is just 1 example.

Narbik starts off by telling you to only believe what he says if he has tested it/shown it to be true.
Narbik does not tell you anything that he has not personally tested and verified to be true.
If there is something Narbik is unsure about (which rarely happens), Narbik will hold his hands up and say he doesnt know. However these instances typically correspond to things occurring within the IOS that only the guy who coded the IOS would know.

Narbik does not repeat something (unless you ask him to repeat it).
This means you need to be 100% focused on what he is saying.
He will start with any topic from the basics, but quickly he will build on it, and pretty often to a level which you may be unfamiliar with.
I mean, I thought I knew RIP prior to this bootcamp.
I sat back, and said internally “you are talking about RIP?! cmon jeez”.
Well I didnt pay attention for a very short period and in that time Narbik mentioned something, and I thought…ok maybe i didnt know rip too well
But this is a GOOD thing!
Narbik mentions that you need to respect technologies.
There is always something to learn, to know about a technology, so give everything the respect it deserves.

Upon reflection, I would say I actually found BGP an easier lecture for the most part than certain aspects of RIP, so this should tell you something.. (hopefully not that my RIP sucks lol).

Narbik is very REAL WORLD.
He does go deep into everything, but as Ali G likes to say he “keeps it real”.
He doesnt go into the toilet-flushing-5 times methods (if you follow groupstudy you will understand what I mean)

Now prior to this bootcamp, I would have followed the configure/verify model.
After this bootcamp, I intend to follow the configure/verify/test model.
There are instances where you can configure & verify something looks fine, but until you actually TEST that its working, you may not be 100% sure that it works.
Additionally, say you make a mistake in your verification…if you also test something is working, say with ping, you can easily see whether it is working, or not.

Tips:

Bring a notepad, & maybe a multicolored pen.

Be ready to pay attention to everything that is being said.

Be as prepared as you can for the bootcamp.

The more you know (or think you know, in my case ), the better off you will be.

Ideally prepare a list of questions that you have, anomalies, anything that you need clarification on.

Also, if you make notes in shorthand, even better.

Having said this, the workbooks does go into verification & testing with explanations, so they will be a refresher for the things you hear in the bootcamp.

Conclusion
I’m so glad I went to this bootcamp, as I have been exposed to, and have learned things that I would just not have learned otherwise.
I can only recommend others to make a beeline, as Darby Weaver puts it, to this bootcamp.
You will not regret it.
Value for money wise, its hard to beat; you get 7 bound workbooks which are focus based, as well as other labs.

Narbik does have a great sense of humour, so its worth attending just for the jokes

And watch out the little men!

Today Narbik covered OSPF & EIGRP.

I have to say, I did learn quite a bit today.

Now I thought I knew these topics to a fair degree, but every time Narbik starts talking about stuff that makes me question what I really do know.

This is a good thing. We are here to be challenged, to learn new things, and thats certainly happening at this bootcamp.

Anyway off to sleep soon, to be ready for another day of learning

Well, day 1 was yesterday.

Quite a day it was, running from 9am till 9pm-ish.

We were all delayed at the beginning of the day due to idle timeouts to the terminal server.

For users of securecrt under session options, its pretty eas to resolve this…just send a character every 5 secs or something.

As I am using iterm under mac os x, I somewhat struggled here.

Did find an option to send an ASCII character on timeout for default terminal profile (iterm users will know what I mean). Will test it today to see if my sessions time out.

If my sessions still time out, Ill just switch to the windows virtual machine, and use securecrt.

As I didnt have securecrt under windows, this was the main reason I didnt use windows from the start.

Anyway will see how things go today with the idle timeout.

On the learning side of things, Narbik went over elements of layer 2 security (DHCP snopping, dynamic arp inspection etc), and later covered frame relay.

Now I thought I could not learn anything more about frame relay prior to attending, but there were a few surprises, and I learned stuff that I just havent seen from books etc.

Narbik’s memory really is something else…as others have said, there are no slides, its all whiteboard.

Narbik also does not like you using a option unless its really needed, eg…a lot of ppl *cough* will put no frame inverse under the main serial interface. Well if theres no IP address under the main interface, why do no frame inv? After all no inarp requests will be sent out a main interface that has no IP address assigned to it.

Narbik also does not like the use of the broadcast keyword used after frame maps unless its really needed

—

Didn’t really get much work done after the bootcamp this night, as some of my colleagues and I spent some time just trying to find a chinese that was open The chinese takeaway was ridicilously expensive too…can you say over 5 quid for special fried rice?!

Anyway Im sure today will go smoother.

There is a certain challenge though that needs to be overcome and that is with ppl talking about various things non bootcamp related, and you are trying to concentrate

Someone in gs mentioned the use of earplugs, and I can see why!

All in all though yesterday was a good day.