EtherChannel และ LACP — สี่สายไม่ได้แปลว่าเร็วสี่เท่า

บทความ Spanning Tree Protocol จบด้วยภาพที่ขัดกับสัญชาตญาณ — คุณเดินสายสำรองไว้สองเส้น แล้ว STP ปิดเส้นหนึ่งทิ้ง เพื่อไม่ให้เกิดลูป เงินที่จ่ายไปกับสายเส้นที่สองจึงนอนรออุบัติเหตุอยู่เฉย ๆ

บทความนี้คือวิธีใช้สายเส้นนั้น แทนที่จะปิดมัน

กลไกนี้ทำให้สายหลายเส้นกลายเป็นเส้นเดียวในสายตาของทุกอย่างที่อยู่ข้างบน STP เห็นพอร์ตเดียวจึงไม่มีอะไรให้ปิด ตารางที่อยู่ MAC เห็นพอร์ตเดียวจึงไม่ สับสน และถ้าสายเส้นใดเส้นหนึ่งขาด ที่เหลือรับงานต่อโดยไม่มีใครข้างบนรู้เรื่อง

Cisco เรียกมันว่า EtherChannel มาตรฐานเรียกว่า Link Aggregation และโพรโทคอล ที่คุมมันชื่อ LACP

และเรื่องนี้ถูกเข้าใจผิดหนักที่สุดในจุดเดียว — คนคิดว่ารวมสายสี่เส้นแล้ว ได้ความเร็วสี่เท่า ซึ่งไม่จริงเลยสำหรับการเชื่อมต่อเดียว การคัดลอกไฟล์ก้อน เดียวข้ามลิงก์ที่รวมสี่เส้นไว้ ยังวิ่งบนสายเส้นเดียวเท่านั้น ข้างล่างมีตัวเลข ที่คำนวณให้ดู

ถ้ายังไม่เคยดู เริ่มตรงนี้

ไม่ต้องมีสวิตช์ก็อ่านเรื่องนี้ได้ เพราะ macOS มีของพวกนี้อยู่ในตัว

$ man ifconfig | grep -A3 'bondmode lacp'

ได้ข้อความที่บอกทุกอย่างที่ต้องรู้ในสี่บรรทัด

  bondmode lacp | static
     If the interface is a bond pseudo device, this option will
     set the mode on the bond interface.  The two currently
     supported modes are lacp and static.  The default mode is lacp.

มีสองโหมด และ ค่าตั้งต้นคือ lacp เหตุผลที่ค่าตั้งต้นเป็นแบบนั้นคือเนื้อหา ครึ่งแรกของบทความนี้ ส่วนคำสั่งที่ใช้ดูสถานะจริงเมื่อมีการรวมลิงก์อยู่คือ

$ ifconfig -b

หน้าคู่มือเขียนไว้ว่า "To monitor the 802.3ad Link Aggregation state, use the -b option."

ปัญหาที่ต้องแก้ มีสองข้อ ไม่ใช่ข้อเดียว

ข้อแรกคือข้อที่ STP ทิ้งไว้ ลิงก์สำรองถูกปิด

ข้อที่สองมองไม่เห็นถ้าไม่ย้อนกลับไปดูยุคนั้น — ความเร็วอีเทอร์เน็ตขยับ ทีละสิบเท่า จาก 10 เป็น 100 เป็น 1000 เมกะบิต ระหว่างขั้นไม่มีอะไรเลย องค์กรที่ 100 ไม่พอแต่ยังซื้อกิกะบิตไม่ไหวจึงไม่มีทางไป

สไลด์แนะนำของ IEEE เมื่อพฤศจิกายน 1997 วางตารางนี้ไว้ตรง ๆ

  Ethernet          10 Mbps      trunked      20-80 Mbps
  Fast Ethernet    100 Mbps      trunked    200-800 Mbps
  Gigabit Ethernet   1 Gbps      trunked      multi Gbps

พร้อมประโยคสรุปว่า "Reuse standard interface technology and go ever faster" — ใช้ของเดิมที่มีอยู่แล้ว แล้วไต่ขึ้นไปทีละขั้นเล็ก ๆ แทนที่จะ กระโดดทีละสิบเท่า

