CCIE Pursuit Blog

March 31, 2008

Internetwork Expert: Mock Lab I Review

Mock Lab: 1
Difficulty Level: 6
Date Completed: 26 March, 2008
Final Score: 89

NOTE: I will be discussing very few details about the actual tasks on this lab.  If you are planning on taking this Mock Lab then you can read this post as will have few (if any) “spoilers”.   :-) 

I purchased 4 of Internetwork Expert’s Graded Mock labs back in December when they were on sale for $99.  The current cost is $129.  I completed the first of my 4 labs last Wednesday.

On your IE member page you’ll see a section for Graded Mock Labs (emphasis mine):

Your mock lab number will be locked in 1 hour prior to your session start. Once your session has started, a “Start” button will appear. Click the “Start” button to receive your lab, topology, physical topology, and configs.

If you do not click the “Start” button within 1 hour of the start of your session, it will automatically be started for you. Once your mock lab has started, you have 8.5 hours to complete it, and a timer will appear telling you how much time you have left. You will be automatically kicked off your rack at the end of the 8.5-hour lab.

Your mock lab will be graded by 9 PM PDT on the second business day.

Click “View” to open a pop-up window displaying your graded mock lab. Click “Overdue” to automatically send a support ticket about not receiving your graded mock lab.

NOTE: The password to open password-protected PDFs is your e-mail address.

My lab was scheduled for 10 am PDT (noon for me).  Sure enough, once noon rolled around there appeared a button to start the lab.  Once you click this button you will be presented with links for the PDF files for the lab, the topology, and the physical topology (cabling).  Anyone who has done the IE Volume II (or Volume III labs) will be familiar with the documentation.  You’ll get a logical Layer 3 document as well as a routing protocol map.  Although I did not need to provide a password, if you are prompted for a password for any of the PDFs, use the email address that you have registered with you IE account.

One thing to note is that the instructions on how to access your rack is located in a different part of your IE membership page.  It’s in the “My Current and Future Rack Rental Sessions” section.  You’ll probably want to familiarize yourself with the rack documentation.  I’ve rented IE racks before so I was familiar with the process.  Although I didn’t do it (only because I didn’t think about it), it’s probably a good idea to log into your rack and open your reverse telnet session before you click the button to get your documents.

One thing to be aware of is that as soon as you click the button to begin the lab the clock will start ticking.  You’re given 8.5 hours to complete the lab.  There is a cool countdown widget on your IE member page that will run through your lab so you can easily see how much time has elapsed and how much time you have left.

Mock Lab 1 Timer

As soon as you click the “start lab” button the clock starts counting down.  I didn’t think about printing the lab until after the lab had started.  Since I was at home I had to load drivers on my laptop before I could print to my ancient Canon printer.  By the time I had printed all of the documentation and logged into each of the devices I had already lost 15 minutes.  As I mentioned above, it’s a good idea to log into your rack before starting your lab.

One of the resources that becomes available once you start the lab is a zip file of the initial configurations.  I had already lost 15 minutes printing and logging in to the rack.  I was a little pissed that I would need to apply the initial configurations.  The initial configurations are already loaded on your rack so you don’t need to worry about that.  The intial configurations are provided so you can redo the lab later (or rebuild your rack if you really fuck up).  Whew!!!

So I was up and running with 8 hours and 15 minutes to go.  The IE documentation states that after 8.5 hours you will automatically be kicked off of your rack.  I’ll spare you the task of reading the rest of this post and just tell you that this did not happen in my case.  When the timer finally hit zero I was not kicked off of the rack. I didn’t make any changes at that point and the initial grading script ran within 1 hour of my time elapsing.  [I can't remember when it ran, it may have run right after time expired, but the score was on my member page less than an hour later]  Your experience my not be the same, so I would just assume that your going to be booted off. 

As I posted earlier the grading script will run and give you an initial grade.  Don’t get too depressed about your initial score from the script as it is likely that you will get more points once a proctor reviews your lab. 

Initial Scoresheet Graded By Script

Within two business days a proctor will manually grade your lab and you’ll be able to see a web page with your final grade along with the proctor’s comments and feedback. 

Proctor Feedback

I read the complete lab and made notes before I started configuring anything.  Reading the lab and creating a simple layer 2 diagram took 22 minutes.  After that I kept track of the when I completed each task as well as how confident I was that I had earned the points.  I had completed IGP redistribution and basic BGP peering just before I took “lunch”.  Lunch turned out to be the 20 minutes I spent picking up my son from school.  :-)

