Saturday, June 27, 2009

Next Attempt Scheduled

I went ahead and schedule my 3rd attempt for August 21st. My plan in the meantime is as follows:

Step 1: Read a novel to get some relaxation in. I picked up Snow Crash from Borders today.

Step 2: Read MPLS Configuration on Cisco IOS. I used a soft copy of this book as a resource for CCIP and the written and found it really helpful. I'm going to pick up a hard copy and read it from cover to cover this time.

Step 3: I might redo one or two vendor labs, but for the most part I want to break away from hard core labbing and do more experimentation. Try putting together interesting architectures on paper and see if I can make them work.

Step 3.5: Pray that core questions don't come out by August 21st.

Step 4: Pass the lab :)


I just wanted to say thanks to everyone for your comments. I'll tell you what, when I undertook this journey 9 months ago I was under the impression that the SP lab wouldn't be a big deal. After 2 attempts I'd say that this is much harder than the R&S lab.

To answer some of the prep questions, after doing all of the INE labs and many of the IPX labs, I'd say both are great resources but neither are enough to pass the lab. I can't really get into why too much, but in general I'd say about 30 points on the my last attempt were either based on, or required by, items that weren't coverd by any of the labs I've completed thus far.

Also, while I haven't talked about it much, I have reviewed some of the SP mini scenarios as well. They do a great job covering some of the topics that aren't covered in the other labs.

For any of the vendors out there who might be reading, there's something that I would really LOVE to see in a product. Put together 10 labs based on the same core. Have the same BGP, IS-IS, and OSPF domains and areas preconfigured. Load the configs and start from there. Maybe even make lab 1 building the core. Then make lab 2 an option 1 inter-as vpn, lab 3 an option 2, and lab 4 and option 5. On the lab 5 labs throw in different complexities such as internet access and CSC, on top of the cores. Just my thoughts...

Bottom Line

I'd say the score was pretty representative on how I feel about the blueprint right now. I'm really comfortable with the core and basic vpn topics and have an "I know I can make just about anything work" attitude.

But when it comes to advanced vpn topics, the configuration is more like a house of cards to me. I can play with it and eventually make it work, but then I'm kind of afraid to touch it and make it all fall down. I need to have the same level of confidence with advanced vpn topics as I do with the rest of the lab.

So I've decided to go back and do some reading. I'm still torn on scheduling an exam in August. Two months out would give me a month for reading and another month for labbing. I might as well go ahead and schedule it.

Friday, June 26, 2009

More studying to do

My score definitely improved, but I still have a little bit to go. I ended up around 70%, with quite a few perfect sections. Unfortunately, the couple of tasks I couldn't do put a possible pass out of reach.

I'm not too discouraged. This isn't a back to the drawing board score. There are just a couple of things I need to get better at.

There aren't any more exams available until August. I'm going to sleep on it to decide if I want to take try #3 then, or hold of a bit.

Waiting Game

Well, I gave it my best shot. Things really started out great. I got stuck in the beginning for about 10 minutes on a trivial task, which seems to happen a lot as I'm getting rid of my morning jitters. After that, I was flying through the exam. By lunch I counted up 67 points and figured I'd have this thing nailed.

Unfortunately after lunch things got a lot tougher. Some things I didn't really know how to do, and others just didn't want to seem to work. And as they love to do, those two tasks that I was stuck on had another 9 points depending on them. So I had little choice but to work around it. I did consider a workaround, but it would have been tough. When I already have 67 points in the lab, I'm so hesitant to add duct tape and risk losing points elsewhere.

So by time I made my first pass, I counted 87 points and had an hour left. I was feeling pretty good because I think a rule of thumb is to expect to lose 6 of your "sure thing" points. But then I went through verification and one of my 3 point tasks was broken. I only had 30 minutes so I crossed my fingers and did a few reboots. Fortunately everything came back up. Unfortunately, my 3 points didn't come back.

I was left with 84 points, that I felt pretty good about. Not a lot of room to spare.

So at this point I'm figured I didn't pass. If I did it'll be a pleasant surprise, but I'm planning for the worst.

The shame is if I could have got that one task to work, I would have easily collected another 5 points after and would most likely be celebrating tonight.

Stay tuned for the results...

