I cannot do the NAT part of this lab.  On R6, as soon as I put NAT on either of the Fa subinterfaces, it locks up.  Stone dead.  No ping responses, no adjacencies, nothing.

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#int f0/0.30
R6(config-subif)#ip nat out

Strange, because R3 seems to be happy with it.  (Apart from complaining it took too long, but then 12.4(2)T always does that when you introduce NAT.  It only seems to do that first time you introduce ip nat inside or ip nat outside; subsequent interfaces are OK)

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s0/0
R3(config-if)#ip nat out

*Apr  8 16:20:00.186: %SYS-3-CPUHOG: Task is running for (2003)msecs, more than (2000)msecs
(1/0),process = Exec.
-Traceback= 0x813C6850 0x813C496C 0x813C874C 0x813C8A1C 0x813C8AF8 0x813C48B0 0x813C4954
 0x813C9120 0x813C48B0 0x813C4954 0x813C7384 0x813C48B0 0x813C4954 0x813C49DC 0x813F9A08
 0x81407B50
*Apr  8 16:20:00.939: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up
R3(config-if)#int s0/0.134
R3(config-subif)#ip nat out
R3(config-subif)#int f0/0
R3(config-if)#ip nat in
R3(config-if)#exit
R3(config)#ip nat inside source static 170.18.255.1  170.18.255.10
R3(config)#^Z
R3#

I wonder what happens if I introduce ip nat inside on Lo106 first, as a dummy.  No, that locks it up as well.  I wonder whether my problem on R6 is anything to do with the ISL trunking?  Tried shutting down Fa0/0 and then introducing ip nat inside on Fa0/0.20.  Same thing … total lockup.

The nearest I could find in the bug database is CSCse48814.  But that applies specifically to RSP routers, and only when using NBAR, and only mentions ip nat outside.  That one is fixed in 12.4(10.4)T.

It’s just as well they use that special bug-free version of IOS in the real exam!

Update

I tried the same config on another router.  Same model (2611XM), same IOS (12.4(2)T advent), same hardware config (WIC-1T in slot 0).  This one allowed me ip nat inside, although still with the CPUHOG warning.  Maybe I have a faulty router in my stack.  Not good news.  (But then neither would a bug be good news.)  I shall look out for future instances of this problem.

Busy busy busy, so I only have time for a few notes which I hope I shall expand later.  Just to punish myself for my mistakes …

• 14.4.1 : RIP : I read too much into the requirements.  I read 14.4.1 as meaning that I should set up neighbor relations R2<–>R6<–>R4, but not R2<–>R4.  Then I wondered why there was nothing in the requirements about the route from R2 to 172.16.104.1 and from R4 to 172.16.102.1.  (Of course, the answer would have been no ip split-horizon on R6-F0/0.)  But it seems I “spotted an issue” that wasn’t there in the first place! 
• 14.8.1 : Security : I’m just going to have to sit down and read the Command Reference for all those itty-bitty security commands.  Boring or what!
• 14.9 : IPv6 : Don’t mess about thinking “can I get away without specifying link-local addresses”.  In a frame-relay configuration, they are absolutely essential so that you can set frame-maps to them.  Do them as a matter of course.  Oh, and the pseudo-broadcast should only go to the link-local at the other end of the DLCI, not to any of the others.  I wasted an hour on the IPv6 section that should have taken me half that time.
• 14.10.2 : Layer-3 access list on Catalyst layer-2 port.  This can be done; I know because I do it all the time on my 4500 switches at work.  What I am a bit puzzled at here is that the access-lists don’t seem to be counting packets.  My first attempt didn’t include return traffic for telnet, so I know the access-list is working.  So why doesn’t it count packets?
• 14.11.2 : NAT : ip nat source list 11 pool IG overload will not do instead of ip nat inside source list 11 pool IG overload. I’m not sure what it does without the “inside” keyword, but it does accept the command, and it doesn’t do the job I wanted it to.  Careful!

I cannot get the NAT requirement working at all, even with the same config as in the SHOWiT. R4 or R6 may well be doing the translation of the source from 172.16.110.1 to 172.16.104.10 for the outgoing packet, and in reverse for the echo response, but then where does R4 send the response? It has no route to 172.16.110.1 does it?

CAT1#ping
Protocol [ip]:
Target IP address: 172.16.101.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.110.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:  

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.101.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CAT1#

If we have debug ip icmp on R1 during this operation, this is what we see:

R1#
*Jan 6 02:30:56.168: ICMP: echo reply sent, src 172.16.101.1, dst 172.16.104.10
*Jan 6 02:30:56.196: ICMP: dst (172.16.101.1) host unreachable rcv from 172.16.234.4
R1#
*Jan 6 02:30:58.163: ICMP: echo reply sent, src 172.16.101.1, dst 172.16.104.10
*Jan 6 02:30:58.195: ICMP: dst (172.16.101.1) host unreachable rcv from 172.16.234.4
R1#
*Jan 6 02:31:00.451: ICMP: echo reply sent, src 172.16.101.1, dst 172.16.104.10
*Jan 6 02:31:00.483: ICMP: dst (172.16.101.1) host unreachable rcv from 172.16.234.4
R1#
*Jan 6 02:31:02.165: ICMP: echo reply sent, src 172.16.101.1, dst 172.16.104.10
*Jan 6 02:31:02.193: ICMP: dst (172.16.101.1) host unreachable rcv from 172.16.234.4
R1#
*Jan 6 02:31:04.165: ICMP: echo reply sent, src 172.16.101.1, dst 172.16.104.10
*Jan 6 02:31:04.193: ICMP: dst (172.16.101.1) host unreachable rcv from 172.16.234.4
R1#

Futhermore, I seem to have a problem with my R6.  As soon as I try to enter an NAT commands on it, it just dies.  Definitively.  No response from the console, and all its adjacencies start timing out.  I suspect an IOS bug.  I wonder what is doing it.  NAT with  HSRP in standby?  NAT on a subinterface?  All three together?  Who knows.