I had finished all of the tasks that I felt I could complete with about 30 minutes left.  I ended up not attempting 3 tasks. I spent quite a bit of time troubleshooting an issue that was probably due to an IOS bug, but I had plenty of time to complete the lab.  I did start getting mentally fatigued about 6 hours into the lab.  If I could have stayed a little more focused I could have finish about 30 minutes earlier.  When I finished, I felt pretty good about meeting my goal of getting 80 points.

When your time expires you’ll see a new link to the solution guide.  I didn’t have the energy or inclination to look through it at the time.  I looked at it briefly this weekend.  There are no breakdowns like in the Volume II labs, only the correct configuration as well as some good verification commands.  The Graded Mock Labs are supposed to include a Class On Demand breakdown of the lab.  I haven’t received a link to that yet.  That will probably include the task breakdowns.

I’m not going to go into details about the lab itself other than to say that it was fairly easy.  The lab has a difficulty level of 6 which is easier than the actual lab.  After spending most of the prior 10 days getting my ass handed to me on level 8 labs, this lab seemed pretty easy by comparison.

On Sunday I got the email saying that my lab had been graded by the proctor.  I was very happy (and a little shocked) to find that I had scored an 89.  Since I had skipped 9 points, so I only failed one of the tasks that I attempted.  I missed it due to a stupid mistake in an ACL, but I’m not complaining because there were at least 3 tasks that I got full credit on which I was unsure about my solution. 

Proctor Graded Scoresheet

Random Thoughts:

Finishing with 30 minutes to spare is nice, but I didn’t have time to go back over my tasks to catch stupid mistakes.  I still need to increase my speed.  As I stated earlier, there was a period about 6 hours in where I lost my edge.  I was making silly mistakes and I would end up reading and rereading tasks as well as configuring things twice (because I forgot I had just configured it) as well as forgetting what device I was on.  Nothing major, but in a more difficult lab this could have been a big problem.  As it was, I think that I probably lost 20 – 30 minutes during that stretch just to lack of focus.

I need to limit myself to items that will only be available in the lab as well as curb practices that will not be allowed in the actual lab.  I’m still using Tera Term as my telnet client.  It’s not hugely different from SecureCRT, but I need to make sure that I am more familiar with SecureCRT, especially the cut and paste hot-keys/options.  I also need to stop writing notes on the lab and lab diagrams.  This is not allowed in the actual lab.  I also need to start getting used to using notepad without saving or closing the notepad instances.  Finally, I keep the lab topology open on my laptop so that it’s visible in the background while I’m working.  This is not allowed in that lab, so I need to nix that habit as well.

I was lucky.  I done over 60 hours of IE labs over the 9 days prior to my mock lab so I had more practice with some technologies that I am normally weak on.  I also watched the IEATC session on setting up a logging server and configuring NTP the night before the lab.  Normally, I would have spent much more time using the DOC CD for those topics and I probably would not have received any of the points for NTP because I totally misunderstood key aspects of that technology until literally the night before the mock lab.  Multicast was very simple.  This is the first time that I’ve ever received all of the points for Multicast so you know it was dead easy.  :-)

I knew which technology to use for each task I attempted as well as how to implement it with minimal need of the DOC CD.  I’m not saying this to brag.  I’m saying it because I still finished with only 30 minutes left.  A more difficult lab would have meant more time mining the DOC CD and therefore more time to complete the lab.  I also completely skipped three tasks.  I somehow need to pick up my speed.

Anyhoo….I’m pretty pleased with my score, but I still realize that I have a LONG ways to go before I am ready for the actual lab.

Question Of The Day: 31 March, 2008

Topic: IPv6

FastEthernet0/0 is up, line protocol is up
  Hardware is AmdFE, address is cc00.17b4.0000 (bia cc00.17b4.0000)
  Internet address is 100.1.1.1/24

r1(config)#ipv6 unicast-routing
r1(config)#int fa0/0
r1(config-if)#ipv6 address 2001:B00B:1E5:1::/64 eui-64

What will r1’s fao/o IPv6 address be after this configuration is applied?

Click Here For Answer


Yesterday’s Question

 Question Of The Day: 28 March, 2008 

