My CCIE Journey Has Officially Begun.

jamesp1983

SteveO86 wrote: »

Awesome links!

Looks like you'll be wrapping up the WB's soon enough, the finish line is coming into view for you!

I'm glad you found them useful. I try to record any useful links I come across so that guys who are starting out or are looking for help on a topic have a good resource.

The time is flying by and I am feeling a little nervous now since my lab date is quickly approaching.

SteveO86

I'm always up for reviewing RegEx

Try not to think too much about it bud. Stay focused and steady.

jamesp1983

SteveO86 wrote: »

I'm always up for reviewing RegEx

Try not to think too much about it bud. Stay focused and steady.

Me too haha.

I just keep pushing forward. Thanks!

jamesp1983

IPv6:
IPv6 Configuration Guide, Cisco IOS Release 12.4T* [Cisco IOS Software Releases 12.4 T] - Cisco Systems

IPv6 Command Reference:
http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_book.html

jamesp1983

I hope this command helps someone:
Interface <int>
ip multicast rate-limit out group-list 47 512000
ip multicast rate-limit out 2000000


47 is a specific ACL defining certain multicast groups.

Zartanasaurus

jamesp1983 wrote: »

I hope this command helps someone:
Interface <int>
ip multicast rate-limit out group-list 47 512000
ip multicast rate-limit out 2000000


47 is a specific ACL defining certain multicast groups.

According to the Cisco documentation, the order you enter those commands is important. It's sort of like how ACEs are processed. Also, the group statement limits each source to the rate, not the entire group itself. So if you had 2 sources sending that matched ACL 47, they'd be limited to 1,024,000 in the aggregate.

I saw your post on Lab 19. I didn't like the SG for the same reason a lot of other people didn't like it. The task called for R3 to do the group->RP mappings, which is what the mapping agent does in auto-rp. BSR allows each router to choose who the RP is for a group. So I felt like they were asking you to a) use auto-RP and b) figure out a way around the issue with R4 not receiving the auto-rp messages.

I used an IGMP helper and some other things to get it working that would likely break the rules in the real lab, but I don't think I had a choice if being restricted to auto-RP. I'm also in the habit of never using static mroutes to fix RPF issues because I think these are generally disallowed in the lab, even if they are allowed in INE labs.

However, when you have the choice to use auto-RP or BSR, always go with BSR. It doesn't have the same issues you'd run into with auto-RP like in this lab.

bolano

In my understanding you are allowed to use mroutes in the lab as they are not about influencing/modifying routing path - their only purpose is to pass the RPF check, isn't it?

Zartanasaurus

This is a post from someone over at IEOC about 9 months ago.

I agree that whether or not static mroutes are allow should be a question for the proctor, however... I attended Cisco Live! in Melbourne last month (March 2012), I was lucky enough to attend the Technical Session discussion of CCIE R&S, which was led by the CCIE Program Director - Bruno van de Werve. During question time I asked if static mroutes are allowed in the lab to solve problems like RPF failure... he laughed.
That was his initial response.. laughter.. and then he shook his head, still laughing.
So definitely get clarity from the proctor, but judging by the response I got, static mroutes aren't the answer.

jamesp1983

Zartan, did you use AS path prepending or MED on the BGP section of Lab 19?

Zartanasaurus

jamesp1983 wrote: »

Zartan, did you use AS path prepending or MED on the BGP section of Lab 19?

I don't remember 100%, but when given a choice between the two, I use AS path prepending. I always go with whatever is highest in the selection process.

jamesp1983

Zartanasaurus wrote: »

I don't remember 100%, but when given a choice between the two, I use AS path prepending. I always go with whatever is highest in the selection process.

I do the same.

jamesp1983

Zartanasaurus wrote: »

I never know for sure until I get my score.

How'd you do ? Better than expected?

jamesp1983

I just wrapped up WB2 Lab 19.

Up next:

Week 46: VOL4 Labs 9+10
Week 47: VOL2 Lab 20
Week 48: Mock Lab 4

Zartanasaurus

jamesp1983 wrote: »

How'd you do ? Better than expected?

About my normal score. It was lower than I'm used to, but then I realized TS was only worth 17 points instead of 21-22.

jamesp1983

Zartanasaurus wrote: »

About my normal score. It was lower than I'm used to, but then I realized TS was only worth 17 points instead of 21-22.

Oh, okay. You're moving right along.

jamesp1983

I have been running through some Boson practice tests after a long time away (>8 months) and have noticed a lot of updates. I'm still passing so that is refreshing. The explanations have always been extremely helpful to me and I'm glad Turgon suggested purchasing this software.

jamesp1983

Keep in mind the difference between ospf e1 and e2 and how you can use this to your advantage...

http://ccieat21.wordpress.com/2009/03/12/ospf-forward-metric/

jamesp1983

IPv6 Configuration Guide, Cisco IOS Release 12.4T - Implementing Tunneling for IPv6  [Cisco IOS Software Releases 12.4 T] - Cisco Systems

ipSpace

jamesp1983 wrote: »

Keep in mind the difference between ospf e1 and e2 and how you can use this to your advantage...

OSPF Forward Metric « Ccie@21′s Weblog

