Неподгружаются сайты или проблема с MTU на PPPoE
-
Проблема проявляется так:
яндекс, мейл.ру, открываются.
pfsense.org - нет. или например хабра - тоже не открывается.Т.е. все как бы работает, и сразу проблемы не видно.
При чем до установки файра все работало. Без шаманств с настройками PPPoE на мопедах.
Поэтому трабла и причины не совсем очевидны.
-
Проблема с ДНС у прова мєй би ? Замените ДНС на 8.8.8.8 и 8.8.4.4 (гугловские) и проверьте.
-
Если PPPoE, напрашивается мысль о проблеме с MTU.
-
А из пакетов что установлено? Помню какие-то нечеловеческие, иррациональные проблемы со squid+pppoe на 1.2.3 и не у одного меня.
Как вариант - можно попробовать перед pfsense поставит простенькую железку, умеющую pppoe, и посмотреть, что будет. -
Оказалось ,что у pf на PPPoE что то не так с MTU
Выясняем так
ping -D -c 2 -s 1400 ya.ruразмер пакета подбираем экспериментально.
вот она бяка какая
–- ya.ru ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[2.0.1-RELEASE][root@local]/root(25): ping -D -c 2 -s 1400 ya.ru
PING ya.ru (93.158.134.3): 1400 data bytes
1408 bytes from 93.158.134.3: icmp_seq=0 ttl=54 time=142.254 ms
1408 bytes from 93.158.134.3: icmp_seq=1 ttl=54 time=142.926 ms–- ya.ru ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 142.254/142.590/142.926/0.336 ms[2.0.1-RELEASE][root@local]/root(26): ping -D -c 2 -s 1460 ya.ru
PING ya.ru (93.158.134.203): 1460 data bytes
1468 bytes from 93.158.134.203: icmp_seq=0 ttl=53 time=144.737 ms
1468 bytes from 93.158.134.203: icmp_seq=1 ttl=53 time=143.890 ms–- ya.ru ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 143.890/144.313/144.737/0.424 ms[2.0.1-RELEASE][root@local]/root(27): ping -D -c 2 -s 1470 ya.ru
PING ya.ru (213.180.193.3): 1470 data bytes
36 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 da05 a0d2 0 0000 40 01 0a00 95.189.255.255 213.180.193.336 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 da05 a6c0 0 0000 40 01 0000 95.189.255.255 213.180.193.3^C
–- ya.ru ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[2.0.1-RELEASE][root@local]/root(28):Заходим в настройки WAN , там ставим подходящее значение, и ребутаем пифа.
-
Можно почистить от воды и кинуть в ФАК
проблема решена.
-
Оказалось ,что у pf на PPPoE что то не так с MTU
Выясняем так
ping -D -c 2 -s 1400 ya.ruразмер пакета подбираем экспериментально.
вот она бяка какая
–- ya.ru ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[2.0.1-RELEASE][root@local]/root(25): ping -D -c 2 -s 1400 ya.ru
PING ya.ru (93.158.134.3): 1400 data bytes
1408 bytes from 93.158.134.3: icmp_seq=0 ttl=54 time=142.254 ms
1408 bytes from 93.158.134.3: icmp_seq=1 ttl=54 time=142.926 ms–- ya.ru ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 142.254/142.590/142.926/0.336 ms[2.0.1-RELEASE][root@local]/root(26): ping -D -c 2 -s 1460 ya.ru
PING ya.ru (93.158.134.203): 1460 data bytes
1468 bytes from 93.158.134.203: icmp_seq=0 ttl=53 time=144.737 ms
1468 bytes from 93.158.134.203: icmp_seq=1 ttl=53 time=143.890 ms–- ya.ru ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 143.890/144.313/144.737/0.424 ms[2.0.1-RELEASE][root@local]/root(27): ping -D -c 2 -s 1470 ya.ru
PING ya.ru (213.180.193.3): 1470 data bytes
36 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 da05 a0d2 0 0000 40 01 0a00 95.189.255.255 213.180.193.336 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 da05 a6c0 0 0000 40 01 0000 95.189.255.255 213.180.193.3^C
–- ya.ru ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[2.0.1-RELEASE][root@local]/root(28):Заходим в настройки WAN , там ставим подходящее значение, и ребутаем пифа.
Это не у пф-а не так с МТУ, это пров такой хитровы@баный. У меня на Укртелекоме все ОК с МТУ - ничего не менял и все работает уже 4-ый год.
А есть местечковые - вот они размер пакета ставят кто во что гаразд. -
werter
При чем до установки файра все работало. Без шаманств с настройками PPPoE на мопедах.
и что вот про это думаете?
яндекс, мейл.ру, открываются.
если имхо, тогда имхуйте.
-
http://zyxel.ru/kb/1571
Вопрос:
Объясните, почему при смене подключения на PPPoE вдруг перестали открываться некоторые сайты и теперь я не могу подключиться к ftp-серверам?
Ответ:
Данная проблема может быть связана с размером передаваемых пакетов (с размером MTU). Дело в том, что максимальный размер Ethernet-пакета составляет 1500 байт, а максимальный размер пакета, передаваемого через PPPoE, составляет 1492 байта. Заголовок PPPoE занимает 6 байт, а PPP Protocol ID 2 байта. Таким образом, пакеты размером свыше 1492 байта будут отбрасываться при использовании PPPoE.
Рекомендуем … установить размер MTU, равный 1492.http://ru.wikipedia.org/wiki/TCP
Известные проблемы
Максимальный размер сегмента
TCP требует явного указания максимального размера сегмента (MSS) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее, чем стандартный MTU Ethernet (1500 байт).
В протоколах туннелирования, таких как GRE, IPIP, а также PPPoE MTU туннеля меньше чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Поскольку фрагментация в подавляющем большинстве случаев запрещена, то такие пакеты отбрасываются.
Проявление этой проблемы выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длиннее допустимого размера.
Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.
MSS может также управляться параметрами операционной системы.
В 2.0 была введена опция MSS для соединения PPPoE. http://redmine.pfsense.org/issues/1886
Как я понял, теперь MTU устанавливает значение непосредственно на Ethernet порт интерфейса (а он как помним должен быть 1500), а MSS позволяет уменьшать это значение для виртуального соединения. То есть по идее 1492 в поле MSS должно спасти ситуацию. -
В 2.0 была введена опция MSS для соединения PPPoE. http://redmine.pfsense.org/issues/1886
Как я понял, теперь MTU устанавливает значение непосредственно на Ethernet порт интерфейса (а он как помним должен быть 1500), а MSS позволяет уменьшать это значение для виртуального соединения. То есть по идее 1492 в поле MSS должно спасти ситуацию.у меня нормально стало работать на MTU 1472
на днях проверю MSS
камень в огород pf. на мой взгляд эта опция по дефолту должна быть . для повышения юзабилити.
-
Зависит от реализации. Возможно в других ситуациях именно такое поведение оправдано. Интерфейс в железе-то Ethernet.
ЗЫ Там в комментах к MSS прописано, что оно устанавливается по умолчанию MTU -40B (=1492). Думаю у Вашего провайдера оно еще немного меньше (~1472).
-
не думаю, что наши провы хитро_как_то_там, скорее это отсутствие какого-либо умысла и смысла.
есть допустим вот это Технология Path MTU discoveryнасколько я понял, то ya.ru и mail.ru открываются потому что админы грамотно настроили блокировку ICMP пакетов. а остальные не настраивали.
осталось одно НО. мопед ехал , а пф нет.
и еще, почему у меня получилось 1472. заголовки или TCP или IP по 20 кб.
MSS= MTU - TCP - IP
1492(mtu)-20(tcp)-20(ip)=1452
ни так ни этак -
не думаю, что наши провы хитро_как_то_там, скорее это отсутствие какого-либо умысла и смысла.
а вот читать и цитировать байки из статей начала века, стыдно.
и есть допустим вот это Технология Path MTU discoveryосталось одно НО. мопед ехал , а пф нет.
А что именно является байками? Какая-то информация устарела?
По поводу мопеда и пф - подумайте поверх чего поднята PPP сессия с модема и с пф? А даже по Вашей ссылке в первых строках ясно сказано "Значения MTU зависят от коммуникационного интерфейса (сетевая плата, последовательный порт, и т. д.)". Сравнивать модем и ПФ следует с учетом этого факта.
-
не думаю, что наши провы хитро_как_то_там, скорее это отсутствие какого-либо умысла и смысла.
а вот читать и цитировать байки из статей начала века, стыдно.
и есть допустим вот это Технология Path MTU discoveryосталось одно НО. мопед ехал , а пф нет.
А что именно является байками? Какая-то информация устарела?
По поводу мопеда и пф - подумайте поверх чего поднята PPP сессия с модема и с пф? А даже по Вашей ссылке в первых строках ясно сказано "Значения MTU зависят от коммуникационного интерфейса (сетевая плата, последовательный порт, и т. д.)". Сравнивать модем и ПФ следует с учетом этого факта.
)) про байки,.. упс, это не вам.
.. интерфейс. пока не знаю разницы.IP to ATM или IP to Ethernet. пойду искать.
-
Можете со мной снова не согласиться, но я настаиваю на мысле о "кривой" реализации соединения Вашим провайдером, т.к. сталкивался с таким у одного(!) единственного прова в своем городе. А у нас их с полтора десятка точно. И только у этого пришлось подбирать размер MTU вручную! Причем подбор производился на "железных" роутерах совершенно разных производителей. Ну вот у всех провайдеров он 1492, а у этого то 1400, то 1370, то 1380. Голова уже болела от этих танцев. Причем таже Windows устанаваливает соединение без проблем. Я так понимаю она динамически подстраивается под размер MTU при установке коннекта.
-
mturoute для диагностики -не пробовали?
-
mturoute для диагностики -не пробовали?
Кстати, да. Спасибо за наводку
http://www.elifulkerson.com/projects/mturoute.php
-
Создайте свою тему. И зачем раскидывать свои сообщения по нескольким топикам?.
