Task 1.1

In going through this lab i have found varous faults in the configs which I though were what task 1.1 - troubleshooting, was trying to get me to uncover.  however, after looking at the SG the solution did not match with what i found.  here are my findings:

  1. wrong int loopback 0 ip address on sw3.  This was causing ospf issues because of dulicate rotuer IDs.
  2. wrong ip addressing on vlan 89 between sw2 and sw3.  they use 145.x.89.x but the diagram shows it as 145.x.8.x.

In looking at the SG, they say the two faults are that the secondary IP address on R6 ser 0/0/0 needs to be removed and that netmask is wrong on R5 Fa0/0.  I can agree with the mask being wrong on R5's interface Fa0/0, but i was able to get my frame relay connection between BB1 and R6 up without having to remove that secondary IP. 

 

Can anyone explian why the secondary IP address has to be removed on R6's ser 0/0/0?

 

I can't even begin to express how frustrated I am with VOL3 of the INE workbooks.  We should all get a refund for it in my opinion.  Labs 5 was probably the biggest mess of them all.  

Comments

  • wrong int loopback 0 ip address on sw3.  This was causing ospf issues because of dulicate rotuer IDs.

    I agree!

    wrong ip addressing on vlan 89 between sw2 and sw3.  they use 145.x.89.x but the diagram shows it as 145.x.8.x

    I agree - although you could argue this is a diagram fault.

    but i was able to get my frame relay connection between BB1 and R6 up without having to remove that secondary IP. 

    This fault won't stop the frame-relay from working - but I think it would cause problems with the BGP section - as it's the next hop for BB1.  Clearly this secondary must be removed.  I found the fault while configuring frame relay so didn't what the knock on effect would be.

    I can't even begin to express how frustrated I am with VOL3 of the INE workbooks.  We should all get a refund for it in my opinion.  Labs 5 was probably the biggest mess of them all. 

    I don't agree with your findings. Volume III is designed to get you build core configurations in your sleep - it also throws some interesting curve balls in which make you pause for thought.  I spent a lot of time messing around with the PPPoFR running OSPF to try to understand what was going on in lab 5 - I learnt a lot from this experience.  In terms of the faults - yeah there maybe extra faults - well that's a nice bonus - troubleshooting is a key skill in passing the lab :-).  Lab 5 also highlights how technologies you thought you understood - can seriously mess with your head!

    It could do with an update but essentially it does what is says on the tin!

     

     

    1. wrong int loopback 0 ip address on sw3.  This was causing ospf issues because of dulicate rotuer IDs.
    2. wrong ip addressing on vlan 89 between sw2 and sw3.  they use 145.x.89.x but the diagram shows it as 145.x.8.x.

    It took me a while for deciding to change the IP addresses or not.  I intially though wrong lo address was added to introduce some problem in the lab but this is not true i guess better to change ip addresses. Such mistakes consumes a lot of unneccessary time but at the same time some learnings as well. 

  • I just found sw3's loopback issue and the wrong subnet on vlan89 as well.  I just corrected the sw3 issue to avoid headaches later on.

  • In total I've found 4 faults- the two pointed by the workbook
    solutions plus SW3 and SW4 loopback addresses were also incorrect. Looking at
    the VLAN assignment we can confirm it is a diagram error as there's no
    VLAN 8 anywhere. Plust the .8 is also missing next to SW3 VLAN 89 segment. Definitely a diagram issue.

    I
    agree that it's not ideal and it can cause a bit of frustration at
    first, specially when the task reads "All information (IP addressing, interface
    numbering, etc) in the diagrams is correct."
    However as opposed to see it as a negative I like think of it (as someone
    mentioned) as bonus faults! Free of charge! Thanks INE! Anyhow, let's hope
    they
    update at least the diagram next time around.

    In a more serious note though
    I've heard candidates before saying that during their lab troubleshooting
    section they were able to find additional faults on
    non-highlighted devices! So the fact we were able to find these extra
    faults can only be a good thing. I see these fault finding tasks just as an opportunity to quickly check the topology and
    make sure everything looks good, that the proctor loaded the right config and etc. So if you spot something
    wrong you can let the proctor know within 10 to 15 mins as opposed to an hour
    into the exam which would have a disastrous affect on one's confidence I'd guess.

Sign In or Register to comment.