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.
Wednesday, June 3, 2009
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.
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.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)
Posts