Great link James. I am still at OSPF so that was of great help. Daniel did a good job on this article.

jamesp1983

ipSpace wrote: »

Great link James. I am still at OSPF so that was of great help. Daniel did a good job on this article.

No problem! Keep at it!

jamesp1983

I just wrapped Lab 9 and 10 in WB4. 10 seemed easier than 9, but these were more challenging for me than any of the previous TS labs.

What's left of Petr's plan:
Week 47: VOL2 Lab 20
Week 48: Mock Lab 4


I'm thinking I'll complete some WB3 and WB1 labs, a few WB2, and then go over Ruhann's CCIE notes.

I also have Mock Labs 5-7 scheduled as well.

jamesp1983

Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.4T - Configuring Transparent Bridging  [Cisco IOS Software Releases 12.4 T] - Cisco Systems

jamesp1983

I am on task 7.2 of WB2 Lab 20. This has been a challenging workbook due to the constraints that they apply.

jamesp1983

I just finished WB2 Lab 20 so I have completed all of INE's WB's. I guess I will just revisit WBI, 3, and 2 as needed. I have Mock labs 4-7 scheduled so that should help keep me fresh. I might brush up a bit on my theory as well before my 3/29 lab date.

Zartanasaurus

jamesp1983 wrote: »

I just finished WB2 Lab 20 so I have completed all of INE's WB's. I guess I will just revisit WBI, 3, and 2 as needed. I have Mock labs 4-7 scheduled so that should help keep me fresh. I might brush up a bit on my theory as well before my 3/29 lab date.

Did you figure out the vlan filter for PPPoE in Lab 17 (I think)?

jamesp1983

I'll have to revisit that as well.

jamesp1983

I just attempted TS 1 since I tried it initially at work and I kept being interrupted so I did poorly. I didn't look at the answers for the first attempt because I knew I would try again. I did a little better this time, but I still need help. I need to stick to the "If you can't solve it in 5-10 minutes, move on" rule. I waste so much time on a ticket if I think I can solve it. I also tend to solve some of the tickets in a more round about way which burns more time.

Anyone else getting beat up by these TS Labs? (1 and 2)

I also need to start drawing out my multicast/redistribution diagrams, as well as BGP and IPv6. I made a layer 2 diagram from switch sh cdp neigh/sh int output and that made me feel like I had a better grasp of the network. That helped with my comfort level as well.

Zartanasaurus

I had gotten in the habit of drawing out complete L1/L2 diagrams for WB2/4 TS but I don't think the 30 device lab allows for that kind of time. With 10 devices it's not so bad. One thing it may have done was helped me visualize the network and the types of problems to look for at L2 that can affect L3. But in the actual lab, you aren't working with much switching for TS. In the 360 lab I took, there were only L2 devices in one small portion of the topology. Everything else was L3.

I write down all the ticket numbers on a sheet of paper, and after each ticket I resolve, I place a check off to the left, and the time remaining to the right. Once I start working on a ticket, if I don't feel like I have a grasp of what is needed, I move on after 5-6 minutes of poking around. It's instinct as a netadmin to dig in on a problem until you get it resolved, but you have to be smart. You have 10 tickets to do in 2 hours which is 12 minutes per ticket. Writing the times down helps keep you focused on moving on I think.

Once you've knocked out those 8-9 tickets that weren't that hard, you realize you've got 30-60 minutes to knock out 1 or 2 tickets you're stuck on. It's not so bad then. Or if you feel really confident about 8 or 9 tickets, you can just move on to config. Extra points in TS don't help you in config, but an extra hour might.

I got beat up by the first TS lab due to some shell shock at the large topology and technology understanding shortcomings. I feel much better about it having done it 3 times now though.

Zartanasaurus

Another way to think about it:

You KNOW they're going to screw with you with frame-relay somehow. What are the things they can do?
lmi mismatch
frame-relay encapsulation mismatch
Wrong IP configured on interface.
Wrong IP configured in frame-relay map.
Wrong DLCI # configured (probably transposed digits that LOOK right at a glance)
shutdown main interface
keepalive not disabled on back to back FR
keepalive disabled on non back to back FR
Mismatch DLCIs on back to back FR without frame-relay local DLCI command.
On the FRSW:
Wrong DLCI
Wrong interface type
No clocking
Mistake in frame-relay route/connect config

So what are the fastest ways to figure this out from show/debug commands?

show frame pvc | i ST (DELETED = problem, STATIC = no keepalive configured)
show frame map (check for misconfigured IPs)
deb frame lmi (yourseen = 0 for LMI mismatches)
sh frame route or show connect all
Everything else is easy to spot with the interface config IMO

Then think about how FR can affect routing protocols. Probably the biggest is not enabling pseudo broadcast on a DLCI.

I kind of have a laundry list of things for each topic and debug/show commands I use to figure out the problems.

jamesp1983

Thanks so much! That is really a great list that you have compiled. I know what you mean about feeling shell shocked by the larger topology because that's exactly how I felt during my first attempt. I was thinking about taking it one more time so that I'm comfortable with this large topology.

What 360 Labs do you recommend? I'd like to get a couple of those under my belt prior to the real lab.