Our Founder's Book
Take the Next Step:
Related Information
Advanced IP Routing in Cisco Networks (First Edition)
Corrections to the Book
Any errors in the McGraw-Hill advertisement on page 508 are not our responsibility (sorry).
The bugs are sorted by bug ID. To check for a bug on a particular page, use your browser's 'Edit->Find' function to search for the page number. Bug severity is identified by the following key:
* Cosmetic or formatting
** Minor technical
*** Major technical
We've been asked about sorting the bugs list via various keys, such as the page number, or who found the bug. We don't have that capability, but you can do the sorting yourself by downloading a CSV version (Comma-Separated-Values) of the bugs list. Open the CSV file in a spreadsheet and enjoy!
Make sure you hit REFRESH if you've been viewing the bugs list lately.
**,164,4/22/02,Michael Falar,pp 48,"On Page 48, Table 1-6, the book indicates Type 2 to be ""destination unreachable"" when it should be Type 3. As stated on page 47, ""message type 3 is destination unreachable"". Michael is correct about the bug. In addition, the type code for Echo Reply should be 0, not 1. Both errors were due to a change by the editor - our manuscript is correct and the first revision back from the editor is incorrect. The change was not noted in the revised manuscript and we missed in our proof reading. Michael still gets his reward for finding the bug, which exists in both editions of the book."
*,163,11/20/00,John Newell,pp 157,"In the first paragraph of the Summary, change 'The router subcommand split horizon ...' to 'The router subcommand passive-interface …'."
**,162,5/24/99,Terry Slattery,pp 432,"In Figure 9-18, change the subnet ID for the NewYork to Moscow ethernet to 199.99.1.4/30."
**,161,5/22/99,Samson Luk,pp 422,In Figure 9-2 change NewYork's Ethernet0 subnet ID to 199.99.1.4/30 and change NewYork's Ethernet0 address from 'E0 - .1' to 'E0 - .5'.
*,N/A,4/9/99,Benjy Rife,pp 284-287,"Ben asks: ""On Pg. 284 it shows an IGRP and Static route network. The Diagram shows that on the New York router, IGRP is running on all interfaces except the S0 interface. The configuration for New York on Pg. 287 shows something different. It shows IGRP running on all interfaces of that router including S0. Which is correct?""
The answer is: ""Both pages are correct. The diagram shows where IGRP should be running. However, the text on page 286 discusses the requirement for adding the network statement to the IGRP routing protocol configuration. The 'network 192.168.6.0' statement is needed to add a route to the IGRP routing updates which can be marked as the candidate default network. An improvement to the configuration would be to add 'passive-interface s0' to the IGRP routing config. There is no reason to send IGRP updates out the interface, since the ISP router (London) is not listening to the updates."""
The below bugs have been fixed in the fourth printing.
**,160,2/21/99,John Kupec,pp 406,"In Figure 8-19, change the next-hop IP address in the static route so that line 19 reads: 'ip route 192.168.0.0 255.255.248.0 144.251.1.249 190'."
**,159,2/18/99,John Kupec,pp 320,"In Figure 6-122, Tokyo's routing table should contain a route to 172.16.0.0 via S0. The entry would be similar to that shown for London in Figure 6-123."
*,158,2/14/99,Carole Reece,pp 477,"In the last sentence, the words 'area range' should be in bold font."
*,157,2/14/99,Carole Reece,pp 472,"In the fifth paragraph, change the words 'possibly down' and 'active' from bold font to italics since they represent command output state, not commands that you would type."
**,156,2/7/99,Lydia Kankkunen,pp 103-104,(Superceeds bugs 41 and 67.) The correct fix for this error is to change Figure 3-8 to use the addresses and masks shown in the configurations of Figure 3-9. NewYork's S1 should be 192.168.1.66 255.255.255.240; Tokyo's S0 should be 192.168.1.65 255.255.255.240; and Tokyo's E0 should be 192.168.1.97 255.255.255.240. The addresses in Figure 3-9 are correct.
*,155,2/12/99,Carole Reece,pp 422,Line 4 of Figure 9-33 should not have the '!' at the start of the line.
*,154,2/12/99,Carole Reece,pp 421,Change the last paragraph from 'that is connected AS 200 through a BGP connection to NewYork' to 'that is connected through a BGP connection to AS 200 in NewYork'.
**,153,2/11/99,John Kupec,pp 351,"(Modifies bug #20). In Figure 7-8, line 4 of the debug output should be deleted. The debug output should result from the ping test that is described on pp 355, third paragraph, and in Figure 7-14, lines 13-30."
**,152,2/5/99,John Kupec,pp 179-180,"In Figures 5-13, 5-14, and 5-15, change the metric for B's route via C from '65/40' to '55/40'."
*,151,2/3/99,John Kupec,pp 140,"In the middle of the last paragraph, change the sentence 'The default values of the coefficients (K1, K2, K3, K4, and K5)…' to 'The coefficients (K1, K2, K3, K4, and K5)…' to remove a redundant clause."
**,150,2/1/99,Galen Huie,pp 426,"In the second paragraph, change '192.169.1.0' to '192.168.1.0'."
**,149,1/17/99,Chris Topher,pp 358,"The first line on the page should change from 'Line 6 provides a static map to force a specific inside global address, …' to 'Line 6 provides a static map to force a specific inside local address, …'."
**,148,1/6/99,Michael Reid,pp 46,"In Figure 1-31, the bottom of the example shows the original TTL=3. It should decrement by one at each hop. Therefore the example should show TTL=3------>TTL=2------>TTL=1------>TTL=0."
**,147,12/29/98,Ruediger Volk,pp xv,"In the last paragraph, 2nd sentence, the description of the contents of Chapter 10 says 'You'll see how to use TTCP, …', but we didn't cover TTCP."
*,146,12/20/98,David Lin,pp 484,"In the second paragraph, last sentence, change 'and the having the ability to quickly' to 'and having the ability to quickly'."
**,145,12/20/98,David Lin,pp 17,"In Figure 1-13, the port number for FTP should be 21. Port 20 is used for FTP-Data."
**,144,12/9/98,Carole Reece,pp 281,"In the last paragraph, the reference to Line 26 in Fig 6-82 should be to line 25."
**,143,11/19/98,Carole Reece,pp 371,"In Figure 7-42, line 22 should be removed. RIP is not used in the router, so rip authentication should not be configured."
**,142,11/19/98,Carole Reece,pp 364,"In Figure 7-31, change the Moscow to Rome link from 10.1.12.0/30 to 10.1.1.12/30."
**,141,11/19/98,Carole Reece,pp 381,"In Figure 7-55, line 34, the ping record route should show the first router as 10.1.1.5."
**,140,11/19/98,Carole Reece,pp 360,"On the first line of the NAT debug output, change 'NAT*:' to 'NAT:'. The first translation is not fast switched, so it should not have the '*'."
**,139,11/19/98,Carole Reece,pp 359,"In the last line on the page, change '… our outside global address of 200.200.200.5, …' to '… our inside global address of 200.200.200.5, …'."
**,138,11/19/98,Carole Reece,pp 359,"In the first paragraph, change 'Sample output from the debug ip nat command…' should be 'Sample output from the debug ip nat 1 command…'."
**,137,11/19/98,Carole Reece,pp 359,"In Figure 7-22, line 16, the third '--' should be shifted to the 'Inside local' column. The other two addresses on this line should then appear in their respective columns. 200.200.200.254 is an 'Outside local' address and 131.108.2.1 is an 'Outside global' address."
*,136,12/13/98,TeckLing,pp 82,"In the first paragraph, change 'examining the top bits of the address.' to 'examining the left-most eight bits of the address.'"
*,135,12/13/98,TeckLing,pp 72,"In the last paragraph, second sentence, change 'is it copied' to 'it is copied'."
*,134,11/23/98,Jess Romero,pp 383,"Three lines from the bottom of the page, change 'Normal' to 'Normally'."
**,133,11/19/98,Scott Hogg,pp 436,About 2/3rds down the page - the sentence that starts 'Lines 25 through 34 shows route map...' should say 'Lines 28 through 34 shows route map...'
*,132,*,*,*,(Duplicate of bug 89.)
**,131,11/19/98,Scott Hogg,pp 364,"In Figure 7-31, change Tokyo's S1 to 10.1.2.2 and London's S0 to 10.1.2.1. This matches the configurations and the routing table displays."
**,130,11/19/98,Scott Hogg,pp 359,"In the first paragraph, all line references to figure 7-23 are one line too large. This is because the command 'debug ip nat 1' should appear as the first line of Figure 7-23. Adding this line and renumbering the lines will match the text."
**,129,11/19/98,Scott Hogg,pp 323,The output of 'sho ip prot' on NewYork should include a section for the OSPF protocol. See also bug # 118.
**,128,11/19/98,Scott Hogg,pp 282,Figure 6-82 is missing the reference to access-list 1 that appears in Fig 6-80.
**,127,11/19/98,Scott Hogg,pp 241,"On the first line, change the reference to lines (4, 5, 23, 24) to (5, 6, 23, 24)."
**,126,11/19/98,Scott Hogg,pp 222,"In the first paragraph, change the reference to Figure 5-36 to a reference to 5-43."
**,125,11/19/98,Scott Hogg,pp 131,"In the second paragraph, change 'Similarly, Rome only knows about 192.168.12.0.' with 'Similarly, Rome only knows about 192.168.1.0.'"
***,124,11/19/98,Scott Hogg,pp 110,Figure 3-14 shows routing tables that are in transition and don't match the configs in Figure 3-13. Figure 3-14 should be replaced with the following: XXX
*,123,11/16/98,Ivan Bacchus,pp 47,"In the first paragraph, the words 'type' and 'checksum' should have their first letters italicized."
*,122,11/16/98,Ivan Bacchus,pp 39,"The router in Figure 1-24 should be labeled 'A', which is how it is referenced in the text at the top of pp 39."
*,TechTip,11/12/98,Jess Romero,"pp 367, 369","> 2. Figs. 7-36 and 7-379 on pp 367, 369 respectively:
* The next hop for the default static is an I/F, lines 24/27, ( not recommended) and you also force an arp. An ip addr. is 'cleaner', assuming a stable nw.
This depends on your requirements. If there are multiple possible paths out of your network, then using an interface route and using ARP can actually a good thing. I believe that Cisco implements IRDP, so that if one of the 'default routers' dies, the Cisco will re-arp and discover another default router. Using ARP is actually less overhead than almost any other mechanism - even HSRP.
* The access-list 1, lines 26/29, does not have the deny statement Explicitly configured, this makes for easier reading and you can also check the number of hits via the 'sh access-l' command, should the need arise.
Exactly! I always recommend including it explicitly. The major reason I like to include it is that it clearly communicates to other network admin team members that you intended for all other traffic to be denied."
*,121,11/12/98,Jess Romero,pp 368,The third line of the first paragraph references Figure 3-36. This should be a reference to Figure 7-36.
*,120,11/12/98,Carole Reece,pp 330,"In Figure 6-128, move line 140 to appear before line 144. The output shown in this figure could appear if you were to type the command, wait for the debug output to appear, then press RETURN to invoke the command. However, the way it is presented could be confusing for someone new to the Cisco router interface."
**,119,11/11/98,Carole Reece,pp 302 & 323,"In Figures 6-111, line 82 and 6-124, line 81, change both to read:
C 172.16.253.4/30 is directly connected, Loopback0"
**,118,11/11/98,Carole Reece,pp 323,"In Figure 6-124, lines 45-68, which display the output of 'show ip prot', should show that EIGRP is routing for networks 172.16.0.0 and 182.18.0.0. Networks 192.168.1.0, 192.168.2.0, 192.168.4.0, and 192.168.6.0 should not appear in the output."
**,117,11/11/98,Carole Reece,pp 322,"In Figure 6-124, line 24, the bandwidth specification for OSPF redistribution in the EIGRP configuration should be '125' instead of '125000'. Also change the delay metric from '1000' to '2000' to match the metrics shown in Table 4-2."
**,116,11/11/98,Carole Reece,pp 300 & 322,"The subnet mask for the loopback interface on NewYork should be 255.255.255.252. This affects Figure 6-111, line 7, and Figure 6-124, line 7."
*,115,11/11/98,Carole Reece,pp 301,Line 22 of Figure 6-111 is duplicated on this page.
*,114,11/10/98,Carole Reece,pp 403,RIP region in Figure 8-14 is not identified on the diagram.
*,113,11/10/98,Carole Reece,pp 306,EIGRP' should be capitalized in Figure 6-115.
*,112,11/10/98,Carole Reece,PP 297,EIGRP' should be capitalized in Figure 6-108 where it appears to the left of NewYork.
*,111,11/10/98,Carole Reece,pp 291,Caption for Figure 6-7 should be 'Redistributing EIGRP and static routes' ('routes' is missing).
*,110,11/9/98,Carole Reece,pp 385,"In caption of Figure 7-60, 'test' should not be bold."
*,109,11/9/98,Carole Reece,pp 269,"Third from last sentence, 'redistribute connected' should be bolded."
*,108,11/9/98,Carole Reece,pp 253,"First paragraph, all of 'show ip protocol' should be bolded."
*,107,11/9/98,Carole Reece,pp 235 - 275,"(Fixed in Second printing) An extra thick bolding is used in the figure captions of Fig 6-4 pp 235, Fig 6-43 pg 259, Fig 6-69 pg 274."
*,106,11/9/98,Carole Reece,pp 45,"On the second line of the first paragraph, 'd' in 'don't fragment' and first 'r' in 'record route' are not in italics, but rest of word is. All of these words should be italicized."
**,105,11/7/98,Scott Shaw,pp 364,"In the NAT Example #3, Tokyo and Rome cannot ping any interface on the 192.168.1.0 or the 192.168.2.0 networks. The example does not indicate whether these networks should be visible to the routers internal to each domain. The symptom is that every other packet will take the correct path and the alternate packets will take the wrong path. If connectivity to these networks from Tokyo and Rome is desired, add the necessary network numbers to the routing protocols in NewYork, Moscow, London, and Paris. In NewYork add 'network 192.168.2.0' and in London, add 'network 192.168.1.0' to their EIGRP configurations. In Moscow add 'network 192.168.2.2 0.0.0.0 area 1' and in Paris add 'network 192.168.1.2 0.0.0.0 area 1' to their OSPF routing protocol definitions. An alternative approach would be to add these networks to the static route definitions in all four routers and modify the static route access list on NewYork and London to include the new definitions."
The below bugs have been fixed in the second printing.
*,104,11/9/98,Carole Reece,pp 455,"In the FYI, replace the '{access-lists}' braces with parens '(access-lists:)'."
*,103,11/9/98,Carole Reece,pp 296,"In the second paragraph, add a period after '… of stub network operation'."
*,102,11/9/98,Terry Slattery,pp 383,"In Figure 7-58, change 'Eigrp 200' to 'EIGRP 200'."
*,101,11/7/98,Terry Slattery,pp 10,"In Figure 1-7, fix the typo of 'Balitmore' to 'Baltimore'."
***,100,11/8/98,Jess Romero,pp 275,"The last paragraph discusses the output in Figure 6-71, but doesn't go into enough detail about why the metrics of the two routes are not equal and are not the same as that specified in the 'default-metric' command."
*,99,11/8/98,Jess Romero,pp 283,"In Figure 6-84, the target of the ping should be 192.168.2.1."
*,98,11/8/98,Jess Romero,pp 290,"Change Example #9's caption to read 'EIGRP, Connected Networks & Static Routes'."
**,97,11/8/98,Jess Romero,pp 283,"In Figure 6-83, add the following line to the end of the routing table display: '15 O IA 192.168.4.0/24 [110/1600] via 192.168.6.1, 00:06:57, Serial 1'."
**,96,11/8/98,Jess Romero,pp 281,"In Figure 6-80, line 19, change '… metric 128 …' to '… metric 125 …'."
**,95,11/8/98,Jess Romero,pp 275,"In the last paragraph, second sentence, change 'If both 192.168.4.0 and 192.168.3.0 are being redistributed …' to 'If both 192.168.4.0 and 192.168.2.0 are being redistributed …'."
*,94,11/8/98,Jess Romero,pp 269,"In the middle of the fourth paragraph of Example #6, change 'Look at the metrics assigned to our two external networks on lines 12 and 15, 192.168.6.0 is 2195456 and 192.168.3.0 is 21529600, an order-of-magnitude difference.' to 'Look at the metrics assigned to our two external networks on lines 12 and 15, 192.168.6.0 is 2169856 and 192.168.3.0 is 21529600, an order-of-magnitude difference.'"
**,93,11/7/98,Scott Shaw,pp 432,"In Figure 9-18, add a loopback address for Paris to the bottom of the drawing: 'Paris 192.168.5.1'."
**,92,11/7/98,Scott Shaw,pp 422,"In Figure 9-2, label NewYork's Ethernet with the subnet address 199.99.1.0. Also, it is unlikely that a real Ethernet will have a subnet mask of /30."
*,91,11/7/98,Scott Shaw,pp 404,Change '… that prevents asynchronous routes.' to '… that prevents asymmetric routes.'
**,90,11/7/98,Scott Shaw,pp 403,"In Figure 8-14, change 'OSPF Area 1' to 'EIGRP 200'."
**,89,11/7/98,Scott Shaw,pp 383,"In the second paragraph of Example #4, change 'The target address that represents our shared TCP hosts is 172.15.3.4.' to 'The target address that represents our shared TCP hosts is 172.16.3.4.'"
**,88,11/7/98,Scott Shaw,pp 371,"(Superceeded by bug #142) In Figure 7-42, line 20, the IP address for Moscow's S0 interface should be 10.1.12.13, not 10.1.1.13."
*,87,11/6/98,Jess Romero,pp 233,"In Table 6-1, in the 'Description' column for 'metric-type', change the typeface of 'from protocol' to italics as is done elsewhere in the table."
*,86,11/6/98,Jess Romero,pp 244,"In the last sentence, change 'To IGRP …' to 'To EIGRP …'."
*,85,11/5/98,Carole Reece,pp 261,"In the last sentence of the page, change the typeface of 'ping 192.168.6.1' to match other commands."
**,84,11/5/98,Scott Shaw,pp 328,"In Figure 6-128, RIP should redistribute OSPF 200, not OSPF 100."
**,83,11/5/98,Ron Trunk,pp 432,"In the second paragraph of the BGP example, change '… Moscow, AS200, …' to '… Moscow, AS100, …'."
*,82,11/5/98,Rob Chase,pp 67,"In the first paragraph, second sentence, there's an unintentional period after the phrase '(that's you)'."
**,81,11/2/98,Jess Romero,pp 132,"In Figure 4-15, add Paris to London's Ethernet. The text on pages 132 and 133 discusses this connection and it needs to be shown to avoid confusion."
*,80,11/2/98,Carole Reece,pp 387,"In Figure 7-64, the commands should be in bold font."
***,79,11/2/98,Carole Reece,pp 295,The output of 'show ip prot' is missing from Figure 6-106.
***,78,11/2/98,Carole Reece,pp 289,The output of 'show ip prot' is missing from Figure 6-95.
*,77,11/1/98,Scott Shaw,pp 213,"In the Paris configuration at the end of Figure 5-38, the RIP protocol configuration includes network 172.20.0.0 but there are no interfaces in this network. It doesn't affect the operation of the router, but is technically incorrect and may cause a problem if an interface on that network is added and you don't want to run RIP on the new interface."
***,76,11/1/98,Scott Shaw,pp 202,"If you do the example that's described in Figures 5-29, 5-30, and 5-31, you may find different OSPF external types for the route to 172.20.5.0 than are shown in Figure 5-30. If Moscow learns the RIP route before Paris, then the route in Tokyo will be an E2 route. However, if Paris learns the RIP route before Moscow, the route will be sourced as an E1 route by Paris. Experimentation shows that it is stable and switches only when the router (Moscow or Paris) that contains the RIP route loses the RIP route. This could create a very interesting troubleshooting situation. An important tip from this exercise is to try to force all routes to the same destination be the same metric type. Thanks, Scott!"
**,75,11/1/98,Scott Shaw,pp 211,"In Figure 5-37, the host portion of the loopback interface IP addresses are not specified. In addition, the loopback interface unit numbers specified in this figure do not match the interfaces used in the configuration of Figure 5-38."
***,74,11/1/98,Scott Shaw,pp 198,"In Figure 5-26, Moscow is missing the configuration of the Serial 1 interface. All that's required is to assign the IP address (172.16.17.4/30) and bandwidth (1544) to the interface."
*,73,10/30/98,Carole Reece,pp 193,"In Figure 5-23, remove the configuration for Serial 1 from the Paris configuration. This interface is shutdown and does not need to be included in the display. Leaving it in the configuration does not change the operation of the router."
*,72,10/30/98,Carole Reece,"pp 192, 193, 197, 199, 200","In Figure 5-23 and 5-26, add the 'bandwidth 1544' statement to Tokyo's Serial 1, and Rome's Serial 1 interfaces. In Figure 5-28, add the 'bandwidth 1544' statement to Serial 1 in Paris and Serial 0 in Rome. One could argue that this isn't necessarily a bug since the default bandwidth is 1544, but it is inconsistent with the other router configurations and may be confusing."
*,71,10/30/98,David Harrison,pp 10,"The last sentence of the second paragraph says that the mailbag will have an address too, but the mailbag in Figure 1-7 doesn't have an address. The mailbag should be labeled 'Baltimore'. Refer to bug #2, #3, and #101 regarding Figs 6, 7, and 8."
***,70,10/26/98,Carole Reece,pp 188,"The first paragraph, third sentence, implies that authentication-keys must be configured on *all* OSPF interfaces, but Figure 5-19 on pg 186 (without authentication between Tokyo & London) appears to work fine, with no loss of adjacencies. However the Cisco docs (March 1998) states 'You are not required to alter any of these paramters, but some interface parameters must be consistent across all routers in an attached network. Therefore, be sure that if you do configure any of these parameters, the configurations for all routers on your network have comparable values.' Confusing at best... Experimentation suggests that the same keyid and key must be used on all routers on the same network segment. Also, it appears that if you don't set a key, the IOS assumes keyid 0 which is a null key. MD5 works the same. Thanks to Carole for working through this example in detail and supplying the correct information!"
*,69,10/29/98,Terry Slattery,pp 132,Figure 4-15 shows the draft figure ID (T194) to the far right. This number was used in preparing the draft manuscript and should have been deleted in the book production process.
**,68,10/28/98,Jess Romero,pp 138,"In Figure 4-23, the mask should be /28 not /24 to match the config in Figure 4-24."
**,67,10/26/98,Wes Ballinger,pp 103-104,(Superceeded by bug # 156) The IP addresses for NewYork's S1 and Tokyo's S0 in Figure 3-8 don't match the IP addresses in the configurations shown in Figure 3-9. Change the IP addresses in Figure 3-9 to 192.168.4.1 and 192.168.4.2 for Tokyo and NewYork respectively. Bug #41 noted that the subnet masks have to also be changed.
*,66,10/26/98,Carole Reece,pp 229,"In the first IGRP paragraph, Transmission is missing the first 's' in 'Maximum Transmission Unit'"
**,65,10/25/98,Jess Romero,pp 81,"In Figure 2-18, the address 192.168.1.97 should be labeled 'London E0', not 'NewYork E0'."
**,64,10/24/98,Jess Romero,pp 87,"In Figure 2-24, the address for Tokyo's E0 interface should be 192.168.1.81, not 192.168.1.199."
*,63,10/24/98,Jess Romero,pp 87,"In Figure 2-24, the bottom router servicing network 192.168.1.80 should be labeled 'Tokyo'."
**,62,10/24/98,Scott Shaw,pp 155,The second paragraph references Paris in Figure 4-33. The reference should be to Figure 4-34 as Paris is not is Figure 4-33.
*,61,10/22/98,Carole Reece,pp 240,"Figure 6-11 - last line is missing from the 'show route-map' command ; should also have included : 'Policy routing matches: 0 packets, 0 byte'."
**,60,10/22/98,Carole Reece,pp 239,"3rd paragraph above Figure 6-10, says Lines 16 & 17 are output of the debug ip igrp transactions; but lines 12-17 are the output."
**,59,10/22/98,Carole Reece,pp 241,"In the last sentence of the FYI, the reference to Figure 6-11 should be a reference to Figure 6-10."
*,58,10/22/98,Carole Reece,pp 239,"In Figure 6-10, the command 'debug ip igrp transactions' should be in bold font."
**,57,10/22/98,Scott Shaw,pp 107,Change the interface route configuration statement from 'ip route 0.0.0.0 0.0.0.0 int s 0' to 'ip route 0.0.0.0 0.0.0.0 s 0'. The configuration statement does not include the word 'interface'.
*,56,10/21/98,Carole Reece,pp 235 - 247,"Figures 6-3, 6-6, 6-9, 6-15, 6-18, and 6-21 contain the statement 'bandwidth 56', but the metric shown in Figures 6-5, 6-8, 6-13, 6-17, 6-20, and 6-24 are for a link configured with 'bandwidth 1544' - the Cisco default. Similarly, the metrics reported in Figure 6-39 do not correspond to the bandwidth set in the configuration of Figure 6-37. The metric for 192.168.6.0 should be 110/1581 and the metric for 192.168.1.0 should be 110/810."
*,55,10/20/98,Carole Reece,pp 241,"The caption for Example 2 should be 'RIP & EIGRP', not 'IP & EIGRP'. Also fix the font size to be the same as the rest of the caption. "
*,54,10/20/98,Carole Reece,pp 71,"The next to last sentence on page, has a superscripted, underlined O before the words 'over the lifetime of the IOS'."
**,53,10/20/98,Scott Shaw,pp 182,Change the text '(some that have had the authentication added and other that have not)' to '(some that have had the authentication added and others that have not)'.
**,52,10/18/98,Eric Germany,pp 48,The table caption should be 'ICMP Types'. Bug #037 notes that this table should be labeled Table 1-6.
**,51,10/18/98,Eric Germany,pp 142,"In the second paragraph, the reference to the IGRP metric calculation in Figure 4-24 should be a reference to Figure 4-26."
**,50, 10/16/98, Narasimhan Kripasagar, pp 100,"In Figure 3-6, the E0 interfaces for both NewYork and London should be 'E0 - .1' to match the configuration of Figure 3-7."
**,49, 10/16/98, Narasimhan Kripasagar, pp 94,"In Figure 3-1, NewYork's E0 interface should be labeled 'E0 - .1' instead of 'E0 - .2' so that it matches the configuration of Figure 3-2."
***,48, 10/15/98, Scott Shaw, pp 76,Figure 2-14 shows only one trace but the text says that there are two. The second trace should be from London to 172.16.6.2 and should take a different path from Paris.
***,47, 10/15/98, Eric Germany, pp 111,"The CCIE Tips section refers to Figure 3-10. There is not a good figure in this chapter to which the text should refer. A good network diagram would look like the one shown in Figure 4-13. NewYork would have a static route that is a valid summary route for the routes within Moscow's region. Similarly, Moscow would use a static route that is a valid summary route for the networks within NewYork's region. Both routers would need to redistribute their respective static route to other routers within its region."
**,46, 10/15/98, Jess Romero, pp 17,"Figure 1-13. The port number for TFTP should be 69, not 67."
*,45, 10/14/98, Carole Reece, pp 167,"The sentence 'Look for the different versions of RIP on each router.' means that you should look for the different output seen when running RIPv2 on the routers. There should only be one version of RIP running, unless you configured RIPv1 on an interface."
*,44, 10/14/98, Carole Reece, pp 167,"The text in the second and third paragraphs describe RIPv2 authentication without referring to a specific network drawing. The configuration examples of Figure 5-6 and 5-7 do not match either Figure 5-5 or 5-8. This was intential, but may be confusing. The text should be clear that the configuration does not match any of the drawings."
*,43, 10/7/98, Carole Reece, pp 7-8,The translated version of 'Terry' is missing the conversion of 'e' -> 'r'.
*,42, 10/7/98, Carole Reece, pp 13-14,Change several occurances of 'TokenRing' to 'Token Ring'.
**,41, 10/13/98, Eric Germany, pp 103-104,(Superceeded by bug # 156) The subnet masks in Figure 3-8 don't match the subnet masks specified in the configuration of Figure 3-9. The subnet masks in Figure 3-8 should be changed to match Figure 3-9.
**,40, 10/12/98, Jim Bender, pp 185,"In the last paragraph, change the line 'Lines 11-14 show the OSPF configuration for NewYork.' to read 'Lines 13-16 show the OSPF configuration for NewYork.' One could make a case that line 17 is part of the OSPF configuration, but since we are describing the basic OSPF configuration and this line is referenced on pp 187, we are not including it in this reference."
**,39, 10/9/98, Jim Bender, pp 60 - 61,"On page 60, Figure 2-1 does not show hosts X and Z referred to on page 61. The correct figure shows host X attached to NewYork's ethernet, host Y attached to Tokyo's ethernet, and host Z attached to London's ethernet. There are no other changes to the figure."
**,38, 10/8/98, Jim Bender, pp 55,"For the New York router, change 'on our protected net (192.168.1.0)' to 'on our protected net (192.168.2.0)' to correct the IP address to match Figure 1-37 and the configuration in Figure 1-38."
*,37, 10/8/98, Jim Bender, pp 48,"The table should be labeled Table 1-6, not 1-2."
**,36, 10/6/98, Jim Bender, pp 35,In Fig 1-22 the Class C network number should be 194.226.19.120 to match the corresponding binary number.
**,35, 10/7/98, Bill Burton, pp 350,"In Fig 7-7, line 30 should read: 30 access-list 1 permit 10.0.1.0 0.0.0.255 and the last paragraph on that page should read: Line 4 shows our initial failed translation from 10.0.2.2 to 200.200.200.2 on the first inside to outside ping because it doesn't meet the criteria defined in the access-list on line 30 in Figure 7-7."
*,34, 10/3/98, Terry Slattery, pp 182,"In the middle of the page, the text 'shutdown/no shutdown' should be bold font."
***,33, 10/3/98, Terry Slattery, pp 166,"In Fig 5-6, line 27 should be omitted from the configuration for clear-text authentication. MD5 authentication would require this line on the serial interfaces of both routers."
**,32, 10/1/98, Jim Bender, pp 24,In Fig 1-17 Tokyo's serial interface should be identified as 'S0 - .1'. Jim reports: 'From what I have seen your book looks great! Thanks for the treasure hunt.'
***,31, 9/22/98, Carole Reece, pp 182,"In the Exercise, you are requested to configure both clear-text and MD5 authentication for EIGRP. There is no clear-text authentication available for EIGRP, but there is for RIP, which was the previous exercise. While researching this bug, we found that the IOS release we are running would not correctly configure EIGRP's MD5 authentication. It would look correct until we did a shutdown/no shutdown sequence on the connecting interfaces. Surprisingly, a 'clear ip route' did not seem to cause EIGRP to reset the authentication mode on the interface."
**,30, 9/17/98, Carole Reece, pp 132,"In Figure 4-15, the caption text should be changed from 'Contiguous subnets' to 'Discontiguous subnets'."
**,29, 10/3/98, Carole Reece, pp 149,"In the Exercise, the reference to 'Figure 4-3' should be changed to 'Figure 4-5'. For the purposes of the exercise, either the configuration of Fig 4-3 or the network map of Fig 4-5 could be used. The change makes improves the continuity of the text and exercises."
**,28, 10/3/98, Carole Reece, pp 144,"In the Exercise, the reference to 'Figure 4-3' should be changed to 'Figure 4-5'. For the purposes of the exercise, either the configuration of Fig 4-3 or the network map of Fig 4-5 could be used. The change makes improves the continuity of the text and exercises."
**,27, 10/3/98, Carole Reece, pp 126,"In the Exercise, the reference to 'Figure 4-3' should be changed to 'Figure 4-5'. For the purposes of the exercise, either the configuration of Fig 4-3 or the network map of Fig 4-5 could be used. The change makes improves the continuity of the text and exercises."
**,26, 9/3/98, Carole Reece, pp 122,"In the Exercise, the reference to 'Figure 4-3' should be changed to 'Figure 4-5'. For the purposes of the exercise, either the configuration of Fig 4-3 or the network map of Fig 4-5 could be used. The change makes improves the continuity of the text and exercises."
**,25, 9/29/98, Terry Slattery, pp 473,last paragraph. Change 'loadback' to 'loopback'.
**,24, 9/29/98, Terry Slattery, pp 472,middle of the page. Change the sentence 'An indication of a flapping link appears in the show ip route output as routes that switch back and forth from possibly down to active.' to read 'An indication of a flapping link will appear in the output of show ip route. Routes which depend on the flapping link will switch back and forth between possibly down and active.'
*,23, 9/29/98, Terry Slattery, pp 423,"In Fig 9-5, line 1, change 'ip.prot' to 'ip prot'."
*,22, 9/29/98, Terry Slattery, pp 357,In Fig 7-19 the figure caption text 'show ip protocol' should be in the same typeface as the other figures.
*,21, 9/29/98, Terry Slattery, pp 354,In Fig 7-15 the figure caption text 'show ip protocol' should be in bold font.
**,20, 9/29/98, Terry Slattery, pp 351,"(Modified by bug # 153) In Fig 7-8 the debug output is incorrect. The correct output is:
1 NewYork#debug ip nat detailed
2 IP NAT detailed debugging is on
3 NewYork#
4 NAT: i: icmp (10.0.2.2, 0) -> (200.200.200.2, 0) [1801]
5 NAT*: i: icmp (10.0.1.1, 0) -> (200.200.200.3, 0) [1806]
6 NAT*: o: icmp (131.108.2.1, 0) -> (200.200.200.3, 0) [1806]
7 NAT*: i: icmp (10.0.1.1, 1) -> (200.200.200.3, 1) [1807]
8 NAT*: o: icmp (131.108.2.1, 1) -> (200.200.200.3, 1) [1807]
9 NAT*: i: icmp (10.0.1.1, 2) -> (200.200.200.3, 2) [1808]
10 NAT*: o: icmp (131.108.2.1, 2) -> (200.200.200.3, 2) [1808]
11 NAT*: i: icmp (10.0.1.1, 3) -> (200.200.200.3, 3) [1809]
12 NAT*: o: icmp (131.108.2.1, 3) -> (200.200.200.3, 3) [1809]
13 NAT*: i: icmp (10.0.1.1, 4) -> (200.200.200.3, 4) [1810]
14 NAT*: o: icmp (131.108.2.1, 4) -> (200.200.200.3, 4) [1810]"
**,19, 9/29/98, Terry Slattery, pp 348,"In Fig 7-4, line 10 is missing that shows the contents of the received update. The missing line is 'network 200.200.200.0 metric 1'"
*,18, 9/29/98, Terry Slattery, pp 289,"In Fig 6-95, line 1, remove the 'y' at the start of the line."
*,17, 9/29/98, Terry Slattery, pp 268,In Fig 6-58 the figure caption text 'show ip protocol' should be in the same typeface as the other figures.
*,16, 9/29/98, Terry Slattery, pp 206,Change section heading from 'Stub & Not-So-Stubby Areas' to 'Stub & Totally Stubby Areas'.
*,15, 9/29/98, Terry Slattery, pp 194,In Fig 5-24 the figure caption text 'show ip route' should be in bold font.
*,14, 9/29/98, Terry Slattery, pp 176,In Fig 5-12 the figure caption text 'show ip eigrp topology' should be in bold font.
*,13, 9/29/98, Terry Slattery, pp 174,In Fig 5-11 the figure caption text 'show ip eigrp neighbor' should be in bold font.
*,12, 9/29/98, Terry Slattery, pp 135,In Fig 4-19 the figure caption text 'show ip route' should be in bold font.
*,11, 9/29/98, Terry Slattery, pp 134,In Fig 4-18 the figure caption text 'show ip protocol' should be in bold font.
*,10, 9/29/98, Terry Slattery, pp 133,In Fig 4-17 the figure caption text 'Trace' should be in bold font.
*,9, 9/29/98, Terry Slattery, pp 105,In Fig 3-10 the figure caption text 'ping' should be in bold font.
*,8, 9/29/98, Terry Slattery, pp 52,In Fig 1-36 the figure caption text 'debug ip igrp' should be in bold font.
*,7, 9/29/98, Terry Slattery, pp 47,In Fig 1-32 the figure caption text 'Trace' should be in bold font.
*,6, 9/29/98, Terry Slattery, pp 45,In Fig 1-30 the figure caption text 'ping' should be in bold font.
*,5, 9/29/98, Terry Slattery, pp 43,In Fig 1-29 the figure caption text 'show arp' should be in bold font.
*,4, 9/29/98, Terry Slattery, pp 42,In Fig 1-28 the figure caption text 'debug arp' should be in bold font.
*,3, 9/29/98, Terry Slattery, pp 10,Envelope in Fig 1-8 shows different address than the envelope in Fig 1-7.
*,2, 9/29/98, Terry Slattery, pp 8,Envelope in Fig 1-6 shows different address than the envelope in Fig 1-7.
*,1, 9/22/98, Steve Elliot, pp 507,Typo 'ABOUTY' should be 'ABOUT'.