Thursday, June 25, 2009

Squeezing in a little more

I went ahead and did IPX Vol 1 labs on l2vpn and multi-as vpn. I took my time with them and played around with some different configs as well.

I definitely learned some new things so I'm glad I did this.
  • To do a frame-relay xconnect, the first the "connect" command must be used from global configuration mode. This specified the dlci and underneath it the xconnect is created
  • When using multi-as vpn option 3, a three-deep label stack is created. In order: 1) ldp label 2) bgp label and 3) vpn label. The ldp label is used to forward the packet to the AS border router, the bgp label gets the packet to the downstream PE, and the vpn label associates the packet with the proper vpn. I never caught on to the fact that an additional label is used for the bgp label.
  • Along with sh ip bgp label, sh ip bgp vpnv4 all label shows the vpn labels.
Well, I think I'm as ready as I'm gonna get. I'm hoping for a good night's rest and some good news tomorrow night!

Incidently, the SP grading takes a lot longer than the R&S grading did. Last time I knew I didn't have a chance, so the extra wait wasn't bad. If I think I'm close, the suspense is gonna drive me crazy.

Wednesday, June 24, 2009

Final Preparations

Ok, I think I'm done labbing. I don't want to burn myself out by Friday.

First I'd like to critique my approach last time. I made two major mistakes. First, I didn't redraw the lab diagram. Second, I didn't draw a vpn diagram. I fully believe the failure to do this contributed to my failure. I typically draw an IGP/multicast diagram and a VPN/BGP diagram. Not sure why I didn't do this on the real thing.

Here's what worried me before the last lab:
1. PPPoE: I was struggling before and I usually get it to come right up now. DHCP, local pools, and encryption are non-issues.
2. L2VPN: I setup a few xconnects. Still not much to it so hopefully this won't be a problem.
3. IS-IS knobs: IP Expert covered these really well and I feel a lot better about them now.
4. Advanced BGP features: No change here, but they're still covered well in the doccd
5. MPLS knobs: These are covered well on IPexpert
6. Multicast: MSDP is going much better now, but really convoluted setups can still throw me off.
7. QoS: I think I understand qos-groups better now
8. Security: No change
9. System Management and IP Services: No change
10. VPN: I feel MUCH better about VPN now. I thought I had it down before, but I was really pretty clueless with the inter-as stuff. I'm really comfortable with option 1 and 2, and 3 is going well now too.

Since my last attempt, here's what I accomplished:
INE: Repeat labs 1 and 2
IPX: Vol 3 labs 1-4 and Vol 2 labs 1-3.
All in all, I found the single best next step in preparing for the lab to be IPX Vol 2 lab 1. But I guess Friday will be the real judge for that.

Tuesday, June 23, 2009

IPX Vol 2 Lab 3

No issues

I had to look up the syntax for one of the PPPoE tasks. I always seem to forget the pppoe-client command on the client end. I'll do "pppoe ?" and since I space through the hyphen I don't see it.
I also ran into an issue with getting the dhcp lease to take. I needed to use the "peer default ip address dhcp-pool" command and also need to stop transposing numbers in ip addresses!
Regardless, I got all this figured out without looking at the answers, so there's no deduction. I can't help it, I still get a smile on my face when PPPoE comes up.

I misunderstood a couple of the requirements, which I'm not taking off for because a proctor would have been able to clarify. I also didn't know the bandwidth for STM-4 off the top of my head, nor did I have any idea where this would be on the doccd. I'm not taking off for that either because that doesn't seem like a likely lab question.

-4 to disable mospf, the command is "ignore lsa mospf".

Wow, what a pain this lab is! Nothing terribly difficult, just a lot of little things to keep you on top of your game. Overwritten communities, default configs that break stuff, requriements mentioned early on that you have to remember for later tasks, recursive routing, and interesting "features" making you do stuff the hard way.

-3 confused fast-external-fallover with graceful restart (AGAIN!!!)

-3 missed mpls ldp discovery targeted-hello accept from X

