Skip to main content

Understanding Data Center Fabrics - Part 4: Clos Scaling

Mục lục


1. Quy tắc cơ bản: số spine và số leaf phụ thuộc lẫn nhau qua port count

Trong một Clos fabric, hai con số luôn ràng buộc lẫn nhau:

  • Số lượng spine tối đa bị giới hạn bởi số cổng uplink mà mỗi leaf node dành để nối lên spine (số kết nối leaf-to-spine).
  • Số lượng leaf tối đa bị giới hạn bởi số cổng có sẵn trên mỗi thiết bị spine.

Hai cặp số này luôn phải khớp nhau — đây chính là cách tính ra các con số scale của fabric.

💡 Hình dung như thế này: một thiết bị leaf giống một cái ổ cắm điện nối dài (power strip) có hai đầu — một đầu nhỏ cắm vào ổ điện tường (uplink lên spine, số lượng ít), một đầu nhiều lỗ để cắm thiết bị (downlink xuống server, số lượng nhiều). Số lỗ cắm nhỏ ở đầu tường quyết định bạn nối được vào bao nhiêu "nguồn điện" (spine) khác nhau; còn thiết bị spine giống bảng điện tổng trong phòng kỹ thuật — mỗi lỗ trên đó chỉ dành cho đúng một power strip (leaf) cắm vào. Hết lỗ trên bảng điện tổng nghĩa là hết chỗ cho leaf mới, dù bạn có bao nhiêu power strip đi nữa.

Diagram dưới đây minh họa trực quan quy tắc port-count vừa nêu — port nào đi đâu, và công thức nào quyết định con số scale tối đa:

Port Count Rule: How Spine and Leaf Counts Scale TogetherSpine Switche.g. 32 ports total, all downlink to leaf1 port : 1 leafLeaf Switche.g. 54 ports total6x Uplink to Spine48x Downlink to WorkloadWorkload / Servers (e.g. 48 hosts)Key FormulasMax leaf count =spine port count(32 ports supports up to 32 leaves)Max spine count =leaf uplink count(6 uplinks supports up to 6 spines)Same rule scales the table below: change port density on either box and the max spine or leaf numbers move with it.

Vì sao chỉ cần đúng hai con số này để tính ra cả fabric?

Nhìn kỹ sẽ thấy quy tắc trên thực chất chỉ là một phép đối chiếu port-to-port: mỗi cổng uplink trên leaf phải cắm vào đúng một cổng downlink trên spine, không hơn không kém. Vì vậy tổng số kết nối leaf-to-spine luôn bị chặn bởi bên nào có ít cổng hơn — hoặc số uplink của leaf (nếu leaf ít cổng hơn), hoặc số port của spine (nếu spine ít cổng hơn). Đây chính là lý do vì sao đổi port density trên một trong hai loại thiết bị (spine hoặc leaf) đều kéo theo thay đổi dây chuyền lên toàn bộ các con số scale còn lại — không phải ngẫu nhiên mà bảng ở mục 2 có nhiều dòng khác nhau ứng với nhiều tổ hợp thiết bị khác nhau.

Cần phân biệt quy tắc port-count này (chỉ đơn thuần đếm số cổng khớp nhau) với khái niệm non-blocking đúng nghĩa gốc trong lý thuyết chuyển mạch. Công thức non-blocking nghiêm ngặt (strict-sense non-blocking) do Charles Clos chứng minh năm 1953 cho mạng chuyển mạch thoại (circuit-switching) yêu cầu số thiết bị tầng giữa phải thỏa m ≥ 2n − 1 (với n là số cổng input trên mỗi thiết bị tầng biên), để đảm bảo luôn tìm được đường đi rảnh giữa bất kỳ cặp input/output nào bất kể trạng thái các kết nối khác trong mạng ra sao. Trong thực hành thiết kế fabric Ethernet ngày nay, người ta không áp nguyên công thức đó — vì đây là mạng chuyển mạch gói (packet-switching), traffic được load-balance qua ECMP trên nhiều đường thay vì phải "đặt trước" một đường cố định như circuit-switching thoại. Do đó rule of thumb phổ biến trong ngành chỉ đơn giản là m = n (số spine bằng số uplink mỗi leaf) nếu muốn tầng spine không bị oversubscribe, còn muốn tiết kiệm chi phí thì giảm m xuống thấp hơn n theo đúng tỷ lệ oversubscription mong muốn.

