LINUX.ORG.RU
Форум — Admin  

Размер пакетов (теоретический вопрос)

 ,


0

1

Доброй ночи,

в администрировании мало что понимаю, подскажите пожалуйста, у меня проблема следующая, арендую сервер, недавно был переезд на новую площадку и ситуация такая: у провайдера были проблемы с настройкой MTU или что-то похожее на это, так как несколько дней сервер тупил (ssh подвисал, сайт медленно работал, потом вообще не загружался, но соединение браузер не терял) потом вроде, они с горем пополам исправили ситуацию за двое суток.

Теперь к сути, на моей сервер не получается отправить пакеты размером 1476 - 1500 байт. То есть (пинг виндовый :) ):

ping x.x.x.x -f -l 1448 - нормально проходит,

ping x.x.x.x -f -l 1449 - превышен интервал ожидания для запроса.. и так до 1472,

ping x.x.x.x -f -l 1473 - здесь уже, требуется фрагментация пакета, но установлен запрещающий флаг.

Скажите пожалуйста, кто в понимает суть проблемы, это серьезный косяк и нужно его исправлять и кто из нас дурак? Я провайдеру говорю, что мол ситуация такая, не проходят пакеты с таким размером, и все свелось, что мне порекомендовали почитать habrahabr.ru/post/226807/ и не маяться ерундой с вымышленной проблемой. Если это недопустимое поведение для канала до сервера, можете подсказать как ткнуть носом провайдера. Что-то должно не работать, так как внешне сайт работает и сервисы тоже вроде функционируют. Может получится сделать синтетическую проблему из этого, простой пинг для них не аргумент.

Спасибо.


← Postfix не доставляются письма
Хранилище для небольшого кластера →

не маяться ерундой с вымышленной проблемой

Если фрагментация на промежуточных узлах выполняется корректно, то ты ищешь проблему не там.

Пример: ping-ом в Linux(и не только) можно послать пакеты и по 5 и по 10 килобайт. Windows/Linux отвечают на ICMP-пакеты >1500 байт(до определенных размеров). Многие коммутаторы(которые имеют IP-адрес, конечно же) - нет. Хотя большие пакеты при этом пропускают через себя на другие узлы. Естественно я подразумеваю настройки «по умолчанию», то есть исключая случай где файрвол на системе специально настроен отбрасывать такие пакеты.

Следует ли что коммутаторы работают неправильно? Нет.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)

Я бы попрбывал занизить ручками MSS TCP сигмента принудительно ниже стандартного, где-то до 1300. Если это решит проблему - значит где-то по маршруту к вашему серверу явно происходит PMTU discovery blackhole. И нужно тогда смотреть по трассе маршруто где он именно

Tok ★★
()
Ответ на: комментарий от Pinkbyte 
tracepath x.x.x.x
 1?: [LOCALHOST]       pmtu 1500
 1:  xxx               0.636ms
 1:  xxx               0.457ms
 2:  xxx               0.453ms
 3:  xxx               0.386ms pmtu 1476
 3:  no reply          
 4:  no reply
 5:  xxx               2.925ms
 6:  xxx               3.440ms
 7:  xxx               68.683ms reached

Только это с сервера путь, так как под рукой нет линукса, в винде не нашел аналог с определением MTU. Но добавлю, что если через winMTR задать размер пакета в недопустимых пределах, то трассировка какая-то странная, как только доходит до хостера, то появляется много хостов (>23) которые не отвечают. Главный их сайт принимает все пакеты нормально. То есть проблема на каком-то роутере, на нашей подсети точно у всех также. У меня фаервол без правил.

RUS-42
() автор топика
Ответ на: комментарий от RUS-42 
tracepath x.x.x.x
 1?: [LOCALHOST]       pmtu 1500
 1:  x.x.230.254       0.636ms
 1:  x.x.230.254       0.457ms
 2:  10.6.8.2          0.453ms
 3:  10.6.8.2          0.386ms pmtu 1476
 3:  no reply
 4:  no reply
 5:  xxx               2.925ms
 6:  xxx               3.440ms
 7:  xxx               68.683ms reached
RUS-42
() автор топика
Ответ на: комментарий от Tok

Через iptables изменял это значение, но ничего не произошло 

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300
до 1000 опускал.

RUS-42
() автор топика
Ответ на: комментарий от RUS-42

Все выглядит нормально. Кроме мифического недохода ICMP-пакетов больше определенного размера какие есть реальные проблемы?

То есть, я имею ввиду не образное «ssh тупит», а выхлоп tcpdump с присутствующими icmp fragmentation needed при этом самом подключенном ssh.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от anonymous

Более того - если проблема во входящем подключении, правило из таблицы FORWARD тупо не будет отрабатывать, о чём можно убедиться посмотрем на счётчики пакетом(iptables -vn -L)

Pinkbyte ★★★★★
()

Ну попробуйте на сервере, допустим:

dig -t any isc.org @199.6.0.30 # Или какой-нибудь другой ip-адрес NS зоны isc.

В ответ должно прилететь 3356 байт, причём без всяких задержек или сообщений типа: ″;; Truncated, retrying in TCP mode.″ (это сообщение будет первым в выводе).

Относительно TCP — у вас всё работает, и закачка, и скачка файлов без правила MSS в iptables?

Вобще проблема может быть в том, что провайдер зачем-то зафильтровал большие icmp-пакеты, а всё остальное не трогал.

mky ★★★★★
()
Ответ на: комментарий от Pinkbyte

Кроме мифического недохода ICMP-пакетов больше определенного размера какие есть реальные проблемы?

Замечено не было.

RUS-42
() автор топика
Ответ на: комментарий от mky

Попробовал, приходит и сразу, размер 3356.

RUS-42
() автор топика

Всем большое спасибо, за помощь, как вывод, я понял, что это нормально и мои опасения не оправдались.

RUS-42
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Postfix не доставляются письма
Admin
Хранилище для небольшого кластера →