Saturday, December 5, 2009

.net file for INE CCIE Security volume I

I've had a request for the .net file for volume 1. Here is what I have been using, more or less. For assistance getting the pix setup, see blindhog's blog at http://www.blindhog.net/category/pemu/

Note: I've removed the serial number and registration key. This is a linux version of the Dynagen.

begin file
----------------------------------------
model = 2620
ghostios = True
sparsemem = True

[localhost]
workingdir = /home/ccie/working

[[2620]]
ram = 64

image = /opt/images/C2600-IK.BIN
idlepc = 0x804a39b8

[[ROUTER R1]]
fa0/0 = sw 1
model = 2620

[[ROUTER R2]]
fa0/0 = sw 2
model = 2620

[[ROUTER R3]]
fa0/0 = sw 3
model = 2620

[[ROUTER R4]]
fa0/0 = sw 4
model = 2620

[[ETHSW sw]]
1 = dot1q 121
2 = dot1q 122
3 = access 123
4 = access 124
10 = access 123
11 = dot1q 1
12 = access 124


[pemu localhost]

[[525]]
#for pix 7 & 8
serial = xxx
license = 0xyyy 0xyyy 0xyyy 0xyyy
image = /opt/images/pix804.bin

[[fw fw1]]

# Connect the firewall's e2 interface to the virtual switch, which will bridge it
# to the real network
e0 = sw 10
e1 = sw 11
e2 = sw 12

Sunday, November 29, 2009

INE Vol 1 Access Control and Configuring NAT Complete

Nothing too difficult here. I did run into a little bit of an issue getting DNS doctoring to work, but it was because my inspect dns was turned off. Once I got the inspect rules right, everything worked as it should.

Friday, November 27, 2009

INE Vol 1 labs underway

Over Thanksgiving I did 9 or 10 of INE's vol 1 labs. It's quite nice to have such a small topology for a change. My laptop has no problems running 3 routers and a Pix in Dynamips/pemu, which is plenty of devices for the first part of vol 1. With the SP laps I needed another dedicated box to get all 12 routers running smoothly.

I haven't really touched any security devices in a year and a half, although I did spend several years with Pix/ASAs, 3000 series vpn concentrators/clients, IDS, etc. For the most part Vol 1 is encompassing getting back in the groove on the old equipment, and is showing me how to do the CCIE level configs on these devices.

I'm really not in a rush at all. If I get Vol 1 done by the end of the year I'd be pretty happy with my progress.

Friday, November 20, 2009

And Away We Go

Two down, four to go. I don't know if I'll actually make it through all six, but continuing down the CCIE road still feels like the best road for me to follow. None of the alternatives are very appealing at this time: PhD, MBA, open source development, or CCDE. So I'll keep getting CCIEs until my priorities change.

I think I've learned a lot in the process of getting R&S and SP and can hopefully apply it to Security.

First, I tried to fly through SP way too fast. It still ended up taking about a year to complete. This is covered in rfc 1925: you can't make a baby in much less than 9 months.

Second, I should have begun labbing much sooner. Personally, I NEED experience before I get theory thrown at me. I'm not going to touch the class on demand, books, or written exam before I go through volume 1. Otherwise, the theory is over my head and I end up zoning out for much of it. I do better learning the how's first, and then getting to the why's after the fact.

Third, I need to do full scale labs from both IPX and INE before my first lab attempt. Last time I tried to just use INE first, and I had a lot of gaps going into my first attempt.

That being said, my rough schedule is something like this:
November 09 - March 10: INE Vol 1
April - May: Written
May - June: INE Vol 2
July - August: IPX Vol 2
September: Lab Attempt #1

Thursday, November 12, 2009

How to get from R&S to SP

From my experience, these are the most beneficial steps to pass the CCIE SP, assuming you already have R&S.

1. Don't believe the rumors you've heard that SP is easy once you have R&S. It's NOT true. While there are a few overlaps, about 60% of the SP exam is completely different. And that 60% is going to be tough. Don't go into this lightly.

2. There really isn't much benefit in getting the CCIP first. However, I would strongly recommend passing the BGP+MPLS exam. This covers the MPLS foundation and some of the BGP topics geared towards SP. If you can read some books and pass exams, do so. If you need more hands on, do some Vol 1 labs and come back to this before attempting the SP written.

3. Unlike R&S, there really isn't a single book that prepares you well. I didn't mind Configuring MPLS on Cisco IOS Software, but it wasn't nearly as good as the Doyle books for R&S were. I really felt pretty lost going after the written. But with R&S knowledge and passing BGP+MPLS, you'll be pretty close.

4. Just like R&S, the Internetwork Expert Videos are a must. Nearly everything you need to pass the lab are covered in these 40 hours. These videos give you a great foundation, you'll just need to remember it all and learn to apply it.

5. Go through all the Volume 1 labs from your provider of choice (in my case INE or IPX). These give you a great foundation for covering the full scale labs. Don't get lazy, do them all!

6. Focus on the Following labs, in order:
a. Start off with IPX Volume 3 labs 1-4. These are great for getting you ramped up to full scale labs. I didn't care for lab 5 much.
b. Do the INE Vol 2 labs. These are especially important for having interesting VPN topologies to configure. They are tough, but keep at it until you fully understand them.
c. Do IPX lab Vol 2 lab 1. If there is a reason to spend the money on the IPX workbook, this is it. INE teaches the toplogies well, but IPX teaches the knobs and question style well. Do this lab!
d. Attend the INE SP Bootcamp. Their labs 1 and 2 are great and cover some topics that aren't really covered well anywhere else.

7. Once again, don't think you can rush through this. It's going to take a lot of work. But, once you're finished you're going to have a real respect for MPLS and the things that can be accomplished with it.

Passed!!!

I finally made it through!!! Whew, that was a challenge. I'm going to relax for a bit and then put together a guide for getting from R&S to SP. In the meantime, time to have some drinks and kill off some of those brain cells that have been tied up for the past year.

Waiting Again

Here we go again, I'm waiting for the score to post.

This time, I had an estimated 77 points before lunch, and had the entire lab completed in 5 hours. My max score was 97%. I went through a very detailed verification and found 9 points that I made stupid mistakes on--basically not reading the requirements properly.

I did run into one situation where I decided to proceed with one method instead of the other. On the drive home it occurred to me a possibility I didn't test for that might have required the other method. The most I could see that costing me is 6 points.

Also, there were another 6 points that I was pretty sure about, but may have been open to interpretation.

So, the absolute worst score I can see myself getting is 85%. This is a lot like when I passed the R&S lab. I better have passed this time!

Sunday, November 8, 2009

INE Bootcamp Lab 2 Complete

This lab wasn't too bad either. I did run into a few issues this time though. A few things I just need to pound into my head.

1. is-is knobs
2. vrf nat requires the global keyword on the ip route vrf
3. for mdt, make sure all of the intermediate interfaces have pim enabled
4. Peak rate vs average rate

I'd put my score as follows:
Layer 2: 7/7
IGP: 17/23
BGP: 7/7
MPLS: 14/14
VPN: 12/16
Multicast: 4/11
QoS: 3/6
Security: 6/6
Management: 7/7
IP Services: 3/3
Total: 80/100

Friday, November 6, 2009

INE Bootcamp Lab 1 Complete

I have 6 days left until my attempt, and I sure took my time getting back into studying.

I didn't run into any major issues at all with lab 1. I didn't have to look up anything and was able to get l2vpn, atm, pppoe, and l3vpn up and running. Final score was 96%. I lost 4 points because I couldn't find a netflow knob. I didn't spend too much time looking for it and would have probably come across it eventually.

On to lab 2...

Friday, September 11, 2009

INE Bootcamp Over

Note I didn't say the bootcamp was complete. Especially when it comes to lab 3, I have a lot of work to do. The three bootcamp labs cover most of the lab topics really well, I feel. After taking three real attempts, I didn't see many core topics that weren't covered in these labs. Sure it wasn't exactly the same, and there are always going to be some knobs that they dig up for the real labs that aren't covered anywhere else, but there's not much you can do to prepare for that besides knowing the DocCD well.

But as far as fundamentals, it's pretty much all covered in these 3 labs. Therefore, my plan is to revert back to my R&S study ways, which was to study every weekend, instead of trying to squeeze study time in during the week.

So I'm going to repeat these 3 labs over and over again until I have them down pat. One on each Sunday. That should give me about 3 practices each, and everything in them should be second nature by then. I'm pretty optimistic that this will get me over that 4% hump.

Tuesday, September 8, 2009

INE SP Online Bootcamp Lab 1