Ví dụ cụ thể: nếu spine có 32 port thì tối đa gắn được 32 leaf — không phải vì lý do kỹ thuật nào sâu xa, đơn giản vì port thứ 33 không tồn tại trên thiết bị đó. Ngược lại nếu leaf chỉ có 6 uplink, dù muốn hay không fabric cũng chỉ scale tới tối đa 6 spine — thêm spine thứ 7 sẽ không còn port nào trên leaf để nối vào. Vì vậy khi thiết kế fabric, việc đầu tiên luôn là chốt xong hai loại thiết bị spine/leaf và port density của chúng, chứ không phải chọn số lượng mong muốn trước rồi mới đi tìm thiết bị phù hợp.


2. Ví dụ các mức scale của một Clos fabric

Tài liệu này đưa ra một loạt ví dụ minh họa cách các con số scale tăng dần khi đổi loại thiết bị spine/leaf.

Bảng dưới đây khá dày số liệu, nên đọc theo đúng thứ tự từ trái sang phải để không bị rối: trước tiên chọn loại thiết bị spine/leaf (cột 1–2, quyết định mỗi thiết bị có bao nhiêu port và port đó chia ra sao) — từ đó suy ra số spine tối đa (cột 3, theo quy tắc "số spine tối đa = số uplink của leaf" vừa nêu ở diagram trên) — rồi suy ra số leaf tối đa (cột 4, theo quy tắc "số leaf tối đa = số port của spine") — cuối cùng nhân số leaf với số port downlink mỗi leaf để ra tổng port workload (cột 5). Cột oversubscription chỉ là tỷ lệ giữa tổng băng thông downlink (xuống workload) và tổng băng thông uplink (lên spine) trên mỗi leaf.

Thiết bị spineThiết bị leafSố spineSố leafTổng port workloadOversubscription
32×100G (1RU)6×100G uplink / 48×25G downlink210480×25G2:1
64×100G (2RU)6×100G uplink / 48×25G downlink220960×25G
64×100G (2RU)6×100G uplink / 48×25G downlink64 (=số port spine)64 (tối đa)3072×25G
32×100G spine / 32×100G leaf (single-skew)3232512×100G1:1
— với optical splitter ×42048×25G
64×100G spine/leaf (2RU, single-skew)32 (=64 port ÷ 2, một nửa lên fabric một nửa xuống workload)64 (tối đa)2048×100G
— với optical splitter ×48192×25G

Vài điểm đáng chú ý từ ví dụ trên:

  • Single-skew design: khi dùng đúng cùng một loại thiết bị cho cả vị trí spine lẫn vị trí leaf, toàn bộ fabric chỉ cần một loại thiết bị duy nhất — nghĩa là chỉ cần dự trữ một loại linh kiện spare, đơn giản hóa vận hành.
  • Với thiết bị 64-port dùng làm cả spine lẫn leaf, số spine tối đa bằng một nửa số port của leaf (64÷2=32), vì mỗi leaf phải chia đều port: một nửa hướng lên fabric (spine), một nửa hướng xuống workload.
  • Optical splitter có thể nhân số port workload lên gấp 4 lần (ví dụ từ 512×100G thành 2048×25G, hoặc từ 2048×100G thành 8192×25G).

Vì sao tăng port density trên một thiết bị lại kéo cả fabric mở rộng theo?

