Là yêu cầu của 2 n số cổng cho EtherChannel là một yêu cầu quan trọng hay chỉ là một đề xuất để đảm bảo, có lẽ, cân bằng tải thậm chí?
Đặc biệt, nếu chúng tôi thiết lập một nhóm EtherChannel với 8 cổng nhưng một trong số đó đã bị hỏng. 7 cổng còn lại sẽ vẫn hoạt động nhưng với cân bằng tải không đồng đều, hoặc 3 cổng sẽ được buộc thành độc lập để đảm bảo sức mạnh của hai nhóm?
Có phải nó được xử lý tương tự cho cả PAgP và LACP?
Câu trả lời:
Sức mạnh của 2 yêu cầu khác nhau tùy theo nhà cung cấp / phần cứng / phần mềm. Cisco đã (có) một sự kỳ thị khá xấu đối với họ với rất nhiều công tắc xúc tác trước đó có khả năng 10G. Vấn đề xảy ra với cách phần mềm băm (hoặc "cân bằng") dữ liệu qua nhiều cổng trong kênh cổng (đây là điều không thể biết về PAgP hoặc LACP).
Bài này làm một công việc tuyệt vời để đơn giản hóa vấn đề chi tiết tốt hơn. Điều này ngày nay ít liên quan hơn với các cải tiến phần cứng / phần mềm, nhưng một lần nữa, nó thay đổi - vì vậy chỉ cần kiểm tra các yêu cầu phần cứng của bạn và đảm bảo bạn không mua phần cứng cũ trở thành nạn nhân của vấn đề này.
http://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/
Là yêu cầu của 2n số cổng cho EtherChannel là một yêu cầu quan trọng hay chỉ là một đề xuất để đảm bảo, có lẽ, cân bằng tải thậm chí?
Hầu hết các nhà cung cấp không có yêu cầu như vậy. Đây là một quy ước thường được thảo luận dựa trên các giới hạn của hàm băm ba bit khi cân bằng tải. Cá nhân tôi không đồng ý với lập trường này, nhưng tôi sẽ nhận được điều đó sau khi trả lời câu hỏi của bạn.
Đặc biệt, nếu chúng tôi thiết lập một nhóm EtherChannel với 8 cổng nhưng một trong số đó đã bị hỏng. 7 cổng còn lại sẽ vẫn hoạt động nhưng với cân bằng tải không đồng đều, hoặc 3 cổng sẽ được buộc thành độc lập để đảm bảo sức mạnh của hai nhóm?
Thông thường, nếu bạn có 8 cổng trong một nhóm tổng hợp liên kết và một cổng bị hỏng, bảy cổng còn lại sẽ vẫn hoạt động. Vâng, tải sẽ có một chút mất cân bằng trong một ý nghĩa, nhưng một lần nữa, tôi sẽ nhận được điều đó trong một phút.
Có phải nó được xử lý tương tự cho cả PAgP và LACP?
Có, và tương tự với một nhóm LAG tĩnh.
Bây giờ theo quan điểm của tôi về lý do tại sao tôi không nắm giữ sức mạnh của hai "quy tắc ngón tay cái" khi nói đến tập hợp liên kết.
Để bắt đầu, bạn thực sự cần phải hiểu rằng không có tập hợp liên kết nào cân bằng việc sử dụng liên kết trên LAG . Rõ ràng có sự khác biệt trong phương pháp cân bằng tải được chọn, và một số tốt hơn so với các phương pháp khác (mặc dù không có cái nào là tốt nhất trong mọi tình huống).
Phương pháp cân bằng tải không cân bằng lưu lượng, thay vào đó nó cân bằng những gì bạn có thể xem là "dòng chảy". Dựa trên nền tảng, bạn có các tùy chọn để sử dụng các giá trị nguồn và / hoặc đích có thể bao gồm địa chỉ MAC, địa chỉ IP, số cổng, v.v. Những giá trị này sau đó được băm để xác định liên kết nào được chọn cho luồng cụ thể đó. Các khung có cùng bộ giá trị sẽ luôn nhận được cùng một hàm băm và được gán cho cùng một liên kết.
Không phải tất cả các luồng đều bằng nhau và điều này có nghĩa là không thể cân bằng việc sử dụng liên kết bằng các phương tiện này. Không lấy đi giá trị của LAG, vì nó thường làm rất tốt việc cân bằng việc sử dụng, nhưng bạn cần hiểu những hạn chế.
Một hoặc nhiều luồng trong số này có thể sử dụng toàn bộ liên kết của chúng trong LAG và bỏ đói các luồng khác được gán cho cùng một liên kết. Trong khi đó các liên kết khác đang được sử dụng.
Khi hầu hết mọi người nhìn vào các biểu đồ như những người trong bài đăng trên blog này hoặc tài liệu này của Cisco , họ thấy rằng lưu lượng truy cập không cân bằng. Theo nghĩa là một số liên kết nhận được nhiều luồng hơn các liên kết khác, điều này là đúng.
Quan điểm của tôi về các bảng này là một chút khác nhau. Đầu tiên, ngay cả với phân phối không cân bằng, khi bạn thêm liên kết, sẽ không bao giờ có bất kỳ điểm nào mà tỷ lệ lưu lượng được chỉ định trên một liên kết tăng lên; thay vì trong phần lớn các trường hợp tỷ lệ phần trăm giảm. Nói cách khác, không có thời gian để có một luồng có quyền truy cập vào băng thông, và trong nhiều trường hợp, nó sẽ có nhiều cơ hội hơn.
Thứ hai, nếu tôi nhìn vào biểu đồ này để quyết định giữa hai hoặc ba liên kết trong một LAG, trong tâm trí tôi, tôi thấy điều này như sau:
Cuối cùng, hãy xem xét những gì xảy ra nếu bạn mất một liên kết trong LAG. Đưa ra hai liên kết để bắt đầu, điều này sẽ giảm LAG của tôi xuống một liên kết. Nếu tôi bắt đầu với ba, tôi vẫn sẽ có hai trái.
Chắc chắn, dòng chảy cân bằng hấp dẫn những phần ám ảnh trong tính cách của tôi, nhưng điều này vẫn không phản ánh lưu lượng cân bằng. Bên cạnh đó, nhiều liên kết tốt hơn bất kỳ cách nào tôi nhìn vào nó.
Những gì tôi có thể nhớ lại (sửa tôi):
Etherchannel không tải cân bằng mỗi lần nói, đó là phân phối tải. Một EC có số lượng liên kết lẻ sẽ không phân phối tải giữa các liên kết một cách đồng đều - các liên kết được đánh số thấp hơn sẽ nhận được nhiều lưu lượng hơn. Lưu lượng sẽ tiếp tục chảy nếu các liên kết vật lý bị hỏng.
Lưu lượng được cân bằng bởi địa chỉ mac đích (theo mặc định). Tùy thuộc vào cấu trúc liên kết của bạn, điều này có thể dẫn đến các mẫu lưu lượng không mong muốn:
Nếu bạn có một máy chủ thư trên một công tắc có EC giữa các công tắc, tất cả các máy trạm trên công tắc ở phía bên kia của Etherchannel sẽ sử dụng cùng một liên kết để đến máy chủ thư .... nếu phần lớn lưu lượng truy cập của bạn là máy chủ thư, điều này không cung cấp cân bằng tải và chỉ một liên kết duy nhất trong Etherchannel được sử dụng cho máy chủ thư.
Điều này có thể giúp: https://supportforums.cisco.com/blog/150511/how-do-etherchannel-hash-alerskym-works-and-load-distribution-happen