พฤศจิกายน 1997 — ตอนที่ทุกเจ้าทำของตัวเองไปแล้ว

หน้าเว็บของ IEEE 802.3 Trunking Study Group ยังอยู่ และรายชื่อผู้บรรยายใน สไลด์ชุดนั้นบอกสถานการณ์ได้ดีกว่าคำอธิบายใด ๆ

  Introduction                     H. Frazier   Cisco
  Ethernet Parallel Path Trunking  P. Bottorff  Bay
  Trunking in Multiple Ethernet    H. Chin      Cisco
  Server/Switch Trunking Schemes   P. Congdon   HP
  Link Aggregation Trunking        A. Hendel    Sun
  The case for In-Band Protocols   D. Friedman  3Com

ห้าบริษัทคู่แข่ง แต่ละเจ้ามีวิธีรวมลิงก์ของตัวเองที่ใช้ข้ามยี่ห้อไม่ได้ การประชุมนั้นจึงไม่ใช่การคิดของใหม่ แต่เป็นการยอมรับว่าของที่ทุกคนมีอยู่แล้ว คุยกันไม่รู้เรื่อง

จากนั้นเดินตามกระบวนการของ IEEE ตามที่หน้าเว็บของทั้งสองกลุ่มบันทึกไว้

  1997-11   ตั้ง Trunking Study Group เปิดด้วยสไลด์แนะนำ
  1998-06   อนุมัติ Project Authorization Request
  2000-03   อนุมัติ IEEE 802.3ad-2000

หน้าของ Task Force เขียนสรุปไว้ว่า "The work of the IEEE P802.3ad Link Aggregation Task Force is now complete with the approval of IEEE 802.3ad-2000 at the March 2000 IEEE Standards Board meeting."

ต่อมาการรวมลิงก์ถูกย้ายออกจาก 802.3 ไปเป็นมาตรฐานของตัวเองชื่อ 802.1AX เพราะมันไม่ใช่เรื่องเฉพาะอีเทอร์เน็ตอีกต่อไป ชื่อ 802.3ad ยังติดปากคนทำงาน และยังเป็นชื่อโหมดในซอฟต์แวร์จำนวนมากจนถึงวันนี้ — โหมดที่ 4 ของ bonding บน Linux ก็ยังชื่อ 802.3ad

ทำไมต้องมีโพรโทคอล ในเมื่อตั้งค่าสองฝั่งให้ตรงกันก็จบ

นี่คือคำถามที่ Del Friedman จาก 3Com ตอบไว้ในสไลด์ชื่อ "Trunking: The Case for In-Band Protocols" เมื่อพฤศจิกายน 1997 และคำตอบยังใช้ได้ทุกคำ

เขายกความล้มเหลวสามแบบ และทุกแบบลงท้ายเหมือนกัน

หนึ่ง ลิงก์ที่ตายแต่ไฟยังเขียว

"Link status alone does not guarantee detection of link outages" "Stuck transmitter prevents effective use of single link"

สอง สายที่วนกลับหาตัวเอง

"Loopback links turn trunks back on themselves"

สาม สายที่สลับคู่

"Split trunks caused by crossed wires"

และผลของทั้งสามแบบเขียนด้วยประโยคเดียวกันทุกครั้ง

"Result: Some conversations disappear"

สังเกตคำว่า conversations ไม่ใช่ "การเชื่อมต่อทั้งหมดล่ม" — เพราะลิงก์ ที่รวมกันไว้กระจายทราฟฟิกด้วยการแฮช ถ้าสายเส้นหนึ่งเสียแบบเงียบ ๆ สิ่งที่ เกิดขึ้นคือบางส่วนของทราฟฟิกหายไป ส่วนที่เหลือทำงานปกติ คนใช้บางคนใช้ได้ บางคนใช้ไม่ได้ และสไลด์ให้คะแนนความยากในการหาสาเหตุไว้ว่า Difficult กับ Very difficult

ข้อสรุปของเขาคือสิ่งที่กลายมาเป็น LACP

