thảo luận Cộng đồng người dùng MikroTik Router

Em đang có đăng ký một đường ILL của VNPT, giờ em muốn cấu hình nó chạy trên mikrotik thì cần những bước gì mấy thím
 
CGGX_ANNX said:
Nếu ISP của bác hỗ trợ MTU 1500 cho PPPoE (hiện đã có feedback của các trên này dùng cả 3 nhà mạng lớn đã đặt được MTU 1500, ít ra là khi dùng converter (cái G-97CM của FPT có hỗ trợ) hay module GPON SFP, còn có vẻ nếu chỉ bridge qua modem nhà mạng thì ít thành công hơn) thì bác đặt MTU của interface ethernet hoặc VLAN ngay dưới cái PPPoE là 1508 nhé (cần 1508 nếu không MSS bị chỉnh sai). Còn interface pppoe-outX thì để Max MRU = Max MTU = 1500. Với 7.15 trở lên chỉ cần sửa MTU=1508 cho cái interface ngay dưới cái PPPoE thôi. Tức là nếu dùng interface VLAN thì chỉ cần cái VLAN sửa 1508, cái etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN có thể để nguyên 1500 không quan trọng. Tuy nhiên nếu dùng 7.13.x-7.14.x thì lại có 1 cái bug, lúc này cái interface etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN bác cũng phải đặt MTU 1508.

Nếu ISP không hỗ trợ MTU 1500 cho PPPoE, hoặc bác bridge router nhà mạng và không được, thì không quan trọng thiết lập MTU của interface ethernet/vlan, cứ để 1500 mặc định là đủ.
Click to expand...
Từ xưa đến giờ em k có setup MTU vì để mặc định port eth 1500 thì pppoe tự nhận 1492 k vấn đề gì cả. Vài hôm trước bỗng dưng line VNPT của em nó rớt pppoe cả ngày, gọi trạm người ta nói có chỉnh (nhưng ko nói chỉnh gì), em phải chỉnh MTU của port eth về 1492 thì pppoe mới connect được và nhận 1484. Em có tìm hiểu thì có bác bảo cứ để 1492 cho chắc ăn nhưng từ đó giờ e toàn cho nó auto thôi, nên thắc mắc xíu
 
Min
CGGX_ANNX said:
Nếu ISP của bác hỗ trợ MTU 1500 cho PPPoE (hiện đã có feedback của các trên này dùng cả 3 nhà mạng lớn đã đặt được MTU 1500, ít ra là khi dùng converter (cái G-97CM của FPT có hỗ trợ) hay module GPON SFP, còn có vẻ nếu chỉ bridge qua modem nhà mạng thì ít thành công hơn) thì bác đặt MTU của interface ethernet hoặc VLAN ngay dưới cái PPPoE là 1508 nhé (cần 1508 nếu không MSS bị chỉnh sai). Còn interface pppoe-outX thì để Max MRU = Max MTU = 1500. Với 7.15 trở lên chỉ cần sửa MTU=1508 cho cái interface ngay dưới cái PPPoE thôi. Tức là nếu dùng interface VLAN thì chỉ cần cái VLAN sửa 1508, cái etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN có thể để nguyên 1500 không quan trọng. Tuy nhiên nếu dùng 7.13.x-7.14.x thì lại có 1 cái bug, lúc này cái interface etherX/sfpX/sfp-plusX/bridgeX dưới cái VLAN bác cũng phải đặt MTU 1508.

Nếu ISP không hỗ trợ MTU 1500 cho PPPoE, hoặc bác bridge router nhà mạng và không được, thì không quan trọng thiết lập MTU của interface ethernet/vlan, cứ để 1500 mặc định là đủ
Click to expand...
Minh đang xài a7 dùng sfp gpon. Nếu để mtu và mru là 1500 của pppoe(vlan để mtu 1508) thì actual mtu nhảy về 1480. Quay pppoe thì vẫn có ip và vào được mạng bằng ipv4 nhưng ipv6 thì rớt luôn. Ros đang dùng là 7.15.1 bác chỉ giáo giúp mình với ạ.

nếu để mặc định thì mtu của pppoe là 1492. Test bằng speedguide thì mss là 1452
 
CHO EM HỎI CÁI OPEN DNS này nó tự chọn trong mikrotik hay sao ạ ? Em để 1 đống DNS nó chỉ chọn ĐÚNG OPEN DNS ko Chọn mấy cái khác là nó tự lựa Ngẫu nhiên trong MIKROTIK HAY SAO Ạ ?
https://imgur.com/a/NtxTv3A