Nhìn vào hai dòng đầu bảng: chỉ đổi spine từ 32×100G (1RU) sang 64×100G (2RU) — giữ nguyên loại leaf — số leaf tối đa tăng từ 10 lên 20 (gấp đôi), và tổng port workload cũng tăng gấp đôi theo (từ 480×25G lên 960×25G). Đây không phải trùng hợp: mỗi leaf vẫn giữ nguyên cách chia 6 uplink cho các spine hiện có, nên khi số port trên mỗi spine tăng gấp đôi, số leaf gắn được vào mỗi spine cũng tăng gấp đôi theo. Ngược lại, nếu chỉ tăng port density của leaf mà giữ nguyên spine, số leaf tối đa không đổi (vẫn bị chặn bởi số port của spine), nhưng oversubscription ratio sẽ thay đổi vì tỷ lệ downlink/uplink trên mỗi leaf đã khác đi.

Điều này cho thấy có hai đòn bẩy scale hoàn toàn độc lập nhau: muốn tăng số leaf (tức tăng số rack/top-of-rack mà fabric phục vụ được) thì tăng port density của spine; muốn tăng oversubscription (giảm chi phí uplink) hoặc tăng số port downlink cho workload thì đổi tỷ lệ uplink/downlink trên leaf. Bảng ở mục này gộp cả hai đòn bẩy trong cùng một bảng để tiện so sánh, nhưng khi thiết kế thực tế nên tách riêng: trước tiên quyết định quy mô leaf (bao nhiêu rack cần phục vụ) để chọn port density spine, sau đó mới quyết định oversubscription ratio để chọn tỷ lệ uplink/downlink trên leaf.

Cái giá phải trả khi dùng optical splitter để nhân bốn port

Optical splitter (breakout) không miễn phí về mặt kiến trúc. Khi một port 100G được chia thành 4 port 25G qua cáp breakout, cả 4 port logic đó chia sẻ chung một port vật lý phía spine — nghĩa là một sự cố ở port 100G gốc (lỗi optic, lỗi cáp) sẽ làm rớt cả 4 kết nối 25G cùng lúc thay vì chỉ một. Đổi lại, số lượng thiết bị vật lý cần mua giảm đi đáng kể — không cần thêm switch mới để tăng port workload, chỉ cần đổi loại cáp/optic — nên đây là lựa chọn kinh tế phổ biến ở các fabric có mật độ server cao nhưng ngân sách port hoặc rack space hạn chế.


3. Ràng buộc vật lý: rack space cho spine

Một Clos fabric không thể chỉ tồn tại trên lý thuyết — phải build được vào rack thật. Ràng buộc thực tế về khả năng scale của fabric chính là không gian rack dành cho các thiết bị spine.

Cách làm: xác định trước quy mô tối đa muốn đạt tới, từ đó tính ra số lượng thiết bị spine cần thiết, rồi dành sẵn đủ không gian rack cho số spine đó. Ví dụ muốn scale tới 32 spine dùng thiết bị 2RU thì cần không gian cho 64 RU — không đủ chỗ trong một rack nên phải chia ra hai rack.

Về mặt cabling, nguyên tắc thường dùng là đặt các thiết bị spine ở vị trí trung tâm để thuận tiện đi dây (dù không phải ai cũng làm theo cách này — tùy sở thích đi cáp của từng người).

Cách scale ra thực tế: bắt đầu với một số lượng spine nhỏ (ví dụ 2 thiết bị, phục vụ 4 top-of-rack), sau đó tăng dần số thiết bị spine để tăng số top-of-rack (leaf) hỗ trợ được — ví dụ tăng gấp đôi số spine sẽ tăng gấp đôi số leaf hỗ trợ được (từ 4 lên 8). Đây chính là bản chất của scale out: chỉ đơn giản thêm box vào lớp spine để tăng số leaf, từ đó tăng số port hướng ra workload.

Vì sao rack space lại là ràng buộc "cứng" hơn cả port count?