Topic: Route Summarization

You have the following subnets in your network:

132.16.32.0/24
132.16.121.0/24
132.16.34.0/24
132.16.33.0/24
132.16.5.0/24
132.16.181.0/24
132.16.27.0/24
132.16.2.0/24

Write a single summary route that will encompass all of these routes while being as specific as possible.

Answer: 132.16.0.0/16

Since the first two octets (132.16) are the same we need to look at the third octet.  Since we’re writing a single line we can just use the lowest (2) and highest (181) values:

132.16.2.0     10000100 00010000 00000010 00000000
132.16.181.0 10000100 00010000 10110101 00000000

I this case we can see that the first bits that are different the first bits of the 3rd octet.  We can stop right there.  Everything before those bits will be our network address (132.16.0.0) and the rest will be our mask (255.255.0.0)  Our summary will be 132.16.0.0/16.

Route Summarization

March 28, 2008

ATTACK BY PROCTOR!!!

Every few months on GroupStudy there will be a story about a CCIE candidate going to lunch and coming back to find out that the proctor has messed with their configuration.  I always figured that this was just an urban legend, but then I experienced an ATTACK BY PROCTOR firsthand.

On Wednesday I took one of Internetwork Expert’s Graded Mock Labs.  I had successfully completed IGP redistribution  and had verified that I had end-to-end connectivity via TCL scripts.  I hurried up and applied the basic BGP peerings.  Then I consoled into each device and wrote the configuration.  Just before I went to lunch (actually just a 20 minute break to pick up my son) I reloaded all of the devices. 

When I got back I ran my TCL script again and noticed that my connectivity was broken.  Between IGP redistribution and basic BGP peering my network somehow “broke”.  I figured that I must have really messed something up with my BGP configuration since everything was fine after IGP redistribution.  I went back and verified my BGP configuration and peering on each device.  Maybe I lost some configuration when I reloaded – even though I was careful to make sure that I wrote each device before reloading.  All of my BGP configuration was there so I obviously wrote each device as that was the last configuration I had completed.  All of the BGP peerings were up and I was seeing routes coming in on the peerings (the ones that should be sending routes at least).  WTF?

I didn’t want to waste a ton of time troubleshooting this mess, so I soldiered on with the exam and made a note to run the TCL scripts again later.  When I did eventually run the scripts again, my network was still broken.

I finally started to look at the individual routes that were missing.  My issue seemed to be between the hub and spokes on one of the Frame Relay networks.  I still could not find an issue with BGP.  I took a look at my OSPF neighbors and I found that my OSPF adjacencies from my hub to my spokes were gone.  I still had some routes coming in via a virtual link between my hub and one of my spokes.  How the hell did that happen?

I looked at my OSPF configuration on my hub and found that my neighbor statements to the spokes were missing.  I added them back into the configuration and then ran my TCL scripts again.  Hallelujah!!!  I had full connectivity once again.  Although I had written my configurations after each task I must have somehow not written r5’s configuration after I finished my first OSPF task?  I continued on with the lab as I only had about 20 minutes left at that point.  I did not reload the routers again before finishing the test.  I did make sure that I wrote my configurations on each device and saved out my configurations to textfiles on my desktop.  I probably verified that those neighbor statements were still on r5 about 10 times before the lab ended.  :-)

Thinking back about this issue later I realized that since my BGP configuration was still on r5 I had definitely written the configuration on that device.  The neighbor statements must have been removed when I reloaded that router.  Somehow those devious bastards at IE must have removed my configuration.  They probably have a script that somehow removes those two lines of configuration whenever r5 is reloaded.  I had experienced the dread ATTACK BY PROCTOR!!!

Or not…. :-)

I went to ccie-in-3-months to see if Tassos had experienced any similar issues with his mock lab and found this:

…I decided to reload all routers! What was even more disastrous, was the fact that i reloaded them all at the same time and i didn’t look at their logs while booting.

The result? After the reload, something wasn’t working as expected. After a quick search I found one router which seemed not to be running OSPF. I checked its configuration (thank god I had saved all my session locally) and I found that there were two “neighbor” commands missing! I added them and reloaded again. This time I watched the logs and there was an error message saying that this particular command is not supported on this kind of topologies (a bug? command is accepted while configuring, but it’s rejected after reloading). So i saved my configuration and warned (through email) the proctor about this behavior.

