I am going to give up on NMC Lab 18 for the moment. It is really really hard, with lots of strange corner cases and obscure new features. I shall come back to it when I am in the frame of mind to learn wierdstuff.
At this stage in my preparation I neeed encouragement, not humiliation!
I am having a problem seeing 802.1Q and 802.1P tags in Ethereal. I am trying to monitor a trunk port using SPAN, and although Ethereal is seeing the traffic, I cannot see the 802.1Q tag . I have seen this before at work, and it is about convincing the NIC on the PC not to discard the tag. At work, we found a registry hack to convince the NIC not to strip the tag.
For reference, I am doing it on an HP ZE4603EA laptop which has a National Semiconductor DP83815 MacPhyter 3v NIC, with driver version 1525.292.
Here are some resources:
But despite a search on the Internet, I cannot find a registry hack for this particular NIC.
Humph!
This lab is the most difficult I ever tried. I suppose it didn’t help that I failed to do a proper read-through before I started, so I missed the VPN requirement 18.7.6, which actually changes the whole approach to the redistribution. So I went steaming through the first 6 sections in under two hours, then came to a screaching halt at the VPN section, and ended up taking a further two hours over it.
18.8 – Security. IPsec VPN is something I have not done before. I really don’t think (please God !!) I am going to get it in the exam, ‘cos I’m not taking CCIE security. If I do then I’m sunk. I’m just going to type in the solution in the AK, and hope something sticks for now. Just look at those routes disappear as soon as I set the tunnel mode to ipsec ipv4, and come back again as soon as I attach the profile. Magic! Haven’t a clue (yet) what it means.
R2(ipsec-profile)#int Tu25 R2(config-if)#tunnel mode ipsec ipv4 R2(config-if)# *Apr 8 17:21:14.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel25, changed state to down R2(config-if)# *Apr 8 17:21:14.271: is_up: 0 state: 4 sub state: 1 line: 0 has_route: True *Apr 8 17:21:14.275: RT: del 151.10.55.0/24 via 151.10.50.5, rip metric [120/1] *Apr 8 17:21:14.275: RT: delete subnet route to 151.10.55.0/24 *Apr 8 17:21:14.275: RT: NET-RED 151.10.55.0/24 *Apr 8 17:21:14.275: RT: interface Tunnel25 removed from routing table *Apr 8 17:21:14.279: RT: del 151.10.50.0/24 via 0.0.0.0, connected metric [0/0] *Apr 8 17:21:14.279: RT: delete subnet route to 151.10.50.0/24 *Apr 8 17:21:14.279: RT: NET-RED 151.10.50.0/24 R2(config-if)#tunnel protection ipsec profile VPN R2(config-if)# *Apr 8 17:22:12.082: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON R2(config-if)# *Apr 8 17:22:14.061: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel25, changed state to up R2(config-if)# *Apr 8 17:22:14.065: is_up: 1 state: 4 sub state: 1 line: 0 has_route: False *Apr 8 17:22:14.065: RT: SET_LAST_RDB for 151.10.50.0/24 NEW rdb: is directly connected
*Apr 8 17:22:14.065: RT: add 151.10.50.0/24 via 0.0.0.0, connected metric [0/0] *Apr 8 17:22:14.065: RT: NET-RED 151.10.50.0/24 *Apr 8 17:22:14.073: RT: interface Tunnel25 added to routing table *Apr 8 17:22:14.185: RT: SET_LAST_RDB for 151.10.55.0/24 NEW rdb: via 151.10.50.5
*Apr 8 17:22:14.185: RT: add 151.10.55.0/24 via 151.10.50.5, rip metric [120/1] *Apr 8 17:22:14.189: RT: NET-RED 151.10.55.0/24 R2(config-if)#^Z R2#
So, on to IPv6, only to find that once again I should have read ahead. The Frame Relay and OSPF sections give you two possible topologies for the R1 connection: physical interface with inverse-arp switched off for those DLCIs you don’t want to use, or a multipoint interface s0/0.124 with interface-dlci statements for the DLCIs you do want to use. I chose the first solution. But the IPv6 wording talks about the IPv6 address on R1-S0/0.124. Humph!
I’ve not blogged for a few days, so I thought I had better do so, even if only to set something on the record. Actually, I have written some journal, but for one reason or another I had to mark the entries as “Private”. Sorry guys! I do this blog as much to keep my own journal as for the benefit of others.
It’s week 17, and I should be doing NMC Lab 17. Unfortunately, as I was preparing my file for the week I caught sight of some of my old notes from the first time I did this lab, which kind of spoilt it. There are three features of Lab 17 that I might have stumbled over, but now I have seen the solutions I shall have to do it as an exercise in speed rather than in puzzle solving.
Cryptically, so as not to spoil it for anyone else, the stumbling blocks would have been:
I have been watching the NetWorkers OnLine presentation about EIGRP troubleshooting, and very good it is too. NWOL is excellent all round. Fortunately, I get it included in the price of my attendance at Barcelona back in January, but you can subscribe even if you didn’t go to the live event. I can thoroughly recommend it.
One trick I learned is ping 224.0.0.10. I hadn’t realised that would provoke a response from every potential EIGRP neighbor. This is a good way of quickly finding out whether a neighbor is listening to the EIGRP multicast, even if it has not yet successfully set up a neighbor relationship. I am still looking into this: for example, I want to find out what happens if the neighbor has a static neighbor configured. Will that stop it from responding to ping 224.0.0.10 ?
My two weakest points are definitely QoS and Security. I spent some time today reading some aspects of security that I am insecure about, but which do crop up in the NMC labs:
Lab 17 involves IRDP. I just wrote a seperate posting for this section.
Getting worryingly close. But I’m not telling!
R2-F0/0. SHOWiT has ip igmp join-group 229.9.9.9. I have no idea why.
R2 filters out supernet summary route during redistribution from EIGRP to OSPF. Is this really necessary?
I forgot the IPv6 split-horizon stuff on R1. In fact, I did not test the IPv6 properly. So much so, that my IPv6 spoke-to-spoke frame maps were missing on R3 as well. However, I did not spray the broadcast keyword quite as liberally as they did.
They had no peer neighbor-route on their PPP link R3<–>R5 and I did not. I don’t think this matters too much, does it?
Following NMC Lab16, I reloaded my stack, only to find R1 is in a reload loop. This isn’t the first time it has happened, and it was R1 last time as well. I wonder if I have a hardware problem, or whether it is an IOS bug. Last time I managed to fix it by loading without the NVRAM, just like a password recovery, then loading the config once the router was running. This time, the technique didn’t work; as soon as I pasted in the old config, it would crash again.
So instead, I loaded up the router without the NVRAM config, then added the config section by section. I narrowed down the crash to a distribute-list in my IPv6 RIP process. The distribute list was called “default-only”, and I think it didn’t like that for some reason. It referred to a prefix list that has only the default route in it. Anyway, I shouldn’t have needed it, because the SHOWiT solution is much more elegant: ipv6 rip RIP default-information only.
As someone recently commented, it’s just as well they use that special bug-free version of IOS for the CCIE exam labs!
I was behind on my labs. Week 16 has finished, and I only just got round to doing lab 16. Nevertheless, I am quite pleased with myself. It looked quite an easy one – no redistribution loops etc. – so I decided to do it as a timed exercise. I estimated 6 hours and managed to complete it in under 4. So either I am getting faster and more confident, or it was exceptionally easy, or there will be lots of mistakes in it when I go through the AK.
Here is my timing. I have not estimated my points yet. The read-through took longer than I allowed, but that’s a good thing. I got interrupted at 08:15 when the family woke up. (Well … it is Sunday.) I had a break mid-morning when I had to go and collect my 11-year-old from his sleep-over. Altogether, I am pretty pleased with how it went.
| Lab 16 | 2008 Wk. 16 | |||||||
| Time | Points | |||||||
| Section | Date | Start | Finish | Actual | Target | Max | Est | |
| Read-through | 19/04/2008 | 17:05 | 17:45 | 00:40 | 00:30 | |||
| 1 | Frame Relay & Serial Interfaces | 20/04/2008 | 07:50 | 07:55 | 00:05 | 00:20 | 4 | |
| 2 | Catalyst Configuration | 20/04/2008 | 07:55 | 08:16 | 00:21 | 00:30 | 10 | |
| 3 | OSPF | 20/04/2008 | 08:35 | 08:50 | 00:15 | 00:30 | 12 | |
| 4 | RIP | 20/04/2008 | 08:50 | 08:57 | 00:07 | 00:15 | 6 | |
| 5 | EIGRP | 20/04/2008 | 08:57 | 09:09 | 00:12 | 00:15 | 4 | |
| 6 | ODR | 20/04/2008 | 09:09 | 09:15 | 00:06 | 00:10 | 2 | |
| 7 | IPv4 Redistribution | 20/04/2008 | 09:15 | 09:29 | 00:14 | 00:30 | 6 | |
| 8 | BGP | 20/04/2008 | 10:55 | 11:26 | 00:31 | 00:40 | 16 | |
| 9 | Address Administration | 20/04/2008 | 11:26 | 11:31 | 00:05 | 00:15 | 4 | |
| 10 | NTP | 20/04/2008 | 11:31 | 11:44 | 00:13 | 00:15 | 6 | |
| 11 | IPv6 | 20/04/2008 | 11:44 | 12:10 | 00:26 | 00:30 | 8 | |
| 12 | QoS | 20/04/2008 | 12:10 | 12:17 | 00:07 | 00:20 | 8 | |
| 13 | Catalyst Specialties | 20/04/2008 | 12:17 | 12:22 | 00:05 | 00:20 | 6 | |
| 14 | Multicast | 20/04/2008 | 12:22 | 12:40 | 00:18 | 00:40 | 8 | |
| TOTAL | 03:45 | 06:00 | 100 | 0 | ||||
Now the hard bit starts. Here are the sections I had some thoughts about:
(BGP entry does not mean much yet. Details to follow.)
Someone had to come up with the idea … a one-way cul-de-sac! To all appearances, we seem to have one here in Luxembourg. For those who know Luxembourg, (which I know is not many of my readers), it is the new layout at the top of Rue Adolphe Fischer.
It’s a quiet residential one-way street, but in a busy area of town, and it ends in a sidewalk (“pavement” for English speakers) across the road, blocking the end. So which is greater: the fine for reversing on a one-way street, or the fine for driving on the sidewalk? Which would you do?
Who forgot to inject the default route into the stub area?
It is week 13, so I should be doing Lab 13. I have done this one before, way back in 2006 week 43. I don’t remember much about it, but according to my notes I did it on a remote rack last time. This time I am doing it on my own rack.
I am quite pleased that I achieved full IGP connectivity in two hours, 21:00 to 23:00. However, I wasn’t happy with my summarisation. This lab has lots of summarisation and filtering, and in particular I wasn’t happy about sections 13.4.5, 13.4.6 and 13.5.5. So I spent an extra half hour whittling down a solution and checking it out with the TCL scripts. Essentially, they were all about not being allowed to summarize in the obvious router, but leveraging summarizations that had already been done elsewhere.
Well, the new strategies paid off. I got the equivalent of a pass, which is way above what I got on my last two attempts. I am really really pleased. The hard study seems to be paying off as well. Of course, I cannot rest on my laurels, and I shall have to look hard at the bits I missed. There is still a long way to go. But I am encouraged by the headway.
As it turned out, opening the scenario an hour before the official start time was not cheating at all. Guess what … the US has gone onto summertime already and so my start time was an hour before I thought it was!
