Keeping track & typo’s – 31 days to go.
What is it with typo’s – is it that we get used to using F7 with Microsoft Word\Outlook to auto-correct our natural spelling mistakes? There is of course no such luxury in IOS and I am constantly having to backtrack on small errors not just typos that have huge implications.
Examples include …..
- NET addressing with ISIS
- Advertising networks into BGP
- Enabling mpls traffic-eng tunnels on the wrong physical interfaces
- Specifying the wrong ip addresses for various interfaces
- Adding neighbors into the wrong address-families
- Wrong mask details for OSPF networks or when filtering through access-lists\prefix-lists, etc
- Missing configurations – e.g. not placing all route-target import\export entries across all transit routers in the inter-network
- Redstribution Filtering – trying to trap all posssibilities – I favour the tagging method.
You’ll have noticed that my blogging has been less technical and more observational – this is of course deliberate – more hours labbing! I have some rack rental time over the coming weekends with both INE & IPExpert – I have put together 4 “Master Labs” basically a culmination of both the aforementioned workbooks plus my recalled tasks I received in my 1st lab attempt [No, not available] – broken these into the 9 sections – put a big chart on my whiteboard and ticking the boxes off as I go. I am fairly confident I can sort out the foundations of the lab reasonably quickly i.e. L2\IGP\EGP & MPLS. The key for me will be obtaining as many of the MPLS VPN’s 27 points available. I am confident with Basic\Multi-VRF, MP-iBGP, MP-eBGP but advanced configurations are killing me time wise and even though I can configure up L2VPN it just seems so strange to type in ‘interworking ip’ commands on one end of the network and the neighbors appear by magic on the other – Good Stuff!
SP Verification Notes
One of the keystones to success in the SP Lab Exam is verification. Now this is obviously key to all tracks but is particularly complex in SP.
With the RS exam there are 4 ways to verify connectivity – ping, traceroute, routing table lookup and TCL Scripting [extended version of ping] where we put together a TCL Script using the foreach functionality – specify the various IP ranges used during the exam and execute the perl script on the routers. It has been covered in various other posts so here’s a link to NMC’s[or Cisco's] TCL document -> http://www.netmasterclass.net/site/articles/CISCO%20IOS%20TCL%20and%20RCMD%20testing%20and%20troubleshooting%20scripting.pdf
Note that for the for the 3550’s, they do not support TCL rather use macro’s so in config mode type…
macro name ICMP
do ping 18.1.1.1
do ping 18.2.2.2
do ping 18.3.3.3
do ping 18.4.4.4
@
However we use the address-family concept in SP and as a result this technique is only valid for L2 & L3 addresses not associated with address-families. As a result we need to place various appendages to our verification commands. Concentrating on the MPLS VPN world we use…
“show ip bgp vpn all summary” command to check the MP-BGP establishment status
“show ip vrf detail” command to verify the import and export route targets.
“ping vrf <vrf> <ip address> source <source ip>” to ping ip addresses not in standard routing table
“sh ip bgp vpn all summary”
Lists all of the MP-BGP and CE peers.
“sh ip bgp vpn all”
Lists all of the VPN prefixes advertised and received by the router.
“sh ip bgp vpn vrf <vrf> summary”
Similar to the first command, but for a specific VRF.
“sh ip bgp vpn vrf <vrf>”
Lists all of the VPN prefixes received in a specific VRF.
“sh ip bgp vpn vrf <vrf> labels”
Lists labels for the VPN prefixes in a VRF.
“sh mpls forwarding”
Shows all LFIB entries (VPN, non-VPN, TE, and so on).
“sh mpls forwarding | inc <prefix>”
Shows whether the prefix is present in the LFIB or not.
“sh mpls forwarding vrf <vrf> <prefix>”
Shows LFIB lookup based on a VPN prefix.
“sh mpls forwarding label <label>”
Shows LFIB lookup based on an incoming label.
This also extends to Multicast wher you need to amend the commands such as sh ip pim vrf <vrf> int, etc.
As you can see the verification in the MPLS VPN portion of the lab will require a good deal of time and hence perhaps why Cisco perform so much pre-config on this exam.
Details, details & details
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
Rack1R4(config-if)#
%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
Rack1R2(config-if)#
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
Rack1R2(config-if)#
%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