Here’s his post on the Internetwork Expert Mock Lab 1 forum:

Task 4.1

After reload:

Cisco 3640 (R4700) processor (revision 0x00) with 111616K/19456K bytes of memory.
Processor board ID 13831044
R4700 CPU at 100MHz, Implementation 33, Rev 1.0
2 Ethernet interfaces
2 Serial interfaces
DRAM configuration is 64 bits wide with parity disabled.
125K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks

Press RETURN to get started!

Like I said, I didn’t reload the router a second time.  I also would not have thought to watch the reload output.  So the good news is that it was not ATTACK BY PROCTOR but I was the victim of a bug.  [My network type on the hub and spoke was NBMA per the task].

This was actually a good experience as I got to do some troubleshooting under pressure.  I did fuck up my troubleshooting as I assumed that the issue was with BGP and did not troubleshoot outside of BGP until much later.  This was also a potentially disastrous experience as I would have lost an untold number of points due to not having end-to-end connectivity.  I am a bit disappointed that IE had not addressed this bug.

Oh, and the ATTACK BY PROCTOR rumor?  It’s exactly that – a rumor:

Hi Maruilio,

Thanks for the reply!!!

Could you please give a clarity on proctor’s behaviour during the Lab exam? I’ve heard that proctor’s occasionally changes the configuration while the exam is on eg- erase passwords, erase configurations, shutting down the interface, changing the IP addreses, etc. I am not sure if that’s all true? If it is, is that justified? I’ve also heard that you should not be too fast even if you know are pretty confident of your configurations because proctor’s probability of changing the configurations increases. Is that also true?

If the above is true, I also want to know to what extent are proctor’s authorised to play with the configurations during the exam?

My second query is – when the lab starts do we get all the devices with zero configurations or we have to first erase all the pre-configured inappropriate configuration on the devices?

My third query is out of curiosity – what method does proctor’s use for checking the lab created by the student?
Regards,
Saurabh Garg

Hi Saurabh,

These are all rumors and do not reflect the CCIE Lab environment.

Proctors do not touch any of the candidate’s devices during the exam.The only exception will be if a candidate thinks that something is not working because a possible failure on your rack the Proctor will ver[if]y it, but the candidate will be aware of it. Proctors do not touch or play with candidate’s configuration during or after the exam.

When you start the exam your routers and switches will have an initial configuration such IP addresses, hostnames, passwords. Depending of the exam you may have more pre-configuration. The ‘General Guidelines’ of the exam will state what you can change and what not can be changed.

We do have a process to development each question of the exam and it is based on results. By the end of the exam Proctors use an automatic tool to save the candidate’s configuration into our database and to verify some questions and do some connectivity tests like pings, verify routing tables, and so on. Then Proctors will manually verify the results and all remaining questions to come up with the final score.

Regards,
Maurilio

Question Of The Day: 28 March, 2008

Topic: Route Summarization

You have the following subnets in your network:

132.16.32.0/24
132.16.121.0/24
132.16.34.0/24
132.16.33.0/24
132.16.5.0/24
132.16.181.0/24
132.16.27.0/24
132.16.2.0/24

Write a single summary route that will encompass all of these routes while being as specific as possible.

See you Monday.


Yesterday’s Question

 Question Of The Day: 27 March, 2008 

Topic: Route Redistribution 

r1 is running EIGRP and RIP:

r1#sh ip proto sum
Index Process Name
0     connected
1     static
2     eigrp 100
3     rip

r1 has the following EIGRP routes:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:01:06, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:00:23, Serial1/0.12

r1’s network admin wants to redistribute the EIGRP routes and pass them on to r3 in the RIP domain (directly connected to r1).  Here is his configuration:

r1(config)#route-map EIGRP->RIP perm 10
r1(config-route-map)#match route-type external
r1(config-route-map)#set tag 1170
r1(config-route-map)#route-map EIGRP->RIP perm 20
r1(config-route-map)#set tag 190
r1(config-route-map)#router rip
r1(config-router)#redistribute eigrp 100 route-map EIGRP->RIP

Which EIGRP routes will appear in r3’s (RIP) routing table?

Answer: The redistributed routes appear in r3’s routing table with a metric of 6 (set by the route-map) and r1’s locally generated RIP routes appear with a metric of 1.

