The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted By |
| Printed |
Page 66
Second paragraph |
"A bridge is a device that connects multiple segments within a single collision domain. Hubs and switches are both considered bridges."
This is not true. A bridge is a device that conforms to the IEEE 802.1d standard. Bridges connect ethernet segments from different collision domains. Switches are fast bridges that can perform cut-through switching. Hubs are not bridges, but rather repeaters.
|
Anonymous |
| Printed |
Page 73
First paragraph under Preventing Loops with Spanning Tree |
"because someone decided to plug both network drops under his desk into the little switch she'd brought in from home" -- pick one gender or the other.
|
Anonymous |
| Printed |
Page 95
Supernet description |
The text says "A supernet is single route that ...". This probably should read "A supernet is a single route that ...".
|
Anonymous |
| Printed |
Page 102
2nd paragraph |
"Routing protocols are applications that reside at layer seven in the OSI model"
Should be:
Routing protocols are applications that reside at layer THREE in the OSI model
|
Anonymous |
| Printed |
Page 102
4th paragraph, last sentence |
The example between the 3rd and 4th paragraphs states:
ip route 0.0.0.0 0.0.0.0 192.168.1.1 1
ip route 0.0.0.0 0.0.0.0 10.0.0.1 2
The primary default route points to 192.168.1.1, and has a metric of 1.
The second default route points to 192.168.1.2 and has a metric of 2.
The last senetence should read:
The second default route points to 10.0.0.1 and has a metric of 2.
The IP in the text doesn't match the example.
|
Anonymous |
| Printed |
Page 104
2nd paragraph |
The second paragraph goes on to say "These separate areas of control are called autonomous systems in
EIGRP, and processes in OSPF. Each instance is referenced with a number--either an autonomous system
number (ASN), or a process ID (PID)."
This is incorrect, OSPF uses "Areas" to do this, not processes. The process number can be the same or
different on all OSPF routers and it will not have any effect with regards to routing updates.
|
Anonymous |
| Printed |
Page 104,105
3rd paragraph |
In the text and in Figure 10-2 it states that the process ID is included in OSPF updates. This is not the case as the process ID has only local significance on the router, the following (from rfc2740) explains how the stated topology could be achieved.
In OSPF for IPv4 this was supported in a haphazard fashion using the
authentication fields in the OSPF for IPv4 header.
However the stated example does apply to OSPF for IPv6 (See section 2.4 of rfc2740), which has the concept of 'Instance ID' which is included in updates
|
Anonymous |
| Printed |
Page 105
1st Paragraph |
The paragraph states that OSPF must be run with the same process ID between routers for routes to be shared, this is false. process Id's are not passed between routers. If multiple routers exist on the same segment OSPF will form a neighbor adjaceny and share routes as long as the following are met:
-Must pass authentication
-Must be in the same primary subnet, including subnet mask
-Must be in the same OSPF AREA
-Must be of the same area type (NSSA, stub, etc)
-Must no have duplicate RID
-OSPF Hello and Dead timers must be equal
(REF. Routing TCP/IP Vol. 1)
|
Anonymous |
| Printed |
Page 105
Figures 10-2 & 10-3 |
As drawn, both figures show two OSPF processes running on various routers. These routers are connected to the same Ethernet. Given a standard OSPF configuration (no authentication, no statically configured neighbors, etc.) all routers shown will associate as neighbors. Process ID has no bearing on OSPF external to the router.
The context given does not clear this up. (Contextual errata have already been submitted).
The diagrams would be nearly correct if OSPF Areas are being discussed except that all OSPF areas must connect to area zero (0), which is not displayed.
|
cisco@malweth.net |
| Printed |
Page 116
15th line |
page 116: "The maximum hop count is 255 instead of 15. 256 is now the unreachable metric,as opposed to 16
with RIPv1."
The hop count for Rip version 2 is 1 to 15 with 16 being unreachable.
This is the same as Rip version 1.
below are references
http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1crip.html
|
Anonymous |
| Printed |
Page 141
1st paragraph |
R2 advertises the router to R1 via OSPF
should be
R2 advertises the route to R1 via OSPF
|
Anonymous |
| Printed |
Page 174
half-way through "Building a Route Map" |
Current software does not permit the "AND" syntax for matches of the same type:
route-map GAD permit 10
match ip address 101
match ip address 102
route-map GAD deny 20
Will be automatically converted to:
route-map GAD permit 10
match ip address 101 102
route-map GAD deny 20
|
Anonymous |
| Printed |
Page 176
3rd Paragraph |
2nd line of third paragraph: only use the frame-relay that that company had purchased
should be:
only use the frame-relay that company had purchased
|
Anonymous |
| Printed |
Page 177
Bottom |
In this example of policy-based routing, the route maps shown will force traffic to take the same route as the routing protocol. The route maps, as written, are:
route-map Company-1 permit 10
match ip address 101
set interface Serial0/0.109
route-map Company-2 permit 10
match ip address 102
set interface Serial0/0.209
When applied as written in the text, the Company-1 route map will take traffic sourced from Company-2 users that's destined for Company-1 servers and send it out interface Serial0/0.109. The routing protocol will choose this same path without the policy routing and this path is against the rational given for the example. The "set" commands in the route maps should be switched to obtain the correct functionality:
route-map Company-1 permit 10
match ip address 101
set interface Serial0/0.209
route-map Company-2 permit 10
match ip address 102
set interface Serial0/0.109
|
Jeffrey Sprankle |
| Printed |
Page 178
2nd paragraph |
"...To accomplish this, we applied the Company-2 route map to the Company-1 Ethernet interface, and vice
versa. This was done on the Branch-9 router:
Interface FastEthernet0/0
description <[ Company-1 Users ]>
ip address 10.109.0.1 255.255.255.0
ip policy route-map Company-2
half-duplex
Interface FastEthernet0/1
description <[ Company-2 Users ]>
ip address 10.209.0.1 255.255.255.0
ip policy route-map Company-1
half-duplex "
The route maps (defined on page 177) are:
access-list 101 permit ip any 10.101.0.0 0.0.0.255
access-list 101 remark <[ Company-1 Network ]>
!
access-list 102 permit ip any 10.201.0.0 0.0.0.255
access-list 102 remark <[ Company-2 Network ]>
route-map Company-1 permit 10
match ip address 101
set interface Serial0/0.109
route-map Company-2 permit 10
match ip address 102
set interface Serial0/0.209
The route maps appear to route Company-1's traffic over Company-2's link and vice versa. This violates
the requirment stated on page 176, 3rd paragraph, that "...each company insisted that its employees
should only use the frame-relay link that that company had purchased."
Assuming that the interface configuration is left as stated above, the route maps should be changed to
route Company-1's employee traffic destined to Comapny-2's servers over Company-1's frame-relay link and
vice versa. The route-maps should be configured as follows:
route-map Company-1 permit 10
match ip address 101
set interface Serial0/0.209 <-- output interface changed
route-map Company-2 permit 10
match ip address 102
set interface Serial0/0.109 <-- output interface changed
|
Anonymous |
| Printed |
Page 210
1st paragrah |
In the portion that explains the difference between module layouts between the 6506, 6509 and 6513, it incorrectly states that the 6513 module layout is the same as the 6506/6509. When in actuality, the sup720's in a 6513 should be in slots 7-8, not 5-6 like in the 6506/6509:
See 'Slot Requirements' on:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856.html
|
Anonymous |
| Printed |
Page 216
4th paragraph (last) |
Second sentence of last paragraph reads "The fabric-only module in slot 1 has two 20 Gbps channels to the
fiber bus", should this read "fabric bus" ?
|
Anonymous |
| Printed |
Page 218
2nd paragraph |
Example of connecting to an FWSM in slot 8:
Switch-IOS# session slot 8 proc 1
The default escape characteris Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.71 ... Open
That last line should read:
Trying 127.0.0.81 ... Open
|
Anonymous |
| Printed |
Page 223
Last paragraph |
Author mentions, regarding the show port command, that "IOS has nothing that directly compares to this command." Actually, the IOS command "show interface status" will show the same output. This command may have shown up after print of book.
|
Adrian Smith |
| Printed |
Page 235
Graph at top of page |
The graph depicts Packets (or Bytes) as a function of Time. Between T1 and T2 the function actually goes back in time. This certainly would be a unique (and lucrative) feature.
|
Adrian Smith |
| Printed |
Page 237
Top graph |
This is another graph with a funtion of time actually going back in time. Same as errata with page 235.
|
Adrian Smith |
| Printed |
Page 324
6th paragrah (All you really need to think...) |
At point 3. you are saying that the wildcard mask of the subnet mask 255.255.255.240 is 0.15.255.255. I think 0.0.0.15 is the correct wildcard mask.
|
Anonymous |
| Printed |
Page 335
1st paragraph |
The first step in restricting host A's communications is to create the necessary ACL. You must allow access to the default gateway, then deny access to other hosts in the network, and, finally, permit access to the rest of the world:
Last line in the access-list should be:
access-list 101 permit ip any any
|
Anonymous |
| Printed |
Page 418
Beneath Figure 29-2 |
The author talks about a T1 link at 1.5Mbps, then below he says "A T1 can handle 1,500,000 packets per second." This is 2-3 orders of magnitude in error!
|
Anonymous |
| Printed |
Page 438-439
Interface definition under Service Policies |
The policy map name applied to the interface is WAN-Edge, not WAN-Link which is the name used in defining the policy-map.
|
Anonymous |
| Printed |
Page 442
First paragraph |
"The link is saturated, but only in one direction: while txload is 249/255, rxload is only 42/255."
I think txload and rxload have to be interchanged to reflect the console output on page 441 (line 7). Where txload is 42/255 and rxload is 249/255.
|
Anonymous |
| Printed |
Page 464
the paragraph just after the first tip, 4th line |
ERRATA:
... you'll need if you want to allow for growth: 340 + 51 =
411, and 411 / 48 = 8.56. This means you'll need...
CORRECTION:
340 + 51 = 391.
Anyway, the following figures in the paragraph are still correct because 391 / 48 = 8.15, so you still
need nine modules.
SUGGESTION:
To include a 15% percent growth on a figure of 340 interfaces, it is simpler to just calculate 340 * 1.15
= 391, instead of doing two operations: 340 * 0.15 = 51; 340 + 51 = 391.
|
Anonymous |
| Printed |
Page 485
2nd paragraph |
The ranges 172.0.0.0-172.15.255.255 and 172.32.0.0-172.255.255.255 are not composed of private
addresses...
*not*
The ranges 172.0.0.0-172.31.255.255...
|
Anonymous |
| Printed |
Page 485
2nd paragraph |
This looks like a typo in the details of the 172.16/12 private prefix range, the passage states "...
private range is 172.16.0.0 - 172.31.255.255. The ranges 172.0.0.0-172.31.255.255 and
173.32.0.0-172.255.255.255 are not composed of private addresses."
172.0.0.0 - 172.31.255.255 would cover the private range in 172.16/12 (16.0 - 31.255.255) the passage
should read:
... private range is 172.16.0.0 - 172.31.255.255. The ranges 172.0.0.0-172.15.255.255 and
173.32.0.0-172.255.255.255 are not composed of private addresses.
|
Anonymous |
| Printed |
Page 490
3rd paragraph |
"Figure 34-4 shows how a single route statment can reference eight Class C neworks."
The diagram seems to show 16 networks, not eight.
|
Anonymous |
| Printed |
Page 491
3rd paragraph |
"Those entries are taking up 18.4 MB of mory in the router"
Shouldn't it be 17.5 megabytes?
http://www.google.com/search?hl=en&q=18417047+bytes+in+MB
|
Anonymous |
| Printed |
Page 495
1st paragraph |
"Because we cannot use the last subnet due to the rules of networking, a lot of space is wasted."
That statement is at best a historical curiosity and is inappropriate in a practical discussion of using
VLSM in 2007. To quote from RFC 1878:
"For the sake of completeness within this memo, tables 2-1 and 2-2
illistrate some options for subnet/host partions within selected
block sizes using calculations which exclude all-zeros and all-ones
subnets [2]. Many vendors only support subnetting based upon this
premise. This practice is obsolete! Modern software will be able to
utilize all definable networks."
and that was in Dec of 1995. This was an effect of the requirements in RFC 1812 from earlier that year.
|
Anonymous |
| Printed |
Page 509
Tip at bottom |
"Older versions of Windows do not support NTP"
Would be nice to be more specific. My understanding is XP and 2003 use NTP. 2000 and presumably lower use
SNTP.
|
Anonymous |