New guy going for CCIE

Turgon

reaper81 wrote: »

Rack rentals finally open for sessions again. Have one schedule for tonight, will try to complete 2 INE TS labs. Next week I will start to focus on QoS and when I'm done with QoS I will probably take a mock lab to see where I am in my studies.

QoS is a big topic and the program I am following has 4 weeks of QoS. My only concern is that I don't want to stay away from routing&switching for 4 weeks so I might mix it up with some Vol3 labs.

Mix it up. At least half an hour each day reading the notes you made that cover all the protocols will keep you frosty across topics while you concentrate on a single subject like QoS for a while.

reaper81

Completed INE TS lab 1. This one was really tough. More difficult than ASET labs I did earlier. Lots of sneaky issues but very good practice. Going to do one more TS lab tomorrow and then on to QoS. Will probably hit 600 hours this week.

Turgon

reaper81 wrote: »

Completed INE TS lab 1. This one was really tough. More difficult than ASET labs I did earlier. Lots of sneaky issues but very good practice. Going to do one more TS lab tomorrow and then on to QoS. Will probably hit 600 hours this week.

Good. It's the daily studying that's getting you there. Some of the other CCIE study threads are stalling without that. For my part Im up early and at my study notes. Keep at it.

reaper81

Good Turgon. Just keep at it.

I'm having difficulty finding the time to do the amount of notes I would like. Need to find a way to get everything down in notes. Maybe I should skip writing by hand and put it into a file on the computer directly.

Turgon

reaper81 wrote: »

Good Turgon. Just keep at it.

I'm having difficulty finding the time to do the amount of notes I would like. Need to find a way to get everything down in notes. Maybe I should skip writing by hand and put it into a file on the computer directly.

I just use one word document called 'CCIE Constructs' now. Suggest you do the same. Its painful, but you want your configuration notes in one word document. The reading and labbing is fine but those revision notes will get you a lab pass. Take the pain and start now. Have sections for every protocol..break the protocol into subsections..then type the config example. Dont hung up on detailed notes about how stuff works, by this stage if you are labbing regularly you just need to look at the config. You will work it out and should know the nuances of PBR and local policy etc. You will pick that stuff up as you do your labs anyway.

I probably spent 100 hours typing config content out of Vol II into first a spreadsheet, then porting into mnemosyne, then cut and paste into a word document. I must flee now as I have 5 meetings today. The people working for me study for exams..I dont have the time.

reaper81

Turgon wrote: »

I just use one word document called 'CCIE Constructs' now. Suggest you do the same. Its painful, but you want your configuration notes in one word document. The reading and labbing is fine but those revision notes will get you a lab pass. Take the pain and start now. Have sections for every protocol..break the protocol into subsections..then type the config example. Dont hung up on detailed notes about how stuff works, by this stage if you are labbing regularly you just need to look at the config. You will work it out and should know the nuances of PBR and local policy etc. You will pick that stuff up as you do your labs anyway.

I probably spent 100 hours typing config content out of Vol II into first a spreadsheet, then porting into mnemosyne, then cut and paste into a word document. I must flee now as I have 5 meetings today. The people working for me study for exams..I dont have the time.

Yeah, that might be a good way of doing it. For now I have mostly focused on putting scenarios in my notes. Configure this feature etc but it takes huge amount of time porting Vol1, Vol2 etc into notes as you have noticed. From now on I'll just keep a document with configuration and gotchas etc from my labs.

jamesp1983

reaper81 wrote: »

Yeah, that might be a good way of doing it. For now I have mostly focused on putting scenarios in my notes. Configure this feature etc but it takes huge amount of time porting Vol1, Vol2 etc into notes as you have noticed. From now on I'll just keep a document with configuration and gotchas etc from my labs.

Do you think the single document or a notebook is the best way to document your configs?

reaper81

jimmypizzle83 wrote: »

Do you think the single document or a notebook is the best way to document your configs?

I'm having some serious thoughts on this. One option is getting the handbook from Ruhann @ Routing-bits but then you will miss out on some personal notes. I do have a notebook that I use when I do the labs.

I'm not sure creating a super document is the way to go, it is just so time consuming. However we do need some form of notes. I guess it's a personal thing.

jamesp1983

reaper81 wrote: »

I'm having some serious thoughts on this. One option is getting the handbook from Ruhann @ Routing-bits but then you will miss out on some personal notes. I do have a notebook that I use when I do the labs.

I'm not sure creating a super document is the way to go, it is just so time consuming. However we do need some form of notes. I guess it's a personal thing.

handbook from Ruhann @ Routing-bits - I've never even heard of that handbook, but I was thinking it'd be useful to use someone else's notes in addition to my own for final prep.

Forsaken_GA

reaper81 wrote: »

I'm having some serious thoughts on this. One option is getting the handbook from Ruhann @ Routing-bits but then you will miss out on some personal notes. I do have a notebook that I use when I do the labs.