-8 Ok, this lab was fair until this step. Every time I think I'm getting more comfortable with MSDP and bgp ipv4 multicast, these labs throw a curve ball at me. And this was one serious curve ball. A total of 8 points wrapped up in a convoluted community passing, route-map next-hop adjusting, and filtering bgp ipv4 multicast domain for controlling mRPF checks. What a mess. I had it 90% of the way, but no partial credit is given. I would be SHOCKED to see something this messy on the lab...

No issues. I went with option 2, but the solutions guide used option 3. Either way seemed to meet the requirements, but I typically have better luck with option 2.

Security, QoS, and IOS (Reviewing):
-3 I probably would have missed some of the flow-export knobs

Total score: 79/100. Of that, 8 points was due to a rediculous multicast requirement. Even if something was that bad on the lab, I'd expect it to be 3 points and not 8. Other than that, this lab mainly focused on IGP and BGP, with a lot of flexibility given on the VPN setup. It was LONG, but really not too bad. The troubleshooting due to bad initial configs was great practice as well.

Sunday, June 21, 2009

INE Vol 2 Lab 3

I completed this lab again and it only took about 4 hours. I'm shocked this lab has a difficulty of 8. The IP core is easy and the l3vpn core is a basic mutli-as option 1 configuration.

About the only difficult step of the entire lab is a multicast vpn task involving multiple mdt's. The problem with this task though is it is buggy as well and difficult to verify. I couldn't get things up even though my config seemed to match the solutions guide. So I'll deduct 5 points for that task, plus the testing task since my pings failed.

Final score 95/100

Now to be clear, I think the INE labs are great labs. I think for the most part they're well put together and cover the wide range of topics well. The problem is they're just too easy for the most part. I didn't remember very much of this lab from the last time I completed in in February, yet it wasn't nearly as complex as the IPX labs.

On to IPX lab 3 tomorrow. 4 days until the real thing.

Friday, June 19, 2009

IPX Vol 2 Lab 2

Lan and Wan:
PPP address assignment: peer default address
-1 VTP Transparent saves the vlan information in the config
-1 load-interval controls collection rate (drew a blank on this one...I typically know it)

-3 advertise passive-only to only advertise isis passive interfaces in IS-IS
-3 lsp-mtu changes the lsp size. I can't believe I couldn't find this one, it was right in front of me.

-3 forgot maximum-paths ibgp

No issues

-4 ip multicast multipath allows for load splitting in multicast

No issues!!! This one was only inter-as option 2, so it wasn't so bad. I ran into a small issue becuase my next-hop-self's weren't set. But once I got that fixed, there wasn't a problem. The thing to keep in mind about option 2 is there are 3 separate mpls domains:
1 2 3

MPLS labels must be flooded across the entire domain, so send-lables or ldp must be running between AS1P and AS2P.

But unlike Option 3, in Option 2 AS1P and AS2P DO understand the VPN label. So the top label can be popped and a lookup on the vpn label can occur. Therefore, there are actually more lookups on the VPN label, but this greatly simplifies configuration (for me anyway!).

Multicast VPN:
No issues

-2 I'm using Dynamips and the first task is 3550 specific. I probably would have missed the second subtask, so I'm taking off for it.

IOS Services:
-2 missed the snmp ifmib ifalias long knob

Total Score: 81/100 Passed! (Barely)

Strangely, this lab was much easier than the first one. There really weren't too many "gotcha's" here and the vpn and multicast configs were rather painless.

Wednesday, June 17, 2009

IPExpert SP Volume 2 Lab 1

Layer 2:
-2 Needed to set dlci to ietf encap as well
-3 Forgot to disable inverse arp

No issues, other than a few attributed to poor wording a proctor would be able to clarify. Not deducting points...

-3 Missed ISIS configuration

No issues...

Internet Access:
No issues

-3 Lots of issues dealing with TE tunnels. Wow, just when I think I have these down, they throw a big curve ball at me. So when doing multi-area OSPF, explicit paths can only be set via loose mode.

No issues

I FINALLY got inter-as vpnv4 multihop to work!!! Yes, it still took me forever. To the point where I had to sleep on it for a bit. But it actually does work! Sleeping on it during the lab may not be possible though...:).