Quy tắc port-count ở mục 1 là một ràng buộc logic — muốn nhiều spine hơn thì đổi sang thiết bị leaf có nhiều uplink hơn, muốn nhiều leaf hơn thì đổi sang thiết bị spine có nhiều port hơn. Về lý thuyết, luôn có một tổ hợp thiết bị nào đó đáp ứng được con số mong muốn. Nhưng rack space thì khác: đó là ràng buộc vật lý của tòa nhà — số rack, số RU khả dụng trong mỗi rack, không "đổi thiết bị" để có thêm được. Vì vậy trong thiết kế thực tế, thứ tự suy luận thường bị đảo ngược so với mục 1: không phải chọn trước quy mô mong muốn rồi đi tìm thiết bị, mà phải xuất phát từ rack space đang có, suy ra tối đa build được bao nhiêu RU cho spine, từ đó mới suy ngược ra số spine tối đa và số leaf tối đa fabric có thể phục vụ.

Một rack tiêu chuẩn phổ biến nhất trong data center hiện nay cao 42U. Nếu dùng spine dạng 2RU, về lý thuyết một rack chứa tối đa 21 thiết bị (42÷2) — nhưng con số thực tế luôn thấp hơn, vì còn phải chừa RU cho patch panel, PDU (thanh nguồn), khay quản lý cáp (cable manager) và khoảng trống thoát nhiệt, những thứ không trực tiếp phục vụ port count nhưng vẫn chiếm chỗ trong rack. Đây là lý do vì sao ví dụ "scale tới 32 spine 2RU cần 64 RU, phải chia làm hai rack" ở trên thực ra còn lạc quan hơn thực tế — trong triển khai thật, con số rack cần dùng thường nhỉnh hơn phép tính RU thuần túy.

Vì sao đặt spine ở vị trí trung tâm lại giúp ích cho cabling?

Lý do nằm ở đặc tính vật lý của cáp: cáp đồng thụ động (DAC — Direct Attach Copper) rẻ hơn đáng kể so với cáp quang (AOC/optic), nhưng chỉ hoạt động ổn định trong khoảng cách ngắn — càng tốc độ cao (25G, 100G) thì suy hao tín hiệu điện trên dây đồng càng tăng nhanh theo chiều dài, nên DAC chỉ dùng được trong phạm vi vài mét. Nếu spine nằm ở một góc xa của dãy rack, các leaf ở đầu kia buộc phải dùng cáp quang đắt tiền hơn để nối tới; còn nếu spine nằm ở vị trí trung tâm, phần lớn kết nối leaf-to-spine có thể giữ trong phạm vi cho phép của DAC, giảm đáng kể chi phí cabling. Dù vậy đây chỉ là một nguyên tắc tối ưu chi phí, không phải yêu cầu bắt buộc — một số kiến trúc sư mạng vẫn chọn đặt spine ở đầu dãy rack để thuận tiện quản lý vận hành, chấp nhận đánh đổi chi phí cáp quang cao hơn.


4. Dùng chassis làm spine: Clos fabric biến thành Benes fabric

Vì số leaf tối đa bị giới hạn bởi số port trên mỗi thiết bị spine, một cách để tăng quy mô fabric là thay thiết bị spine dạng fixed-form-factor (1RU/2RU) bằng thiết bị chassis — chassis cho phép tăng số port lên gấp đôi, gấp bốn, v.v.

Xét cấu trúc bên trong một thiết bị fixed-form-factor: traffic vào qua PHY chip → RX ring → input queue → switching engine → output queue → TX ring → PHY chip ra ngoài. Không có bus/backplane nội bộ đáng kể — chỉ có memory transfer, chạy ở tốc độ đầy đủ của switching engine.

