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.
Sunday, March 8, 2009
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.
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.
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...
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
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
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.
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.
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.
Subscribe to:
Posts (Atom)
Posts