r3#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/6] via 10.1.13.1, 00:00:03, Serial1/0
     22.0.0.0/32 is subnetted, 1 subnets
R       22.2.2.2 [120/6] via 10.1.13.1, 00:00:03, Serial1/0
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.12.0 [120/1] via 10.1.13.1, 00:00:03, Serial1/0
     12.0.0.0/32 is subnetted, 1 subnets
R       12.12.12.12 [120/6] via 10.1.13.1, 00:00:03, Serial1/0
     13.0.0.0/32 is subnetted, 1 subnets
R       13.13.13.13 [120/1] via 10.1.13.1, 00:00:03, Serial1/0

The order of preference for defining the metric when redistributing routes into a protocol (values in parentheses are the values used in our example):

1) If a route-map is used, then use the metric specified in the route-map (6).
2) If no route-map is used or the route-map does not specify a metric, then use the metric specified in the ‘redistribute’ command (2).
3) If a metric is not specified in a route-map nor is it specified in the ‘redistribute’ command, then use the ‘default-metric'(4).
4) If no metric is specified by any of the above methods, then the routes will not be redistributed (see this QOD).

route-map > redistibution metric > default metric
redistribute (IP)

The metric value specified in the redistribute command supersedes the metric value specified using the default-metric command.

set metric (BGP, OSPF, RIP)

default-metric (RIP)

Usage Guidelines
The default-metric command is used in conjunction with the redistribute router configuration command to cause the current routing protocol to use the same metric value for all redistributed routes. A default metric helps solve the problem of redistributing routes with incompatible metrics. Whenever metrics do not convert, using a default metric provides a reasonable substitute and enables the redistribution to proceed.

The default-metric is only in conjunction with redistribution.  Don’t fall into the trap of thinking that the default metric will affect routes that are not redistibuted.

March 27, 2008

Cool Command 2: Verify Your BGP Regular Expressions

Here’s a great command for verifying (or just practicing) your BGP regular expression filters.  In the example below, I want to only see the routes where AS54 is the last AS in the AS path*.  I’m pretty sure that my regular expression is correct, but I want to verify it by running it against my BGP database.

Here’s the full BGP database:

r6(config)#do sh ip bgp | b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i
*> 112.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.3.254               0             0 54 i
*> 115.0.0.0        54.1.3.254               0             0 54 i
*> 116.0.0.0        54.1.3.254               0             0 54 i
*> 117.0.0.0        54.1.3.254               0             0 54 i
*> 118.0.0.0        54.1.3.254               0             0 54 i
*> 119.0.0.0        54.1.3.254               0             0 54 i
*> 205.90.31.0      204.12.1.3                             0 200 254 ?
*> 220.20.3.0       204.12.1.3                             0 200 254 ?
*> 222.22.2.0       204.12.1.3                             0 200 254 ?

Here’s the results of filtering with ^54_ :

r6(config)#do sh ip bgp regex ^54_
BGP table version is 14, local router ID is 150.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i
*> 112.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 113.0.0.0        54.1.3.254               0             0 54 50 60 i
*> 114.0.0.0        54.1.3.254               0             0 54 i
*> 115.0.0.0        54.1.3.254               0             0 54 i
*> 116.0.0.0        54.1.3.254               0             0 54 i
*> 117.0.0.0        54.1.3.254               0             0 54 i
*> 118.0.0.0        54.1.3.254               0             0 54 i
*> 119.0.0.0        54.1.3.254               0             0 54 i

show ip bgp regexp

*Thanks to apep for the correction.  See comment section for details.

Question Of The Day: 27 March, 2008

Topic: Route Redistribution

The network admin on r1 is tasked with redistributing the EIGRP routes into RIP so that they appear in the routing table of the directly connected router r3 (running RIP only).  Here are the EIGRP routes currently in r1’s routing table:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:07:44, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:07:44, Serial1/0.12

Here is the configuration on r1:

router rip
 version 2
 redistribute eigrp 100 metric 2 route-map EIGRP->RIP
 passive-interface default
 no passive-interface Serial1/0.13
 network 10.0.0.0
 network 13.0.0.0
 default-metric 4
 no auto-summary
!
route-map EIGRP->RIP permit 10
 set metric 6

On r3, what will be the metric of the redistributed EIGRP routes?  What will be the metric of the locally generated RIP routes (i.e. 13.13.13.13/32)?

I’ll post the answer tomorrow.


