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