"Confirmation of proper connectivity of link before using or configuring it" "Achievable via simple Hello-Message exchange" "Minimal bandwidth utilization - < .01% of 100 Meg Link"

ประโยคสุดท้ายคือเหตุผลที่ไม่มีข้ออ้างจะไม่เปิดมัน ราคาของการรู้ว่าสาย เส้นนั้นยังใช้ได้จริง คือน้อยกว่าหนึ่งในหมื่นของลิงก์ 100 เมกะบิต

LACPDU — 110 ไบต์ที่วิ่งอยู่ตลอดเวลา

LACPDU ไม่ได้ห่อด้วย IP และไม่มีพอร์ต มันเป็นเฟรมอีเทอร์เน็ตล้วน ๆ

  destination   01:80:C2:00:00:02
  ethertype     0x8809
  subtype       0x01

0x8809 คือ Slow Protocols ส่วนที่อยู่ปลายทางเป็นที่อยู่สงวนของ IEEE ที่ สวิตช์จะไม่ส่งต่อออกไปพอร์ตอื่น เฟรมนี้จึงไปได้แค่อุปกรณ์ที่อยู่ปลายสาย อีกด้านหนึ่งเท่านั้น ไม่มีวันหลุดออกไปทั้งวง

โครงในซอร์สของเคอร์เนล Linux เขียนไว้ครบ นับออฟเซ็ตได้ตรงนี้

  offset  size  field
       0     1   subtype = 0x01
       1     1   version
       2     1   TLV actor
       3     1   length = 20
       4     2   actor system priority
       6     6   actor system (MAC)
      12     2   actor key
      14     2   actor port priority
      16     2   actor port
      18     1   actor state
      19     3   reserved
      22    20   บล็อก partner หน้าตาเหมือน actor ทุกฟิลด์
      42    16   collector max delay + reserved
      58    52   terminator + reserved

รวม 110 ไบต์ บวกหัวอีเทอร์เน็ต 14 เป็น 124 ไบต์ต่อเฟรม เกินขั้นต่ำ 64 ไบต์ ของอีเทอร์เน็ตจึงไม่ต้องเติมช่องว่าง

สิ่งที่ต้องเข้าใจคือคำว่า actor กับ partner ทุกฝั่งเขียนสองอย่างลงใน เฟรมเดียว — สิ่งที่ฉันเป็น และสิ่งที่ฉันเชื่อว่าเธอเป็น เมื่ออีกฝั่งได้ รับ มันจะเทียบว่าสิ่งที่คู่สนทนาเชื่อเกี่ยวกับตัวเอง ตรงกับความจริงไหม

นั่นคือกลไกที่จับสายสลับคู่ได้ ถ้าคุณเสียบสายผิดไปเข้าสวิตช์คนละตัว ค่า partner system ที่สองฝั่งเขียนถึงกันจะไม่ตรง และการรวมลิงก์จะไม่เกิด แทนที่จะเกิดแล้วพังเงียบ ๆ

แปดบิตที่ตัดสินทุกอย่าง

actor_state กับ partner_state เป็นไบต์เดียว แต่ละบิตมีความหมาย

  0x01  Activity          ฉันเป็นฝ่ายเริ่มคุย ไม่ได้รอฝ่ายเดียว
  0x02  Timeout           ฉันขอแบบเร็ว ส่งทุกวินาที
  0x04  Aggregation       พอร์ตนี้รวมกับพอร์ตอื่นได้
  0x08  Synchronization   ฉันเห็นว่าเราตกลงกันได้แล้ว
  0x10  Collecting        ฉันเริ่มรับเฟรมจากพอร์ตนี้แล้ว
  0x20  Distributing      ฉันเริ่มส่งเฟรมออกพอร์ตนี้แล้ว
  0x40  Defaulted         ฉันไม่ได้ยินจากคู่สนทนา ใช้ค่าตั้งต้นแทน
  0x80  Expired           ข้อมูลของคู่สนทนาหมดอายุแล้ว

