NMC Lab 18

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!

Congratulations to Ethan, CCIE #20655!

Ethan passed!  Congratulations!  Well deserved!

With the amount of work he has put in, if anyone deserved to pass it was Ethan.  Thanks for all your hard work in sharing your studies with us too.

NMC Lab 9.8 BGP

Following a posting on DISCUSSiT, I reloaded my configs for Lab 09 to investigate the BGP question.  Here are my notes:

Start with default from FRS:

R3#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:03:25 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:03:25 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700

R4#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:03:28 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:03:28 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700

Shut down Lo107:

FRS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
FRS(config)#int Lo107
FRS(config-if)#shut

This is what happens on R3 and R4:

R3#
*Apr  8 17:20:36: RT: del 0.0.0.0 via 172.16.34.7, bgp metric [20/0]
*Apr  8 17:20:36: RT: delete network route to 0.0.0.0
*Apr  8 17:20:36: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:36: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:37: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: is directly connected

*Apr  8 17:20:37: RT: add 0.0.0.0/0 via 0.0.0.0, static metric [250/0]
*Apr  8 17:20:37: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:37: RT: default path is now 0.0.0.0 via 0.0.0.0
*Apr  8 17:20:37: RT: new default network 0.0.0.0
*Apr  8 17:20:37: RT: NET-RED 0.0.0.0/0
*Apr  8 17:20:37: RT: delete route to 172.16.107.0 via 172.16.34.4, eigrp metric [90/158720]
*Apr  8 17:20:37: RT:
R3#SET_LAST_RDB for 172.16.107.0/24
  OLD rdb: via 172.16.34.4, FastEthernet0/1

*Apr  8 17:20:37: RT: no routes to 172.16.107.0
*Apr  8 17:20:37: RT: NET-RED 172.16.107.0/24
*Apr  8 17:20:37: RT: delete subnet route to 172.16.107.0/24
*Apr  8 17:20:37: RT: NET-RED 172.16.107.0/24
R3#
.Apr 27 10:22:55: RT: recursion error routing 172.16.107.0 - probable routing loop
.Apr 27 10:22:55: RT: del 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:22:55: RT: delete subnet route to 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 0.0.0.0/0
R3#
R3#
R3#
R3#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 250, metric 0 (connected), candidate default path
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

And on R4:

R4#
*Apr  8 17:01:33: RT: del 0.0.0.0 via 172.16.34.7, bgp metric [20/0]
*Apr  8 17:01:33: RT: delete network route to 0.0.0.0
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:33: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: is directly connected

*Apr  8 17:01:33: RT: add 0.0.0.0/0 via 0.0.0.0, static metric [250/0]
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:33: RT: default path is now 0.0.0.0 via 0.0.0.0
*Apr  8 17:01:33: RT: new default network 0.0.0.0
*Apr  8 17:01:33: RT: NET-RED 0.0.0.0/0
*Apr  8 17:01:34: RT: delete route to 172.16.107.0 via 172.16.34.7, eigrp metric [90/156160]
*Apr  8 17:01:34: RT:
R4#SET_LAST_RDB for 172.16.107.0/24
  OLD rdb: via 172.16.34.7, FastEthernet0/0

*Apr  8 17:01:34: RT: no routes to 172.16.107.0
*Apr  8 17:01:34: RT: NET-RED 172.16.107.0/24
*Apr  8 17:01:34: RT: delete subnet route to 172.16.107.0/24
*Apr  8 17:01:34: RT: NET-RED 172.16.107.0/24
R4#
.Apr 27 10:22:55: RT: recursion error routing 172.16.107.0 - probable routing loop
.Apr 27 10:22:55: RT: del 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:22:55: RT: delete subnet route to 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 172.16.0.0/16
.Apr 27 10:22:55: RT: NET-RED 0.0.0.0/0
R4#

Now bring back Lo107:

FRS(config-if)#
FRS(config-if)#no shut
FRS(config-if)#
*Mar  1 01:13:15: %LINK-3-UPDOWN: Interface Loopback107, changed state to up
*Mar  1 01:13:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback107, changed state
 to up

This is R3:

R3#
.Apr 27 10:23:44: RT: SET_LAST_RDB for 172.16.107.0/24
  NEW rdb: via 172.16.34.4

.Apr 27 10:23:44: RT: add 172.16.107.0/24 via 172.16.34.4, eigrp metric [90/158720]
.Apr 27 10:23:44: RT: NET-RED 172.16.107.0/24
R3#
.Apr 27 10:23:46: RT: closer admin distance for 0.0.0.0, flushing 1 routes
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: via 172.16.34.7