Wow, I actually passed the first mock lab. All I can say is this lab is MUCH better preparation than the INE vol 2 workbook.

Final score: 80%. I missed 4 points from lack of understanding, 8 points from stupid mistakes, and 8 points weren't attempted (long story...).

Aside from the lab, it's also quite nice to rent Scott Morris for the week as he gives excellent explanations. I managed to ingrain 3 or 4 fundamental concepts into my head which I didn't quite catch onto before. I hear the next two labs are much tougher so I hope I'm up to the challenge.

Friday, September 4, 2009

Signed up for INE bootcamp next week

To further ensure my success in November, I signed up for the INE online SP bootcamp next week. I debated for a bit whether or not to take it, but it was a great deal and I know, even with my 76%, I still have some areas that could use a lot of help.

Sunday, August 23, 2009

You've got to be kidding me...

I got my score report back about 2 hours ago. I totaled my score up 3 different times, because I couldn't believe my eyes.

76%

That's right, 76%

100% in 4 different sections, and not quite enough in the rest.

Not even any point in a reread, because I'd need them to give me 2 tasks, not just 1.

So it looks like I'll be back in November...

Friday, August 21, 2009

Lab Recreates

Ok, I've officially verified that I missed 6 points this lab and 12 points on my last lab due to the same stupid mistake. Remove the command and I get the exact same failure. Add it back in, and everything works like a champ.

On top of that, I recreated another 3 points and sure enough one of my ideas did the trick. I actually went down that road but the "?" led me astray. Probably exactly why they have that question in the lab--it doesn't look possible unless you really trust what you're configuring.

So now I'm up to 9 points that I really should have got.

Regardless of the outcome, I'm feeling really good anyway. I KNOW this stuff and I can definitely pass this lab. The core knowledge is there, I just need to work my way through their "gotachas".

The Waiting Game

Had the lab again today. It was fair and about 50% of it was pretty simple. My progress was almost identical to last time. I had about 60% by lunch and just had to eek out another 20% to pass.

Yet again, as soon as I get back from lunch, I get stuck. I give it an hour and decide to give up the 6 points. I'm now at home researching and I think I found out why I got stuck. And it's ridiculously stupid. I'm pretty sure I needed those 6 points too. Ugh...

So my best possible score is 85%. This includes 3 points I nearly missed but got back during verification, and 3 points I completed with literally 2 minutes to spare.

Of the 15 points I know I missed:
6 points were pure stupidity...
3 points I had no idea how to do and didn't want to muck of my core by messing with it
3 points I looked up in the doccd, and it was such a mess I chose not to mess with it
3 points I knew wasn't a strong point of mine so I chose to spend more time on other issues

So really, I'm not too concerned about 9 of the points I left on the table. And if I got the other 6 points, I would have had more time to go after those 9.

So it's all basically going to come down to how solid my vpn setup is. I have my fingers crossed.

Thursday, August 20, 2009

The "Wake Up Call"

Tomorrow will be my 5th CCIE lab--2 for R&S and now 3 for SP. One of the interesting pieces that all 4 of my labs had in common was the "Wake up call".

I'm referring to something that comes up early in the lab, usually within the first 30 minutes of configuration, that just doesn't want to work. It typically seems to be something intentionally done by the proctor in the initial config, with a purpose to test those troubleshooting skills or make you doubt yourself early on in the lab.

Naturally, I can't get into the details of what the wake up call itself was, but I think how long it takes to find this single error has been a predictor of my success on the entire lab.

Lab 1 (R&S): My nerves were really going on this one. I was configuring the second or third task of IGP when something SIMPLE just wouldn't work. I began to doubt myself and wonder if I misunderstood the technology. Or did I screw up the switching config to break this? Finally, after an hour and a half of troubleshooting, I found the initial config problem. I couldn't believe it took me so long to find it.... Final score: 65%. That hour and a half probably cost me a passing score.

Lab 2 (R&S): Before I even started with the config, I reviewed all of the initial configs. I found a problem off the bat. And it could have been a NASTY one if I just started with configuration right away. Final score: PASS

Lab 3 (SP): I actually hit this one in MPLS--unfortunately I didn't realize it until VPN. That hurt! I spent over an hour (maybe 2!) troubleshooting a VPN problem because my MPLS config wasn't sound. I never had a chance on this lab. Final score: 45%.

Lab 4 (SP): I hit the problem right off the bat in the first few tasks. Within about 15 minutes I was able to workaround this issue, but to this day I still wonder if I did the correct fix. I ran into some funky vpn issues later on that I think may have been related to an incorrect fix early on. I also surprisingly lost some points in switching, while I was perfect in everything else leading up to vpn. I think I missed something in the beginning that killed my whole lab. Final score 65%.

Gameplan for lab 5: Review configs before I start, and trust my troubleshooting skills, not my config. In other words, use show and debug commands to check EVERYTHING. Are required adjacencies present? Do pings work? Is the LSP good? Take nothing for granted.

Wednesday, August 19, 2009

Still going...

Completed IPX vol 2 lab 3 and IPX vol 1 l2vpn and CSC labs.

At this point I'm getting real tired of labbing. As I run through these things over and over again, I rarely find anything new. For the most part it's just refreshing all of this information in my head.

The bottom line is that it's pretty much all in here. As long as I don't get caught on something stupid again on Friday, I should do just fine. I'm done with full labs at this point. I'm going to redo some of the vol 1 IPX labs and maybe some vol 1 INE labs tomorrow, but more than anything just try to not burn myself out before the real thing.

Monday, August 17, 2009

IPX Lab 2 complete

My lab is on Friday and my goal is to get through vpn and multicast sections on IPX labs 2-4.

I completed lab 2 today and didn't really run into too many issues. On to lab 3 tomorrow. I'm not going to be spending too much time on the writeups, you'll just have to take my word for it that I'm completing these :).

Friday, July 24, 2009

Gotta get back on the horse

Work has been pretty busy lately so I haven't had any time at all to study. I'm less than a month out now so I have to get going. This weekend is already taken, so I need to get started again by Monday.

Tuesday, July 7, 2009

Snow Crash Complete

Interesting book. It was a quick read, kind of a cross between William Gibson, Dan Brown, and Michael Crichton. The ending was kind of weak (like many of Crichton's), but the rest held my attention. I'm also trying to ignore a morally offensive chapter near the end. I am really interested in picking up Crytonomicon next, once I get the SP lab out of the way.

Time to get back to studying and away from the book reviews. I'm planning on spending the rest of July experimenting with Inter-AS VPN, CSC, and Multicast to see what kind of trouble I can get myself into. After that I'll probably knock out the last 3 IPX labs and repeat a couple more INE labs before my 3rd (and hopefully final!) attempt.

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 :)

Thanks

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

Switching:
No issues

WAN:
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.

IS-IS and OSPF:
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".

BGP:
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!!!)

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


Multicast:
-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...

VPN:
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)

IS-IS and OSPF:
-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.

BGP:
-3 forgot maximum-paths ibgp

MPLS:
No issues

Multicast:
-4 ip multicast multipath allows for load splitting in multicast

MPLS VPN:
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:
PE----AS1P-----AS2P----PE
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

QoS:
-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

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

OSPF:
-3 Missed ISIS configuration

BGP:
No issues...

Internet Access:
No issues

MPLS:
-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.

mBGP:
No issues

L3VPN:
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:
Reviewed

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.

BGP:
-4 BGP Advertisement interval is different from bgp scan interval

MPLS:
-4 I need a better understanding on targeted hellos

VPN:
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!

IGP:
No issues

BGP:
No issues

MPLS:
No issues

VPN:
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.

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

QoS:
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

IGP:
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.
-2

BGP:
No issues

Multicast:
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.
-3

MPLS:
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
-3

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.

Management:
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

MPLS:
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

VPN:
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

QoS:
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.
-3

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.
-2

High Availability:
No issues

Management:
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.

BGP
-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

Multicast
-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.

Monday, May 25, 2009

IPExpert SP Volume 3 Lab 2 Cont

MPLS:
No issues

MP-BGP:
No issues

MPLS VPN
No issues. I correctly chose to use an import map. Strangely, I had only configured export maps before, so it was nice to use the other method for a change.

PE-CE Routing:
I missed an earlier requirement to configure all bgp peers for soft-reconfig. When the new bgp peering session was created, this should have been configured as well. Aside from that, I didn't have any issues with the intuitive redistribution. Would have been a -3, but I messed up this task to begin with anyway, so omitting the requirement here didn't hurt me.

QoS:
I almost missed the match-any when I did http and secure-http. Aside from that, during verification I was able to verify secure-http, but couldn't get http to show up in the counters. I have a feeling it's just NBAR looking for a certain pattern that I wasn't providing.

