Errata

Cloud Native Data Center Networking

Errata for Cloud Native Data Center Networking

Submit your own errata for this product.

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.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
O'Reilly learning platform Page Chapter 2, Data Centre Build Out
third paragraph

Assuming 32-port 100GbE switches—a common model as of this writing—you can build a pod topology for a 200-server cluster using five leaf switches (assuming 40 servers per rack) and five spine switches, assuming an oversubscription ratio of 2:1 (two server-facing ports for every uplink port) for a total of 10 switches.

200 servers need 200 ports. 2:1 means 100 uplinks, a total of 300 ports. 32x5 is 160 ports. So we need 300, but have 160.

I think you meant 200 servers across several pods of 5 leaf switches each. Maybe 2, so 150 ports are needed which is under 160. Each spine needs 100 (50 up, 50 down, assuming 1:1) that's 4 spines per pod. Superspine needs 100 (50 from each spine set from each pod), so 4 superspines.

The total being 2*5 + 2*4 + 4 = 22

This is still less than the 41 for the alternative.

 Craig Small  Dec 05, 2023 
Printed, PDF, ePub, Mobi, , Other Digital Version Page 104
In "Link-state protocol’s behavior in a Clos network"

All of the leaves also compute the area summary routes to announce to the other backbone area routers. S11, which saw the change, sends the new updates to its neighbors in the backbone area, the super-spines. This update propagates through the backbone area until all routers in the backbone area have received it. This includes leaves in other pods. We’re assuming that the spines are not summarizing in this case (see the “Route Summarization in Clos Networks” on page 105 for details on summarization).

All of the leaves also compute the area summary routes to announce to the other backbone area routers.
Since leaves are not in backbone area, and spines are ABR, I think it should be"All of the spines also compute the area summary routes to announce to the other backbone area routers(The super spines). "

"This includes leaves in other pods."
Should it be "This includes spines in other pods."? Because leaves are not in backbone area.

３. If my first two assumptions were correct, then they will contradict this sentence "We’re assuming that the spines are not summarizing in this case (see the “Route Summarization in Clos Networks” on page 105 for details on summarization)."

I think I may misunderstand most of this paragraph, could you please help me with that? Thanks.

I googled some introduction of OSPF route summary. It says that only ABR and ASBR can summary the routes. I think the leaves in Clos topo are not ABR or ASBR, so why can they advertise area summary routes?

 Zhao Huabing  Jan 16, 2020 
Printed, PDF Page 139
Figure 6-9(b)

Title on figure has "VXLAN Aymmetric Routing"
Minor typo should be "VXLAN Asymmetric Routing"

 Julio Perez  Jul 29, 2020 
Printed, PDF Page 139
Last paragraph

Last paragraph for bridging example first states communication from H1-H5. Then states "shows only nodes H1 and H6 because the entire packet is considered bridged"

Update references in paragraph from H6 to H5

 Julio Perez  Jul 29, 2020 
Printed, Page 160
5th paragraph

The sentence "Kubernetes also has a routing daemon, Kube-router, as part of the package." is not correct. Kube-router is not a part of Kubernetes. It is a third-party tool.

Eric Pederson  Jan 06, 2021 
Printed Page 162
1st paragraph, last sentence

Sentence states, "There are five hosts, H1 through H6".
However, counting H1, H2, H3, H4, H5, H6 - appears to reflect six hosts.

 Kelvin Meeks  Jul 11, 2023 
PDF Page 180
last paragraph of Anycast RP

"Cisco’s NX-OS has a proprietary PIM extension to synchronize RP state, especially
when used with anycast RP. This extension allows the RP receiving a PIM Register
message to send it to all the other defined RP peers."

This looks to be a standardized feature: https://tools.ietf.org/html/rfc4610, not a proprietary one.

Radu Pavaloiu  Nov 07, 2020 
Printed, PDF Page 311
3rd configuration example

From book:
ip prefix-list DC_LOCAL_SUBNET seq 5 permit 172.16.0.0/16 ge 26
ip prefix-list DC_LOCAL_SUBNET seq 10 permit 10.0.0.0/24 ge 32 route-map ACCEPT_DC_LOCAL permit 10 match ip-address DC_LOCAL_SUBNET
redistribute connected route-map DC_LOCAL_SUBNET

Correction, redistribute route map and not prefix list
"redistribute connected route-map ACCEPT_DC_LOCAL"

 Julio Perez  Jul 18, 2020 
Printed, PDF Page 329
Figure 15-5

Figure lists server 21 but sentence below figure states "server11 has assigned the address 10.172.1.0/24 to cbr0, and server12 has assigned the address 10.172.2.0/24 to cbr0."

Update sentence to state "server11 has assigned the address 10.172.1.0/24 to cbr0, and server21 has assigned the address 10.172.2.0/24 to cbr0.

 Julio Perez  Jul 18, 2020