IE – Mock Lab 1

I’ve finally found some time to go through and dissect my mock labs. I’ll start with lab 1, cos that would make sense…

Difficulty 6, Score 73

Section	Score	Max
1. Frame Relay	7	7
2. HDLC/PPP	2	2
3. Bridging and Switching	11	16
4. Interior Gateway Routing	23	23
5. Exterior Gateway Routing	5	16
6. IP Multicast	3	6
7. IPv6	5	5
8. QoS	6	6
9. Security	2	5
10. System Management	3	8
11. IP Services	6	6

Not what I was expecting, but by no means disheartening. I’d say my approach was a bit sloppy, and it certainly gave me a good taste of how thorough I need to be in the lab.

Bridging & Switching
3.1 – Staring off I created the wrong IP address on Vlan7, I configured it for rack 1 when it should have been rack 10.
3.4 – In the trunking section, I didn’t configure VLAN6. This baffled me a bit because I always check reachability to all devices on each segment.

BGP
5.1 - No prefixes were installed into SW2’s routing table. No sure what went on here…
5.2 – R6’s interface was unreachable because I screwed up task 3.4
5.3 – SW1’s interface was unreachable because I screwed up task 3.1

Multicast
6.1 – I honestly had no idea how to approach this task, as simple as it was. Multicast is a deffinately a weaker area for me. Since both mock labs I’ve managed to read the majority of my ‘Developing IP multicast’ book and I think further attempts will be muc more understood.

Security
9.1 – For some reason I thought this was a typo. I did for a second think VLAN Acl’s were the answer, but then I had this idea that because SW3 wasn’t in the diagram, it wasn’t part of these questions. It was silly to think that a typo would be in these labs in the first place….

System Management
10.1 – R6 didn’t have a route to the NMS, so although my configuration was right….it wouldn’t have actually worked.
10.2 – R6 didn’t have a route to the NTP server and hence it wasn’t synced.

I’m absolutely livid about the VLAN mistakes, they cost me my BGP section. But on the other hand getting the IP address wrong was probably the most important lesson from the whole lab. If you assign the wrong IP to and interface and then copy the interface IP’s for the TCL script, you will never see the problem in the first place.

Propper study.

So I’m pissing off to New York for 8 days on Monday for work, and the thought crossed my mind that since I’ve never been, I’ll be all but interested in reading text books at the hotel…

My work week at the moment is only 4 days, with Friday being my day off. Ideally If I could get three labs done in three days with some reading I’d be pretty happy.

Friday morning I got up at 9, had breakfast, and started on IE Volume II Lab 18. For all three labs I took the exact same approach, spending more time on each task to be confident enough that the solution I had was the right one and then just note how long I had left left once i’d fionished all the tasks.

IE Vol II – Lab18
Difficulty 7

4.1 – I broke the task by not paying attention to the wording, using 0.0.0.0 on one of the routers when it should have been more specific.
5.4 – Didn’t know how to do this task and meet the requirements. Eventually I just gave up, got connectivity and moved on.
6.4 – Didn’t filter correctly, my method was to use the autorp keyword with multicast boundary when it shoul dhave been using an acl.
7.2 – IPv6 NAT-PT, never read up on this before  and found the DocCD a little hard to understand. Still got some work to do with IPv6.
9.2 – I always get passive and active FTP mixed up, its the only part of this one I couldn’t get right. After the lab I read up on both and think i’ve finally got it nutted.
10.1 – I turned on “logging count” for this task to track if changes were made on the syslog server. This was in fact the answer to 10.2. The command I was after was “service sequence-numbers”.
11.1 – Had the commands right but it didn’t occur to me that I needed to put the domain on the end of each hostname.
11.2 – This was a 4 point task to show off to your ‘colleagues’ how you can make a router always reply to traceroutes from its loopback interface. Thought I had it right, and it actually worked from one router, but not any of others. Regardless, I didnt worry too much about it since its more of a “stupid router trick” (TM Brian Dennis).

—–

Saturday and today I decided to do IE Mock Lab 1 and 2. I’ll post about these when I receive the results, but from looking at the solution guide for lab 1 it would appear I got most of it right (although the score report could say otherwise!). Lab two is still running, but I’ve finished with configuration.

I completed Lab1 in 6hrs, and Lab2 in 6hrs 30 minutes.

IEWB – Volume II – Lab 8

Difficulty 8

Last night I started IE’s Lab 17 from Volume II and finished this morning. It all went pretty well, taking me just under 5 hours to complete. Obviously my verification could have gone for another 3 hours and I could have maybe got a few more points but I thought I’d just see how it went by just verifying as I moved along.

1.1 – I cant believe I missed this but it just skipped my mind to put the VTP password on the domain. Not sure if I would have picked this up a second time around….