Also, for CBWFQ the solution specifies fair-queuing on the default class. While this is often a good idea to confiure in practice, I don't see where this is specified in the lab.

Lab 2 Complete. In general, this lab is still too easy. However, it is getting trickier with the knobs and early requirements getting "undone" by later tasks. There were a few options that I hadn't configured before, which is a good thing.

Total score: 89/100. The points were missed due to misundersanding bgp and isis knobs, lack of experience with mlg virtual-templates, and a stupid snmp mistake. I'm not concerned. I just hope the topology and multicast get more complex in the next few labs. Topics such as domain-id, down bits, TE, send-labels, SOO, and mtp haven't even been touched yet.

Thursday, May 21, 2009

IPExpert SP Volume 3 Lab 2

I hope they made lab 2 a little more challenging.

Frame Relay:
No issues

Switching:
No issues

PPP:
Hey, finally something new. I've never created a ppp mlg using a virtual-template before. Pretty straightforward and the media-independent ppp section of the doccd covers it well. Chap, however, is a bit strange. It has to be configured on the serial interfaces and not the mlg.
-4 points on this task since I did chap wrong.

ISIS:
I chose domain-password instead of area-password. Domain-password uses level-2 lsps, while area-password uses level-1 lsps. The task specified area. -2

BGP:
I was fortunate to get the first task right. "New style bgp configuration" means using address families for configuration. Also, to optimize updates, use a peer group. I actually went with a peer session instead of a peer group, because I haven't seen it before. It seems a little more modular than peer groups and separates bgp session commands from bgp update commands.

I did, however, go with graceful-restart instead of fast-external-fallover. I didn't go with the latter because it seemed to be doing the opposite. Turned out that this is turned on by default and I needed to turn it off to meet the task requirements.
-3

IOS Service:
No issues

Security:
I just applied the access-group to the interfaces, but COPP is an interesting solution as well. A method I'll need to keep in mind.

Logging trap is used to set the syslog logging level.
-2

Multicast:
I finally seem to be catching onto multicast. This called for a pretty straightforward anycast implementation. I did get caught up for a little bit on rpf failures, which ended up being due to an unreachable rp. Once it was added to isis almost everything worked fine. One exception is the host router still got rpf failures when attempting to ping its own igmp address. This appeared to be because its own traffic had to go through the RP instead of staying local, and no interfaces could be made the RP for the routers own traffic.

IPExpert SP Volume 3 Lab 1 Cont

OSPF:
No issues

BGP:
Used peer groups for the fun of it
I made a stupid mistake on a summary address that would have cost me 3 points. If I had reviewed the running config I would have caught it.

Security:
No issues

Multicast:
Had to look up rp filtering syntax, but aside from that, no issues

MPLS:
No issues

MP-BGP:
No issues

VPN:
Took me a minute to remember how as-override works

QoS:
No issues

Ok, this lab was really easy. I suppose it's a good warm-up to get me on the studying horse again.

Tuesday, May 19, 2009

IPExpert SP Volume 3 Lab 1

Section 1:
sh frame-relay pvc can verify a DE list via "in DE pkts" and "out DE pkts"

Section 2:
Wow, I totally misread the span session requirements. Even if I had read it right, rspan isn't a problem, but remembering to add it to be allowed across the trunk likely would have been.

Section 3:
no issues

Section 4:
More stupid mistakes. MFR isn't a problem as long as the solution's guide is followed. However I duplicated another ip address which caused 50% success. I spent quite a bit of time troubleshooting what I thought was a physical layer issue before a debug ip packet showed half my packets trying to go out another interface.

Monday, May 18, 2009

I'm baaaaaccccckkkkk!

Ok, so that break took a little longer than I expected. I had been pretty busy between work, reading, golf, and enjoying family life. But not that I'm about a month out I need to get back on the horse.

I ended up purchasing the IPExpert SP Lab Mentoring Kit because I wanted to use another vendor but I really didn't feel the need to go through all the basics again. I wasn't too far off on my last attempt. I was mostly just missing a couple of advanced topics which cost me time to complete the other loose ends and verification time. So I'm hopeful these five labs will do the trick. Additionally, they are supposed to include video walkthroughs of each lab, which should be pretty handy for areas I'm stuck on.

Thursday, April 16, 2009

2nd Attempt Scheduled

I've scheduled my second attempt at the SP lab in RTP for June 26th. I spent last week on some much needed time off and put very little thought toward the CCIE or any work related matters. I've also decided to take a breather this week and next to re-energize for another full two months of lab prep.

After evaluating my failure, I feel the root cause was due to two factors.

First, toward the end of my studies I reverted to a brute force approach instead of taking my time and ensuring I fully groked the material. In the beginning of my studies I was very diligent in researching new topics, such as soo, down bits, and such subjects. But when I moved on to full scale labs, I stopped doing this. When something didn't work, I kept changing the config manically until I was able to get things to come up.

Second, I think I simply rushed into the lab too fast. I only really spent 2 months on full scale labs. I feel this was too much information too quickly for my brain to absorb. Since the next two months should be review and reinforcement, I'm hopeful the material will be much more natural to me.

I'm going to go back to rejuvination mode and will be back for studying at the end of April.

Tuesday, March 31, 2009

Next Steps

First off, I wanted to say thanks to everyone's comments over the past couple of days. I'm now trying to figure out what to do next.

I scheduled the lab this week because I have a family wedding to attend at the beach next week, so I'll be taking some time to relax and unwind. The big question is what to do next.

My score on the lab ended up right around 50%. I'm not surprised because not only did I spend all my time troubleshooting and point hunting, but I didn't have any time to verify (since I had no shot at even an 80, what was the point?). Typically I like to spend the last hour just going over the entire lab step by step verifying configs.

I could repeat the IE labs and lab up some of the SP mini scenarios . I really do believe 90% of the lab was covered by the IE labs. I would just rank the real thing as more of a 9 on the difficulty scale. I was studying for it like it'd be a 7, as was the case for the R&S lab. It turned out the actual lab was a little harder than the IE labs.

Another option would be to use IPexpert. I used them as well for R&S. I really found the annoying lack of clarity in the IPexpert tasks to be great practice for the lab.

I've also seen some folks recommend iementor.com's products for SP.

It looks like I'll have to wait until July to retake the lab, unless I want to schedule it for the week of Memorial Day, which I really don't.

I also think I'm going to buy a hard copy of at least one MPLS book. I've done ALL of my studying via Books Online and the DocCd, and I think I'd like to have something physical to thumb through.

Monday, March 30, 2009

No Chance

I'm still waiting for the score report, but I know I don't have a chance to pass. Even if I got everything right that I thought I did, I'd still be left with less than 80.

So what happened? I can blame a little bit on poorly written tasks, but for the most part I simply wasn't ready.

There are still too many topics that I can figure out if I spend 15 or 20 minutes troubleshooting. I need to be automatic with all of these.

I lost an hour troubleshooting a stupid mistake that I would have caught right away if I had verified properly. What's worse is I did I verify it, but I missed something. Not only did I lose valuable time, but I kind of spooked myself when I got stuck on something so vital. By time I found it I was a little burned out as well.

I also didn't stick to my game plan. For some silly reason, I opted to skip the VPN diagram right away. I was having a hard time understanding some of the requirements, so I chose to jump right in instead of doing a diagram. What the heck was I thinking? Regardless, this may have made the VPN portion take longer than normal, but it wasn't a killer.

In a nutshell, there are 4 or 5 topics that I need to be COMPLETELY automatic on. I need to have the ability to look at the topology and already know the issues and how to work around them. This is the level I was at when I passed R&S.

When you can look at the topology and think "I bet they're gonna throw this, that, and this other thing at me, and here's how I'll work around it", then you're ready.

All in all, it was a fair exam. If I was a little more solid in 2 or 3 more areas, and had another hour, I believe I would have passed.

Internetwork Expert did a great job for preparing me for the exam. There material is great, I just plain wasn't ready yet. I need to put more time in.

I'm waiting for the score report now to see how I fared on the tasks I think I completed. If my total score is in the 60% range, then I'm right on track. If it's much lower than that, then I really misunderstood some of the requirements or my attention to detail faltered.

I plan on shooting for it again in May.

Sunday, March 29, 2009

Game Plan for tomorrow

Here is how I plan to attack the lab.

1. Contrary to popular strategy, I am NOT going to do a read-through the first time. In the past I've found doing a read-through to be a waste of time because my short-term memory just ain't that good.

2. If there are troubleshooting tasks, review the config and spend 30 minutes or so trying to spot them.