Với thiết bị chassis, đường đi phức tạp hơn: packet vào qua PHY → RX ring → input queue → switching engine → line card output queue → TX ring → PHY → đi qua một fabric nội bộ (internal fabric) → tới line card đích qua RX ring/output queue/TX ring → PHY → ra media. Fabric nội bộ này có thể là crossbar (phổ biến nhất), đôi khi là toroid, và ngày nay thường thấy nhất là chính một Clos fabric ba tầng — nhà sản xuất tái sử dụng cùng chipset Ethernet/switching engine để xây fabric nội bộ nối các line card với nhau.

💡 Hình dung như thế này: một switch fixed-form-factor giống một cửa hàng nhỏ chỉ có đúng một quầy thu ngân — khách vào, thanh toán, ra, không có bước trung gian nào khác. Một switch dạng chassis giống một trung tâm thương mại có nhiều quầy thu ngân (line card) nằm rải rác — muốn chuyển hàng từ quầy này sang quầy kia phải đi qua một "hành lang nội bộ" (internal fabric) nối các quầy với nhau. Hành lang đó thực chất chính là một Clos fabric thu nhỏ, nằm ngay bên trong vỏ máy.

Hệ quả quan trọng: khi đưa thiết bị chassis vào vị trí spine, thực chất là thay một thiết bị đơn bằng một fabric khác (thường là Clos ba tầng). Toàn bộ cấu trúc ban đầu vốn là Clos ba tầng giờ trở thành Benes fabric năm tầng (five-stage) — đếm số hop: vào leaf (1) → qua spine-chassis input (2) → qua fabric nội bộ của chassis (3) → ra spine-chassis output (4) → tới leaf đích (5).

Nói cách khác: gói tin tưởng chỉ nhảy qua đúng một "trạm trung chuyển" (spine), nhưng vì trạm đó bên trong lại là cả một fabric ba tầng thu nhỏ, nên thực tế gói tin phải nhảy thêm hai hop ẩn (vào và ra khỏi fabric nội bộ của chassis) mà từ bên ngoài không nhìn thấy được — ba tầng nhìn thấy được (leaf → spine → leaf) cộng thêm hai tầng ẩn bên trong chassis (input line card → internal fabric → output line card) cộng lại thành năm tầng.

Chassis-as-Spine: 3-Stage Clos becomes 5-StageBefore — fixed-form-factor spine (3 stages)Leaf ASpine (1RU)Leaf BAfter — chassis spine (5 stages)Leaf Alooks like 1 device — is actually a 3-stage fabric insideLine Card inInternalFabricLine Card outLeaf B3 stages (Clos) → 5 stages (Benes) once chassis replaces a single spine device

Hai hop ẩn đó có làm chậm traffic đi không?

Về lý thuyết, mỗi hop bên trong một thiết bị switch — dù là spine fixed-form-factor hay line card của chassis — đều cộng thêm độ trễ chuyển mạch (switching latency), thường ở mức nano giây tới vài micro giây tùy kiến trúc buffer/queue. Vì vậy hai hop ẩn thêm vào khi dùng chassis (line card input → internal fabric → line card output) về nguyên tắc làm tăng tổng latency so với một thiết bị spine đơn thuần chỉ có một switching engine. Tuy nhiên trên thực tế mức chênh lệch này thường không đáng kể so với latency phát sinh từ hàng đợi (queuing delay) khi mạng có tải cao — lý do là internal fabric bên trong chassis do chính nhà sản xuất thiết kế và kiểm soát hoàn toàn, nên thường được cấp phát băng thông dư dả (over-provisioned), hiếm khi trở thành điểm nghẽn thực sự trong vận hành bình thường.

Vì sao nhà sản xuất chọn cách này thay vì thiết kế internal fabric riêng?