I'm not sure creating a super document is the way to go, it is just so time consuming. However we do need some form of notes. I guess it's a personal thing.

Ruhann's book is worth it. I just printed it out, and mark up the printout as I feel necessary, it seems to be working well so far

Turgon

reaper81 wrote: »

I'm having some serious thoughts on this. One option is getting the handbook from Ruhann @ Routing-bits but then you will miss out on some personal notes. I do have a notebook that I use when I do the labs.

I'm not sure creating a super document is the way to go, it is just so time consuming. However we do need some form of notes. I guess it's a personal thing.

A super document is the way to go. You will not complete it at this stage of your prep but just get the sections in there anyway! By the time you get to my stage its less super, 300 - 400 pages of hurt because you jettison stuff you have already got down.

NOC-Ninja

reaper81 wrote: »

Are you doing the breakout switch or the quad port NIC setup? I've never done this myself but the way I understand it you connect routers to cloud which is actually NIC going to breakout switch or to switches. What does your .net look like?

Im still waiting for my 3560 and another 3550 to arrive. Also, I'm bidding right now for another 3560.

Im not doing the NIC. Im doing something different. Ill show it to you as soon as it works.

jamesp1983

NOC-Ninja wrote: »

Im still waiting for my 3560 and another 3550 to arrive. Also, I'm bidding right now for another 3560.

Im not doing the NIC. Im doing something different. Ill show it to you as soon as it works.

Where are you getting your equipment from? All from ebay?

NOC-Ninja

jimmypizzle83 wrote: »

Where are you getting your equipment from? All from ebay?

ebay and monoprice

if you add computer then newegg

reaper81

Did a vol4 TS lab yesterday. Went recently well. Learned a command I have not used before, debug ip packet detail ****. The **** at the end is the first time I've used and it's hidden from the command parser. Let's you see a **** of packets. Pretty cool

Turgon

reaper81 wrote: »

Did a vol4 TS lab yesterday. Went recently well. Learned a command I have not used before, debug ip packet detail ****. The **** at the end is the first time I've used and it's hidden from the command parser. Let's you see a **** of packets. Pretty cool

hehehe..there are many hidden commands in the IOS.

reaper81

600 baby. Hit 600 hours today. Going through all stuff sure take time. I think I need to hit at least 1000 before being ready for lab. Just need to keep pushing.

Turgon

reaper81 wrote: »

600 baby. Hit 600 hours today. Going through all stuff sure take time. I think I need to hit at least 1000 before being ready for lab. Just need to keep pushing.

Good progress. I think once you get 400 lab hours you are in the zone. Its really then about doing it everyday. Congratulations on the staying power because as we have seen most CCIE wannabees bow out long before accumulating the hours you have. More note taking for me this morning before a trip to a DC for some hands on with checkpoint and VSS..INE Vol II IP Services at 7:43 AM!

jamesp1983

reaper81 wrote: »

600 baby. Hit 600 hours today. Going through all stuff sure take time. I think I need to hit at least 1000 before being ready for lab. Just need to keep pushing.

That has to be a good feeling. Do you feel a lot more comfortable with the material at this point? Also, excellent blog. I was just checking out some of your posts. keep pushing man.

reaper81

There is a huge difference from when I began but I still have many topics I need to get better at. Thanks on the blog. I like to be really prepared, maybe I might be overpreparing if there is such a thing but I won't know until I get to the lab

reaper81

Started with the QoS section yesterday. Got roughly 4.5 hours of studies done. Mostly legacy stuff in the beginning of the QoS labs but its good to get the history and most of the newer stuff is based on this anyway.

Will try my best to keep a good pace until the finish line. These are the months that will make or break my lab attempt.

Turgon

reaper81 wrote: »

There is a huge difference from when I began but I still have many topics I need to get better at. Thanks on the blog. I like to be really prepared, maybe I might be overpreparing if there is such a thing but I won't know until I get to the lab

Why are you overpreparing? What you are doing is typical. Besides, once you have the CCIE moniker you have lot to live up to in the field. Expectations. Study well or you may want to hide that CCIE number when you are called into certain technical meetings in the future. It's much more than just an exam.

Turgon

reaper81 wrote: »

Started with the QoS section yesterday. Got roughly 4.5 hours of studies done. Mostly legacy stuff in the beginning of the QoS labs but its good to get the history and most of the newer stuff is based on this anyway.

Will try my best to keep a good pace until the finish line. These are the months that will make or break my lab attempt.

Yup keep at it each day now. Im reading my INE Vol II examples on QoS today.

reaper81

More QoS studies done. GTS and CAR was covered. Although these are legacy protocols I must say they are handy to use for putting in a quick shaper/policer. Not anything I would use in production but certainly a good tool to have in your belt.

Turgon

reaper81 wrote: »

More QoS studies done. GTS and CAR was covered. Although these are legacy protocols I must say they are handy to use for putting in a quick shaper/policer. Not anything I would use in production but certainly a good tool to have in your belt.