ลำดับของสามบิตกลางคือหัวใจ พอร์ตจะไม่ส่งข้อมูลจริงจนกว่าจะได้ Synchronization ก่อน แล้วจึง Collecting แล้วจึง Distributing การรับมาก่อนการส่งเสมอ เพราะถ้าเริ่มส่งก่อนที่อีกฝั่งจะพร้อมรับ เฟรมจะหาย

จังหวะเวลา และสิ่งที่มันแลกมา

ค่าคงที่ในซอร์สของ Linux ตรงกับที่มาตรฐานกำหนด

  fast periodic         1 s     ส่ง LACPDU ทุกหนึ่งวินาที
  slow periodic        30 s     ส่งทุกสามสิบวินาที
  short timeout         3 s     สามเท่าของ fast
  long timeout         90 s     สามเท่าของ slow
  churn detection      60 s     ตรวจว่าสถานะแกว่งไปมาไหม
  aggregate wait        2 s     รอให้พอร์ตอื่นมาเข้ากลุ่มก่อน

กฎสามเท่ามีเหตุผล ยอมให้ LACPDU หายได้สองใบติดกันโดยไม่ตัดสินว่าลิงก์ตาย ถ้าตั้งเป็นสองเท่า เฟรมหายสองใบเพราะสายสัญญาณรบกวนชั่วครู่ก็จะทำให้ลิงก์ หลุดออกจากกลุ่มโดยไม่จำเป็น

และนี่คือจุดที่คนตั้งค่าพลาดบ่อย โหมดช้าคือค่าตั้งต้นในอุปกรณ์ส่วนใหญ่ ซึ่งแปลว่าถ้าสายเส้นหนึ่งตายแบบไฟยังเขียว จะใช้เวลาถึง 90 วินาที กว่า อีกฝั่งจะยอมรับว่ามันตาย ตลอด 90 วินาทีนั้นทราฟฟิกที่ถูกแฮชไปลงสายเส้นนั้น หายหมด ถ้าต้องการให้เร็วต้องตั้งโหมดเร็วทั้งสองฝั่ง แล้วจะเหลือ 3 วินาที

active กับ passive และกับดักที่ตามมา

แต่ละพอร์ตเลือกได้ว่าจะเป็นฝ่ายเริ่มคุยหรือไม่ ซึ่งก็คือบิต Activity

  active   + active    ตกลงกันได้
  active   + passive   ตกลงกันได้
  passive  + passive   ไม่มีอะไรเกิดขึ้นเลย

สองฝั่ง passive คือความเงียบที่ดูเหมือนอุปกรณ์เสีย ไม่มีใครเริ่มพูด จึง ไม่มีใครได้ยิน ไฟที่พอร์ตเขียวปกติ สายก็ดี แต่การรวมลิงก์ไม่เกิด

Cisco มีโพรโทคอลของตัวเองมาก่อนชื่อ PAgP ซึ่งใช้ตรรกะเดียวกันแต่คนละชื่อ desirable คือ active และ auto คือ passive ส่วนคำสั่งที่อันตรายที่สุดคือ mode on ซึ่งแปลว่าไม่ใช้โพรโทคอลอะไรเลย เท่ากับ static บน macOS

หน้าคู่มือของ macOS อธิบาย static ไว้ว่า

"In static mode, a member interface is made an active part of the link aggregate as long as the link status is active."

"as long as the link status is active" คือคำที่ต้องอ่านช้า ๆ เพราะสไลด์ ปี 1997 บอกไว้แล้วว่า "Link status alone does not guarantee detection of link outages" — โหมดนี้เชื่อสิ่งเดียวกับที่เอกสารเมื่อยี่สิบเก้าปีก่อน บอกว่าเชื่อไม่ได้

การกระจายเฟรม — จุดที่ความเข้าใจผิดทั้งหมดอยู่

มาตรฐานไม่ได้บอกว่าต้องกระจายเฟรมยังไง มันบอกแค่ว่าห้ามสลับลำดับเฟรมของ บทสนทนาเดียวกัน วิธีที่ทุกคนใช้เพื่อรับประกันข้อนั้นคือแฮช