Lý do chính là tận dụng lại đúng chipset switching engine đã có sẵn (thường là ASIC Ethernet thương mại từ Broadcom, Marvell...) để làm luôn cả vai trò internal fabric, thay vì thiết kế riêng một loại chip chuyên dụng khác cho việc này. Cách làm này giảm chi phí phát triển và rút ngắn thời gian đưa sản phẩm ra thị trường, vì chỉ cần nhân bản cùng một loại chip ở quy mô nhỏ hơn để làm "spine nội bộ" nối các line card — về bản chất là xây một Clos fabric thu nhỏ ngay bên trong vỏ máy, dùng chính công nghệ mà hãng đã làm chủ. Đây cũng là lý do vì sao càng ngày càng nhiều chassis hiện đại dùng kiến trúc fabric nội bộ dạng Clos đa tầng, thay vì crossbar chuyên dụng như các thế hệ chassis cũ.


5. Trade-off giữa thiết bị chassis và thiết bị fixed-form-factor

Việc dùng chassis ở lớp spine là một sự đánh đổi (trade-off), không đơn thuần là "tốt hơn". Gốc rễ của mọi khác biệt trong bảng dưới đây đều quay về đúng một điểm đã nêu ở mục 4: chassis giấu một fabric ba tầng bên trong vỏ máy, còn fixed-form-factor thì không — mọi ưu điểm (mật độ, quản lý gọn) và nhược điểm (blast radius, độ phức tạp ẩn) của chassis đều là hệ quả trực tiếp của việc "gói" nhiều thiết bị logic vào chung một vỏ máy vật lý.

Chassis vs Fixed-Form-Factor: Trade-off at a GlanceChassis SpineFixed-Form-Factor Spine (1RU/2RU)+Looks like one device to manage+Higher port density, shared power/cooling-Hidden internal fabric adds 2 extra hops-Large blast radius on failure-High vendor lock-in, plan capacity upfrontInFabricOut+Transparent: single switching engine+Small blast radius, easy troubleshooting+True scale-out, low vendor lock-in-More physical devices to manage-Lower port density than chassisScale pattern: SCALE UPAdd line cards; must size chassis upfrontScale pattern: SCALE OUTAdd boxes incrementally as demand growsBoth are valid choices — the right pick depends on how predictable growth is and how much blast radius is tolerable.
Khía cạnhThiết bị chassisThiết bị fixed-form-factor (1RU/2RU)
Cấu hình/quản lý bên ngoàiThường đơn giản hơn — trông như một thiết bị duy nhất với nhiều interfaceNhiều thiết bị vật lý riêng lẻ hơn, phải quản lý nhiều interface hơn
Độ phức tạp nội bộCao hơn — có internal fabric, processor riêng, thêm một lớp RX/TX ring, input/output queue ẩn bên trongThấp — "what you see is what you get", traffic chỉ đi thẳng qua input queue → switching engine → output queue
Failure domain / blast radiusLớn hơn — mất một chassis là mất nhiều capacity cùng lúcNhỏ hơn — mất một thiết bị chỉ ảnh hưởng phạm vi thiết bị đó
Khả năng troubleshootKhó hơn (nhiều thành phần ẩn bên trong)Dễ hơn — do chỉ có một switching engine duy nhất, minh bạch trong telemetry
Kiểu scaleThiên về scale up — phải mua chassis trước rồi cắm line card dần, phải đoán trước quy mô cuối cùng cần đạt tớiThiên về scale out — tận dụng đúng khả năng mở rộng point-by-point của Clos fabric, miễn là chừa đủ rack space
Mật độ (density)Cao hơn — không phải chạy fan/power supply riêng cho từng thiết bịTrung bình, không cao bằng chassis
Hiệu suất dùng điệnHiệu quả hơn — chassis tự quản lý điện tập trungKém hiệu quả hơn một chút
Lock-inRất cao — chỉ có thể thay chassis bằng một chassis tương tự khácThấp hơn

Vì sao "mất một chassis" lại nghiêm trọng hơn "mất một fixed-form-factor switch"?