3. Attack L2, IGP, and EGP immediately after. I'll go ahead and configure authentication/encryption type tasks that aren't required for core connectivity, but I won't hesitate to skip them if I hit a snag.

4. Diagram entire BGP/VPN topology. Note that I wait until core is complete before doing this. I like having a good feel for the core before starting the diagram.

5. Complete the VPN configuration. While I'm comfortable with TE now, I'll consider skipping it if it's just a few points because it just seems to have a habit of breaking other things. If I can have VPN completed before lunch, I'll be extremely happy because that should give me plenty of time to polish off the other tasks and do verifications.

6. Diagram and complete multicast. Nothing too fancy of the diagram, I just find it greatly helps me spot rpf and inter-AS issues when I have a separate mcast diagram drawn out. Unfortunately, I know how nasty multicast can be from the R&S lab, so I need prepared to give up these points altogether if need be.

7. Complete the rest of the lab. Consider skipping any traffic filtering related security tasks altogether. If I'm feeling confident in my points, I'm not even going to bother with them because I'm just too afraid of breaking my core. Seems like there's always a routing protocol or tunnel involved that get broken. If I must filter, I'm going to throw an explicit deny log at the end of the access-list so I can see everything that's getting dropped.

At this point, hopefully I have at least an hour left to go back through the lab, step by step, to verify everything. When I passed R&S, I found at least 6 points doing this that were due to stupid omissions (e.g. only applying QoS policy to R5 instead of R5 and R6).

Then, with 30 minutes left, I won't make any more configuration changes unless ABSOLUTELY necessary.

My speed has been fine though, so I'll be a little surprised if I don't have the whole lab wrapped up with 2 hours to spare. If I do, I'll probably keep doing verifications and annoy the proctor with the pickiest little questions I can think of until the labs over or the proctor kicks me out.

And here's what worries me:
Layer 2:
PPPoE. I've done a few basic configs, but it seems like it could get pretty complicated.
l2tp/AToM. There really isn't much to it, so it shouldn't give me any problems.
ATM: I have the basics down, but if some knobs get thrown my way I could have issues.

IGP: IS-IS knobs make me a little nervous.

EGP: I could have spent more time on advanced BGP features like orf and fast external failover. But these seem to be covered well in the doccd.

MPLS: ldp knobs, such as funky neighbor attributes, label filtering, and label retention

VPN: Making sure to spot if/where I need to use domain-id, sham links, and soo. Broken LSPs can be nasty to figure out too.

Multicast:
I'm happy with MDTs and bgp ipv4 multicast now. I'm still a little uncomfortable with MSDP. I think I just have to keep in mind that if I don't have a pim path between two hosts, I'll need two RPs and will need to join them with MSDP.

QoS: They always seem to find something nasty I haven't thought of. I'll just need to spend a little extra time verifying that what I put on is working properly

Security: Bottom line, don't break the core

System Management and IP Services: Gotta find those knobs.

MPLS VPN Inter-AS Feature Guide

This document could be a life saver tomorrow. It's located under the 12.0S(29) feature guides.

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsiasleb.html

It has a wealth of information on the send label command, route reflectors, and peering non-adjacent vpnv4 routers.

Saturday, March 28, 2009

IE SP Vol 2 Lab 10

Ok, I've changed my mind and decided to give lab 10 another try.

4:27pm lab started
4:35pm 1.1 complete, 3
4:43pm 1.2 complete, 3
4:45pm 1.3 complete, 3
4:49pm 1.4 complete, 3
Layer 2 complete, 12/12, 0:22

5:07pm 1.1 complete, 3
5:13pm 1.2 complete, 3
5:15pm 1.3 complete, 3
IGP complete, 9/9, 0:26

5:24pm 3.1 complete, 4
5:32pm 3.2 complete, 3 -- probably gonna need some next-hop-self's later but I'll add them when req'd.
EGP complete, 7/7, 0:17

5:42pm 4.1 complete, 3
6:01pm 4.2 complete, 3
6:09pm 4.3 complete, 3
6:24pm 4.4 complete, 3
MPLS complete, 12/12, 0:52

8:20am back from break
8:33am vpn diagram complete
8:49am 5.1 complete, 3
8:57am 5.2 complete, 3
9:58am 5.3 0/4 -- this one completely blew my mind. So it IS possible to have an interface participate in multiple vrf's using the vrf selection source command. I'm glad I decided to do lab 10 or I would have had no idea about this if I run into it tomorrow.

10:21am back from break
10:54am 4/4. Got this one, and it works beautifully! In summary, vrf leaking occurs on the way out so traffic can leave the vrf and go out to the global routing table. But on the way back in, the PE router needs to know which traffic goes to which vrf. The vrf selection commands enable the router to put the flows into the proper vrf on the way back to the P network. This essentially requires three steps.

1. Create the vrf and assicated rd and rt's on the PE router
2. Leak the vrf routes out to the global routing table for the downstream C networks
3. Inject the upstream C routes into the global routing table so the downstream C networks have reachability back
4. Specify which source networks are associated with which vrfs via the vrf selection source command
5. Enable ip vrf select source and ip vrf receive on the PE upstream interface
6. Resolve any next-hop rechability and MPLS LSP issues.

Sounds like a lot, but after doing a couple it's really not too bad.

11:22am 5.5 complete, 4, trick here was default-information-originate on R4 ipv4 address family.
11:48am 5.6 not complete, 0/4. I got hung up because the debug ip packet didn't show my packets flowing. All I needed to do was to advertise my link in bgp to BB1, but I never bothered to try because I thought something else was broken. Most likely these packets were being cef switched so I didn't even know they were flowing. Painful 4 points to give up...

VPN complete, 14/22, 2:05, 4:02 total

6.1 not complete, 0/3. They got me on this one. I tried to put this on the TE tunnel and the pim adjacencies wouldn't come up. I considered creating a gre tunnel, but figured there was some knob that would allow pim to talk across the TE tunnel. Nope, a gre tunnel was the solution.

6.2 not complete, 0/3. This makes sense at least, now. The new loopback can't pass the rpf check since R4 doesn't have a route to it. We don't want to add full ip reachability, we just want to pass the rpf check. So we add a bgp multicast peer and add the loopback there, so R4 can do the rpf check on the new loopback. Got it.

12:27pm 6.3 complete, 3/3. Have to carry the ipv4 multicast route out to R1.

Multicast complete, 3/9, 0:39

12:42pm 7.1 complete, 3/3
12:51pm 7.2 complte, 3/3
12:54pm 7.3 complete, 3/3
1:00pm 7.4 not complete, 0/3, they got me again, I forgot about the nat. Sad, because I even had NAT written on the diagram.
QoS complete, 9/12, 0:33

1:17pm 8.1 complete, 2/2. More trickery, do to this, besides mpls, ttl expiration messages must also be filtered. The solutions guide didn't catch onto this even, as it only prevents traffic that passes through the TE tunnels from showing the hops. Not all traffic is going through the tunnels!

1:21pm 8.2 not complete, 0/3. I misunderstood and didn't filter the tunnels too. I'm sure a customer would just love an ISP who filtered all tunneling from their network lol.

1:26pm 9.1 not complete, 0/3. I was looking for something totally different.

1:30pm 9.2 complete, 3/3. For once I didn't forget to enable traps.

1:31pm 10.1 complete, 2/2. Scan time

Lab 10 complete, 71/100, 5:45

Wow, not bad for a difficulty 9 lab. There were a few new concepts in this lab that was was able to catch on to and am sure I would be able to configure them next time. I'm actually feeling really good right about now.

Friday, March 27, 2009

IE SP Vol 2 Lab 7 Repeat

Here goes my 2nd attempt at lab 7.

2:15pm lab started
2:25pm 1.1 complete, 3 points
2:29pm 1.2 complete, 2 points
2:34pm 1.3 complete, 3 points
2:36pm 1.4 complete, 3 points
2:42pm 1.5 complete, 3 points
L2 complete, 14/14, 0:27

Taking CoD break

12:40am back from break
12:50am 2.1 complete, 3 points
12:57am 2.2 complete, 2 points
1:00am 2.3 complete, 3 points
1:01am 2.4 complete, 2 points
IGP complete, 10/10, 0:21

1:21am 3.1 complete, 3 points
1:33am 3.2 complete, 2 points
1:46am 3.3 complete, 2 points
1:52am 3.4 complete, 3 points
1:54am 3.5 complete, 3 points
2:03am 3.6 complete, 3 points
EGP complete, 16/16, 1:02

2:13am 4.1 complete, 3 points
MPLS complete, 3/3, 0:10

