MTU - а надо ли?

M

mihmih

Well-Known Member
Господа, а Вам не кажется, что эти свистопляски с гаданием/изменением MTU несколько излишни? Почему? сейчас объясню:

Проблема с MTU возникает в следствие того, что TCP пакет заварачивается в UDP пакет, удлинняясь на величину служебных заголовков. И в этот момент общая длина такого конверта получается чуть-чуть выше, чем допускается у клиента (ADSL-модем, роутер (провайдера) и т.п.). В результате пакет на каком-то этапе просто отбрасывается. В том числе и потому что, возможно, не всякое оборудование еще и позволяет фрагментировать UDP-пакеты.

Что предлагаю:
Бить пакеты в самом AMICON NDIS-драйвере сразу по 300 байт (а на сервере - собирать) тогда они ГАРАНТИРОВАННО пройдут через сеть.
Конечно понадобится вносить изменения в клиентское и серверное ПО, но проблема-то исчезнет навсегда. И, ГЛАВНОЕ уйдет поиск труднодиагностируемых ошибок прикладного ПО, связанных с "плохим MTU"


Ведь сам факт того что на компьютере КЛИЕНТА вносятся изменения (читай - костыли) в сетевую инфраструктуру влияет на престиж организации-установщика ФПСУ-клиента.
 
<r>Если разрешено прохождение icmp ответов по цепочке шлюзов, то при включенном PMTUDescovery, в большинстве случаев, никаких настроек MTU не требуется.

<URL url="http://ru.wikipedia.org/wiki/MTU">http://ru.wikipedia.org/wiki/MTU</URL>

Path MTU Descovery
<URL url="http://msdn.microsoft.com/en-us/library/ms817967.aspx">http://msdn.microsoft.com/en-us/library/ms817967.aspx</URL>

Debug the MTU values between you and a host
<URL url="http://www.elifulkerson.com/projects/mturoute.php">http://www.elifulkerson.com/projects/mturoute.php</URL>

Diagnoses and treatment of black hole routers
<URL url="http://support.microsoft.com/kb/159211/">http://support.microsoft.com/kb/159211/</URL></r>
 
<r><QUOTE author="mihmih"><s>
mihmih написал(а):
</s>Господа, а Вам не кажется, что эти свистопляски с гаданием/изменением MTU несколько излишни? Почему? сейчас объясню:

Проблема с MTU возникает в следствие того, что TCP пакет заварачивается в UDP пакет, удлинняясь на величину служебных заголовков. И в этот момент общая длина такого конверта получается чуть-чуть выше, чем допускается у клиента (ADSL-модем, роутер (провайдера) и т.п.). В результате пакет на каком-то этапе просто отбрасывается. В том числе и потому что, возможно, не всякое оборудование еще и позволяет фрагментировать UDP-пакеты.

Что предлагаю:
Бить пакеты в самом AMICON NDIS-драйвере сразу по 300 байт (а на сервере - собирать) тогда они ГАРАНТИРОВАННО пройдут через сеть.
Конечно понадобится вносить изменения в клиентское и серверное ПО, но проблема-то исчезнет навсегда. И, ГЛАВНОЕ уйдет поиск труднодиагностируемых ошибок прикладного ПО, связанных с "плохим MTU"


Ведь сам факт того что на компьютере КЛИЕНТА вносятся изменения (читай - костыли) в сетевую инфраструктуру влияет на престиж организации-установщика ФПСУ-клиента.<e>
Нажмите для раскрытия...
</e></QUOTE>

+1

полностью поддерживаю, я уже задолбался - соединяеться с 20го раза.. у меня провайдер двухсторонний спутниковый и так лагает, тут еще MTU на проксе да на клиентских машинах менять...

кстати, mihmih, я смотрю ты разбираешся хорошо, подскажи настройки чтобы соединение проходило нормально, а то я со своим провайдером уже воевал изза клиентом Минбанка - тоже проблема с MTU была, так ничего дельного и не подсказали</r>
 
<r>Реализация стека TCP/IP на большинстве роутеров такова, что если переданный пакет больше MTU, то пакет не фрагментируется, а попросту отбрасывается без каких либо icmp сообщений. Роутеры, которые тупо отбрасывают превышающий MTU пакет без ICMP сообщения Destination host unreachable, называются Black Hole router.
У Windows XP есть параметр реестра
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\tcpip\parameters\EnablePMTUBHDetect
с помощью которого можно включить обнаружение таких "черных дыр" с грубой подгонкой значения MTU для прохождения через такие роутеры. Но на мой взгляд, это не самое изящное и далеко не самое оптимальное решение.