Absolutley. There is a chance that you may be given a lab question to convert from a legacy protocol or one where you are not allowed to use MQC to fullfill a requirement. I think looking at the legacy protocols is also good to understand the new way of doing things better i.e MQC. MQC was an attempt to provide a common interface to the plethora of different QoS mechanisms that developed over time.

reaper81

More QoS studies. No racks were available so did some reading/videos instead. Have a double session coming up tomorrow. Will keep going with the QoS and mix it up with some Vol3 next week to keep my core fresh. QoS is an area I enjoy but there is a lot to know when you start looking at queues for Catalyst switches etc.

Had a situation a couple of months ago where some of this knowledge could have definately helped. Was troubleshooting a multicast issue for several months and Cisco TAC was involved. First we thought it was related to Q-in-Q but turned out that people sending the multicast feed had the default queues in Catalyst and traffic was being dropped. 3560/3750 are very sensitive to bursty traffic when you have rates at several hundred Mbit/s.

Turgon

reaper81 wrote: »

More QoS studies. No racks were available so did some reading/videos instead. Have a double session coming up tomorrow. Will keep going with the QoS and mix it up with some Vol3 next week to keep my core fresh. QoS is an area I enjoy but there is a lot to know when you start looking at queues for Catalyst switches etc.

Had a situation a couple of months ago where some of this knowledge could have definately helped. Was troubleshooting a multicast issue for several months and Cisco TAC was involved. First we thought it was related to Q-in-Q but turned out that people sending the multicast feed had the default queues in Catalyst and traffic was being dropped. 3560/3750 are very sensitive to bursty traffic when you have rates at several hundred Mbit/s.

Interesting. What work arounds config wise would you propose to improve matters? Priority queue matching on the multicast IP address perhaps?

I know what you mean about hardware queues and Catalyst switches, its something of a black art.

reaper81

Turgon wrote: »

Interesting. What work arounds config wise would you propose to improve matters? Priority queue matching on the multicast IP address perhaps?

I know what you mean about hardware queues and Catalyst switches, its something of a black art.

If I remember correctly there are 4 hardware queues for output on the Catalyst. By default every queue gets 25% of the buffer space. The people sending the multicast did no QoS at all and everything was ending up in one queue. The solution was to assign more of the buffers to the queue that the multicast traffic was ending up in. I've heard people say that it's better to assign all buffers to one queue but I can't swear on that. Anyhow Cisco TAC increased the buffers for the queue with a command I can't remember right now. There is a lot of tweaking available if you know what you're doing, running auto-QoS could be an option too I guess.

Turgon

reaper81 wrote: »

If I remember correctly there are 4 hardware queues for output on the Catalyst. By default every queue gets 25% of the buffer space. The people sending the multicast did no QoS at all and everything was ending up in one queue. The solution was to assign more of the buffers to the queue that the multicast traffic was ending up in. I've heard people say that it's better to assign all buffers to one queue but I can't swear on that. Anyhow Cisco TAC increased the buffers for the queue with a command I can't remember right now. There is a lot of tweaking available if you know what you're doing, running auto-QoS could be an option too I guess.

Sounds about right, but I would have to look it up. There are a couple of configs below that relate to queues and buffers.

3560 egress queues tuning

SW1
mls qos srr-queue output dscp-map threshold 3 46
mls qos srr-queue output dscp-map threshold 2 8 10 18 34

mls qos queue-set output 2 threshold 1 200 150 100 250
mls qos queue-set output 2 threshold 2 200 150 10 250
mls qos queue-set output 2 threshold 3 200 150 100 250
mls qos queue-set output 2 threshold 4 200 150 100 250

mls qos queue-set output 2 buffers 10 70 10 10

3560 Ingress Queuing

mls qos

mls qos srr-queue input threshold 2 80 100
mls qos srr-queue input cos-map threshold 2 6 7
mls qos srr-queue input buffers 25 75

reaper81

Turgon wrote: »

Sounds about right, but I would have to look it up. There are a couple of configs below that relate to queues and buffers.

3560 egress queues tuning

SW1
mls qos srr-queue output dscp-map threshold 3 46
mls qos srr-queue output dscp-map threshold 2 8 10 18 34

mls qos queue-set output 2 threshold 1 200 150 100 250
mls qos queue-set output 2 threshold 2 200 150 10 250
mls qos queue-set output 2 threshold 3 200 150 100 250
mls qos queue-set output 2 threshold 4 200 150 100 250

mls qos queue-set output 2 buffers 10 70 10 10

3560 Ingress Queuing

mls qos

mls qos srr-queue input threshold 2 80 100
mls qos srr-queue input cos-map threshold 2 6 7
mls qos srr-queue input buffers 25 75

Yeah, those are the ones. The buffers was increased with mls qos queue-set output 2 buffers command. I think queue 2 is default if you don't specify anything? The threshold was also increased with mls qos queue-set output 2 threshold command. Can't remember the actual numbers though.