2:30am vpn diagram complete
2:39am 5.1 complete 3
2:54am 5.2 complete 3
3:22am 5.3 complete 3
3:42am 5.4 complete 3
3:46am 5.5 complete 3
4:22am 5.6 incomplete, 0/4 looked up the answer. This one still baffles me.
4:59am 5.7 complete, 3
5:14am 5.8 complete, 3
VPN mostly complete, 21/25, 3:01 (too long!!!)

5:24am 6.1 complete, 3 watch rfp checks on TE tunnel
5:44am 6.2 not complete, 0, not sure what vlan 7 is. Needed mpls ip on TE tunnel (AGAIN!!!)
6:15am 6.3 not complete, 0, but I did eventually get it working!
Multicast barely complete, 3/9, 1:01 (still making progress...)

6:25am 7.1 complete, 3
6:52am 7.2 not complete. 0/3 I have it configured right but the marking doesn't seem to be occurring.
7:11am 7.3 complete, 3
QoS complete, 6/9, 0:54

10:34am back from break
11:25am 8.1 complete, 3 points--too much time!
11:30am 8.2 wrong, 0/2--no ip unreachable on null0 interfaces, I never would have thought of that!
11:34am 8.3 complete, 3.
Security complete, 6/8, 1:00

11:43am 9.1 not complete, missed snmp ifindex persist and didn't use absolute
11:49am 10.1 not complete, needed to use nat instead of policy routing

Lab 7 complete, 8:11, 79%
The single biggest thing that worries me about this lab is task 5.6. I understand that a route is needed for the PE router so the mpls bindings occur. What is beyond me is why on earth redistribute connected works. Just as I'm typing that, I actually bother to do a sh ip route on R4. Sure enough, 131.1.5.5 shows up as connected, due to it being a peer neighbor route. Ok, I feel better now.

Thursday, March 26, 2009

IE SP Vol 2 Lab 4 Repeat

I'm going to try to do a repeat of labs 4, 7, and 8 before my big day. Here it goes...

4:44am lab started

Layer 2
4:55am 1.1 complete. 3 Vtp was acting up and I had to bounce both sides of the trunk int
4:58am 1.2 complete 3
5:04am 1.3 complete 3
5:07am 1.4 complete 3
Layer 2 complete, 12/12, 0:23

IGP
5:10am 2.1 complete 2
5:21am 2.2 complete 3, frame-rel map clns broad
5:25am 2.3 complete 2
6:06am 2.4 complete, 2 --got distracted
6:16am 2.5 complete, 3
IGP complete, 12/12, 1:09

EGP
6:27am 3.1 complete, 3
6:40am 3.2 complete, 4
EGP complete, 7/7, 0:34

MPLS
6:43am 4.1 complete, 3
6:49am 4.2 complete, 2
6:54am 4.3 complete, 2
7:01am 4.4 complete, 3
7:26am 4.5 complete, 3
MPLS complete, 13/13, 0:46

taking lunch
10:33am back from lunch
10:43am vpn diagram complete
10:47am 5.1 complete, 3 points
10:56am 5.2 complete, 3 points
11:00am 5.3 complete, 3 points
11:18am 5.4 complete, 3 points
11:34am 5.5 complete, 3 points
11:53am 5.6 complete, 3 points
12:41pm 5.7 skipped, the export map won't take
BGP almost complete, 18/21, 2:08. Too much time spent troubleshooting 5.7!

taking another lunch.
3:56pm back from lunch
4:10pm 6.1 complete, 3 points
4:13pm 6.2 complete, 2 points
4:17pm 6.3 complete, 3 points
5:06pm 6.4 not complete, 0 points, needed to make msdp router pim dr.
for the second time, task 6.5 killed r1.
Multicast complete, 8/14, 1:10

Total time so far: 6:10

QoS:
7.1 no issues, 3 points, 0:15
7.2 no issues, 3 points, 0:30
QoS complete, 6/6, 0:45

Security
8.1 no issues, 3 points, 0:05
8.2 no issues, 3 points, 0:05
Security complete, 6/6, 0:10

System Management
9.1 0/0, 0:10, banner motd, and no motd on other ports
9.2 2/2, 0:05
9.3 3/3, 0:10
System Management complete, 5/8, 0:25

IP Services
10.1 2/2, 0:10

Lab complete, 88%. Of the 12 points I missed, at least 6 seem to be due to dynamips issues. The solutions guide shows I was doing mdt's and the nat exercise correctly, but they just didn't want to come up.

By far my biggest weakness is multicast. I'll take a stab at lab 7 tomorrow and will again spend a lot of time on the mulitcast portion. I think I remembered most of the key concepts today, I just ran into some small implementation issues.

Sunday, March 22, 2009

IE SP Vol 2 Lab 10

Here we go, the last of the labs I haven't looked at yet.

12:38am lab started

Layer 2
12:44am 1.1 complete, 3
12:48am 1.2 complete, 3
12:52am 1.3 complete, 3
1:02am 1.4 complete, 3, assuming pvc command satisfies requirement
Layer 2 complete, 12/12, 0:24

IGP
1:12am 2.1 complete, 3
1:28am 2.2 complete, 3. Unable to authen RIP. Verified no spaces, etc, assuming BB issue.
1:33am 2.3 complete, 3 points
IGP complete, 3/3, 0:31

EGP
1:48am 3.1 complete, 3. Tried confederations but ran into issues so went with local-as.

3:30am back from work break
3:46am 3.2 complete, 3 points
EGP complete, 6/6, 0:31

MPLS
4:03am 4.1 complete, maybe--te w/o mpls on each interface

Well, after 2.5 hours of working on 4.2, I give up. As far as I can tell, I had everything right 2 hours ago. I ran into an issue where I was somehow missing my loopback 0 ip address, which wouldn't allow me to bring the tunnels up. I added this, and my tunnel through R9 worked fine. but the dynamic tunnel won't come up. I've checked and rechecked my interfaces, but it just won't work.

Saturday, March 21, 2009

IE CoD Service Provider Multicast

Since Multicast is obviously my weakest point now, I've decided to review the IE CoD for Multicast.

1. Don't touch mVPN until each PIM domain has been verified
2. Use debug ip pim to find "RPF lookup failed" messages
3. Enable pim between msdp peers so rp information can be exchanged
4. For multicast testing, getting a ping reply is not a great test. It is only really necessary to verify the downstream traffic is getting to the host. To get icmp replies, it may be necessary to enable multicast routing on the destination and enabling pim there, ensuring it is not the pim dr.
5. mBGP is solely for the purpose of advertising source ips for rpf lookup. Verify using show ip rpf.

Friday, March 20, 2009

IE SP Vol 2 Lab 9

Time once again to change things up for a timed lab. This is the second to last of the Vol 2 labs. It also has a difficulty of 7, which generally means its difficulty closely mirrors that of the real thing. So I need to pay close attention to my performance on this one.

12:15am lab started

Layer 2
12:26am 1.1 complete
12:28am 1.2 complete
12:45am 1.3 complete, fun with inverse-arp. Will probably need point-to-multipoint for ospf.
12:48am 1.4 complete
12:53am 1.5 complete
Layer 2 complete, 10/10, 0:38

IGP
12:58am 2.1 complete
1:00am 2.2 complete
1:02am 2.3 complete
1:08am 2.4 complete
1:10am 2.5 complete
1:19am 2.6 complete
1:22am 2.7 complete, had to manually redis loopback on r1
IGP complete, 15/15, 0:29

EGP
1:24am 3.1 complete
1:28am 3.2 complete
1:30am 3.3 complete
EGP complete, 7/7, 0:08

MPLS
1:33am 4.1 complete
1:36am 4.2 complete
2:05am 4.3 complete
MPLS complete, 8/8, 0:35

VPN
2:33am forced break
3:59am back from break
4:05am 5.1 complete
4:11am 5.2 complete
4:30am 5.3 complete
4:55am 5.4 complete
5:05am 5.5 complete, as-override
5:26am 5.6 complete, domain-id
5:32am 5.7 complete, export map
5:38am 5.8 complete, one label still shows, but it's in vrf 100, so should be ok
5:47am 5.9 complete
VPN complete, 25/25, 2:16

Time so far: 4:06

Multicast
6:36am skipping multicast, having issues with p2mp network
taking break
10:25am back from break

QoS
10:30am 7.1 complete, assuming it's ok to do this from the router side instead of the switch side
10:35am 7.2 complete
10:40am 7.3 complete
Qos complete, 8/8, 0:15

Security
10:46am 8.1 complete, permit means don't do uRPF check
11:13am 8.2 complete, got pppoe going!!!
11:30am time's up, almost had it
Security incomplete 6/11, 0:44

