Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

I just finished up volume 2 lab 11. I’ve had to put a limit on my study time on work days as of late. My new rule is to try to not go past 2:00 AM when I have work the next day, or I have a seriously hard time getting up in the morning. I was pleasantly suprised last night to have finished all the way through my BGP section in about 4 hours. This included the initial hour I spent drawing out my diagrams, reading the lab all the way through, etc. I would say this was a fairly mild lab in terms of difficulty. There was no IPv6 and no multicast so that was a nice suprise.

I ended up doing pretty well, but I screwed up on the following tasks:

Task 2.2 — Etherchannel setup — I cry proctor guide error on this for sure, and I’ve sent in an email. The task asks us to use an “industry standard” etherchannel protocol, so I configured LACP using “channel-group 1 mode active”, yet the proctor guide shows “channel-group 1 mode on”. I am pretty sure this is a mistake on their part. It also says that “etherchannel ports should be statically in trunking mode and should not use DTP to negotiate trunks.” Therefore, I configured “switchport mode trunk” and “switchport trunk nonegotiate” on all my etherchannels. For some reason the proctor guide did not include the switchport nonegotiate command, but I’m quite sure it should be there

Task 3.2 — R6/R9 PPP Setup — I don’t know if this would be considered wrong in the real lab or not. I did not read the question carefully enough. In this lab there are 2 serial links between R6 and R9. The task specifically asks you to configure an ip address for 1 of the serial links. I jumped right in and configured MLPPP instead of just configuring the 1 link and shutting the other down. bah!

Task 3.3 — R7/R8 back to back frame-relay — This seems to be a common problem area for me. I always seem to not fully understand the question and end up configuring something extra. The task was to configure the serial link between R7 and R8 with frame-relay encapsulation. Do not configure any layer 3 addresses on the physical interface. R7 and R8 should peer to each other in the and subnets over 2 seperate PVCs.

For some reason, when I see something involving back to back frame with multiple PVCs I seem to think PPPoFR. So, I went ahead and configured PPPoFR with 2 virtual-templates on each side, each with it’s own DLCI….and it worked great. But the easier solution, and thus the one in the PG was to simply configure 2 point-to-point frame-relay subinterfaces. The PPP part was totally unnecessary. Again, I’m not sure if I would get knocked points for this or not because technically my soltion did use the right subnets and 2 separate PVCs and it did work.

Task 5.4 — EIGRP Timers — I got the first part of this question which was to tweak the SIA timers, but I botched the 2nd one. I’m still not sure I fully understand the solution. The task asked me to “Configure the EIGRP process on R2 and R4 to drop routes from inactive neighbors after half of the default time” My solution was to configure the hold time on both R2 and R4 to 90 seconds (the default over NMBA interfaces is 180 seconds). The solution in the proctor guide was “timers nsf route-hold 120”. I looked up the command, and I am not really sure what the difference is between that and the hold timer to be honest

Task 9.1 – QoS — I nailed this 5 point task except for one little thing. In my MQC policing I entered “police <rate>” instead of “police rate <rate>” so I ended up configuring the CIR instead of an actual bitrate.

Thats it for now. Lab 12, coming soon

– Joe A


5 Responses to “IPexpert Volume 2 Lab 11 — Review”

  1. Yandy Ramirez on January 12th, 2009 1:27 pm

    I hope you don’t mind me butting in, just a couple of things I noticed..

    Task 2.2: technically “on” is using LACP just no negotiation. It’s like using auto with PAGP.

    With “switchport mode trunk” you wont negotiate a trunk, the question asked to not negotiate a trunk, set it statically. You could be right, but maybe over configuration? I know DTP is still sent, but basically does nothing, unless the other side is in dynamic mode, then it will negotiate the trunking protocol to use, and if you configured one, “switchport trunk encap dot1q or isl” then I see you’re point there, if the other side is in dynamic mode or you were asked to configure both sides.

    Task 3.3: yup completely over thinking things.. lol, i do the same sometimes.

    Cool post though, and thanks for sharing.

  2. Joe A on January 12th, 2009 2:19 pm

    Hi Yandy,

    Thanks for the feedback. Actually, etherchannel mode “on” just unconditionally turns it on, it does not use either lacp or pagp. http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/command/reference/cli1.html#wp1860162

    For LACP you can have either active or passive. With PaGP you can have auto or desirable

    As far as the trunk negotiation, if you have switchport mode trunk I believe it still sends DTP frames out, but I could be wrong.

  3. Yandy Ramirez on January 12th, 2009 2:48 pm

    no you’re right it still sends out DTP frames, but I believe it’ll negotiate the trunking protocol not the actual trunking mode.

  4. Yandy Ramirez on January 12th, 2009 2:49 pm

    Oh, yea sorry about the LACP stuff, must have miss-read somewhere.. thanks.

  5. Bryan on January 12th, 2009 5:19 pm

    Hey Joe, I got the timer one wrong too. I think it has to do with the act of dropping routes of an inactive neighbor. The normal timers are used for EIGRP adjacencies and if an adjacency drops – those routes are removed. But in NSF, I believe a peer can tell it’s neighbor “hey I am going down but I can still forward (in hardware)”. If that timer (NSF) expires, then remove the routes.

    Here’s more info:


Leave a Reply