The more mock labs I do the more I realise the SP Lab is all about details. Small details or nuances if you wish. Having completed INE Vol2 Lab 7 tonight I have begun collecting them and the trick is to be aware of their existance during the pressure moments of the lab.
- Typos – These happen to me all the way through my practise labs – NET addresses in ISIS, ATM PVC addressing, the wrong configuration on the wrong router or the right configuration on the wrong interface, wrong masks on loopbacks, etc
- Gotchas – ensure clns statements added to both ATM & FR connections if passing ISIS traffic across. Know the PPPoE configuration is dependent on IOS versions with different hardware,
- Diagram\IP Analysis – Match up your pre-configurations with the diagrams handed out. You literally have to walk each router interface by interface and match it up with the workbook you have been given. It has been known for the wrong workbooks to be handed to candidates.
- Pro-Active Management – Enable debug ip routing on relevant core devices – you need to know when routes are being deleted on one router as you make changes on another.
- Always complete IGP, EGP, MPLS & MPLS VPN prior to multicast to prevent issues such as RPF, etc -> Look what happens when you do not!
Rack1R4(config-if)#ip vrf forwarding 65001
% Interface Ethernet0/1 IP address 10.3.48.4 removed due to enabling VRF 65001
%PIM-5-NBRCHG: neighbor 10.1.48.8 DOWN on interface Ethernet0/1 non DR
Rack1R4(config-if)#ip address 10.3.48.4 255.255.255.0
- Be aware that strange events will occur – do not let them phase you – here is an example – enabling VRF on an interface removes the ip address right?
Rack1R2(config-if)#ip vrf forwarding 65001
% Interface FastEthernet1/0 IP address 10.3.27.2 removed due to enabling VRF 65001
RT: del 10.3.27.0/24 via 0.0.0.0, connected metric [0/0]
RT: delete subnet route to 10.3.27.0/24
RT: delete network route to 10.0.0.0
%DEC21140-5-REMOVE_HWADDR_FAIL: Interface FastEthernet1/0 failed to remove Addr:=0100.5e00.000d from HWAF
- Reloads – 1. Know when to reload – 2. why you should reload – 3. how reload can help you and 4. when not to reload.
My opinion? 1. At the start to ensure no gremlins, if strange events\issues strike you, just before lunch. 2. To remove issues, to ensure stable configurations & for piece of mind. 3. again to assist in resolving unknown issues and 4. at the end of the lab.
- Time Management – we stress this over and over again but we engineers do not know when to let an issue go – however be aware that the SP exam is more hierarchical then the RS exam and there is less scope for skipping sections due to the nature of the SP Core and the reasoning behind end-to-end connectivity.
These are just some notes as I have come across them – there are a few more and I will incorporate them in the Version 3 of the CCIE SP Lab Checklist which I published before my last attempt in February.
Happy labbing, Steve