Here's a little checklist. I'll try it out on the next lab to see how it goes:
1. From the CE router, verify a route exists through the PE router
2. At the PE router, verify a bgp vpnv4 route exists, with a next-hop of a remote PE router
3. At the PE router, verify a label exists for the next-hop, either via sh ip bgp labels or sh mpls for
4. If things appear to be configured correctly, clear mpls ldp neigh *, clear ip bgp * soft, or even reload

Multicast and IOS Services:

Ok, for lab 1, this thing sure was tough! On thing I definitely have to say about the IPX labs is you cannot take getting the IGP and MPLS stuff up for granted. The IE labs tended to throw a pretty vanilla IGP config at you and focus the rest at complex vpn scenarios. But IPX throws a lot of curveballs early on, and not only do you have to figure them out, but you have to adapt the VPN configs around them.

If I were to recommend a study approach, I'd probably suggest something like this:
1. IE CoD
2. IE Vol 1
3. IPX Vol 3 Labs 1-4
4. IE Vol 2 Labs 1-5
5. IPX Vol 2
6. IE Vol 2 Labs 6-10, IPX Vol 3 Lab 5

Thursday, June 11, 2009

IPExpert SP Volume 3 Lab 5

Layer 2:
-4 VTP version 2 is required for a transparent mode switch to forward VTP messages that have not been authenticated.

-4 BGP Advertisement interval is different from bgp scan interval

-4 I need a better understanding on targeted hellos

Lots of stuff going on here, but no major issues