System Management, no time, 0/3
IP Services, no time, 0/5

Total possible, 79/100.
Time spent: 5:03 :(. I had too many distractions during the night and by time 6:30am got here I was just too tired to go on. I KNOW I could have completed 8.3, 9.1, 10.1, and 10.2. So all that really leaves is multicast. If this were my actual lab, I'm about 99% sure I would have passed it.

Reviewing the solutions to see if I missed anything:
Task 5.8 added the keyword forwarded
For 6.1, it looks like I did what I needed to . I remembered autorp listener and nbma mode, so I'm not sure why I couldn't get it to work.

Realistically, if I had 8 hours, I would have definitely got 8.3, 8.4, and 9.1. Most likely 10.1 and 10.2 as well, but even if I don't include those I'm still looking at 87%, which is passing.

Tuesday, March 17, 2009

IE SP Vol 2 Lab 8

Layer 2
1.1 no issues
1.2 no issues
1.3 no issues
1.4 unfortunately I had to look this one up. All I needed to do was to create an mpls subinterface and configure mpls ip on it. I'm not sure why I couldn't figure that out. Been dealing with pvc's so much lately, and didn't even need one this time.

IGP
2.1 no issues
2.2 no issues
2.3 no issues
2.4 no issues

EGP
3.1 well I mapped the peer group, but I didn't actually use it. The task could have been a little more restrictive to actually for me to use it.

MPLS
4.1 no issues
4.2 no issues

VPN
5.1 no issues
5.2 no issues, allowas-in
5.3 I used an export map, but the solutions guide wanted soo. Either way works fine.
5.4 I had to get creative on this one. A couple of TE tunnels with MED thrown in seemed to do the trick.
5.5 ok, the TE tunnel killed my redundancy. Now I could have probably done something really fancy with the tunnels to work around this, but it made more sense to get rid of them altogether and follow the solution guide. So I went with local preference, which for this task worked much better. Aside from that, some rip redistribution did the trick.
5.6 finally, an easy one

Monday, March 16, 2009

2 weeks out

I sit for the lab on March 30th, 2 weeks from today.

Thus far, I have completed the following:
IE Vol 1, all labs
IE Vol 2, labs 1-7 (4 and 7 were only partially completed)

At this point I feel pretty comfortable with most of the topics. I'm still a little concerned with the following:

MSDP - I just don't have the big picture on this yet
TE - I can get the tunnels up just fine now, but routing vpn traffic across the tunnel gives me problems
PPPoE - I just plain need more practice
AToM - Haven't touched it

My game plan is as follows:
Squeeze in labs 8, 9, and 10 during the week
Study SP scenarios during the week
3/21 - Repeat Lab 4
3/23 - Repeat Lab 7
3/28 - Whatever I need the most

The big thing I'm doing differently in studying for the SP lab vs R&S is I'm going slowly and banging away until I figure out the issues. I definitely like this approach better. But on these last 3 timed attempts, I'll need to do it like it's for real to help me decide which tasks to skip, etc.

Lab 6 Task 6 - 9

Ok, back to finish off lab 6.

6.1 no issues
6.2 accept-rp to only use certain rp's. Also, need to configure sparse-mode on links between domains.
6.3 advertise the remote router loopback into bgp ipv4 multicast.

7.1 I wasn't paying attention to scale. And yet another lab anomaly.

8.1 Almost, missed the discovery transport address. I don't understand why this is required at all. If I get a question like this on the lab I may add it just to be on the safe side, but it seems irrelevant, unless it is somehow locking down the address.

9.1 no issues

10.1 took me a bit of hunting but I finally found it. ip access-list logging

Duh!

Even though on the last couple of labs I've been able to get the TE tunnels up, I haven't been successful in actually routing traffic across them

During troubleshooting, I'd see the TE tunnel in the forwarding table, and verified mpls packets flowing through the tunnel. But the packets always seemed to get dropped at the endpoint. I thought this could have been something to do with the implicit-null issue, but forcing explicit nulls never helped.

I also noticed the mpls forwarding table showed no label for the TE tunnel. I thought maybe this was just a quirk of TE tunnels.

As it turns out, I need to enable mpls ip on the tunnel interface.

IE SP Vol 2 Lab 7

I'll have to take a break from lab 6 so I can do my scheduled timed lab 7.

3:00am began
3:08am 1.1 complete
3:11am 1.2 complete
3:18am 1.3 complete, verified using debug ppp authen and shut/no shut int
3:21am 1.4 complete, ppp peer neighbor (default) route allows connectivity
...55 minute break...
4:24am 1.5 complete
Layer 2 complete, 14/14

..50 minute break...
5:05am 2.1 complete
5:07am 2.2 complete
5:32am 2.3 complete, redistribute ip level-2 into level-1 route-map
5:35am 2.4 complete
IGP complete, 10/10

5:47am 3.1 complete
5:58am 3.2 complete
6:02am 3.3 complete
6:07am 3.4 complete
6:15am 3.5 complete, route-maps can set next hops too
6:31am 3.6 complete
BGP complete, 16/16

6:37am 4.1 complete, looks like ldp uses 224.0.0.2
MPLS complete, 3/3

6:46am 5.1 complete
7:04am 5.2 complete, as override
8:24am 5.3 complete, export maps and playing with the next-hop route-maps
9:54am 5.4 skipped. Ugh, I had all sorts of unrealized issues here. I didn't have an isis adjacency on the atm link. For some reason, I needed to change the atm subinterface type to p2m so it matched with r2's interface only config. After this, I had to ensure all broadcasts were permitted on the pvc's so that mpls would come up. And after all that, once the TE tunnels were up, yet again traffic going across them would drop, so I had to shut the tunnel and move on.
10:10am 5.5 complete


Unfortunately a large number of distractions only let me get about 5 hours toward this lab before I ran out of time.

The final tally is:
projected: 55/100

Task notes:
1.5: Ha, I was right to change a3/0.12 to multipoint. I'd give myself extra credit for that if I could!
After reviewing most of the tasks, I caught on to most of the tricks. Even though I didn't get very far into the lab, I'm very excited with my progress!

Saturday, March 14, 2009

IE SP Vol 2 Lab 6 Continued

VPN
5.1 no issues
5.2 something in Dynamips crashed and I had to reload a couple of routers to get the 5-8 adjacency up.
5.3 no issues. Sham links are covered nicely on the doccd.
5.4 no issues.
5.5 no issues
5.6 no issues. I'm getting MUCH better with TE, this one only took me a few minutes.
5.7 this task was a major pain. I went ahead and made an assumption that only vlan78 was required. The first step was obvious, adjust bgp weights so the correct link was preferred. But it wasn't quite so simple. One of the PE routers refused to advertise the required routes. After way too much time troubleshooting, it turned out that this was due to sham-link costs. Adjusting these ensured the path through R5 was used.

The solutions guide just ignored the sham link altogether saying there was a conflict. It then went ahead and used an export map, which basically took the place of my weight adjustment. 6 one way a half dozen the other...

5.8 no issues

5.9 Yet another task that took a heck of a long time. The pings between ASs failed at first, naturally. It didn't take much time in debugging to determine that send-labels was required on the P-P bgp peers, since they were not running mpls with each other and did not split the vrf's out via subinterfaces. Next, I made sure the route-reflector left the next-hop-unchanged to allow the vpn traffic to flow PE-PE to ensure the vpn tag remained entact.

But no matter what I did, the upstream PE router was still seeing the bgp network as sending no label. I spent multiple hours troubleshooting this. Debug mpls packet is becoming my best friend.

So as it turns out, with a little help from the solutions guide, that the route-map is to blame. If a route map is used, set mpls-label must be configured in the route-map, otherwise this will override the send-label portion of the bgp neighbor config.

But even after I configured this, the CE router still couldn't ping AS54. After another hour or two troubleshooting, the problem seemed to be that the upstream P router was trying to send the traffic back via mpls instead of ip. I have no idea why this was happening, but a mpls encapulation failed message was occurring. Guessing that something may have just gotten hosed on the router in all my previous messing around, I gave up and just reloaded the upstream PE routers. Sure enough, everything came up upon the reload. Annoying, but it's working.

Too much time spent, but I think I got a lot of good troubleshooting experience.

5.10 Yet again more nastiness. The basic task was simple--summarize using an aggrigate address to ensure the longer-match prefix is preferred. An interesting trick. But for some reason, the path to R8 breaks once I set this. Tearing down the TE tunnel fixes it. So yet again i put a ton of time into troubleshooting this. It turns out that for some reason R1 is ignoring the sham-link when TE is operational.

A reboot of R1 seemed to take care of the sham-link issue, but my traffic is still not making it back to R8.

After another hour spent of troubleshooting, I'm giving up on this one. I'm going to write it off as some kind of weird incompatibility with sham-links and TE or something like that. Either that or something is still not clicking with TE that's not mentioned in the solutions guide either.

5.11 wow, no issues

5.12 of course, once again issues. This again deals with the sham link and R7 cannot be made to take the backdoor route to R8 to come into nat on R5 in the appropriate interface.

IE SP Vol 2 Lab 6 Continued

MPLS
4.1 no issues
4.2 no issues

Some good information is contained in the solutions guide for verifying the ldp session is encrypted. I'll all for verifying everything, and fully believe it was the reason I was able to pass R&S the second time.

First, find your ldp/tdp session:

Rack1R4#sh tcp brie
TCB Local Address Foreign Address (state)
651EA2F4 20.1.4.4.29641 20.1.6.6.179 ESTAB
6520C0C4 20.1.4.4.646 20.1.6.6.28294 ESTAB
65185A8C 20.1.14.4.15156 20.1.14.1.179 ESTAB
651EDBFC 20.1.4.4.179 20.1.3.3.53879 ESTAB

Then check out the appropriate tcb (port 711 or 646). Note the flags section.

Rack1R4#sh tcp tcb 6520c0c4
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 20.1.4.4, Local port: 646
Foreign host: 20.1.6.6, Foreign port: 28294

...
Flags: passive open, retransmission timeout, gen tcbs, md5,
...

Friday, March 13, 2009

IE SP Vol 2 Lab 6 (Untimed)

I'm gonna see if I can squeeze this lab in on an unscheduled day so I can make it through all of them before the big day. 16 days to go...

Layer 2
1.1 No issues
1.2 No issues
1.3 No issues
1.4 No issues
Layer 2 complete, 12/12.

IGP
2.1 No issues
2.2 No issues
2.3 No issues
IGP complete, 9/9

EGP
3.1 No issues
3.2 No issues
3.3 No issues
3.4 No issues
3.5 I ALMOST had this. Of course almost equals nothing in the lab. I figured out what needed to be redistributed to get the ebgp adjacency up. I also figured out some admin distance changes needed to be made in as 100. But what I didn't get right is getting traffic from R3 to R6 flowing across the R1-R4 link. I knew it needed to be done, I just couldn't figure out how, within the scope of current BGP adjacencies. I ended up looking this one up. The trick was to advertise BOTH loopbacks on each AS100 router. Then I could easily adjust the metric on the AS 200 ABRs during redistribution.
EGP complete, 12/15

Sunday, March 8, 2009

IE SP Vol 2 Lab 5

12:20am Lab started
12:26am Read through complete

Layer 2
12:33am 1.1 complete, 3 points
12:37am 1.2 complete, 3 points
12:46am 1.3 complete, 3 points
Layer 2 complete, 9/9 points

IGP
12:53am 2.1 complete, 3 points "Most appropriate" is awfully subjective
12:58am 2.2 complete, 3 points
1:10am 2.3 complete, 2 points
1:15am 2.4 complete, 3 points
IGP Complete, 11/11 points

EGP
1:29am 3.1 complete, 3 points, assuming confederations
1:33am 3.2 complete, 3 points
1:37am 3.3 complete, 3 points
1:43am 3.4 complete, 3 points
skipping 3.5 until neighbors are up
EGP incomplete, 12/15

MPLS
1:55am 4.1 complete, 3 points
2:04am 4.2 complete, 3 points, changing ethernet link b/w to 100m.
2:13am 4.3 complete, 3 points
2:41am 4.4 incomplete, 0 points, tricky requirements and researching static routes for TE cost some time. Static routes are failing. I think it's a label popping issue.
MPLS complete, 9/13

VPN
2:48am 5.1 complete, 3 points
3:13am 5.2 complete, 3 points
3:20am 5.3 complete, 3 points
4:25am spent over an hour troubleshooting 4 measly TE points. Subtracting points.
5:00am spent another 30 minutes working on the earlier skipped bgp task. moving on...
5:18am 5.4 incomplete, 0 points. Finally getting somewhere...
5:29am 5.5 complete, 3 points. A little unsure about the last bullet point.
6:04am 5.6 complete, 3 points. Determined 5.4 was broken, removed.
6:31am 5.7 complete, 3 points
VPN complete, 18/21

Multicast
6:36 am 6.1 complete, 2/2 points
6:41am 6.2 incomplete, 0/3, unsure how to get rp across mdt
6:56am 6.3 complete, 3/3, points. Unsure about data access-list
7:01am 6.4 incomplete, 0/2, testing failed, I believe it's an rp issue
Multicast complete, 5/10

QoS
7.1 incomplete, unsure how to match on traffic going to r6
7.2 incomplete, unsure how to match on traffic gong to r5
7.3 incomplete, same
7.4 skipping
7.5 skipping
Qos incomplete, 0/13

Security
8.1 complete, 3 points

System Management
skipped. I can't remember the trick to this. Something to do with rotary I think?

Ip Services
10.1 complete, 3 points

Lab 5 complete. Highest possible score, 70/100. I ran into some TE issues, some VPN issues, and was pretty much clueless on QoS and Multicast.

Schedule Status

Well, I finished Labs 1-3 and got through the guts of Lab4, but didn't quite get to the fluff. I reviewed it briefly and there didn't seem to be anything too extraordinary in it. But when it comes to the CCIE, the devil is definitely in the details.

Tonight is my first timed lab. I'll be tackling Vol 2 Lab 5. Since I've been taking my sweet time so far, I have no idea how fast or slow I'm actually doing these things. It'll definitely change my plan of attack now that I'll be skipping some tasks.

Here is an updated schedule:
3/9: Vol 2 Lab 5
3/16: Vol 2 Lab 6
3/21: Vol 2 Lab 7
3/23: Vol 2 Lab 8
3/28: Vol 2 Lab 9

Now that leaves me without doing Lab 10. I think I'll try to squeeze lab 10 in during the weeks, as, at least in R&S, the last lab was some ugly impossible thing that was WAY above and beyond the lab requirements.

IE SP Vol 2 Lab 4 Task 6

6.1 no issues
6.2 no issues
6.3 Multicast boundary filters access-list denies--needs permit any at the end.

6.4 Ugh--I forgot all about msdp. I'm gonna have to do some more reading on it. I know I understood it at one point for R&S, but those brain cells have long since died off.

6.5 Crashed my R1. After multiple attempts I can't get it back up :(. There's pretty much no hope of me rebuilding it. I'll have to try some different IOS versions. But no time for that now.

IE SP Vol 2 Lab 4 Task 5

This one started out ok but got rough towards the end.

5.1 Complete, no issues
5.2 Complete, no issues
5.3 Complete, no issues
5.4 Ok, this task is just plan annoying. I hope the real lab doesn't require quite so many assumptions. I'm referring to the "Redistribute where necessary to advertise these prefixes". On top of redistribution, vrf's need to be assigned to interfaces not specified and bgp adjacencies need to be created that aren't specified. I hate when the lab does this. How am I supposed to know that we're allowed to create a bgp adjacency yet not a whole new vrf? Is this really a case of doing whatever I want that doesn't violate the lab requirements? I guess I'd just have to harrass the proctor on lab day...

5.5 Complete, no issues

5.6 I did this one all wrong. I knew it violated requirements but I went ahead an used a static route, simply because that's the way I've always done internet access before. I didn't even think about creating a new vrf and establishing the bgp session inside of it. I'll definitely have to commit that to memory.

5.7 I couldn't get nat working at all. It turns out that I needed to create a new loopback which reflects the nat pool. Something else I'll have to commit to memory, I guess. Another tidbit I should have realized--debug ip packet doesn't show MPLS traffic!!! Duh--MPLS is NOT IP. To track mpls, use debug mpls packets. But it doesn't show a whole lot, other than the labels. I wish there was a way to slow the router down and do deep inspection of mpls packets for debug purposes...

Thursday, March 5, 2009

IE SP Vol2 Lab 4 Task 4

4.1 Complete, no issues
4.2 Complete, no issues
4.3 Complete, no issues. neighbor send-label tells bgp to send the lables.
4.4 and 4.5 Complete--lots of issues!!!

Tasks 4.4 and 4.5 were a major pain. I'm still having a tough time with TE, but I'm getting there slowly but surely. I refused to look up the answers on these tasks and kept pounding away at it until I got it figured out.

Here's a little checklist for getting it setup.

1. Keep in mind that TE tunnles are unidirectional. A tunnel interface does NOT need to exist on both sides, as is common with gre/ipsec tunnels. It is for one-way transfer of traffic. As a matter of fact, by setting up tunnels on both directions, it can exhaust rsvp bandwidth and make bringing up all of the tunnels impossible.

2. mpls traffic-engineering tunnels must be configured globally and at the interface level on all routers in the path, including the head.

3. ip rsvp bandwidth must be reserved on all links in the path, including the head

4. The tunnel must have an ip address (unnumbered is fine), priority, and path configured.

5. If an explicit path is used, all hops must be valid and the correct name or idenitifer must be used.

And here is a list of verification steps:

1. Check sh ip rsvp int on all routers to ensure rsvp is enabled
2. Check sh mpls traf tun on the head to look for error messages and tunnel state
3. Check sh mpls traf top path to see the path the tunnel is taking

For establishing the explicit path, I like to do the following:
1. Configure the tunnel for dynamic
2. Shut down some links to force the tunnel to dynamically take the path you want
3. Configure the explicit-path list to mirror the output of sh mpls traf top path
4. Reconfigure the tunnel with the explicit-path

IE SP Vol2 Lab 4

Here we go, 3 days ahead of schedule, woohoo!

1.1 Complete, no issues
1.2 Complete, no issues
1.3 Complete, no issues
1.4 Complete, surprisingly. Even without inverse-arp or mappings, we can configure a p2p subinterface with a broadcast pvc. Per the solutions guide, the broadcast keyword isn't even required. I guess if you have a p2p subinterface with a single pvc, it assumes to send all traffic out that single pvc.

2.1 Complete, no issues
2.2 Complete, no issues. Minimum amount of commands means specify is-type under router isis instead of on each interface.
2.3 Complete, pretty poorly worded task, but adjusting the hello timers took care of it.
2.4 Complete, no issues, for md5 isis authen we need key-chains.
2.5 Complete, no issues

3.1 Complete, no issues
3.2 Complete, wow, the instructions sure could have been more specific here. Nowhere is it mentioned that redistribution should be done. Nowhere is it mentioned that the peering should come up here, just that it should be configured. I guess in theory I should have read the rest of the lab and figured out the design to know what must have to happen here.

Also, the neighbor next-hop-unchanged command stops an eBGP router from updating next-hop advertised from an iBGP peer.

Wednesday, March 4, 2009

IE SP Vol 2 Lab 3 Complete

I actually feel pretty good about this lab.

Sections 1 - 4 were pretty easy for the most part.
Section 5 was a tough vpn with two P ASs joined by vrf-lite. It turned out to be a great exercise which really boosted my confidence.
Section 6 was a bit over my head when I started, but I feel much better about mdt now. I think I have a pretty good idea what's going on and how to troubleshoot issues.

I'm feeling really good about QoS right now. Funny, I always seem to feel good about QoS yet I tend to get my butt kicked on the lab on this topic.

Security was something completely different. I think I understand how remotely triggered black holes work now.

System management was silly, and IP Services involved ORF, which while a new topic for me, was pretty easy to configure.

So, keeping in mind that I didn't enforce a time limit, I'd score myself about a 79 on this one, since I blew half the multicast and the whole QoS section. Still, not bad for a difficulty 8 lab.

IE SP Vol 2 Lab 3 Task 10

10.1 Complete. While I knew the theory from the CCIP, this is the first time I actually configured ORF. The guide on the doccd doesn't really explain much, the key is to keep in mind that it's backwards from what it appears. The CE is the sender and the PE is the receiver. The CE router defines a prefix-list and sends it to the PE router, which then filters the prefixes it sends accordingly.

IE SP Vol 2 Lab 3 Task 9

9.1 Complete, I hate menus...just seems like stupid router tricks
9,.2 Complete, username secret

IE SP Vol 2 Lab 3 Task 8

Source Based Remotely Triggered Black Hole Filtering. Wow, that's a mouthful. I've never heard of this before.

In a nutshell--part of the problem with a DOS attack is that it consumes bandwidth. Even if a customer drops packets on an inbound access list, the circuit would still be congested.

This is a way to allow a customer to have the provider drop traffic inside of the P network, so the PE-CE link does not get saturated.

To do this, the customer simply advertises a route with a prearranged tag to the PE router. The PE router will then ensure that traffic from this source gets dropped instead of clogging the link.

Sounds great in theory minus one important concept. Single host DOS attacks are really not that big of an issue. Heck, you could just as easily get your ISP on the phone and have them shun a single host. The manual effort of adding tagged null0 routes would do little to stop a distributed DOS attack, or one that randomly spoofs source addresses.

Anyway, as far as the task:
8.1 Mostly Complete. I was close--for being unsure of what they were looking for, I was happy I made it as far as I did.
8.2 Again mostly complete.
8.3 I did it a different way, but complete.

IE Vol 2 Lab 3 Task 7

7.1 Complete. No issues, same as R&S. If you can't use MQC, there's always CAR.

7.2 Complete. No issues, if you can't use an access list, use a custom nbar port-map.

7.3 Complete. Surprisingly, no issues. Like the solutions guide, I opted to not use qos-groups since the underlying packet was marked ef as well.

One note on QoS. I usually don't bother to use ip sla to test it. Big mistake!!! I have to get into the habit of setting this up every time. It's just way to easy to watch the counters to ensure everything is setup correctly.

Monday, March 2, 2009

IE SP Vol 2 Lab 3 Task 6

Ok, this multicast task was a bit rediculous too. Now on the bright side I was pretty much able to nail the config. But when I got down to the test, I was not able to get it to work at all. I went through the solutions guide and primarily found one mistake--that I didn't have the mdt router's loopback interfaces running pim. Even upon fixing this, however, the multicast test still did not work.

-----12 hours later-----

I was really starting to get desperate here, but I FINALLY got everything figured out. It basically boiled down to two things:

1. sparse-mode requires autorp listener for the autorp groups to be able to pass through. Without it, autorp will not function across sparse-mode interfaces.

2. On mVPN, rp's are required for both the main routing instance and the vrf. This was my main mistake. I was missing a static rp on a vrf interface.

So, after a long time of being worried I had no idea what I was doing and that this stuff was way over my head, it turned out to be silly mistakes that did me in.

As with other topics I spent so much time on troubleshooting an issue, I really hope all this time put in helps me the next time I come across mVPN. I'm feeling pretty good about it now, but we'll see how it goes next week.

If multicast contines to be this complex, I may need to draw a mVPN diagram in order to keep all the tunnels and vrf's straight.

IE Vol 2 SP Lab 3 Task 5

5.1 Complete, no issues
5.2 Complete, no issues
5.3 Complete, no issues
5.4 Wow, what a task. I now see why this lab gets an 8. For 2 bullet points, there is a heck of a lot of assumptions that have to be made, tons of redistribution, and a bunch of vrfs to keep track of. I actually made my way through this pretty well, but it certainly took some time. An excellent exercise to validate understanding of the big picture.
5.5, piece of cake after making it through the last task.

Sunday, March 1, 2009

IE Vol 2 SP Lab 3

Here we go with lab 3, right on schedule. Again, I'll be spending a full week on this one, taking my time to research and experiment with anything I'm not confident on. This lab moves up to a difficulty rating of 8, so I'm assuming there will be some curve balls thrown in this time.

1.1 Complete, no issues
1.2 Complete, even in transparent mode, dynamips doesn't seem to allow extended vlans on the ethernet modules.
1.3 Complete, no issues
1.4 Complete, no issues
1.5 Complete, had to change the label protocol to tdp.

2.1 Complete, no issues--no DR? use p2p or p2mp
2.2 Complete, no issues--no area authen? put it on the interface
2.3 Complete, stupid mistake. I couldn't get the isis adjacency up across the frame-relay interface. I thought there may have been some trick here since the frame-relay map had to support clns. Turns out I missed configuring isis on the interface to begin with. A dumb mistake that would have cost me valuable time in the lab.
2.4 Wrong. I used the isis password command. However, this exchanges the passwords in plain text. To do md5, an authentication key-chain must be used ala rip and eigrp.

3.1 complete, no issues
3.2 complete, no issues
3.3 complete, no issues. I'm probably splitting hairs a bit here, but the maximum prefix drops the connection when the limit is exceeded. Since the requirements specify that if the table "continues to grow to 12,000", to me this means at 12,000 the connection should be reset, meaning maximum-prefixes is 11,999. I'd hope the lab wouldn't be quite this particular, but who knows.

4.1 Complete, no issues. Here's where the tdp requirement from earlier gets specified.
4.2 Complete, no issues.

Well so far this lab is laughable. I'm assuming it's gonna it rough here shortly, because the difficulty is nowhere near an 8 so far.