.Apr 27 10:23:46: RT: add 0.0.0.0/0 via 172.16.34.7, bgp metric [20/0]
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: default path is now 0.0.0.0 via 172.16.34.7
.Apr 27 10:23:46: RT: new default network 0.0.0.0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
R3#
.Apr 27 10:23:51: RT: network 172.16.0.0 is now variably masked
.Apr 27 10:23:51: RT: SET_LAST_RDB for 172.16.0.0/16
  NEW rdb: via 172.16.107.0

.Apr 27 10:23:51: RT: add 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:23:51: RT: NET-RED 172.16.0.0/16
.Apr 27 10:23:51: RT: NET-RED 0.0.0.0/0
R3#
Apr 27 10:23:55: RT: NET-RED 0.0.0.0/0
R3#
R3#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:00:24 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:00:24 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700

And R4:

R4#
.Apr 27 10:23:44: RT: SET_LAST_RDB for 172.16.107.0/24
  NEW rdb: via 172.16.34.7

.Apr 27 10:23:44: RT: add 172.16.107.0/24 via 172.16.34.7, eigrp metric [90/156160]
.Apr 27 10:23:44: RT: NET-RED 172.16.107.0/24
R4#
.Apr 27 10:23:46: RT: closer admin distance for 0.0.0.0, flushing 1 routes
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: SET_LAST_RDB for 0.0.0.0/0
  NEW rdb: via 172.16.34.7

.Apr 27 10:23:46: RT: add 0.0.0.0/0 via 172.16.34.7, bgp metric [20/0]
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
.Apr 27 10:23:46: RT: default path is now 0.0.0.0 via 172.16.34.7
.Apr 27 10:23:46: RT: new default network 0.0.0.0
.Apr 27 10:23:46: RT: NET-RED 0.0.0.0/0
R4#
.Apr 27 10:23:51: RT: network 172.16.0.0 is now variably masked
.Apr 27 10:23:51: RT: SET_LAST_RDB for 172.16.0.0/16
  NEW rdb: via 172.16.107.0

.Apr 27 10:23:51: RT: add 172.16.0.0/16 via 172.16.107.0, static metric [1/0]
.Apr 27 10:23:51: RT: NET-RED 172.16.0.0/16
.Apr 27 10:23:51: RT: NET-RED 0.0.0.0/0
R4#
Apr 27 10:23:55: RT: NET-RED 0.0.0.0/0
R4#
R4#
R4#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65034", distance 20, metric 0, candidate default path
  Tag 700, type external
  Last update from 172.16.34.7 00:00:17 ago
  Routing Descriptor Blocks:
  * 172.16.34.7, from 172.16.34.7, 00:00:17 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 700

R4#

Shows BGP route does pre-empt the static.

 

 

NMC 17.9.3 – NAT related bug?

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.

NMC Lab 17.9.2 – IRDP

Lab 17 involves IRDP.  IDRP is a protocol that allows a host (R7 in this case) to discover the gateway address.  It is a bit of a corner-case, but since it is in this lab, I had better take the opportunity to get to know it.

Where is the docuemtnation for IRDP?  This is not the first time I have been unable to find the Conf Guide for First-Hop routing protocols.  It is, in fact, in the IP Application Services Guide.  Who would have guessed?  But once you are there, (12.4) you find GLBP, HSRP, and VRRP, but no IRDP.  They seem to have forgotten to include it.  It is, in fact, in the 12.4T IP Application Services Guide.  Huh?

Even once you have found the documentation, it is not very good.  It does not tell you how to set up a router-host to get its gateway address from IDRP.  For reference, the command is ip gdp idrp.  GDP stands for “Gateway Discovery Protocol”.  This command also allows the router-host to discover the gateway address from RIP.  I cannot find this command anywhere in the IOS version 12 command references, and only very few glancing references to it in the IOS version 11 command references.

The IRDP is enabled on the routers (R3 and R6) with the interface comnmand ip irdp.  At the most basic level, that is all there is to it.

This particular scenario wants us to prefer R  over R3, and this can be achieved simply with ip idrp preference.  (The debug refers to “preference” as “priority”.)  Also, apparently there has been some confusion in the past over whether high wins or low wins, but the concensus seems to be that high wins.

Note that this priority mechanism is not pre-emptive.  At least, not with the 12.2(15)T17 I am using in my 2520 R7 client.

There is then a whole load of other options to do with the timing an format of the advertisments.  These parameters are each configured as a seperate command line, but behave in a strange way.  If you do no ip idrp, then they all disappear from the config.  If you then re-instate IRDP with ip irdp, then these former parameters automagically reappear.

One parameter deserves a mention: ip irdp multicast.  This sends out the IRDP hellos on a special multicast address so that Sun workstations can understand them.  However, it also means that a router-host such as R7 cannot understand them.

 