Для определения максимального MTU, можно воспользоваться утилитой mturoute (<URL url="http://www.elifulkerson.com/projects/mturoute.php">http://www.elifulkerson.com/projects/mturoute.php</URL>)
Для этого надо установить ФПСУ подключение и "натравить" эту утилиту на один из узлов, указанных в списке хостов ФПСУ. Далее, попробовать задать полученное значение MTU для интерфейса, через который устанавливается VPN соеднинение.
Подробности здесь:
<URL url="http://www.amicon.ru/faq.htm#cli12">http://www.amicon.ru/faq.htm#cli12</URL>

Справочные материалы
<URL url="http://support.microsoft.com/kb/159211/">http://support.microsoft.com/kb/159211/</URL>
<URL url="http://support.microsoft.com/default.aspx?scid=kb;en-us;120642"><LINK_TEXT text="http://support.microsoft.com/default.as ... -us;120642">http://support.microsoft.com/default.aspx?scid=kb;en-us;120642</LINK_TEXT></URL>
<URL url="http://support.microsoft.com/kb/136970/">http://support.microsoft.com/kb/136970/</URL></r>
 
Deonis спасибо за ссылку на програмку,
ну всё же опять на пустом месте не надо гонять, человек же предложил вообще не заморачиваться с MTU, а призвал разработчиков решить проблему кординальным образом с ихним софтом! Кто нибудь из разработчиков может откликнуться по данному топику?
 
Ваши советы, уважаемые, не лишены смысла и естественно требуют дополнительных затрат времени для их реализации. По возможности, в новых версиях ip-клиента, мы все это учтем.
 
<r>ну это хорошо. вот еще бы хотелось нормальную поддержку Socks и без глюков всех проксей (например, User Gate 2.<E>8)</E></r>
 
Больше проблем с MTU в ФПСУ-IP/Клиент быть не должно.
В версии, выложенной на сайте, добавлен механизм регулировки MSS TCP(работает автоматически).
Аналогичный механизм реализован в ФПСУ в версии 2.52 (в общих параметрах есть опция "Корректировать MSS TCP").
Реализовано по просьбе специалистов Сбербанка из г. Саратов. Спасибо им за полезное предложение!!!
 
а да и можно ссылочку прямую, а то на странеце загрузки версия от сентября висит!
 
<r><B><s></s>zeomegazord<e></e></B>,

на данный момент на сертификации находится версия ФПСУ-IP 2.52. Ожидается получение сертификата в текущем году.</r>
 
MTU

Идеальным решением для клиентов, был бы перевод трафика на http. https.Это везде пропускают, проблем с МТU возникать почти не будет, у клиента ничего перенастраивать не придется. Зато, конечно возникнут проблемы оперативной доставки трафика.
 
Позвольте с Вами не согласиться, коллега, насчёт http. Подобный подход осложнит "выделение" данного трафика. Ведь не единственная задача - пропустить его. Нужно и ограничить доступ, и иметь логи по нему. С отдельным протоколом проще в этом случае.
В любом случае этого счастья мы не дождёмся - придётся переписывать клиентов банка, на что банк не пойдёт. Использование Амикона не потребовало от них ровным счётом ничего, клиент банка, и сервера банка даже и не догадываются, что между ними появилась прослойка в виде ФПСУ клиента / МСЭ ФПСУ. Удобно. Для банка, разумеется. Да и логично, ничего не скажешь.
Если бы Амикон клиент создавал своё интерфейс, а не фильтр (ну как cisco VPN хотя бы) - проблем с MTU никаких не возникло бы вовсе.
А самым удобным для нас с Вами решением была бы отдельная маленькая железка на линуксе в одним USB портом и двумя ethernet. Либо машину через неё подключаем, либо на маршрутизаторе маршруты через неё рисуем - и ни у кого никаких проблем. Пробросил протокол на isa - и всё. Ни тебе проблем с FWC, ни с клиентским софтом/железом, и с кривыми драйверами...
 
Re:

<r><QUOTE author="Roman_Sein"><s>
Roman_Sein написал(а):
</s>Ваши советы, уважаемые, не лишены смысла и естественно требуют дополнительных затрат времени для их реализации. По возможности, в новых версиях ip-клиента, мы все это учтем.<e>
Нажмите для раскрытия...
</e></QUOTE>
А когда еще планируются обновления? И учитываются ли по прежнему пожелания форумчан? А то я бы хотел бы поделится кое какими соображениями..</r>
 
Re: MTU

<r><QUOTE author="mvkir"><s>
mvkir написал(а):
</s>Идеальным решением для клиентов, был бы перевод трафика на http. https.Это везде пропускают, проблем с МТU возникать почти не будет, у клиента ничего перенастраивать не придется. Зато, конечно возникнут проблемы оперативной доставки трафика.<e>
Нажмите для раскрытия...
</e></QUOTE>

Полностью поддерживаю вас!</r>
 
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху