MTU больше 1492 по PPPoE-соединениям.

PPPoE-соединения ограничены значением 1492. Некоторые CPE могут даже отказаться подключаться, если провайдер разрешает PPPoE MTU в 1500. Поэтому большинство провайдеров следуют стандарту и заставляют PPPoE MTU равняться 1492. Во Франции у всех крупных провайдеров транспортная сеть ADSL имеет MTU в 1500, поэтому абсолютно нет возможности выйти за пределы 1492 для PPPoE MTU, а MLPPP через одно соединение тоже не поддерживается. Это ужасная ситуация по сравнению с Англией, где British Telecom предлагает VDSL2-соединения, поддерживающие RFC 4638 с PPPoE MTU в 1500. Если RFC 4638 поддерживается провайдером и CPE, то во время установления PPP-соединения согласовывается опция для определения расширенного MTU. PPPoE over ATM – это всё ещё устаревшая технология по сравнению с более новыми IPoA или EFM-соединениями, но PPPoE-соединения по RFC 4638 с MTU в 1500 всё равно лучше, чем отвратительное значение 1492, которое у нас есть уже много лет на ADSL PPPoE-соединениях… Во Франции мы можем использовать PPPoA с MTU в 1500, но это возможно только в том случае, если завершить PPP-сессию на модеме. Если вы хотите завершить её на роутере, это не сработает, если только вы не сможете подключить модем и роутер через ATM-соединение. У некоторых старых модемов был интерфейс ATM25, но маршрутизаторы Mikrotik в любом случае не поддерживают интерфейсы ATM25, и это слишком сложная и дорогая вещь для большинства людей. Другая возможность – иметь модем с PPPoA для PPPoE внутреннего бриджа, но это не распространено. RFC 4638 – это простое и недорогое альтернативное решение, в ожидании того, что технологии EFM и оптоволокно медленно заменят ADSL. Фактически, возможно быть совместимым с RFC 4638, используя linux или OpenWRT-боксы. Надеюсь, что Mikrotik последует этому примеру. Это побудит провайдеров поддерживать это и будет хорошим вариантом даже для частного использования.

Это выдержки из моего pppoe-клиента и сервера. Клиент: > int pppoe-client monitor pppoe-rt-bfs-2
         статус: подключен
         время работы: 16м16с
      время простоя: 55с
   активные соединения: 1
       кодировка: MPPE128 stateless
   имя услуги: rt-bfs-2
        имя учетной записи: rt-bfs-2
         MAC-адрес учетной записи: 00:0C:42:A4:7A:51
            MTU: 1500
            MRU: 1500
  локальный адрес: 172.32.1.2
 удаленный адрес: 172.32.1.1 Сервер: > int pppoe-server monitor pppoe-rt-bfs-3
    статус: подключен
    время работы: 21м1с
 время простоя: 0с
      пользователь: rt-bfs-3
 caller-id: 00:0C:42:33:35:1F
  кодировка: MPPE128 stateless
   услуга: rt-bfs-2
 интерфейс: br-int
       MTU: 1500
       MRU: 1500 И несколько тестов: > ping 172.32.1.1 size=1500 do-not-fragment
HOST                                     SIZE TTL TIME  STATUS                                                    
172.32.1.1                               1500  64 2ms  
172.32.1.1                               1500  64 2ms  
172.32.1.1                               1500  64 2ms  
   sent=3 received=3 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=2ms

> ping 172.32.1.1 size=1502 do-not-fragment  
HOST                                     SIZE TTL TIME  STATUS                                                    
172.32.1.2                                576  64 1ms   fragmentation needed and DF set                            
172.32.1.2                                576  64 1ms   fragmentation needed and DF set                            
172.32.1.2                                576  64 1ms   fragmentation needed and DF set                            
   sent=3 received=0 packet-loss=100%

Предполагаю, что ты изучил переговоры и заметил, что PPP-Max-Payload нет в PADI и PADR. Ну что ж, я согласен, MT должен включить RFC 4638 в код RouterOS. Добавь запрос на новую функцию здесь: http://wiki.mikrotik.com/wiki/MikroTik_RouterOS/Feature_Requests

Я прошёлся по этой переписке и читал только про то, что MTU стоит на 1492 байта. Что не так с установкой его на 1500 в сети, которую вы полностью контролируете от CPE до транспортной сети?