NMC 17.8 BGP – Routing loop

The BGP in this lab is definitely worth a mention.  I allowed myself 40 minutes in the time plan, but that was not nearly enough given the complexity of the topology.  It was the only task in that lab I overran on, taking slightly over an hour, and still not being sure I was all right.

Even though routes are truning up in all the routers, and meeting the spec, I still do not have complete pingability.  Most inconveniently, the NMC pingability chart does not cover the BGP addresses in this lab, so I wonder if reachability is really required.  Let us assume it is for the moment.

There are four things that are likely to affect pingability in this sort of topology:

1. Is synchronisation switched on.  No it isn’t; I disabled it on the CATs.
2. Does every router have a reachable next-hop to the NLRI of each prefix?
3. Does the path to any next-hop that is through a router that doesn’t speak BGP?
4. Do we have any circular next-hop paths?

One thing that should sound alarm bells is “Do we have any BGP peerings that are not direct neighbors?”  Yes we do.  We have R1 and R2 which are peered in AS 100, but which are not directly connected.  To make matters worse, the route between R1 and R2 goes through R3, which is in AS 10.  This sounds like a recipe for a forwarding loop.

In fact, let us try and trace from R1 to 140.10.5.1:

R1#trace
Protocol [ip]:
Target IP address: 140.10.5.1
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]: 8
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 140.10.5.1

  1 170.18.123.3 8 msec 12 msec 12 msec
  2 170.18.134.4 24 msec 24 msec 28 msec
  3 170.18.134.1 24 msec 24 msec 28 msec
  4 170.18.123.3 20 msec 20 msec 25 msec
  5 170.18.134.4 40 msec 36 msec 40 msec
  6 170.18.134.1 36 msec 36 msec 36 msec
  7 170.18.123.3 36 msec 32 msec 32 msec
  8 170.18.134.4 48 msec 52 msec 52 msec
R1#

Mmm, we seem to have a loop R1, R3, R4, R1, R3, R4, R1, etc.  According to the peerings, we should be going R1, R2, R5, CAT1.  SHOWiT does not support the trace command, so I shall do a trace by hand according to the SHOWiT routing tables:

R1 to 140.10.5.1, via 170.18.25.5, recursively via 170.18.123.2.  So the next hop is R2.  Or is it?  In fact, it is via DLCI 103, so the next hop is actually R3.

R3 to 140.10.5.1, via 170.18.134.1.  The next IP hop is R1, but that is via DLCI 304, so via R4.

So it looks rather like they have the same loop as I have.  In fact, I think the only way to make this address reachable is to build a tunnel to make up for the missing R1 <–> R2 link.  To traffic to pass between R1 and R2 without being intercepted by R3.  It took a lot of experimentation, but this is what I ended up with:

R1#show run int Tu21
Building configuration...

Current configuration : 132 bytes
!
interface Tunnel21
 ip unnumbered Loopback101
 ip ospf cost 19
 tunnel source Serial0/0.123
 tunnel destination 170.18.123.2
end

R2#show run int Tu21
Building configuration...

Current configuration : 132 bytes
!
interface Tunnel21
 ip unnumbered Loopback102
 ip ospf cost 19
 tunnel source Serial0/0.123
 tunnel destination 170.18.123.1
end

That’s better.  I ran a full pingability check on all routers, and found everything was OK … drat! … except R5 could not reach 140.10.1.1 to 140.10.4.1.  That is because R5’s next hop is 1.1.2.10 so it is sourcing the ping from 1.1.2.5.  That’s fine for CAT1, but CAT2 does not have a route back to it.  If I source the ping from Lo105 instead, (170.18.105.1 –> 140.10.1.1), then I get a response.

 

Background process

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.

NMC Lab 17 

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:

• 17.1.4 – how to arrange the FR topology
• 17.8.6 – how to decide which router in AS 10 is the route reflector
• 17.8.12 – how to arrange the filtering without looking at the prefixes or the AS-PATH

EIGRP Troubleshooting

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 ?

Security stuff

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:

• dot1x authentication
• aaa authentication in general
• lock-and-key access lists
• reflexive access lists

IRDP

Lab 17 involves IRDP.  I just wrote a seperate posting for this section.

Next lab date

Getting worryingly close.  But I’m not telling!

 

NMC Lab 16 : Differences

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?

 

Oh-Oh! Have I hit a bug?

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!

 

NMC DOiT Lab 16

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:

• 16.5 EIGRP – Summarization
• 16.8 BGP – (to follow) – use as test bed for messing up routes through a backbone
• 16.14 Multicast – Receive-only devices+ dense-mode prunes

(BGP entry does not mean much yet.  Details to follow.)