Ý bác là PCC (per connection classifier) chứ không phải PPC đúng không ạ? Theo tên gọi của nó, thì cách load balancing này chia (classify) dùng bảng route nào (tức là coi như dùng đường WAN nào nếu mỗi bảng route bác chọn 1 WAN là default route) theo từng kết nối một (per connection). Một "connection" TCP hay UDP thường được nhận dạng bằng bộ tứ
cổng nguồn-địa chỉ nguồn-cổng đích-địa chỉ đích. 2 packets mà khớp nhau 4 cái này thì coi như thuộc cùng 1 connection, lệch một trong 4 cái là thuộc 2 connection khác nhau.
Như vậy với PCC và chỉ một thiết bị (1 client) bác sẽ vẫn tận dụng được việc phân kết nối ra nhiều đường WAN (bảng route) đồng thời. Vì tuy chỉ có 1 client tức là nếu gửi packet đi thì sẽ chỉ có 1 source address, nhưng nếu client đồng thời nối vào nhiều host khác nhau thì đã là có nhiều destination address khác nhau rồi và nhiều connection rồi. Hay gửi vào cùng 1 địa chỉ đích, nhưng nhiều cổng đích khác nhau cũng là các kết nối khác nhau. Hoặc cùng server và cổng bên kia là 1, nhưng trên máy của bác chọn nhiều cổng khác nhau là sẽ tạo được nhiều kết nối đồng thời. Khi bác download bằng download manager chẳng hạn là như vậy. Phía đầu kia chỉ có địa chỉ IP và 1 cổng, thí dụ 443. Nhưng download manager của bác sẽ dùng nhiều cổng ở trên máy bác để tạo nhiều kết nối đồng thời.
PCC trên RouterOS hoạt động là từ các thông tin của 1 kết nối, sẽ tính ra 1 số hash (một số nguyên 32bit thôi) sau đó, thí dụ bác có 3 bảng route (3 WAN) bác sẽ bảo (bằng rule mangle) RouterOS
chia số này cho 3 chẳng hạn, sau đó
lấy số dư, nếu dư 0 thì cho routing vào bảng A, nếu dư 1 thì vào bảng B, dư 2 thì vào bảng C. Như thế nếu có nhiều kết nối đồng thời, và số hash của các kết nối phân bố khá đồng đều (thí dụ không phải chỉ ra toàn số chẵn chẳng hạn) thì coi như các kết nối đó sẽ được chia đều ra các bảng route.
Vì sao lại chia theo kết nối, vì bác không muốn các packet của cùng 1 kết nối, cái thì đi theo route A, cái thì đi theo route B, cái thì C, như thế bên server sẽ không nhận được chúng là cùng thuộc 1 kết nối, vì đi ra đường nào thì sau khi masquerade (NAT) địa chỉ nguồn của packet đã bị sửa thành địa chỉ của interface WAN. Nếu các packet của 1 connection không đi qua cùng 1 đường thì server đích sẽ thấy chúng đến từ các source khác nhau và không thuộc cùng 1 connection.
Bác có thể chọn cho RouterOS lấy thông tin gì của packet để tính số hash. Có:
Code:
both-addresses
both-ports
dst-address-and-port
src-address
src-port
both-addresses-and-ports
dst-address
dst-port
src-address-and-port
Thí dụ nếu chọn mỗi src-address thì tất cả các kết nối từ cùng 1 client sẽ cùng 1 số hash và chỉ đi qua 1 đường. Như vậy 1 client không load balance được gì. Cần nhiều thiết bị trong LAN mới tận dụng được các đường WAN. Nếu chọn mỗi dst-port chẳng hạn, thì tất cả các kết nối HTTPS, dù từ client nào đến server nào cũng sẽ chỉ ra 1 số hash và chỉ đi qua 1 đường. Tương tự nếu chọn dst-address thì lúc này coi như load balance dựa theo server đích. Tất cả kết nối đến cùng 1 server sẽ đi qua 1 đường.
Ngược lại chọn cái both-addresses-and-ports thì cả 4 tham số của kết nối đều tham gia vào việc tính hash. Như vậy nếu bác download gì đó bằng download manager thì dù chỉ down từ 1 server tới 1 thiết bị có thể đã đủ để các connection mà download manager tạo ra chạy qua các routes khác nhau, coi như tận dụng được hết tất cả các đường WAN một lúc.
Tuy nhiên nhiều ứng dụng hay trang web, thí dụ online banking sẽ không hề thích điều này. Vì khi nối vào server của ngân hàng, dù chỉ là 1 site, nhưng có thể 2 request của bác cách nhau vài giây dùng 2 kết nối khác nhau, với 2 source port khác nhau. Như thế có thể đủ để ngân hàng nhìn thấy 2 kết nối đến từ 2 địa chỉ IP khác nhau cho cùng 1 tài khoản rồi (2 đường WAN khác nhau) và có thể block/ban bác ngay tức thì. Với trường hợp này thì bác nên chọn both-addresses thôi, như vậy với 1 server ngân hàng và 1 client trong LAN sẽ chỉ ra 1 hash và dùng 1 route. Hoặc dst-address-and-port cũng được, như thế mọi kết nối đến server ngân hàng sẽ chỉ dùng 1 route. Tất nhiên nếu trang web không chỉ có mỗi HTML mà còn các resources như script, hình ảnh, v.v... host ở nhiều nơi khác nhau thì những cái này vẫn có thể được download qua nhiều route (WAN) khác nhau.
Còn nếu cùng 1 lúc 1 client kia chỉ tạo 1 đường truyền thực sự cần truyền lưu lượng lớn (download gì đó to mà không dùng download manager), thì do chỉ có 1 connection sẽ chỉ có 1 đường WAN phải chịu tải các đường còn lại ngồi chơi và bị bỏ phí.
Đây để minh họa em vừa quay đường FPT nhà em lên 3 phát (nhưng vẫn chỉ 1 đường vật lý thật) và cấu hình PCC với
both-addresses-and-ports. Speedtest với chỉ 1 server của FPT Hà Nội thôi. Ở chế độ Multi thì browser sẽ tạo nhiều kết nối đồng thời, tức là bên em có nhiều source port và như bác thấy ở đây, PCC chia tải ra cả 3 đường PPPoE:
View attachment 2475559
Tốc độ lên được gần 2.2Gbps (giới hạn của GPON là 2.488Gbps, trừ thêm overhead của các loại protocol thì thường tầm 2.3Gbps gì đó là max tốc độ của payload, kiểu đường 1G thì ra tầm gần 940Mbps vậy), mặc dù thường ngày với cái test server FPT Hà nội này chỉ giới hạn ở 1060Mbps. Như vậy là với 1 client (1 PC 1 browser), và 1 remote server (FPT HN) em đã dùng được nhiều hơn giới hạn của 1 line thường ngày (không được 3x vì giới hạn của GPON và đường truyền mà cả 3 cái WAN cùng share).
Use Speedtest on all your devices with our free desktop and mobile apps.
www.speedtest.net
Khi chuyển sang chế độ test Single thì chỉ có 1 connection thực sự down/upload. Nên chỉ có 1 đường pppoe-out2 là chịu tải (các đường còn lại chỉ vài trăm kbps do các kết nối không liên quan khác sử dụng):
View attachment 2475561
Và tốc độ speedtest chỉ còn 1Gbps.
Vì cách tính theo hash này không hề biết 1 kết nối sẽ gửi nhiều hay ít dữ liệu, cũng như với các tổ hợp cổng địa chỉ có thể thiên vị 1 route nào đó hơn. Nên ở đây không hẳn là "
cân bằng" tải. Như cái hình trên kia bác cũng có thể thấy là 3 đường chịu tải không đều. Có đường sẽ dính nhiều connection hơn, hoặc nhiều connection nặng hơn các đường còn lại. Ngoài ra trong trường hợp bác có các đường với tốc độ giới hạn lệch nhau, như 1 đường 10G và 1 đường 5G như bác nói, thì lúc cấu hình bác không nên chọn số chia là 2 rồi số dư là 1 và 0. Mà bác nên chọn số chia là 3 chẳng hạn, rồi cho số dư 1 và 2 đều dùng route của đường 10G, và số dư 0 dùng route 5G. Như thế chia tải sẽ "cân bằng" hơn.
Để cấu hình PCC thì bác cứ làm theo tài liệu của MikroTik thôi ạ
Per connection classifier - RouterOS - MikroTik Documentation (https://help.mikrotik.com/docs/display/ROS/Per+connection+classifier)
Nôm na là dùng rule mangle mark-connection, rồi với connection được mark thì mark-routing. Quan trọng là mấy phần rule có per-connection-classifier=xxx chỗ bác chọn cái gì được dùng để tính hash cũng như số chia và số dư. 3/1 là "chia 3 dư 1" chẳng hạn.
Hoặc bác có thể dùng wizard của bác TranDucAnh.com rồi copy paste
TẠO SCRIPT TERMINAL PCC PPPOE MIKROTIK (https://mikrotik.tranducanh.com/lb.php)