VPN across non-MPLS core:
Well, as usual I was having issues getting this part working. I REALLY need to get this down before I sit for the lab. I found the underlying issue which was my label switch path was broken at the first intermediary AS router. No matter what I did, I couldn't seem to get it working. Then after WAY too much time troubleshooting, it dawned on me that I had a route map configured and have to set mpls labels on the route-map. Unfortunately once I did this the label still wasn't showing up in the forwarding table, even though it now showed up properly in the bgp labels. I tried to do a reboot and for some reason my configuration did not come back :(.

So I have to write this one off as a failure. I'll definitely need to repeat it before I sit on the 26th. I won't be getting much studying in the next few days because I have family visiting.

Tuesday, June 9, 2009

IE SP Vol 2 Lab 2

Ok, change of page--I decided to attack IE vol 2 lab 2 again.

Layer 2:
No issues, not even with PPPoE--yay!

No issues

No issues

No issues

Ahhh, now here was a nice complicated VPN scenario. Not too many tricks up their sleeves, but i definitely had to do some thinking.

Send-labels was not required, even though the two ASs weren't running MPLS. This is because the vpnv4 routers were back to back so an ipv4 lookup was possible at each AS edge router. Now if the AS edge routers weren't vpnv4 routers, they wouldn't understand the vpn tag and would have dropped the packet. If that were the case, send-labels (and next-hop-unchanged) would have been necessary.

I had a little bit of an issue with VRF Internet Access, but I eventually got it worked out. A stupid mistake where I did "ip nat source" instead of "ip nat inside source".

Finally, the solutions guide used an export map which sets bgp communities and then filters them on the PE routers to filter the management interfaces. Ugh, I thought that was an ugly method. I went with an import map that just filtered the ips out on the PEs without having to mess with communities.

They went with a tunnel, but my mdt worked just fine too.

I just couldn't get mpls marking to work. I tried topmost and imposition, and verified the packets were getting marked on their way out, but the never showed up as marked on the other side. The solutions agreed wtih my first method. I'm gonna write this off as a dynamips frame switch issue.

I'm just going to review the rest of the lab since I pretty much know how to do these. Besides, the Management and Services section is more of an easter egg hunting than experience anyway.

Final thoughts: No real issues on the lab at all.

Sunday, June 7, 2009

IPExpert SP Volume 3 Lab 4 Complete

Layer 2:
No issues

I've never heard of isis mesh-groups before. From the task, it sounded like a split-horizon type of technology, and that's exactly what it does. In essence, don't flood a route out a mesh-group interface if you received the route from another interface in that mesh group.

No issues

Messed up MSDP AGAIN!!! Ugh, I was so close this time. I spent some time verifying and was able to see the packets flowing, but they were getting stopped due to null output interface. No RPF issues and the loopbacks were running pim, so I couldn't figure it out. Turns out the external peer didn't have an RP, so the sa cache was empty on the inside peer. Once I statically made the external peer an RP, the internal peer's sa cache populated and pings went through.

No issues

L2/L3 VPN:
The basic VPN topology is still way too simple. No issues until the end when I got to the L2 part. I never would have dreamed of encapsulating a q-in-q tunnel inside of l2vpn--very cool!
I cheated and used a vlan other than 49 instead, so -2 for breaking the rules of one of the tasks.

QoS and Security:
Blew setting DSCP for RSVP

Lots of really ambiguous working on the other tasks in this section. I would have been able to ask a proctor for clarification if this were real, so I'm not deducting points. On two tasks, I chose the wrong option.

Chose the wrong banner. More ambiguity. I'll take these points off though. -2
Wrong telnet config, -2
Wrong interface buffer config, -2

Lab complete, 86%

The lab definitely got more complicated this time. The VPN is still a bit on the easy side, but everything else is about right now. A lot of ambiguity that I probably could have got points on with a proctor to talk to.

Speed is good too. Total time was 6 hours, with quite a few short breaks.

Saturday, June 6, 2009

Study Schedule

Here is my study schedule up to the lab date:

6/7-8: IPX Vol 3 Lab 4
6/9-10: IPX Vol 3 Lab 5
6/11-12: IPX Vol 2 Lab 1
6/13-14: IPX Vol 2 Lab 2
6/15-16: IPX Vol 2 Lab 3
6/17-18: IPX Vol 2 Lab 4
6/18-19: IPX Vol 2 Lab 5
6/20: INE Vol2 Lab 2
6/21: INE Vol2 Lab 3
6/22-23: INE Vol2 Lab4
6/24: INE Vol2 Lab5
6/25: INE Vol2 Lab6

Hopefully that will do the trick. There are two pieces I really need to focus on. First is Multi-AS MPLS VPNs, I always have a really tough time spotting the issues and getting them up.

Second is vpn multicast in general, especially msdp and mdt verification. It's usually some stupid mistake preventing me from getting them up and running.

Thursday, June 4, 2009

IPExpert SP Volume 3 Lab 3 Cont

I had no clue how to fix an untagged lfib issue. It turned out to be a problem with ospf advertising a different mask than what was configured for the interface. Due to this, the ospf neighbors had a label entry for the /32, but the host router did not have a local binding, since the /32 did not actually exist on the router. Closer inspection of the bindings on the ospf neighbors shows the remote bindings are actually for the neighbors, not for the host. Once OSPF advertised the correct mask, the LDP neighbor as able to associate the labels appropriately. -4

I also completely misunderstood what implicit withdraw did. -2

Got hung up for a bit on a export map because I needed to do a soft bgp reset to get the export map to take effect

Needed to match on EXP instead of Prec. I got hung up on whether or not I needed to do a QoS group, decided I didn't, and then didn't even think to still match on EXP.

Saw the ip identd command, but couldn't find it in the QoS reference so I didn't feel good about enabling it. Turns out this should have been more in Security than QoS. The command was located in that section.

High Availability:
No issues

No issues

Lab 3 complete, 84%. Ok, now we're getting down to business. This lab was much more in the style of what I'd expect to run into. The core was still a bit on the simplistic side, but the nobs and tricky questions are definitely getting up to speed.

All in all I feel pretty good about this one. A couple of small mistakes but the only real show stopper was the missing mpls tags due to the ospf loopback address.

Wednesday, June 3, 2009

IPExpert SP Volume 3 Lab 3

My work schedule changed a little bit so it was no longer convenient to rent rack time at proctor labs for the IP Expert labs. I had things going on the new IP Expert dynamips topology, but for some reason I just couldn't get dot1q trunking to work. I finally reverted to an older 3640 IP Expert topology, which seems to be working better.

Here we go with Lab 3

Layer 2 - No issues

IGP - No issues. Strangely, IGP seems to be getting more into R&S territory than what I'd expect to see on the SP lab.

-3 for confusing deterministic med and always compare med...AGAIN!!!
I also skipped task 1.4 for now since it can't be verified until a later section

-3 for confusing multicast boundary with ip igmp access-group

Halfway done with this lab. While the architecture isn't much more difficult, the wording is getting tricker and more vague, which is great in preparing for the real thing.