08/06/2026
Port-Channel Loadbalance ที่ไม่ Balance 😅
Thanaris Field Note | EtherChannel Load-Balance Case
Port-channel มี 2 เส้น แต่ Traffic ใช้จริงเหมือนมีเส้นเดียว?
ผมไปเจอคำถามมาว่า
"Core Switch ทำ Port-channel ไป Firewall แบบ HA ใช้ LACP 2 เส้น
Link ขึ้นครบ ไม่มี CRC / FCS / physical error
แต่ traffic ขาออกกลับไปกองอยู่ที่ member link เส้นเดียว
อีกเส้นแทบไม่ได้ใช้
และเส้นที่ traffic สูงมี Total output drops / OutDiscards เพิ่มขึ้นเรื่อย ๆ
คำถามคือ อาการแบบนี้เกี่ยวกับ EtherChannel load-balance แบบ src-mac ได้ไหม?
แล้วถ้าเปลี่ยนเป็น src-dst-ip จะช่วยไหม?
ที่สำคัญ ถ้าเป็น Production และ command นี้เป็น global command ต้องระวังอะไรบ้าง?"
-----
จะมาตอบคำถามนี้กัน
เคสนี้เป็นอีกเคสที่มีโอกาสเจอได้ใน Production Network
โดยเฉพาะเวลาทำ Link Aggregation, EtherChannel หรือ Port-channel แล้วคาดหวังว่า traffic จะกระจายเท่า ๆ กันทุกเส้น
แต่พอดู graph จริง กลับเจอว่า link หนึ่ง traffic สูงมาก
อีก link หนึ่งแทบไม่ได้ใช้งาน
หนักกว่านั้นคือ
เส้นที่ traffic สูงเริ่มมี output drops หรือ OutDiscards เพิ่มขึ้น
ทั้งที่ใน Port-channel ยังมี member link อีกเส้นว่างอยู่
แต่ตรงนี้ต้องระวังนิดหนึ่ง
output drops หรือ OutDiscards ไม่ได้แปลว่าเกิดจาก hashing เสมอไป
มันอาจเกี่ยวกับ queue, buffer, microburst, oversubscription
หรือ traffic pattern บางประเภทได้เหมือนกัน
แต่ถ้าอาการคือ traffic skew ไป member link เดียวชัดเจน
และปัจจุบันใช้ load-balance แบบ src-mac
อันนี้ถือว่าน่าสงสัยมากครับ
คำถามคือ
ทำไมทำ Port-channel แล้ว
แต่ traffic ไม่ balance ตามที่คิด?
คำตอบสั้น ๆ คือ
เพราะ EtherChannel ไม่ได้ทำ load balance แบบ round-robin
มันไม่ได้ส่ง packet แรกออกเส้นที่ 1
packet ถัดไปออกเส้นที่ 2
แล้ววนไปเรื่อย ๆ แบบนั้น
แต่ EtherChannel จะใช้ hash algorithm
เพื่อเลือกว่าจะส่ง traffic ออก member link เส้นไหน
โดยพิจารณาจาก field ที่ platform นั้นรองรับและถูก configure ไว้
เช่น
- source MAC
- destination MAC
- source/destination MAC
- source IP
- destination IP
- source/destination IP
- หรือบาง platform อาจรองรับ Layer 4 port เพิ่มเติม
เหตุผลที่ต้องทำแบบนี้
เพราะต้องการรักษา packet ordering ของ flow เดียวกัน
ถ้า packet ใน flow เดียวกันถูกกระจายออกหลาย physical links แบบสุ่ม
มีโอกาสเกิด packet out-of-order
ซึ่งอาจกระทบ application หรือ TCP performance ได้
ดังนั้น EtherChannel จึงมัก balance แบบ flow-based
ไม่ใช่ packet-based
-----
Engineer Trap
กับดักที่เจอบ่อยคือ
เห็น Port-channel มี 2 links
แล้วคิดว่า bandwidth จะถูกหารครึ่งอัตโนมัติ เช่น
มี 2 x 10G
ก็คิดว่า traffic จะออก 10G แรกครึ่งหนึ่ง
และ 10G ที่สองอีกครึ่งหนึ่ง
แต่ในโลกจริงไม่ได้เป็นแบบนั้นเสมอไป
ถ้า hash input มีความหลากหลายมาก
traffic ก็มีโอกาสกระจายดี
แต่ถ้า hash input มีความหลากหลายน้อย
traffic ก็อาจไปกองที่ member link เดียวได้
ตัวอย่างเคส
สมมติ Core Switch ต่อ Port-channel ไป Firewall
Port-channel มี 2 member links
แต่ traffic ส่วนใหญ่ไปออก link เดียว
อีก link หนึ่งใช้งานน้อยมาก
ตรวจ configuration แล้วพบว่า
EtherChannel load-balance ถูกตั้งเป็น src-mac
คำถามคือ src-mac ทำให้ traffic skew ได้ไหม?
คำตอบคือ ได้
และเป็นจุดที่ควรสงสัยมากในเคสที่เป็น routed traffic
เพราะ traffic ที่วิ่งจาก Core ไป Firewall
โดยเฉพาะ traffic ที่ผ่าน SVI, gateway, routing boundary หรือ firewall edge
ค่า source MAC อาจไม่ได้หลากหลายอย่างที่คิด
หลาย flow อาจใช้ source MAC เดิม ๆ เช่น
- MAC ของ SVI
- MAC ของ routed interface / SVI บน Core Switch
- MAC ของ gateway
- หรือ virtual MAC ของ FHRP บางรูปแบบ
เมื่อ source MAC ซ้ำกันมาก
hash result ก็มีโอกาสเลือก member link เดิมซ้ำ ๆ
ผลคือ
Port-channel ดูเหมือนมีหลายเส้น
แต่ traffic จริงอาจไปกองอยู่ที่เส้นเดียว
-----
แล้วเปลี่ยนเป็น src-dst-ip ช่วยไหม?
ในเคสที่ traffic ส่วนใหญ่เป็น routed traffic
เช่น Core ไป Firewall, Internet, SD-WAN, Data Center หรือหลาย subnet
การใช้ src-dst-ip มักมีโอกาสเหมาะกว่า src-mac
เพราะ source IP และ destination IP มักมีความหลากหลายกว่า MAC address
เมื่อ hash มี input ที่หลากหลายขึ้น
โอกาสกระจาย flow ข้าม member links ก็ดีขึ้น
แต่ต้องพูดให้ชัด
src-dst-ip ไม่ได้ guarantee ว่าจะได้ 50/50
เพราะถ้ามี elephant flow ใหญ่ ๆ เช่น backup, replication, large file transfer, tunnel, NAT session, storage traffic
หรือ traffic จำนวนมากไป destination เดียวกัน
ก็ยังมีโอกาสที่ traffic จะไปออก link เดียวได้อยู่
EtherChannel ไม่ได้มองว่า link ไหนว่างกว่าแล้วเลือกเส้นนั้นเสมอ
แต่มันเลือกตาม hash result ของ flow
นี่คือจุดที่หลายคนเข้าใจผิด
สิ่งที่ต้องระวัง
การเปลี่ยน load-balance method บน Catalyst หลายรุ่น
เป็น global command
หมายความว่าไม่ได้มีผลเฉพาะ Port-channel ไป Firewall เท่านั้น
แต่มีผลกับ Port-channel อื่น ๆ บน switch ตัวนั้นด้วย
เช่น
Port-channel ไป Distribution Switch
Port-channel ไป Access Switch
Port-channel ไป Firewall
Port-channel ไป SD-WAN
Port-channel ไป WLC
Port-channel ไป Server / UCS / Hypervisor
Port-channel ไป Storage หรือ Backup Network
ดังนั้นห้ามมอง change นี้เป็นแค่การแก้ link ไป Firewall เส้นเดียว
ต้องมองเป็น Production Change ที่มีผลกับ forwarding behavior ของหลาย Port-channel
-----
ก่อนเปลี่ยนควรเก็บอะไร?
ก่อนเปลี่ยน ผมแนะนำให้เก็บ baseline ก่อนเสมอ
อย่างน้อยควรดูข้อมูลเหล่านี้
show etherchannel load-balance
show etherchannel summary
show interfaces port-channel x
show interfaces member-link
show interfaces counters errors
ดู utilization ของแต่ละ member link
ดู output drops
ดู OutDiscards
ดู queue drops ถ้า platform รองรับ
ดู physical errors เช่น CRC, input errors, output errors
ถ้ามี NetFlow, telemetry, SNMP graph หรือ firewall log
ควรดู top talker / top flow เพิ่มด้วย
เพราะถ้าปัญหาเกิดจาก elephant flow ใหญ่ flow เดียว
การเปลี่ยน hash algorithm อาจไม่ได้ช่วยมากเท่าที่คาด
แต่ถ้า traffic มีหลาย source/destination IP
แต่ hash เดิมใช้ src-mac แล้วทำให้ skew
การเปลี่ยนไป src-dst-ip ก็มีโอกาสช่วยได้มากกว่า
ถ้า platform รองรับ
ควรใช้คำสั่งทดสอบ hash ประกอบด้วย
เช่นแนวทาง
test etherchannel load-balance interface port-channel x ip source-ip destination-ip
คำสั่งนี้ช่วยดูว่า flow ที่สนใจ
จะถูก hash ไปออก member link ไหน
แต่ syntax จริงอาจต่างกันตาม platform และ software version
จึงควรตรวจสอบ command reference ของรุ่นที่ใช้งานจริงอีกครั้ง
-----
ตอนเปลี่ยนกระทบ traffic ไหม?
โดยหลักการ
การเปลี่ยน EtherChannel load-balance method
ไม่ใช่การ shutdown interface
ไม่ใช่การลบ Port-channel
และไม่ควรทำให้ LACP down โดยตรง
แต่ใน Production
ยังควรทำใน maintenance window หรือช่วง traffic ต่ำ
เพราะหลังเปลี่ยน hash method
flow distribution อาจเปลี่ยน
output queue อาจเปลี่ยน
member link ที่เคยว่างอาจเริ่มรับ traffic มากขึ้น
และ Port-channel อื่น ๆ บน switch อาจได้รับผลด้วย
โดยเฉพาะ environment ที่มี traffic ใหญ่ ๆ เช่น
- backup
- replication
- storage
- server farm
- UCS / Hypervisor
- WLC / CAPWAP
- SD-WAN tunnel
- Firewall HA
กลุ่มพวกนี้ควร monitor ใกล้ชิดหลังเปลี่ยน
หลังเปลี่ยนต้อง monitor อะไร?
หลัง change อย่าดูแค่ว่า Port-channel ยัง up อยู่
ต้องดูว่า behavior ดีขึ้นจริงไหม
สิ่งที่ควรดูคือ
- traffic rate ต่อ member link
- packet rate ต่อ member link
- output drops
- OutDiscards
- queue drops
- latency
- packet loss
- firewall session
- SD-WAN tunnel health
- WLC / AP / CAPWAP status
- server หรือ storage performance
ถ้า traffic กระจายดีขึ้น
แต่ output drops ยังเพิ่ม
อาจแปลว่าปัญหาไม่ได้มีแค่ hash algorithm
อาจเป็นเรื่อง microburst, queue, buffer, oversubscription หรือ traffic pattern บางประเภท
-----
Thanaris Takeaway
Port-channel ไม่ได้แปลว่า traffic จะหารเท่ากันทุกเส้นเสมอไป
EtherChannel ใช้ hashing
ไม่ใช่ round-robin
ถ้า hash input มี entropy ต่ำ
หรือพูดง่าย ๆ คือ ค่าที่เอาไปคำนวณ hash ไม่ค่อยหลากหลาย
traffic ก็มีโอกาสไปกองที่ member link เดียว
สำหรับ routed traffic
การใช้ src-dst-ip มักมีโอกาสเหมาะกว่า src-mac
เพราะ IP address มักหลากหลายกว่า MAC address
แต่ src-dst-ip ก็ไม่ได้ guarantee 50/50
ถ้ามี elephant flow หรือ traffic pattern แคบ
ก็ยัง skew ได้อยู่
และที่สำคัญ
คำสั่ง load-balance บนหลาย Catalyst platform เป็น global command
ดังนั้นก่อนเปลี่ยนต้องมี baseline
มี change window
มี rollback plan
และมี monitoring หลังเปลี่ยน
-----
สรุปง่าย ๆ เลยครับ
อย่าดูแค่ว่า Port-channel up/up
ให้ดูด้วยว่า
- traffic กระจายจริงไหม
- member link ไหนมี drop
- hash algorithm ใช้อะไร
- traffic pattern เป็นแบบไหน
- และ change นี้กระทบ Port-channel อื่นหรือไม่
นี่แหละครับ
ความต่างระหว่างการ “ทำ Port-channel ให้ติด”
กับการ “เข้าใจว่า Port-channel ส่ง traffic ยังไงใน Production”
จบบริบูรณ์ครับ 😄
Reference:
Cisco - Understand EtherChannel Load Balance and Redundancy on Catalyst Switches
Cisco - Configuring IEEE 802.3ad Link Bundling and Load Balancing
Cisco - Catalyst EtherChannel Configuration Guide / Command Reference