4.1 – I dint get this this one wrong, but after looking at the solution guide this had the potential to cause lots of problems. It basically forces you to configure non-broadcast across the hub and spoke frame-relay network. The problem is, that it specifically tells you that interface OSPF commands are not allowed. This means that during DR election any router could potentially become the DR, breaking LSA advertisement. The highest IP router (R5) was correct to be the DR, but had that rebooted there would have been all sorts of problems. I very much doubt this kind of thing would be on the LAB, but who knows.

4.7 – I didn’t redistribute connected on R5 to advertise the link to BB2. This would have been a proctor question for me since it never asked to advertise it. Either way, it was wrong.

5.1 – Same thing, this time it was the same route to go into BGP. Again, it would have been the proctor question.

9.3 – This task was asking for EAPoUDP. I had absolutely no idea where it was in the documentation. Turns out it lives under the Network Admission Control section of Traffic filtering. I hadn’t actually got to reading all of this document yet, but at least now I know where it is.

Some labbing and a smack in the teeth….

Today I decided to hop back into a bit of labing with one of IE’s core volume III labs. I’ve done up to number 4 so far so it seemed logical to go ahead with number 5.

I’ve never had so many problems!

It started with the switching section. First up I couldn’t ping between the two switches (SW3 & SW4) because I wasnt paying attention to the behind the scenes configuration which needed to be done on SW2. I still got the section done under the allotted time but its a reminder that I need to pay more attention to the diagrams, and the physical topology.

Next was the PPP configuration with Dialer profiles. I’ve done heaps if DDR before back at my old job but not with point-to-point serial. Initially I got them dialing each other and had ping working but then the dialer’s dropped due to idle, after that although both ends came back up, nothing worked. I spent probably half an hour stuffing around with this and in the end just got rid of it and just did it the easy way. The IE forums had a few posts on others having the same issue….and most of them didnt seem to get it working properly.

With L2 out of the way I moved on to the IGP which in itself pretty straight forward except for a couple of areas that weren’t attached to the backbone. One of them required a tunnel because it was a stub area, not too hard….and the others were virtual links. Next up I went through redistribution, I begun testing connectivity…..this is where the real problems started.

Problem 1:
R5 is the hub and R1 / R2 are spokes. because R1 was in area 0 I set up a virtual link directly to R5 and a virtual link directly to R2. Although this looks right in the routing table it was purely and utterly wrong. R2’s virtual link was passing through R5 before it terminates to R1. This was causing traffic to hit R5 and then not be routed in the corect direction even though the routing table had the right next hop. To fix it, the virtual links went from R1 -> R5 -> R2 -> Then the tunnel to SW1.

All good right? No.

Problem 2:
R1 still couldn’t ping R2’s loopback. I cleared processes, double checked my config, went though the routing table, checked the OSPF database, and rang packet debugs for ping tests. It was all rather strange. So bugger it….I’ll move on and check my redistribution and come back to it…..Silly move really….

Problem 3:
Routers in the OSPF domain couldn’t ping R4’s Serial PPP interface, R5’s Serial PPP interface, and R4′ Ethernet interface. Yet it could ping SW2’s interface which was attached to R4’s Ethernet interface!! Once again I checked and checked and checked…..nothing.

By this time I was getting well pissed off. Then I thought….maybe I’ll just try a reboot.

Problem 1, problem 2, and problem 3…..all fixed in 2 minutes. I don’t know what the cause was….IOS related, Dynamips being a pig, or just me making too many changes. But either way it was a very valuable lesson which I hopefully wont fall for again.

BGP was next and it was pretty easy. Phew.

Overall I dropped 3 points on the Dialer profiles, but the lab took a lot longer than what it should have.

This is the first one I’ve done for a while and I certainly wasn’t on the ball as what I have been in the past. Tomorrow I think I’ll do Volume II lab 16, and hopefully with the ordeal I went through today it will keep me on my toes for tomorrow….

Plodding away….

Over the weekend I booked in some rack time and went through the Volume I version 5 bridging and switching labs. Since I have been reading a fair chunk of the 3550/3560 documentation recently I was able to get though almost all the tasks without having to reference it. RSPAN required a quick lookup, but apart from that most of the tasks are pretty straight forward. I have noticed however that MST can get a lot more complicated than what is in the workbook. Whether or not the actual lab even goes into this kind of complexity, I’m going to spend more time on learning this just to be sure. But hopefully a lot of my knowledge gaps can be cleared up in the IE bootcamp.

On top the switching, I finished watching the OSPF videos from week one of the CoD and got halfway through BGP. Again, pretty much everything I saw was what I learnt from the first sitting. Week one does certainly start from the ground up basics so maybe week two will be where I missed a lot of material.

Now that I’ve started my new job (which is only til mid October), I’m somewhat concerned about how much study will get done during the week. I’m hoping that four day weeks will be the answer, but even after just one day, it was noticeably harder to come home and hop straight into it. Maybe I just forget whats its like to start a new job, after all it has been a while…