Một thiết bị fixed-form-factor đóng vai trò đúng một spine — mất thiết bị đó, fabric chỉ mất đúng số port của một spine, và traffic được ECMP tự động dồn qua các spine còn lại. Nhưng một chassis đóng vai trò gộp của nhiều spine logic vào chung một khối phần cứng: nhiều line card cùng chia sẻ chung supervisor engine, chung khay quản lý fabric nội bộ (fabric module), đôi khi chung cả nguồn điện và hệ thống làm mát. Vì vậy khi một thành phần dùng chung đó gặp sự cố — không phải bản thân line card, mà là supervisor hay fabric module — hậu quả không dừng ở một line card mà lan ra toàn bộ chassis cùng lúc. Đây là lý do "blast radius" của chassis được xem là lớn hơn: rủi ro không nằm ở việc chassis "dễ hỏng hơn", mà nằm ở việc một điểm lỗi có thể kéo theo nhiều capacity hơn.

Vậy nên chọn chassis hay fixed-form-factor?

Câu trả lời phụ thuộc vào việc quy mô fabric có dự đoán trước được hay không. Nếu tổ chức đã biết rõ quy mô cuối cùng cần đạt tới (ví dụ đã lên kế hoạch fabric cho một số lượng rack cố định ngay từ đầu), chassis giúp giảm số thiết bị cần quản lý và tăng mật độ trên mỗi RU, đổi lại phải trả tiền trước cho slot line card chưa dùng tới. Ngược lại, nếu quy mô tăng trưởng khó đoán trước — phổ biến trong môi trường cloud hoặc doanh nghiệp đang mở rộng dần — fixed-form-factor cho phép trì hoãn quyết định đầu tư, chỉ mua thêm spine khi thực sự cần, đồng thời giữ blast radius nhỏ hơn nếu có sự cố xảy ra. Không có lựa chọn nào đúng tuyệt đối; đây luôn là quyết định cân bằng giữa chi phí vận hành, tốc độ tăng trưởng và mức độ chấp nhận rủi ro của từng tổ chức.


Nguồn tham khảo

Nguồn gốc: Understanding Data Center Fabrics, Part 4: Clos Scaling (Russ White) — kênh Packet Pushers. Xem thêm tại packetpushers.net và bản video trên YouTube.

Ghi chú fact-check (truy cập 2026-07-14):

  • Quy tắc "số spine tối đa = số uplink của leaf; số leaf tối đa = số port của spine" khớp với cách trình bày chuẩn về Clos/leaf-spine sizing trong tài liệu ngành (vd Juniper "Design Considerations for Spine-and-Leaf IP Fabrics", và bài phân tích "The Effect of Switch Port Count in Clos Topology") — đây là công thức sizing phổ biến, không riêng của tài liệu này.
  • Bảng số liệu port-count ở mục 2 (thiết bị 32×100G/64×100G, leaf 6×100G uplink/48×25G downlink, oversubscription 2:1) là ví dụ minh họa mang tính giáo dục để dạy cách tính scale, không mô tả specs của một sản phẩm thương mại cụ thể nào — các con số port/tốc độ này (6 uplink 100G, 48 downlink 25G) là cấu hình rất phổ biến trong ngành và xuất hiện lặp lại ở nhiều tài liệu/whitepaper khác nhau (Cisco, Juniper, các bài phân tích Clos độc lập) như một ví dụ chuẩn để giảng dạy, chứ không gắn với một SKU/model switch cụ thể.
  • "Optical splitter nhân port lên gấp 4 lần" — xác nhận đúng là cơ chế thực tế phổ biến trong data center, gọi là breakout (100G QSFP28 chia thành 4×25G qua breakout cable/AOC hoặc MPO fiber). Cisco, Juniper và Arista đều hỗ trợ và tài liệu hóa cơ chế này chính thức (vd Cisco QSFP-100G-to-4×SFP-25G breakout cable, Juniper "100G Breakout Capable" doc, Arista breakout mode 4×25GE trên port 100G) — claim trong bài là chính xác, không phải suy diễn.