RFC 7424 ของ IETF อธิบายเหตุผลไว้ตรง ๆ

"The advantages of hash-based techniques for load distribution are the preservation of the packet sequence in a flow and the real-time distribution without maintaining per-flow state in the router."

"The result of the hashing procedure is a many-to-one mapping of flows to component links."

many-to-one คือคำที่ต้องจำ หลายโฟลว์ไปลงลิงก์เดียวได้ แต่หนึ่งโฟลว์ไป ลงหลายลิงก์ไม่ได้

เอกสารของ bonding บน Linux ระบุสูตรไว้ทั้งหมด แบบที่ง่ายที่สุดคือ

  hash = source MAC[5] XOR destination MAC[5] XOR packet type ID
  slave number = hash modulo slave count

และเขียนกำกับผลของมันไว้ว่า "This algorithm will place all traffic to a particular network peer on the same slave."

แบบที่ใช้พอร์ตด้วยคือ layer3+4 และคำเตือนอยู่ในประโยคเดียว

"This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves."

"a single connection will not span multiple slaves" คือคำตอบของคำถามที่ ทุกคนถาม เขียนไว้ในเอกสารทางการอยู่แล้ว

สี่สายไม่ได้แปลว่าเร็วสี่เท่า

ผมเขียนสูตรจากเอกสาร Linux ข้างบนเป็นโปรแกรมแล้วลองจริง

การเชื่อมต่อเดียว เช่นคัดลอกไฟล์ก้อนใหญ่ผ่าน ssh

  2 links    ใช้เส้นเดียว เหลือว่าง 1 เส้น
  3 links    ใช้เส้นเดียว เหลือว่าง 2 เส้น
  4 links    ใช้เส้นเดียว เหลือว่าง 3 เส้น
  8 links    ใช้เส้นเดียว เหลือว่าง 7 เส้น

เพิ่มสายไม่ช่วยเลย เพราะแฮชของโฟลว์นั้นเป็นค่าคงที่ค่าเดียว

หลายการเชื่อมต่อ เช่นเว็บเซิร์ฟเวอร์ที่มีคนเข้าเยอะ กระจายได้ดีจริง ทดลองด้วย 500 การเชื่อมต่อ

  2 links   47.2%  52.8%
  4 links   24.8%  25.2%  22.4%  27.6%
  8 links   12.4%  13.0%  10.6%  14.2%  12.4%  12.2%  11.8%  13.4%

ลิงก์ที่หนักที่สุดได้ราว 1.1 เท่าของค่าเฉลี่ย ซึ่งยอมรับได้

แต่ของจริงโฟลว์ไม่ได้ตัวเท่ากัน RFC 7424 บอกเงื่อนไขที่ต้องเป็นจริงไว้ สามข้อ ข้อหนึ่งคือ "the individual flow rates are much smaller as compared to the link capacity" และอีกข้อคือ "the differences in flow rates are not dramatic"

ผมลอง 200 โฟลว์ โดยให้สี่โฟลว์เป็นงานสำรองข้อมูลขนาดหลายกิกะไบต์ ที่เหลือ เป็นทราฟฟิกทั่วไป แล้ววัดสองแบบ — by flow คือนับจำนวนการเชื่อมต่อ ส่วน by bytes คือนับปริมาณข้อมูลจริง

  4 links
    by flow    22.0%  29.5%  23.0%  25.5%   worst 1.18x
    by bytes    0.5%  52.1%  46.7%   0.6%   worst 2.08x

  8 links
    by flow    10.5%  14.0%  14.0%  14.5%
               11.5%  15.5%   9.0%  11.0%   worst 1.24x
    by bytes    0.3%   0.4%  21.0%   0.3%
                0.2%  51.8%  25.7%   0.3%   worst 4.14x

อ่านสองบรรทัดนี้แล้วจะเห็นปัญหาที่แท้จริง ระบบเฝ้าระวังที่นับจำนวนการ เชื่อมต่อจะรายงานว่าทุกอย่างสมดุลดี ที่ 1.18 เท่า ขณะที่ปริมาณข้อมูลจริง กระจุกอยู่ที่สองลิงก์ในสี่ อีกสองลิงก์แทบไม่ได้ทำงาน

