Tweet
Chào anh em,
Hôm rồi ngồi review lại config của một con switch access, thấy đoạn này khá quen thuộc với ai từng làm việc trong phòng server ảo hóa:
interface GigabitEthernet1/0/5
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
!
interface GigabitEthernet1/0/6
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
!
interface GigabitEthernet1/0/7
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
!
interface GigabitEthernet1/0/8
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
4 port Gi1/0/5 đến Gi1/0/8 được gom lại thành Port-channel 12, cắm vào một server chạy VMware ESXi. Đây là kiểu config mình gặp rất nhiều lần khi đi hỗ trợ hạ tầng ảo hóa, nhưng cũng là chỗ dễ gây hiểu lầm nhất cho anh em mới bắt đầu đụng tới networking cho server, nên tranh thủ ngồi viết lại kỹ một chút, có gì anh em góp ý thêm.
1. Vì sao lại là mode on chứ không phải LACP?
Đa số anh em học CCNA/CCIE sẽ quen thuộc hơn với LACP (active/passive) vì đây là kiểu được dạy phổ biến nhất — có thương lượng đàng hoàng giữa 2 đầu, chuẩn IEEE 802.3ad. Nhưng khi ra thực tế, đụng tới server ESXi thì rất hay gặp channel-group X mode on, tức là Static EtherChannel. Kiểu này không có thương lượng gì cả — switch cứ đóng gói các port lại với nhau và mặc định tin rằng phía đầu kia (server) cũng đang bundle y hệt như vậy.
Lý do nằm ở cách con ESXi đó cấu hình NIC Teaming ở tầng vSwitch:
Cho nên, thấy mode on đi cùng với mô tả server ảo hóa như trong ví dụ trên thì gần như chắc chắn đội vận hành đang dùng vSS + "Route based on IP hash", chưa nâng cấp lên vDS.
Lưu ý quan trọng (và cũng là lỗi hay gặp nhất): hai đầu bắt buộc phải khớp cấu hình với nhau. Nếu phía switch làm Static EtherChannel nhưng phía ESXi lại chọn một policy teaming khác (ví dụ "Route based on originating port ID" hoặc "Route based on source MAC hash") thì các port vẫn lên up/up hoàn toàn bình thường — nhìn vào tưởng mọi thứ ổn — nhưng thực chất đang có sự lệch pha nghiêm trọng giữa 2 đầu. Hậu quả thường gặp: duplicate frame, mất gói ngẫu nhiên, thậm chí là loop L2 mà cực kỳ khó xác định nguyên nhân nếu không biết để ý ngay từ chỗ này.
2. Traffic thực sự chạy như thế nào?
Đây là phần mình thấy nhiều anh em hiểu sai nhất, kể cả bản thân mình hồi mới ra trường cũng từng nghĩ vậy: cứ tưởng 4 port gộp lại thành Port-channel thì traffic sẽ tự động được rải đều ra, gói này đi cổng 5, gói kia đi cổng 6, tổng cộng lại thành băng thông 4Gbps.
Không phải như vậy.
EtherChannel chia traffic theo flow, chứ không phải theo từng gói tin riêng lẻ (per-packet). Một flow ở đây được hiểu là một phiên giao tiếp, được xác định thông qua kết quả hash của một số trường thông tin trong gói tin. Và một khi đã xác định được flow đi qua port vật lý nào, thì toàn bộ traffic của phiên đó sẽ luôn đi qua đúng port vật lý ấy cho tới khi phiên kết thúc.
Cơ chế hash phía switch
Switch sẽ dựa vào tổ hợp một số trường để tính toán ra port nào trong Port-channel sẽ đảm nhiệm một flow cụ thể, các trường thường dùng gồm:
show etherchannel load-balance
Và có thể đổi thuật toán hash bằng:
port-channel load-balance src-dst-ip
Cơ chế hash phía ESXi
Ở phía ESXi, khi chọn policy "Route based on IP hash", con host cũng tự thực hiện một thuật toán hash dựa trên cặp IP nguồn - đích để quyết định traffic của một VM/session cụ thể sẽ được đẩy ra pNIC vật lý nào trong dàn NIC đã teaming.
Mấu chốt ở đây: logic hash của 2 bên (switch và ESXi) cần phải tương thích với nhau (thường khuyến nghị dùng src-dst-ip ở cả 2 phía) thì traffic mới được phân bổ đúng, và quan trọng hơn là đối xứng — traffic đi và về của cùng một phiên nên đi qua đúng cùng một cặp port, tránh tình trạng đi 1 đường về 1 nẻo gây khó khăn cho việc troubleshoot sau này.
Hệ quả thực tế mà anh em cần nắm
Khi cần xác minh trạng thái của Port-channel 12 trong ví dụ trên, anh em có thể dùng:
show etherchannel 12 summary
show etherchannel 12 port-channel
show etherchannel load-balance
show interfaces port-channel 12
show interfaces status | include Gi1/0/5|Gi1/0/6|Gi1/0/7|Gi1/0/8
Điều cần chú ý nhất là cột trạng thái của từng port thành viên trong output của show etherchannel summary:
4. Tổng kết
Việc cấu hình channel-group X mode on khi đấu nối với server ESXi không phải là do ai đó cấu hình tùy tiện hay thiếu chuẩn, mà thực chất là lựa chọn bắt buộc phải đi kèm với cách ESXi đang teaming NIC ở tầng Standard vSwitch. Còn về mặt vận hành, điều quan trọng nhất khi đi troubleshoot một Port-channel loại này không nằm ở việc "port có lên up/up hay không", mà nằm ở câu hỏi cốt lõi hơn:
Hai đầu (switch và ESXi) có đang áp dụng cùng một logic hash để phân bổ traffic hay không?
Rất nhiều trường hợp server bị chập chờn, mất gói tin ngẫu nhiên, hoặc có hiện tượng kỳ lạ về hiệu năng mạng dù switch báo tất cả các port đều up/up bình thường, thì nguyên nhân gốc rễ lại nằm chính xác ở sự lệch pha giữa 2 cấu hình này.
Anh em nào có kinh nghiệm troubleshoot các ca tương tự, hoặc có case thực tế về vụ lệch hash gây lỗi ngầm như trên, mời chia sẻ thêm cho anh em khác cùng học hỏi nhé.
Hôm rồi ngồi review lại config của một con switch access, thấy đoạn này khá quen thuộc với ai từng làm việc trong phòng server ảo hóa:
interface GigabitEthernet1/0/5
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
!
interface GigabitEthernet1/0/6
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
!
interface GigabitEthernet1/0/7
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
!
interface GigabitEthernet1/0/8
description "STAFF 5 - SV 12"
switchport access vlan 26
switchport mode access
channel-group 12 mode on
4 port Gi1/0/5 đến Gi1/0/8 được gom lại thành Port-channel 12, cắm vào một server chạy VMware ESXi. Đây là kiểu config mình gặp rất nhiều lần khi đi hỗ trợ hạ tầng ảo hóa, nhưng cũng là chỗ dễ gây hiểu lầm nhất cho anh em mới bắt đầu đụng tới networking cho server, nên tranh thủ ngồi viết lại kỹ một chút, có gì anh em góp ý thêm.
1. Vì sao lại là mode on chứ không phải LACP?
Đa số anh em học CCNA/CCIE sẽ quen thuộc hơn với LACP (active/passive) vì đây là kiểu được dạy phổ biến nhất — có thương lượng đàng hoàng giữa 2 đầu, chuẩn IEEE 802.3ad. Nhưng khi ra thực tế, đụng tới server ESXi thì rất hay gặp channel-group X mode on, tức là Static EtherChannel. Kiểu này không có thương lượng gì cả — switch cứ đóng gói các port lại với nhau và mặc định tin rằng phía đầu kia (server) cũng đang bundle y hệt như vậy.
Lý do nằm ở cách con ESXi đó cấu hình NIC Teaming ở tầng vSwitch:
- Nếu ESXi đang xài Standard vSwitch (vSS) với policy teaming là "Route based on IP hash" → bắt buộc phía switch phải làm Static EtherChannel (mode on), vì vSwitch chuẩn của ESXi hoàn toàn không hỗ trợ nói chuyện LACP.
- Chỉ khi nào hạ tầng được nâng cấp lên Distributed Switch (vDS) thì mới có thể bật LACP thật sự (active/passive) ở cả 2 đầu.
Cho nên, thấy mode on đi cùng với mô tả server ảo hóa như trong ví dụ trên thì gần như chắc chắn đội vận hành đang dùng vSS + "Route based on IP hash", chưa nâng cấp lên vDS.
Lưu ý quan trọng (và cũng là lỗi hay gặp nhất): hai đầu bắt buộc phải khớp cấu hình với nhau. Nếu phía switch làm Static EtherChannel nhưng phía ESXi lại chọn một policy teaming khác (ví dụ "Route based on originating port ID" hoặc "Route based on source MAC hash") thì các port vẫn lên up/up hoàn toàn bình thường — nhìn vào tưởng mọi thứ ổn — nhưng thực chất đang có sự lệch pha nghiêm trọng giữa 2 đầu. Hậu quả thường gặp: duplicate frame, mất gói ngẫu nhiên, thậm chí là loop L2 mà cực kỳ khó xác định nguyên nhân nếu không biết để ý ngay từ chỗ này.
2. Traffic thực sự chạy như thế nào?
Đây là phần mình thấy nhiều anh em hiểu sai nhất, kể cả bản thân mình hồi mới ra trường cũng từng nghĩ vậy: cứ tưởng 4 port gộp lại thành Port-channel thì traffic sẽ tự động được rải đều ra, gói này đi cổng 5, gói kia đi cổng 6, tổng cộng lại thành băng thông 4Gbps.
Không phải như vậy.
EtherChannel chia traffic theo flow, chứ không phải theo từng gói tin riêng lẻ (per-packet). Một flow ở đây được hiểu là một phiên giao tiếp, được xác định thông qua kết quả hash của một số trường thông tin trong gói tin. Và một khi đã xác định được flow đi qua port vật lý nào, thì toàn bộ traffic của phiên đó sẽ luôn đi qua đúng port vật lý ấy cho tới khi phiên kết thúc.
Cơ chế hash phía switch
Switch sẽ dựa vào tổ hợp một số trường để tính toán ra port nào trong Port-channel sẽ đảm nhiệm một flow cụ thể, các trường thường dùng gồm:
- Source MAC / Destination MAC
- Source IP / Destination IP
- Source Port / Destination Port (Layer 4, nếu switch hỗ trợ hash sâu tới tầng này)
show etherchannel load-balance
Và có thể đổi thuật toán hash bằng:
port-channel load-balance src-dst-ip
Cơ chế hash phía ESXi
Ở phía ESXi, khi chọn policy "Route based on IP hash", con host cũng tự thực hiện một thuật toán hash dựa trên cặp IP nguồn - đích để quyết định traffic của một VM/session cụ thể sẽ được đẩy ra pNIC vật lý nào trong dàn NIC đã teaming.
Mấu chốt ở đây: logic hash của 2 bên (switch và ESXi) cần phải tương thích với nhau (thường khuyến nghị dùng src-dst-ip ở cả 2 phía) thì traffic mới được phân bổ đúng, và quan trọng hơn là đối xứng — traffic đi và về của cùng một phiên nên đi qua đúng cùng một cặp port, tránh tình trạng đi 1 đường về 1 nẻo gây khó khăn cho việc troubleshoot sau này.
Hệ quả thực tế mà anh em cần nắm
- Một VM giao tiếp với một server khác, dù Port-channel có tổng cộng 4 port Gigabit, thì băng thông tối đa cho một session/kết nối đơn lẻ vẫn chỉ là 1Gbps — vì session đó chỉ đi qua đúng 1 port vật lý mà thôi, không được cộng dồn.
- Cái lợi thực sự của EtherChannel nằm ở 2 điểm:
- Tăng tổng thông lượng khi có nhiều flow khác nhau — nhiều VM, nhiều session cùng lúc thì mới thực sự tận dụng được băng thông tổng của cả 4 port.
- Redundancy — khi 1 trong 4 sợi dây bị đứt hoặc port bị down, các flow đang chạy trên port đó sẽ tự động được hash lại sang các port còn sống, server không bị gián đoạn hoàn toàn, chỉ có một vài session bị ảnh hưởng trong thời gian ngắn rồi tự phục hồi.
Khi cần xác minh trạng thái của Port-channel 12 trong ví dụ trên, anh em có thể dùng:
show etherchannel 12 summary
show etherchannel 12 port-channel
show etherchannel load-balance
show interfaces port-channel 12
show interfaces status | include Gi1/0/5|Gi1/0/6|Gi1/0/7|Gi1/0/8
Điều cần chú ý nhất là cột trạng thái của từng port thành viên trong output của show etherchannel summary:
- P (Bundled in port-channel) — port đã tham gia Port-channel thành công, đây là trạng thái mong muốn.
- I (Individual) — port chưa được bundle vào Port-channel, đang hoạt động độc lập. Đây là dấu hiệu có vấn đề, thường do VLAN không khớp giữa các port, chế độ access/trunk không đồng nhất, hoặc STP đang block port đó vì phát hiện bất thường.
4. Tổng kết
Việc cấu hình channel-group X mode on khi đấu nối với server ESXi không phải là do ai đó cấu hình tùy tiện hay thiếu chuẩn, mà thực chất là lựa chọn bắt buộc phải đi kèm với cách ESXi đang teaming NIC ở tầng Standard vSwitch. Còn về mặt vận hành, điều quan trọng nhất khi đi troubleshoot một Port-channel loại này không nằm ở việc "port có lên up/up hay không", mà nằm ở câu hỏi cốt lõi hơn:
Hai đầu (switch và ESXi) có đang áp dụng cùng một logic hash để phân bổ traffic hay không?
Rất nhiều trường hợp server bị chập chờn, mất gói tin ngẫu nhiên, hoặc có hiện tượng kỳ lạ về hiệu năng mạng dù switch báo tất cả các port đều up/up bình thường, thì nguyên nhân gốc rễ lại nằm chính xác ở sự lệch pha giữa 2 cấu hình này.
Anh em nào có kinh nghiệm troubleshoot các ca tương tự, hoặc có case thực tế về vụ lệch hash gây lỗi ngầm như trên, mời chia sẻ thêm cho anh em khác cùng học hỏi nhé.