Yesterday’s Question

 Question Of The Day: 26 March, 2008 

Topic: Route Redistribution 

r1 is running EIGRP and RIP:

r1#sh ip proto sum
Index Process Name
0     connected
1     static
2     eigrp 100
3     rip

r1 has the following EIGRP routes:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:01:06, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:00:23, Serial1/0.12

r1’s network admin wants to redistribute the EIGRP routes and pass them on to r3 in the RIP domain (directly connected to r1).  Here is his configuration:

r1(config)#route-map EIGRP->RIP perm 10
r1(config-route-map)#match route-type external
r1(config-route-map)#set tag 1170
r1(config-route-map)#route-map EIGRP->RIP perm 20
r1(config-route-map)#set tag 190
r1(config-route-map)#router rip
r1(config-router)#redistribute eigrp 100 route-map EIGRP->RIP

Which EIGRP routes will appear in r3’s (RIP) routing table?

Answer: NONE

RIP routes on r3 do not include the routes redistributed from EIGRP on r1: 

r3#sh ip route rip
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.12.0 [120/1] via 10.1.13.1, 00:00:22, Serial1/0
     13.0.0.0/32 is subnetted, 1 subnets
R       13.13.13.13 [120/1] via 10.1.13.1, 00:00:22, Serial1/0

When redistributing routes into RIP you must specify a default metric:

r1(config)#router rip
r1(config-router)#redistribute eigrp 100 metric 3route-map EIGRP->RIP

Now we should see the EIGRP routes in r3’s routing table with a metric of 3:

r3#sh ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/3] via 10.1.13.1, 00:00:19, Serial1/0
     22.0.0.0/32 is subnetted, 1 subnets
R       22.2.2.2 [120/3] via 10.1.13.1, 00:00:19, Serial1/0
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.12.0 [120/1] via 10.1.13.1, 00:00:19, Serial1/0
     12.0.0.0/32 is subnetted, 1 subnets
R       12.12.12.12 [120/3] via 10.1.13.1, 00:00:19, Serial1/0
     13.0.0.0/32 is subnetted, 1 subnets
R       13.13.13.13 [120/1] via 10.1.13.1, 00:00:19, Serial1/0

It’s pretty easy to forget the metric as the IOS will not throw an error.  You are basically redistributing the EIGRP routes with a metric of zero.  :-)

March 26, 2008

Internetwork Expert Graded Mock Lab 1: First Impressions

I just finished IE’s Graded Mock Lab 1.  This culminates a week and a half of hardcore labbing.  Now I get to go back to work and spend the next week and a half digging out of the work that’s been backing up over my “vacation”.

Mock Lab 1 is a difficultly level 6 lab.  That means that it’s easier than the actual lab.  After reading through the lab I felt that I had a very good chance of passing it.  There were only a couple of tasks that I was not sure how to do.  I cruised through the core tasks up until route-redistribution.  Even though the redistribution was insanely easy, I still spent a lot of time running scripts and verifying connections.  By the time I took my “lunch break” I had just completed BGP peering.

I left 9 points on the table (3 points each in BGP, Security, and IP Services).  Of those three tasks, there was only one (in IP Services) that was something completely alien to me. 

I really felt that I passed the lab.  I estimate that I scored between 75 and a 91.  There were about 4 or 5 questions that I would have asked of the proctor.

As soon as the lab is over you get an initial scoring report.  The initial score report is graded by a script.  You lab will also be graded by a proctor in the next two business days.  After that you’ll receive your final score and feedback from the proctor.

My initial score report is 70.

You Scored: 70
Date:03/26/2008
Mock Lab:R&S Mock Lab 1
Difficulty Level:6
You scored better than 69% of all students who took this lab.

Note: This mock lab was graded by our automated grading system.  A proctor will also grade your configuration and it will appear in your members site within 2 business days.

Hopefully I can get another 10 points from the proctor.  As it stands, these results mirror my experience with most of the Volume II labs.  I do really well on the all of the core IGP and switching tasks.  I then fall down a little on BGP.  Then I nosedive on the last sections.  In this case, I got 56 of the first 64 points.  That means that I only got 14 of the last 36 points.  If I score over 80 (my goal) then I will be happy.  If my score stays at 70, I will be satisfied but still a little disappointed.

I’m too tired and punch drunk to go over the solution guide right now.  I’ll post more about this lab later.