และผลที่สวนสามัญสำนึกที่สุดคือ เพิ่มลิงก์แล้วแย่ลง จาก 2.08 เท่าที่สี่ ลิงก์ เป็น 4.14 เท่าที่แปดลิงก์ เพราะโฟลว์ใหญ่สี่ก้อนแบ่งตัวเองไม่ได้ ยิ่งมีลิงก์เยอะ ค่าเฉลี่ยยิ่งต่ำ แต่ก้อนใหญ่ยังกองอยู่ที่เดิม

เมื่อมันโกหก

"รวมสี่สายได้สี่เท่า" ไม่จริงสำหรับโฟลว์เดียว และจริงแบบมีเงื่อนไขสำหรับ หลายโฟลว์ สิ่งที่ได้แน่ ๆ คือความทนทาน ไม่ใช่ความเร็ว

"กราฟบอกว่าสมดุลดี" ต้องดูว่ากราฟนับอะไร ถ้านับจำนวนการเชื่อมต่อหรือ จำนวนแพ็กเก็ต มันจะสวยเสมอ สิ่งที่ทำให้ลิงก์เต็มคือไบต์

"เพิ่มลิงก์แล้วดีขึ้นเสมอ" ไม่เสมอไป ถ้าทราฟฟิกมีก้อนใหญ่ไม่กี่ก้อน การเพิ่มลิงก์ทำให้ความไม่สมดุลแย่ลงตามที่วัดได้ข้างบน

"ไฟเขียวแปลว่าใช้ได้" นี่คือความเชื่อที่เอกสารปี 1997 เขียนไว้ว่าเชื่อ ไม่ได้ และเป็นเหตุผลที่ LACP ถูกสร้างขึ้นมาทั้งโพรโทคอล

"ตั้ง mode on เร็วกว่า ไม่ต้องรอเจรจา" เร็วกว่าจริง และเป็นวิธีสร้าง ลูปที่ STP มองไม่เห็น เพราะฝั่งหนึ่งคิดว่ารวมแล้วอีกฝั่งคิดว่ายังไม่รวม

"แฮชแบบไหนก็เหมือนกัน" ไม่เหมือน ถ้าเซิร์ฟเวอร์ออกอินเทอร์เน็ตผ่าน เกตเวย์ตัวเดียว แฮชแบบ layer2 จะให้ค่าคงที่ค่าเดียวเสมอ เพราะทั้ง MAC ต้นทางและปลายทางไม่เปลี่ยน ทราฟฟิกทั้งหมดลงลิงก์เดียว

ตัวอย่างจริงจากงานจริง

กรณีที่ 1 — บางเครื่องใช้ได้ บางเครื่องใช้ไม่ได้

สถานการณ์ หลังเพิ่มสายเส้นที่สองเข้ากลุ่ม ผู้ใช้บางคนบ่นว่าเข้าเซิร์ฟเวอร์ ไม่ได้ อีกหลายคนใช้ได้ปกติ ไฟที่พอร์ตเขียวทั้งคู่

คำสั่ง ดูสถานะการรวมลิงก์ ไม่ใช่ดูไฟ

$ ifconfig -b bond0

อ่านอย่างไร อาการ "บางคนได้ บางคนไม่ได้" คือลายเซ็นของสายเส้นเดียวใน กลุ่มที่เสีย ไม่ใช่ปัญหาที่เซิร์ฟเวอร์ ผู้ใช้ที่เดือดร้อนคือกลุ่มที่แฮชพา ไปลงสายเส้นนั้นพอดี ซึ่งเป็นประโยคเดียวกับที่สไลด์ปี 1997 เขียนว่า "Some conversations disappear" ถ้าใช้ static หรือ mode on อยู่ ให้ เปลี่ยนเป็น LACP ก่อนเป็นอันดับแรก เพราะโหมดนั้นไม่มีทางรู้เลยว่าสายเสีย

