cuibapvodanh
Member
CHR k liên quan tới ổ cứng nào cả. Cứ cài bản CHR rồi nhập tk và mk có mua license rồi kích hoạt là xong. ( cài lại thì transfer key từ cái cũ qua cái mới) tầm 20s là xong
thảo luận Cộng đồng người dùng MikroTik Router
- Thread starter tuanreb
- Start date
Doraemon309
Senior Member
Promox, VMware đều là máy ảo mà anh? Lấy dung lượng từ ổ SSD thật để cài mà anh?
wuhoatu
Senior Member
clean trong diskpart luôn rồi dùng img ghi ra USB xong cài lại, license còn nguyên, trong khi 1 cái thì mất.Thím format cài lại thì 100% mất license, chỉ có restore từ cái image trước đó có license mới không bị mất license. Còn chuyển boot UEFI sang LEGACY "ĐÚNG" sẽ không mất license. Nghe thím nói format xong cài lại mà có license thấy sai sai
Restore là trước đó mình backup lại nguyên SSD (kiểu dùng paragon partition backup) rồi restore ah bác?
wuhoatu
Senior Member
Mình thấy trên GitHub có topic nghiên cứu decode license của Mik. Ko biết có thím tây lông hay tung cửa nào nghiên cứu ra cách encode ra license chưa nhỉ 
github.com
GitHub - Ygnecz/MTLic: Mikrotik license file structure
Mikrotik license file structure. Contribute to Ygnecz/MTLic development by creating an account on GitHub.
github.com
wuhoatu
Senior Member
Mình có khoảng 25 client ra internet qua 2 đường WAN dạng dhcp-client, mỗi đường 100M và chạy dưới dạng bonding. Mình thắc mắc nếu dùng LB PPC thay cho bonding thì 1 client có ra internet đc 200M ko?
LB thì rõ rồi, nhưng với LB PPC thì mình còn lăn tăn chỗ này. VD: có 2 WAN 10G và 5G, nếu PPC chia local connection làm 3 thì tổng local connection sẽ đúng bằng đầu ra là 15G, nó tương tự như cách lý giải bonding balance-alb của Mik.
Như vậy, CÁC client trong LAN sẽ được Mik chỉ đường cho đi WAN nào sao cho tổng đầu ra đạt max các WAN (15G). nhưng nếu chỉ có 1 client thì liệu client đó có ra internet max 15G không hay chỉ ra đc 10G? Nếu đc thì script PPC như thế nào?
LB thì rõ rồi, nhưng với LB PPC thì mình còn lăn tăn chỗ này. VD: có 2 WAN 10G và 5G, nếu PPC chia local connection làm 3 thì tổng local connection sẽ đúng bằng đầu ra là 15G, nó tương tự như cách lý giải bonding balance-alb của Mik.
Như vậy, CÁC client trong LAN sẽ được Mik chỉ đường cho đi WAN nào sao cho tổng đầu ra đạt max các WAN (15G). nhưng nếu chỉ có 1 client thì liệu client đó có ra internet max 15G không hay chỉ ra đc 10G? Nếu đc thì script PPC như thế nào?
Last edited:
CGGX_ANNX
Senior Member
Mình thấy trên GitHub có topic nghiên cứu decode license của Mik. Ko biết có thím tây lông hay tung cửa nào nghiên cứu ra cách encode ra license chưa nhỉ
GitHub - Ygnecz/MTLic: Mikrotik license file structure
Mikrotik license file structure. Contribute to Ygnecz/MTLic development by creating an account on GitHub.
Chắc không ăn thua đâu bác ạ. Đọc ở đoạn giữa có signature dùng Elliptic curve 25519. Mình chỉ có cái public key của MikroTik thì check được license có valid không. Còn muôn tạo license thì phải có cái private key của họ để còn sign. Mà cái này thì chắc chắn không mò ra được rồi
.
wuhoatu
Senior Member
cứ /system package check update check-for-update thôi
Doraemon309
Senior Member
Của anh ấy lòng term anh phải chuyển từ lòng term sáng stable mới được ạ!
tml3nr
Senior Member
wuhoatu
Senior Member
Code:
#channel: stable
# long-term
# testing
# development
:global chkChannel "stable"
/system package update set channel=$chkChannel
:global insVer [/system package update get installed-version]
:global newVer [/system package update get latest-version]
:if (" $newVer" = " ") do={
:log warning "There no $chkChannel version!"
} else={
:if ($newVer = $insVer) do={
:log warning "System is already up to date!"
} else={
/system package update download
:execute {/system reboot}
}
}CGGX_ANNX
Senior Member
Theo em biết thì thiết bị di động ngày nay nó random đia chỉ MAC nhưng là random mỗi khi nối vào một mạng WiFi mới. Còn khi nối lại mạng đã nhớ sẵn thì nó sẽ sử dụng cái địa chỉ MAC random đã tạo lần đầu nối vào mạng này. Tức là dù không phải là địa chỉ MAC gốc thực của thiết bị, nhưng mạng của bác sẽ vẫn nhận ra được thiết bị này.
Với iOS thì địa chỉ MAC gán với một mạng WiFi này sẽ thay đổi nếu bác factory reset hoặc reset toàn bộ thiết lập mạng. Với các bản iOS mới gần đây thì nếu lâu quá (6 tuần) không dùng mạng WiFi đó thì nó cũng sẽ tạo địa chỉ MAC mới khi lần sau quay lại. Nếu dùng tính năng Forget Network rồi nối lại ngay thì nó vẫn dùng địa chỉ MAC cũ. Nó chỉ đổi sang địa chỉ random mới nếu bác Forget Network rồi đợi 2 tuần sau mới add lại. Thông tin chi tiết Use private Wi-Fi addresses on iPhone, iPad, iPod touch, and Apple Watch - Apple Support (https://support.apple.com/en-us/102509).
Bên Android thì mặc định địa chỉ random là loại persistent, tức là với cùng 1 SSID và cùng 1 phương thức xác thực địa chỉ MAC sẽ không thay đổi. Forget Network rồi add lại vẫn vậy (không có thời gian như iOS). Phải factory reset mới đổi được địa chỉ MAC random ứng với mạng WiFi này khi dùng loại persistent randomization mặc định này. Từ Android 12 thì có thêm sự lựa chọn dùng Non-persistent randomization. Ở chế độ này thì 4 tiếng sau khi ngắt mạng mà nối lại, hoặc nối lại mà đã quá 24h kể từ lần tạo địa chỉ MAC trước, thì thiết bị sẽ tạo địa chỉ MAC mới cho mạng WiFi đang nối vào này. Chế độ mới này được áp dụng khi nối vào mạng WiFi Open (không pass) mà không có captive portal và một thiết lập phải đặt giá trị khác giá trị mặc định, hoặc khi ứng dụng kết nối WiFi yêu cầu, hoặc người dùng có thể bật Developer Mode lên, rồi bật setting tương ứng trong phần Developer Mode. Thông tin chi tiết: MAC Randomization Behavior | Android Open Source Project (https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior)
Như vậy bình thường ra mà nói thì với mạng WiFi nhà bác các thiết bị dù có bật chế độ random địa chỉ MAC thì cái địa chỉ MAC này nó vẫn coi như không thay đổi, khi thiết lập mạng WiFi của bác không thay đổi (không đổi tên SSID hay biện pháp xác thực). Ngay cả nếu người dùng Forget Network rồi nối ngay lại nó sẽ vẫn giữ địa chỉ MAC cũ. Ngoại lệ như ở trên, thì phải factory reset, hoặc nhiều tuần liền không kết nối (iOS), hoặc như bên Android là bật thiết lập trong Developer mode.
Tất nhiên, nếu đây là bác đang muốn kiểm soát thiết bị của con bác. Và con bác nó rành một chút về công nghệ, thì nó có thể làm trò với cái chính setting trong Developer mode kia và ngày nào thiết bị của nó cũng sẽ có một địa chỉ MAC mới. Bác muốn ngăn nó trong trường hợp này thì chỉ có cách, hơi mệt một chút là:
* Trên subnet liên quan (bridge hoặc vlan tương ứng) chuyển chế độ ARP sang "reply-only"
* DHCP cấp cho các thiết bị trong bảng này phải chỉnh hết sang static leases (điền từng entry bằng tay vào bảng Leases của DHCP Server).
* Sau đó phải vào bảng ARP (IP -> ARP) điền bằng tay một lần nữa các địa chỉ MAC được phép sử dụng cũng như địa chỉ IP tương ứng với chúng.
Khi này với cái subnet đã bật ARP = disabled này sẽ chỉ còn các thiết bị có địa chỉ MAC đã điền sẵn trong bảng ARP và trong bảng Lease của DHCP Server mới vào được mạng và mới được cấp IP. Thiết bị mới, hoặc thiết bị cũ có địa chỉ MAC mới sẽ phải chờ bác update nội dung các bảng.
Last edited:
junjie
Member
thank bác, quá chuẩn và quá chi tiết
CGGX_ANNX
Senior Member
Em vừa phải sửa lại cái hình chỗ ARP bác ạ
Tự dưng não bị chập lại tự sửa sang disabled (màu xanh trong hình cũ) nó là "reply-only" bác nhé.
CGGX_ANNX
Senior Member
Ý 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-portThí 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:
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).
Speedtest by Ookla - The Global Broadband Speed Test
Use Speedtest on all your devices with our free desktop and mobile apps.
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):
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)
Last edited:
wuhoatu
Senior Member
All clear. Thx U bác nhiều. Qua bài này của bác mới rõ tại sao mình config PCC đúng rồi mà speed ko tăng, vì mình ko xài download manager bao giờ.Ý 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).
Speedtest by Ookla - The Global Broadband Speed Test
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)
Sà bì chưởng
Junior Member
Mới cắm lại con nhà mạng cấp thì có ipv6 bạn ạ
Attachments
Van Huong
Đã tốn tiền
iPhone đúng k?
Tắt cái Private address đi là được. Bật nó là nó random Mac
via theNEXTvoz for iPhone
Similar threads