Question Of The Day: 26 March, 2008

Topic: Route Redistribution 

r1 is running EIGRP and RIP:

r1#sh ip proto sum
Index Process Name
0     connected
1     static
2     eigrp 100
3     rip

r1 has the following EIGRP routes:

r1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 10.1.12.2, 00:01:06, Serial1/0.12
     22.0.0.0/32 is subnetted, 1 subnets
D EX    22.2.2.2 [170/2560512256] via 10.1.12.2, 00:00:23, Serial1/0.12

r1’s network admin wants to redistribute the EIGRP routes and pass them on to r3 in the RIP domain (directly connected to r1).  Here is his configuration:

r1(config)#route-map EIGRP->RIP perm 10
r1(config-route-map)#match route-type external
r1(config-route-map)#set tag 1170
r1(config-route-map)#route-map EIGRP->RIP perm 20
r1(config-route-map)#set tag 190
r1(config-route-map)#router rip
r1(config-router)#redistribute eigrp 100 route-map EIGRP->RIP

Which EIGRP routes will appear in r3’s (RIP) routing table?

Click here for the answer.


Yesterday’s Question

 Question Of The Day: 25 March, 2008 

Topic: EIGRP

Which of the following commands will make EIGRP AS 100 consider delay only when calculating the EIGRP metric?

1) router eigrp 100
    default metric 1 1 0 1 1500

2) router eigrp 100
    metric weights 0 1 0 0 0 0    

3) router eigrp 100
    metric weights 0 0 1 0 0 0

4) router eigrp 100
    metric weights 0 0 0 1 0 0

Answer:

4) router eigrp 100
    metric weights 0 0 0 1 0 0


metric weights (EIGRP)

metric weights tos k1 k2 k3 k4 k5

The first value is ‘tos’ (Type of Service) and is always zero.  The remaining five values are the EIGRP ‘k-values’.

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:

metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay]

If k5 does not equal zero, an additional operation is performed:

metric = metric * [k5/(reliability + k4)]

The ‘trick’ is not assuming that the five k-values match up with the five EIGRP metrics:

default-metric (EIGRP)

default-metric bandwidth delay reliability loading mtu

The five EIGRP metrics (which I memorized with the mnemonic “Big Dogs Really Love Meat”) do NOT correspond to the k-values.  So don’t do what I did and use ‘metric weights 0 0 1 0 0 0′  :-)

March 25, 2008

Question Of The Day: 25 March, 2008

Topic: EIGRP

Which of the following commands will make EIGRP AS 100 consider delay only when calculating the EIGRP metric?

1) router eigrp 100
    default metric 1 1 0 1 1500

2) router eigrp 100
    metric weights 0 1 0 0 0 0    

3) router eigrp 100
    metric weights 0 0 1 0 0 0

4) router eigrp 100
    metric weights 0 0 0 1 0 0

Click here for the answer.

March 24, 2008

Cool Command 1: Verify OSPF Authentication

Here’s a nice command to quickly verify that your OSPF authentication is enabled:

r5#sh ip os int | i proto|auth|Area
OSPF_VL0
is up, line protocol is up
  Internet Address 191.1.45.5/25, Area 0
  Message digest authentication enabled
Loopback0 is up, line protocol is up
  Internet Address 150.1.5.5/24, Area 0
Serial0/0 is up, line protocol is up
  Internet Address 191.1.125.5/24, Area 0
  Message digest authentication enabled
FastEthernet0/0
is up, line protocol is up
  Internet Address 191.1.5.5/24, Area 5
  Simple password authentication enabled
FastEthernet0/1.45
is up, line protocol is up
  Internet Address 191.1.45.5/25, Area 45
  Simple password authentication enabled
FastEthernet0/1.59
is up, line protocol is up
  Internet Address 191.1.59.5/24, Area 90
FastEthernet0/1.50 is up, line protocol is up
  Internet Address 191.1.50.5/24, Area 90

This command shows us all of the OSPF enabled interfaces, what area they are they are in, whether they are using authentication or not, and – if so – what type of authentication we are using.

For example, we can see that s0/0 is OSPF enabled, is in area 0, is running authentication, and the authentication type is md5.

ip ospf authentication

ip ospf authentication-key

ip ospf message-digest-key

area authentication  

show ip ospf interface

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 114 other followers