สิ่งที่ยังไม่ได้พิสูจน์ เรารู้ว่าอาการเข้ากับรูปแบบนี้ ยังไม่รู้ว่าสาย เส้นไหน ต้องดูสถานะรายพอร์ตว่าพอร์ตใดไม่ได้บิต Distributing และยังไม่ ตัดความเป็นไปได้ว่าปัญหาอยู่ที่ MTU หรือ VLAN ที่ตั้งไม่ตรงกันระหว่างสอง พอร์ต ซึ่งให้อาการคล้ายกัน

กรณีที่ 2 — รวมสี่สายแล้วคัดลอกไฟล์ไม่เร็วขึ้น

สถานการณ์ รวมสี่พอร์ตกิกะบิตเข้ากลุ่มแล้ว แต่คัดลอกไฟล์ก้อนใหญ่ระหว่าง สองเครื่องยังได้ราว 900 Mbps เท่าเดิม

คำสั่ง วัดด้วยการเชื่อมต่อเดียว แล้ววัดด้วยหลายการเชื่อมต่อพร้อมกัน

$ iperf3 -c 10.0.0.5                 การเชื่อมต่อเดียว
$ iperf3 -c 10.0.0.5 -P 8            แปดการเชื่อมต่อพร้อมกัน

เอาต์พุตจริง รูปแบบที่คาดได้จากสิ่งที่คำนวณไว้ข้างบน

  -P 1     ~900 Mbps    ใช้ลิงก์เดียว
  -P 8    ~3.4 Gbps     กระจายได้ แต่ไม่ถึงสี่เท่าพอดี

อ่านอย่างไร นี่ไม่ใช่ความผิดพลาด แต่คือพฤติกรรมที่ออกแบบไว้ การเชื่อมต่อ เดียวไปลงลิงก์เดียวเสมอ เพราะแฮชของมันเป็นค่าคงที่ ถ้างานหลักขององค์กรคือ การย้ายไฟล์ก้อนเดียวใหญ่ ๆ การรวมลิงก์แก้ปัญหาให้ไม่ได้เลย ต้องซื้อ พอร์ตที่เร็วกว่าแทน

สิ่งที่ยังไม่ได้พิสูจน์ ตัวเลข -P 8 ที่ไม่ถึงสี่เท่าอาจมาจากการแฮชที่ ลงไม่ครบทุกลิงก์ หรืออาจติดคอขวดที่ดิสก์ ที่ซีพียู หรือที่หน้าต่าง TCP ตามที่ TCP และ UDP อธิบายไว้ ต้องแยกวัดทีละอย่าง

กรณีที่ 3 — ลิงก์ไม่ขึ้นเลย ทั้งที่ตั้งค่าครบ

สถานการณ์ ตั้งค่ารวมลิงก์ทั้งสองฝั่งแล้ว แต่กลุ่มไม่เกิด ไม่มีข้อความ ผิดพลาดใด ๆ

อ่านอย่างไร ไล่ตามลำดับนี้ ข้อละหนึ่งคำถาม

  1  สองฝั่งเป็น passive ทั้งคู่หรือเปล่า
  2  ความเร็วและ duplex ของทุกพอร์ตในกลุ่มตรงกันไหม
  3  พอร์ตอยู่ VLAN เดียวกันและเป็นชนิดเดียวกันไหม
  4  ฝั่งหนึ่งใช้ LACP อีกฝั่งใช้ PAgP หรือ mode on หรือเปล่า

ข้อแรกคือข้อที่เจอบ่อยที่สุดและมองไม่เห็นที่สุด เพราะทุกอย่างดู "เปิดอยู่" ทั้งสองฝั่ง แต่ไม่มีใครเริ่มพูด

สิ่งที่ยังไม่ได้พิสูจน์ สี่ข้อนี้ครอบคลุมสาเหตุที่พบบ่อย แต่ไม่ครบทุก สาเหตุ อุปกรณ์บางรุ่นมีข้อจำกัดว่าพอร์ตที่รวมกันได้ต้องอยู่ในชิปเดียวกัน หรือจำกัดจำนวนกลุ่มต่อเครื่อง ซึ่งไม่มีทางเดาได้จากภายนอก ต้องอ่านคู่มือรุ่น