Lâu lâu thấy check ko ra DNS Nào chỉ thấy 1 cái SEVER bằng webiste Check - Surfshark (https://surfshark.com/check)
Và GAME nó tự DISCONECT hết nó nhảy DNS cũng bị DISCONECT GAME lun hay là bị lỗi gì ko ?
 
Mò mẫm mấy ngày nay không khắc phục được bệnh trên con RB5009, line Aon cắm quang trực tiếp vào sfp chạy được 30 phút mất mạng nhưng chữ R vẫn còn khởi động lại chạy được 5 phút rớt tiếp :sexy_girl: quay pppoe trên cổng lan 2.5G qua converter thì không sao :sweat:

via theNEXTvoz for iPhone
 
trinhymh said:
Mò mẫm mấy ngày nay không khắc phục được bệnh trên con RB5009, line Aon cắm quang trực tiếp vào sfp chạy được 30 phút mất mạng nhưng chữ R vẫn còn khởi động lại chạy được 5 phút rớt tiếp :sexy_girl: quay pppoe trên cổng lan 2.5G qua converter thì không sao :sweat:

via theNEXTvoz for iPhone
Click to expand...
Mạnh dạn mua lại 5009 của thím😆

Ủa, qua converter được thì xài converter thôi. Hay thím muốn all in one cho gọn🤔
 
Shane™ said:
Từ xưa đến giờ em k có setup MTU vì để mặc định port eth 1500 thì pppoe tự nhận 1492 k vấn đề gì cả. Vài hôm trước bỗng dưng line VNPT của em nó rớt pppoe cả ngày, gọi trạm người ta nói có chỉnh (nhưng ko nói chỉnh gì), em phải chỉnh MTU của port eth về 1492 thì pppoe mới connect được và nhận 1484. Em có tìm hiểu thì có bác bảo cứ để 1492 cho chắc ăn nhưng từ đó giờ e toàn cho nó auto thôi, nên thắc mắc xíu
Click to expand...

MTU của interface Ethernet bác không cần và cũng không nên để thấp hơn số chuẩn 1500 ạ. Nếu hôm nào đó mạng nhà bác lại dở chứng thì thay vì giảm MTU của cái interface ethX bác đặt thẳng Max MTU/Max MRU của cái pppoe-outX về 1484 hay 1480.

Hai tham số này mà để trống thì RouterOS từ bản 7.2 sẽ tính toán giá trị cho chúng là giá trị MTU của interface bên dưới trừ 8 (tức là 1492 nếu bên dưới là 1500). Các bản cũ hơn 7.2 thì là trừ 20 (tức là trước đó, dùng RouterOS 6.x chẳng hạn, nếu không đặt hai tham số này bằng tay và interface ethernet có MTU 1500 thì pppoe-outX RouterOS coi mặc định Max MRU và Max MTU = 1480).

Khi bác đặt hai giá trị Max MRU và Max MTU của interface pppoe-outX thì RouterOS sẽ ưu tiên sử dụng 2 giá trị này và không quan tâm đến giá trị MTU của interface ethernet bên dưới khi quay PPPoE (nó lại có quan tâm khi tính MSS tối đa như em viết ở post cũ, MSS bị giới hạn trần bởi cái này).

Trước bản 6.33 thì RouterOS sẽ giới hạn giá trị của Max MRU/Max MTU (giá trị người dùng nhập vào hay nó tự tính từ MTU của interface ethernet) không được quá 1492. Cái này là tuân theo giới hạn ghi trong RFC2516 (bác có thể search 1492 ở đây RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE) (https://datatracker.ietf.org/doc/rfc2516/)).

Kể từ bản 6.33 RouterOS hỗ trợ RFC4638 (RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) (https://datatracker.ietf.org/doc/rfc4638/)), đây là phần mở rộng cho PPPoE để hỗ trợ được payload (cái "MTU") lớn hơn giới hạn 1492. Hiện nay RouterOS kích hoạt cái phần mở rộng này cả khi giá trị Max MRU / Max MTU <= 1492. Các bác có thể vào System -> Logging và thêm rule theo dõi topic "pppoe":

1BtweFv.png

https://imgur.com/1BtweFv

Khi bắt đầu quay PPPoE RouterOS sẽ broadcast packet PADI (PPPoE Active Discovery Initiation), do hỗ trợ RFC4638, packet này sẽ có thêm tag (parameter) ppp-max-payload (như mũi tên da cam đầu tiên trên hình kia), giá trị này là cái to hơn trong hai cái Max MTU và Max MRU.

Cái đống access concentrators của nhà mạng (hay còn gọi là BRAS) sẽ trả lời bằng packet PADO (PPPoE Active Discovery Offer). Nếu nhà mạng cũng hỗ trợ RFC4638 thì trong packet này cũng sẽ có tag ppp-max-payload ghi "MTU" mà nhà mạng hỗ trợ được (mũi tên da cam thứ 2), cái này sẽ thấp hơn hoặc bằng cái mà RouterOS gửi đi ở PADI. Nếu thấp hơn cái gốc thì RouterOS sẽ biết hạ giá Max MRU / Max MTU xuống. Các giá trị này được gửi đi gửi lại tiếp trong các packet PADR (PPPoE active discovery request, router gửi trả lời cái PADO) và PADS (PPPoE Active Discovery Session-confirmation, bên ISP trả lời cái PADR) sau đó như hình trên.

Nếu nhà mạng không hỗ trợ RFC4638 thì sẽ không có cái ppp-max-payload trong trả lời PADO hay PADS. Lúc này RouterOS sẽ biết điều và giới hạn Max MRU / Max MTU không quá 1492 (giới hạn gốc của RFC2516).

Cái phần mở rộng từ RFC4638 ở trên thì chỉ giúp hai đầu của kết nối PPPoE biết mình có khả năng hỗ trợ được payload lớn hơn chuẩn hay không, và tối đa là bao nhiêu. Còn bước negotiate kích thức thực sự thì ở bên dưới, chỗ các packet LCP (Link Control Protocol). Cái này được định nghĩa chung cho chuẩn PPP (không chỉ riêng PPPoE) từ RFC1661 (RFC 1661: The Point-to-Point Protocol (PPP) (https://datatracker.ietf.org/doc/rfc1661/)).

Chỗ mũi tên xanh đầu, lúc router gửi đi packet LCP configuration request, nó sẽ điền vào đây giá trị từ cái Max MRU đang có của nó (giá trị có thể đã bị hạ xuống như các bước ở trên so với giá trị nhập hay tính toán tự động gốc). Cái này giúp router báo cho cái BRAS biết giới hạn payload tối đa mà router của bác sẽ nhận được. Đây là MRU (R = Receive) của bác, nhưng với phía nhà mạng đây sẽ là MTU của họ (Max Transmission Unit), phía ISP sẽ không gửi cho bác packet có payload to quá cái này.

Ở packet trả lời của cái access concentrator, packet LCP configuration acknowledged có mũi tên xanh thứ 2 bên dưới thì ISP gửi giá trị MRU của họ, tức là cho biết họ nhận được payload to tối đa bao nhiêu. Nếu ISP hỗ trợ RFC4638 thì giá trị này có xét đến các giá trị ppp-max-payload đã trao đổi ở trên, nên ở thí dụ này ghi 1500. Còn không thì có thể ISP sẽ giới hạn ở đây 1492, hay 1480, hay giá trị nào đó khác. Cái này là MRU của họ nên đối với router của bác nó có ý nghĩa là MTU. Nhà mạng bảo họ nhận được payload tối đa bao nhiêu tức là router bác lúc gửi packet đi sẽ chỉ được gửi tối đa to như thế.

MTU thực sự cuối cùng mà Router bác ghi ở chỗ Actual MTU sẽ là giá trị nào nhỏ hơn trong 2 cái MRU của nhà mạng thông báo và cái thiết lập Max MTU của router bác (có thể thiết lập bằng tay hoặc tự tính, và sau đó có thể đã bị giảm ở các bước trên). Nên nếu bác để Max MRU = 1500, Max MTU = 1480, và nhà mạng hỗ trợ RFC4638 thì sẽ thấy ở tất các bước trao đổi PADI/PADO/PADR/PADS/LCP lúc tạo kết nối này đều ghi 1500 hết nhưng cuối cùng router vẫn chỉ ghi MTU 1480 và MRU 1500, do bị giới hạn bởi giá trị điền bằng tay Max MTU.

Bác có thể thiết lập sao cho ra kết quả cuối cái MTU và MRU của cái pppoe-out nó là hai số khác nhau. Và bác cũng sẽ thấy được lúc gửi và nhận packet UDP hay ICMP sẽ có các giới hạn khác nhau giữa nhận và gửi. Nhưng nếu dùng TCP và bật cái tự động chỉnh MSS thì khi này RouterOS sẽ đặt MSS dựa theo số nào nhỏ hơn cho cả 2 chiều gửi và nhận. Và ngoài ra còn bị giới hạn bởi MTU của interface ethernet bên dưới trừ 8 nữa. Nên cuối cùng vẫn cần nâng MTU của interface ethernet lên cao hơn 8 so với Max MTU / Max MRU mới đạt được giới hạn mong muốn khi dùng TCP.

Và tất nhiên, chỉ mỗi hai đầu của kết nối PPPoE hỗ trợ giao thức mô tả trong RFC4638 không thôi là chưa đủ. Còn một yêu cầu nữa là layer 2 ethernet bên dưới, bao gồm cổng trên router, các switch ở giữa nếu có, và modem, converter, v.v... phải hỗ trợ ethernet frame có kích thước đủ to. Thay vì chỉ cần hỗ trợ gửi frame có giới hạn kích thước chuẩn 1518 bytes (hoặc nếu PPPoE quay trên VLAN thì 1522 bytes) thì nếu muốn có MTU 1500 với PPPoE phần cứng ethernet phải hỗ trợ ethernet frame to ít nhất 1526 bytes (hoặc 1530 nếu có dùng VLAN).

Nếu thiết bị trên layer ethernet hỗ trợ jumbo frames thì hiển nhiên sẽ hỗ trợ được payload PPPoE 1500 bytes, vì thường hỗ trợ jumbo frames thì sẽ hỗ trợ frame tầm hơn 9000 bytes, hoặc ít ra cũng tầm hơn 4000 bytes. Nhưng ngay cả khi các hệ thống ở layer 2 này không hỗ trợ jumbo frames (hoặc có hỗ trợ nhưng tắt trong setting) thì vẫn có rất nhiều thiết bị hỗ trợ nhận và gửi ethernet frame lớn hơn kích thước chuẩn 1518 bytes. Thí dụ để hỗ trợ VLAN/QoS 802.1Q thì sẽ phải nhận gửi được frames to ít nhất 1522 bytes, nếu muốn hỗ trợ cả Q-in-Q thì thêm 4 bytes nữa, rồi hỗ trợ MPLS, v.v... đây là các phần mở rộng optional cho Ethernet, không phải lúc nào cũng dùng, nhưng cứ bật lên là header của frame ethernet lại phình to ra một chút. Do đó việc các frame lớn hơn kích thước chuẩn 1518 bytes từ mười mấy đến vài chục bytes vẫn được hỗ trợ là rất phổ biến. Những frame có kích thước nhỉnh hơn kiểu này được gọi là "baby jumbo frames". RFC4638 cũng nhắc đến việc tận dụng điều này để hỗ trợ dùng được MTU 1500 cho PPPoE (cần frames 1526 bytes, hoặc 1530 nếu dùng cả VLAN, phải được hỗ trợ).

Nếu có thiết bị router của MikroTik (PC router/CHR nhiều lúc nó không hiện) thì nếu bác nhìn vào bảng Interfaces hoặc Ethernet sẽ thấy có cột L2MTU. Nếu lấy giá trị này ở dòng ứng với các interface etherX hay sfpX (interface vật lý) rồi cộng với 18 (kích thước envelop chuẩn của frame ethernet khi không thêm gì) là sẽ ra kích thước giới hạn của ethernet frame hiện thời trên cổng đó, và bác sẽ thấy nó đủ to hơn 1530.

Tuy nhiên thế cũng có nghĩa là nếu gặp phải thiết bị (thí dụ cổng LAN của modem nhà mạng đã bridged) chỉ hỗ trợ frame to tối đa 1518 bytes (hay ngay cả với 1522), và bác đặt Max MRU = Max MTU = 1500 trong thiết lập pppoe-out1, lúc khởi tạo kết nối PPPoE các giá trị ppp-max-payload = 1500 và mru=1500 sẽ được đưa đi đưa lại bình thường, nhưng khi đến lúc cần gửi packet với payload thực sự 1500 bytes thì sẽ cần gửi 1 ethernet frame 1526 (hoặc 1530) bytes và sẽ không gửi được qua layer 2, Kết quả là kết nối PPPoE sẽ bị treo hoặc bị ngắt.

Vấn đề này cũng có thể xảy ra ngay cả khi bác không dùng gì RFC4638 cả, để mặc định cho RouterOS tính ra MTU/MRU 1492. Nếu giả sử đường PPPoE của bác cần VLAN, khi đó kích thước ethernet frame cần được hỗ trợ là 1522, nhưng đâu đó trên đường ethernet của bác có thiết bị nào đó chỉ hỗ trợ frame to tối đa 1518 thôi chẳng hạn (thí dụ 1 switch siêu cổ), thì cũng sẽ không gửi được. Khi này bác cũng phải chủ động giảm kích thước MTU/MRU xuống, thí dụ 1488 (hoặc RouterOS giảm hộ bác sau nhiều lần kết nối không thành công).
 
pantigon25 said:
MTU 1500 và 1492 nó khác biệt nhiều không bác, em thử thì không thấy khác biệt lắm 😅
Click to expand...

Nếu chỉ tính về hiệu năng thì khi dùng PPPoE, không có VLAN, IPv4 và TCP, với MTU 1492 gửi 1 packet tối đa được 1452 bytes dữ liệu thực sự, thì cần tốn 1538 bytes trên đường truyền ethernet (gồm 20 bytes overhead ở layer 1, 18 ở layer 2, 8 bytes header PPPoE, 20 bytes header IPv4, và 20 bytes header TCP). Như vậy hiệu quả đạt được 1452 / 1538 tầm 94.41% (đây là lý do các bác speedtest với đường 1Gbps ra được tầm 94xMbps).

Khi dùng MTU 1500 thì payload đạt được là 1460 bytes, tốn tổng cộng 1546 bytes trên đường ethernet, hiệu năng 94.44%. Khác biệt giữa 2 con số này chẳng là cái gì đáng kể hết. Ngay cả nếu so khi dùng IPv6, overhead thêm 20 bytes so với IPv4, thì có 1432/1538 so với 1440/1546, vẫn chỉ là 93.11% so với 93.14% mà thôi. Lợi ích thực sự của việc dùng được MTU 1500 nó ở chỗ khác.

Các giá trị MTU mà bác thấy ghi trên interface PPPoE hay các interface ethernet hay bridge hay vlan, là kích thước tối đa của packet ở layer 3, layer IP có thể truyền qua được. Tức là không tính các overhead của các layer với protocol bên dưới (không tính overhead PPPoE, Ethernet, v.v...) mặc dù có là chữ T (Transmission) cho chiều gửi đi nhưng thường nó cũng áp dụng cho cả chiều nhận vì nó thường bằng luôn giá trị MRU. Khi truyền dữ liệu từ 1 đầu A đến 1 đầu B qua giao thức IP (có thể là IPv4 hoặc IPv6 không quan trong, vẫn là packet IP) thì một packet sẽ được truyền lần lượt qua nhiều node/hop khác nhau, thường là các router. Mỗi node sẽ có giới hạn MTU của nó, cho phép packet IP có kích thước tối đa bao nhiêu được đi qua. Khi đến 1 node mà packet nhỏ hơn MTU thì sẽ được chuyển đi tiếp. Hầu hết các node trung chuyển trên internet, cũng như trong mạng LAN dùng ethernet đều hỗ trợ MTU 1500 chuẩn của payload của ethernet.

Điều gì xảy ra khi trên đường truyền 1 packet lớn đến một node/hop/router và kích thước của packet đó to hơn giá trị MTU mà node đó chấp thuận được? Cái này phụ thuộc vào protocol đang là IPv4 hay IPv6, và thuộc tính của packet đó.

* Nếu là IPv4, và nếu packet đó không bật cờ (flag) DF (do not fragment), thông thường là như vậy, thì node có MTU nhỏ hơn kích thước packet này sẽ tiến hành phân mảnh packet thành nhiều packet nhỏ hơn MTU. Các packet này sẽ được bật flag MF (more fragments), trừ packet cuối, và được gán giá trị ở trường fragment offset của packet để biết vị trí của mảnh này trong packet gốc. Các packets/mảnh này sẽ được chuyển tiếp, và khi đến đích sẽ được ghép lại thành packet gốc, đúng thứ tự và vị trí, nhờ các thông tin flag và offset kia. Tất nhiên là với điều kiện phải đợi nhận được đủ tất cả các packet mảnh. Nếu có packet loss thì chỉ cần mất 1 trong các mảnh là coi như mất cả packet gốc. Như vậy với cùng tỉ lệ packet loss, do thay vì chỉ có 1 packet thành ra có nhiều packet, nên nguy cơ bị mất packet sẽ tăng lên so với trường hợp không cần phân mảnh packet. Ngoài ra việc phải phân mảnh packet tốn tài nguyên xử lý và bộ nhớ của các node trên đường truyền, do phải xử lý nhiều packet hơn, node phải thực hiện phân mảnh và node đích phải thực hiện ghép mảnh còn phải tốn nhiều tài nguyên hơn nữa. Ngoài ra overhead của các tầng protocol do có nhiều packet cũng tăng lên, so với kích thước payload vẫn như ban đầu, nên hiệu năng bị giảm. Delay cũng sẽ cao lên.

* Nếu là IPv4 và packet có bật cờ DF thì node sẽ không tự phân mảnh packet mà sẽ drop nó và gửi 1 packet ICMP về nguồn gửi của packet với type 3 code 4 (Fragmentation required, and DF flag set). Packet này cũng mang thông tin MTU ở vị trí node bị drop packet. Nếu trên đường truyền về này không bị cái nào chặn ICMP thì phía gửi ban đầu sẽ nhận được thông tin này. Có thể nó sẽ biết xử lý đúng đắn và giảm kích thước packet xuống (với thông tin MTU trong packet ICMP này), gửi lại, cũng có thể nó sẽ thông báo lỗi, do việc giảm kích thước không tương thích với ứng dụng, hoặc tệ hơn hơn là nó không biết phải làm gì. Tệ hơn nữa là có tường lửa nào đó trên đường chặn ICMP (vì admin đọc được cái guide cũ rích từ mấy chục năm trước bảo nên chặn ICMP để block ping 😢), và thế là phía gửi không biết packet bị drop do to quá, đợi một hồi thì tưởng là bị packet loss, và thử gửi lại với kích thước y như cũ, và lại bị từ chối, kết quả là người dùng thấy mọi thứ như bị treo đơ đơ.

* Nếu là IPv6 thì do IPv6 quy định rõ là các router trên đường truyền không được phép tự ý phân mảnh packet, nên với IPv6 thì sẽ giống như tình huống IPv4 mà có bật cờ DF. Chỉ khác biệt là ở chỗ là khi drop packet do to quá thì node bên IPv6 sẽ gửi packet ICMPv6 type 2 code 0 (packet too big) trả lại về cho sender mà thôi (còn thông tin MTU thì cũng có như bên IPv4). Và ở đây sẽ cũng có các vấn đề như bên IPv4 nếu các tường lửa chặn ICMPv6.

Như vậy vấn đề gặp phải khi lỡ gửi packet to hơn MTU đâu đó trên đường truyền không nhỏ. Nhẹ thì như bên IPv4 sẽ bị giảm hiệu năng do phải phân mảnh packet, nặng hơn như bên IPv6 thì phải truyền lại, hoặc nếu ICMPv6 bị chặn thì treo đơ luôn. Tối ưu sẽ là phía bên gửi đi chỉ gửi các packet không lớn hơn MTU trên khắp đường truyền.

Một giải pháp là khi A truyền dữ liệu đến B, trước khi bắt đầu truyền A sẽ thử tìm giá trị MTU nhỏ nhất trên toàn bộ đường truyền. Cái này là Path MTU Discovery (PMTUD), phía gửi ban đầu coi như MTU là MTU trên adapter mạng của nó và gửi packet với kích thước này đến B. Với IPv4 nó sẽ bật cờ DF. Như viết ở trên, nếu trên đường truyền gặp node nào đó có MTU nhỏ hơn thì packet sẽ bị drop và trả về packet ICMP/ICMPv6 chứa thông tin MTU nhỏ hơn đó. Phía gửi sẽ dùng thông tin này, giảm kích thước packet xuống và gửi lại. Cứ thế lặp lại cho đến khi đến đích. Khi đến đích được thì packet đã đủ nhỏ để không bị chỗ nào drop và kích thước đó có thể được sử dụng như MTU của toàn bộ đường truyền (Path MTU). Từ đó A chỉ dùng kích thước tối đa này khi gửi packet cho B.

Tuy nhiên như ở trên đã đề cập, cái này fail toàn tập nếu đâu đó trên đường truyền có tường lửa chặn ICMP/ICMPv6, khi này kết nối sẽ bị treo 1 hồi đến khi timeout. Ngoài ra, ngay cả khi không bị chặn thì quá trình dò PMTUD cũng tạo ra delay trước khi dữ liệu được truyền.

Một giải pháp nữa, nhưng mà chỉ áp dụng được cho TCP, đó là node trên đường truyền có MTU nhỏ hơn sẽ chỉnh sửa giá trị của field MSS (Maximum Segment Size) trên packet TCP SYN được gửi đi qua nó khi khởi tạo kết nối. Thí dụ với IPv4 TCP khi packet SYN đi qua node có MTU 1492, và node này có hỗ trợ tính năng điều chỉnh MSS tự động, và nó thấy field MSS của packet không có giá trị hoặc to hơn 1452 (1492-40 bytes header IPv4 TCP, với IPv6 thì là 1432 = 1492-60), thì nó sẽ sửa giá trị này của packet xuống 1452. Điều này cũng sẽ được nó làm với packet đi từ hướng kia trở lại của quá trình khởi tạo kết nối TCP. Kết quả là sau bước này ở hai đầu kết nối TCP vừa được tạo đều có thông tin MSS=1452 (1432 với IPv6) và cả 2 đầu sau đó sẽ không tạo packet TCP nào to hơn 1492 cho kết nối này.

Nhiều HĐH router, trong đó có RouterOS tự động làm điều này. Trong RouterOS thì nó là setting "Change TCP MSS" bật mặc định trong cái profile PPP mà các interface pppoe-out sử dụng. Nhờ đó, với các kết nối thông thường dùng TCP, hầu như các bác sẽ không cảm nhận thấy các vấn đề gây ra bởi việc packet quá khổ so với MTU. Nếu cái này không hoạt động tự động thì có thể thêm rule mangle vào RouterOS như bác @ppptran viết ở trên, để nó "clamp MSS to path-mtu".

Nhưng cái này chỉ áp dụng cho TCP, không sử dụng được cho UDP hay các protocol khác. Trong khi, thí dụ, mặc định DNS dùng UDP trước tiên, và nhiều domain trả về rất nhiều địa chỉ khiến packet trả lời chạm đến giới hạn MTU (trả lời query to qua sẽ bị cụt trong packet này, và sau đó client sẽ chuyển sang query bằng TCP, nhưng chỉ làm điều đó nếu nó nhận được cái packet UDP trước cái đã), hay với HTTP/3 và QUIC, cả duyệt web bình thường cũng chuyển qua dùng UDP, và sẽ bị ảnh hưởng bởi MTU sai. Một lần nữa nhắc lại thì thông thường IPv4 sẽ không bật cờ DF và router sẽ tự phân mảnh packet quá khổ hộ nên các bác sẽ không cảm nhận được nhiều (nhưng sẽ có thêm delay và tốn thêm tài nguyên). Nhưng với IPv6, nếu PMTUD không hoạt động được đúng thì các vấn đề gặp phải sẽ lớn hơn nhiều. Em nghĩ chắc phần lớn các vấn đề các bác trên này hay gặp phải khi bật IPv6, kiểu lag giật, timeout, trắng xóa, đại khái là không "mượt" như bác @ppptran viết ở trên, là do MTU gây ra.

Quay lại vấn đề MTU của PPPoE mặc định bị hạ xuống <= 1492. Ở phần Introduction của RFC4638 (RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) (https://datatracker.ietf.org/doc/rfc4638/)) họ có đề cập đến lý do tại sao ngày nay cái RFC này, cái đề xuất giải pháp cho MTU PPPoE lên được 1500 hoặc cao hơn, lại cần thiết hơn so với trước:

* Thời hai mươi mấy năm trước, lúc PPPoE mới ra, thì khi vào internet bằng PPPoE thường sẽ là có 1 thiết bị PC cắm trực tiếp vào thiết bị chuyển đổi (CPE), và chính cái PC đó (đa số là Windows) thực hiện việc quay PPPoE. Do tự quay nên cái interface này trên hệ điều hành (Windows) chạy trên cái PC này biết rõ MTU tối đa chỉ có 1492 (hoặc nhỏ hơn). Từ đó các ứng dụng chạy trên PC này cũng biết chỉ nên gửi packet to tối đa này mà thôi. Và như vậy coi như không gây ra vấn đề gì ít ra là cho chiều gửi đi cả. Và do tự biết MTU bị hạ, các ứng dụng cũng có thể tự bảo đầu bên kia không gửi packet to quá (thí du bằng cách set TCP MSS).

* Ngày nay (từ cả chục năm nay) hầu hết những nơi sử dụng PPPoE đều đã chuyển sang mô hình có 1 router đứng sau đường PPPoE, và sau router là một lô thiết bị, máy tính, điện thoại, tablet, IoT này nọ. Các cổng quay về hướng LAN của router, gồm cả các giao diện WiFi, đều có MTU đặt mặc định 1500 (hoặc cao hơn nếu bật jumbo frames). Tương tự, adapter mạng ethernet hay WiFi trên các thiết bị client cũng đều có MTU mặc định 1500. Nếu dùng Windows các bác có thể chạy lệnh

Code: 
netsh interface ipv4 show subinterfaces

Nếu Linux thì

Code: 
ip addr
(hoặc lệnh cũ)
ifconfig

MacOS thì

Code: 
ifconfig
(hoặc)
netstat -i

Và thấy MTU 1500 ở các adapter ethernet và WiFi (trừ phi bật jumbo frames). Thông thường chỉ có các interface VPN mới có MTU < 1500 trên các thiết bị. Tóm lại các ứng dụng trên các thiết bị đều sẽ bắt đầu với assumption là gửi packet to đến 1500 bytes sẽ ok, và sẽ có nhiều ứng dụng tận dụng điều này, gửi packet to tối đa. Lúc này hoặc cần router can thiệp, phân mảnh hộ hoặc set hộ TCP MSS, hoặc các ứng dụng trên các thiết bị dùng PMTUD và phát hiện ra trên đường truyền có MTU < 1500, hoặc xui hơn thì gặp các kịch bản lỗi treo đơ đơ.

Cái này cũng áp dụng với chiều từ ngoài internet gửi dữ liệu về mạng của bác. MTU 1500 gần như là chuẩn được mọi node ngoài internet (không kể PPPoE) chấp nhận. Nếu không bị can thiệp bởi MSS, sẽ có rất nhiều server gửi packet to 1500 bytes cho bác, để rồi đến router sẽ bị phân mảnh (với IPv6 thì thường họ không dám làm điều này, thí dụ Cloudflare chỉ dám gửi packet to 1400 bytes nếu dùng IPv6 Fixing an old hack - why we are bumping the IPv6 MTU (https://blog.cloudflare.com/increasing-ipv6-mtu/) do lo sợ PMTUD không hoạt động).

Như vậy giải pháp đỡ đau đầu nhất là làm cho cái đường PPPoE của bác nó dùng được MTU 1500. Từ đầu đến cuối sẽ chỉ có MTU 1500, không sợ bị dính các cái quái gở như ở trên kia. Chính vì thế cái RFC4638 nó mới ra đời và giờ được càng nhiều ISP hỗ trợ (và RouterOS hỗ trợ từ 6.33).
 
ohn0n0n0 said:
Min

Minh đang xài a7 dùng sfp gpon. Nếu để mtu và mru là 1500 của pppoe(vlan để mtu 1508) thì actual mtu nhảy về 1480. Quay pppoe thì vẫn có ip và vào được mạng bằng ipv4 nhưng ipv6 thì rớt luôn. Ros đang dùng là 7.15.1 bác chỉ giáo giúp mình với ạ.

nếu để mặc định thì mtu của pppoe là 1492. Test bằng speedguide thì mss là 1452
Click to expand...

Nếu có thời gian bác đọc 2 posts ngay ở bên trên của em ạ. Nếu có thể bác vào System -> Logging thêm tạm thời entry để nó log topic "pppoe" (khi test xong thì lại gỡ nó đi), sau đó cho quay PPPoE và xem trong log xem các giá trị max payload với mru bọn nó trao đổi với nhau là gì ạ, với lúc nào bị hạ xuống 1480, bởi bên nào. Cũng có khả năng hai bên đàm phán với nhau thành cổng và chọn được MTU/MRU 1500 nhưng sau đó cái SFP của bác nó không cho gửi frame đủ to nên RouterOS hạ xuống 1480, bác nghiên cứu log nó viết gì ạ. Có thể phải tìm chỗ trên giao diện quản lý cái module SFP để nâng giới hạn (có thể bằng cách tăng setting MTU trên website quản lý của nó).

Còn một khi MTU đã bị hạ xuống 1480 thì như viết ở post trên, IPv6 sẽ là cái bị ảnh hưởng nhiều hơn, nhất là khi Path MTU Discovery không hoạt động. Và bản thân payload IPv6 đã nhỏ hơn IPv4 rồi, nên MTU nhỏ 1480 thì payload chỉ còn 1420, nhiều packet sẽ thành quá khổ. Nếu không khắc phục được vấn đề MTU nhỏ quá thì bác phải xem lại cấu hình tường lửa (để không block ICMPv6), xem lại thiết lập tự chỉnh TCP MSS (hoặc thêm rule vào mangle IPv6 như bác @ppptran), cái này chỉ giúp TCP.
 
CGGX_ANNX said:
Nếu có thời gian bác đọc 2 posts ngay ở bên trên của em ạ. Nếu có thể bác vào System -> Logging thêm tạm thời entry để nó log topic "pppoe" (khi test xong thì lại gỡ nó đi), sau đó cho quay PPPoE và xem trong log xem các giá trị max payload với mru bọn nó trao đổi với nhau là gì ạ, với lúc nào bị hạ xuống 1480, bởi bên nào. Cũng có khả năng hai bên đàm phán với nhau thành cổng và chọn được MTU/MRU 1500 nhưng sau đó cái SFP của bác nó không cho gửi frame đủ to nên RouterOS hạ xuống 1480, bác nghiên cứu log nó viết gì ạ. Có thể phải tìm chỗ trên giao diện quản lý cái module SFP để nâng giới hạn (có thể bằng cách tăng setting MTU trên website quản lý của nó).

Còn một khi MTU đã bị hạ xuống 1480 thì như viết ở post trên, IPv6 sẽ là cái bị ảnh hưởng nhiều hơn, nhất là khi Path MTU Discovery không hoạt động. Và bản thân payload IPv6 đã nhỏ hơn IPv4 rồi, nên MTU nhỏ 1480 thì payload chỉ còn 1420, nhiều packet sẽ thành quá khổ. Nếu không khắc phục được vấn đề MTU nhỏ quá thì bác phải xem lại cấu hình tường lửa (để không block ICMPv6), xem lại thiết lập tự chỉnh TCP MSS (hoặc thêm rule vào mangle IPv6 như bác @ppptran), cái này chỉ giúp TCP.
Click to expand...

Vấn đề nằm ở thằng sfp bác ạ. e có thử lắp lại cục viettel thì mtu nhảy lên 1500 ngon lành(mtu để auto vẫn là 1492 nhưng set bằng tay thì lên được 1500) nhưng cứ lắp sfp là xuống 1492. set mtu bằng tay thì actual mtu xuống 1480 luôn. con sfp này thì có web để cài đặt gpon nhưng lại ko thấy phần chỉnh mtu, file config.xml của sfp thì cũng ko thấy luôn. trong winbox thì báo cổng sfp mtu là 1500. chả lẽ lại phải lắp lại cục viettel.
https://imgur.com/gkcGNdb
 

Similar threads

hongducwb
thắc mắc gateway bị đổi
2 3
Replies
44
Views
1K
hongducwb
hongducwb
K
tin tức Acer ra mắt Router Mesh Wave 7 với Wi-Fi 7 và công nghệ Multi-Link cho kết nối gia đình toàn diện
Replies
0
Views
326
Kisuf
K
M
thảo luận Cách Mesh router tp link AX5400 với WA8021V5 cùng 1 mạng ??
Replies
7
Views
437
ohyourgod
ohyourgod
Duy1122
kiến thức NAT là gì, và tại sao lại cần NAT trong mạng?
Replies
6
Views
1K
schaffer513655
schaffer513655
T
thắc mắc Hỏi về Unifi Dream Machine
Replies
9
Views
493
titani
T

Share this page

Back
Top