กรณีที่ 4 — ลิงก์เต็มทั้งที่กราฟบอกว่าใช้ไปครึ่งเดียว

สถานการณ์ กราฟรวมของกลุ่มบอกว่าใช้แบนด์วิดท์ไป 50% แต่ผู้ใช้บอกว่าช้า และมีแพ็กเก็ตตก

อ่านอย่างไร กราฟรวมคือค่าเฉลี่ยของทุกลิงก์ ซึ่งซ่อนความจริงว่าลิงก์เดียว เต็ม 100% ขณะที่อีกสามลิงก์ว่าง จากตัวเลขที่วัดไว้ข้างบน สี่ลิงก์ที่มีโฟลว์ ใหญ่ไม่กี่ก้อนให้ค่า 0.5% / 52.1% / 46.7% / 0.6% ซึ่งเฉลี่ยแล้วดูเหมือน ใช้ไปครึ่งเดียวพอดี ต้องดูกราฟรายลิงก์เสมอ ค่าเฉลี่ยของกลุ่มไม่มีความหมาย

สิ่งที่ยังไม่ได้พิสูจน์ เห็นว่าลิงก์ไม่สมดุล ยังไม่รู้ว่าเปลี่ยนวิธีแฮช แล้วจะดีขึ้นไหม ถ้าปัญหาคือโฟลว์ใหญ่ไม่กี่ก้อน การเปลี่ยนจาก layer2 เป็น layer3+4 อาจไม่ช่วยอะไรเลย เพราะก้อนใหญ่ก้อนเดิมก็ยังเป็นก้อนเดียวอยู่ดี

เมื่อการรวมลิงก์ไม่พอ

การรวมลิงก์ทำงานระหว่างอุปกรณ์สองตัว ถ้าสวิตช์ตัวที่ปลายทางเสียทั้งตัว กลุ่มก็หายไปทั้งกลุ่ม การแก้คือรวมลิงก์ข้ามสวิตช์สองตัวที่ทำตัวเสมือนเป็น ตัวเดียว ซึ่งแต่ละยี่ห้อเรียกคนละชื่อและใช้ข้ามยี่ห้อไม่ได้ — เป็นสถานการณ์ เดียวกับปี 1997 ที่ทำให้เกิดมาตรฐานนี้ขึ้นมาตั้งแต่แรก

และถ้างานจริงคือการย้ายข้อมูลก้อนใหญ่ก้อนเดียวให้เร็วขึ้น คำตอบไม่ใช่การ รวมลิงก์ แต่คือพอร์ตที่เร็วกว่า

อ้างอิง

มาตรฐานและเอกสารต้นทาง

• IEEE 802.3ad Link Aggregation Task Force หน้าที่บันทึกว่ามาตรฐานผ่านเมื่อมีนาคม 2000
• IEEE 802.3 Trunking Study Group ที่มาของโครงการ และวันที่อนุมัติ PAR เมื่อมิถุนายน 1998
• สไลด์แนะนำ 11 พฤศจิกายน 1997 ทั้งชุด รวมถึง "Trunking: The Case for In-Band Protocols" ที่ยกมาอ้าง ในบทความนี้
• RFC 7424 อธิบายการกระจาย ทราฟฟิกด้วยแฮชและเงื่อนไขที่ทำให้มันไม่สมดุล

การนำไปใช้จริงที่อ่านซอร์สได้

• drivers/net/bonding/bond_3ad.c ค่าคงที่เวลาและที่อยู่ปลายทางของ LACPDU มาจากไฟล์นี้
• include/net/bond_3ad.h โครง LACPDU ที่ใช้นับออฟเซ็ตในบทความนี้
• เอกสาร bonding ของ Linux สูตรแฮชทุกแบบและคำเตือนเรื่องการเชื่อมต่อเดียว

คู่มือ

• man ifconfig บน macOS หัวข้อ bonddev และ bondmode

อ่านหน้านี้เป็นภาษาอังกฤษ

← กลับไปหน้าความรู้พื้นฐาน