forum.opennet.ru - "MTU 1492" (42)

форумы

правила/FAQ

поиск

регистрация

вход/выход

слежка

"MTU 1492"

Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"MTU 1492"	+/–
Сообщение от ego on 26-Сен-17, 07:16
в настройках DSL соединении через network manager выставил параметр MTU 1492, но все равно некоторые сайты не открывает. Что еще можно сделать?
Ответить \| Правка \| Cообщить модератору

Оглавление

MTU 1492, zanswer CCNA RS and S, 07:46 , 26-Сен-17, (1)

MTU 1492, ego, 09:31 , 26-Сен-17, (2)

MTU 1492, zanswer CCNA RS and S, 09:47 , 26-Сен-17, (3)

MTU 1492, ego, 09:53 , 26-Сен-17, (5)

MTU 1492, zanswer CCNA RS and S, 10:01 , 26-Сен-17, (7)

MTU 1492, ego, 10:09 , 26-Сен-17, (8)

MTU 1492, zanswer CCNA RS and S, 10:15 , 26-Сен-17, (9)

MTU 1492, ego, 10:44 , 26-Сен-17, (10)

MTU 1492, zanswer CCNA RS and S, 10:46 , 26-Сен-17, (11)

MTU 1492, ego, 10:57 , 26-Сен-17, (12)

MTU 1492, zanswer CCNA RS and S, 11:27 , 26-Сен-17, (15)

MTU 1492, ego, 11:30 , 26-Сен-17, (17)
MTU 1492, zanswer CCNA RS and S, 11:43 , 26-Сен-17, (21) +1
MTU 1492, ego, 11:34 , 26-Сен-17, (19)
MTU 1492, karen durinyan, 11:37 , 26-Сен-17, (20)
MTU 1492, zanswer CCNA RS and S, 11:46 , 26-Сен-17, (22)
MTU 1492, ego, 11:48 , 26-Сен-17, (23)
MTU 1492, zanswer CCNA RS and S, 11:51 , 26-Сен-17, (25)

MTU 1492, eek, 09:50 , 26-Сен-17, (4)

MTU 1492, ego, 09:53 , 26-Сен-17, (6)

MTU 1492, keir, 11:14 , 26-Сен-17, (13)

MTU 1492, ego, 11:19 , 26-Сен-17, (14)

MTU 1492, keir, 11:27 , 26-Сен-17, (16)

MTU 1492, zanswer CCNA RS and S, 11:34 , 26-Сен-17, (18)

MTU 1492, keir, 11:50 , 26-Сен-17, (24)

MTU 1492, zanswer CCNA RS and S, 11:54 , 26-Сен-17, (26)

MTU 1492, ego, 12:07 , 26-Сен-17, (27)

MTU 1492, zanswer CCNA RS and S, 12:15 , 26-Сен-17, (28)
MTU 1492, zanswer CCNA RS and S, 12:18 , 26-Сен-17, (29)

MTU 1492, ego, 16:21 , 26-Сен-17, (30)

MTU 1492, zanswer CCNA RS and S, 16:37 , 26-Сен-17, (31)

MTU 1492, ego, 17:06 , 26-Сен-17, (32)
MTU 1492, zanswer CCNA RS and S, 17:58 , 26-Сен-17, (33)

MTU 1492, universite, 18:29 , 26-Сен-17, (34)
MTU 1492, zanswer CCNA RS and S, 18:52 , 26-Сен-17, (37)
MTU 1492, ego, 18:44 , 26-Сен-17, (35)
MTU 1492, zanswer CCNA RS and S, 18:50 , 26-Сен-17, (36)
MTU 1492, ego, 20:24 , 28-Сен-17, (39)
MTU 1492, Дмитрий, 17:28 , 27-Сен-17, (38) –1
MTU 1492, ego, 20:27 , 28-Сен-17, (40)
MTU 1492, ACCA, 06:51 , 30-Сен-17, (41)
MTU 1492, ego, 08:29 , 01-Окт-17, (42)

Сообщения по теме [Сортировка по времени | RSS]

1. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 07:46

> в настройках DSL соединении через network manager выставил параметр MTU 1492, но
> все равно некоторые сайты не открывает. Что еще можно сделать?
А почему вы установили Layer 3 MTU именно в такое значение и самое главное зачем?
Каждый Internet Host RFC 1122: Requirements for Internet Hosts -- Communication Layers, кроме случаев, когда это запрещено или по каким-то причинам блокируется, выполняет Path MTU Discovery, RFC 1191: Path MTU Discovery.
Иными словами, узел сам пытается определить максимальный Layer 3 MTU.
И всё же, если вы считаете, что проблема у вас с MTU, установите его в значение 1400 байт, рекомендуемое MTU для случаев, когда используются протоколы туннелирования.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 09:31

выставил значением 1400 не помогает

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 09:47

> выставил значением 1400 не помогает
Значит ваша проблема лежит вне поля Layer 3 MTU, к тому же, маршрутизаторы кроме опять же случая с установленным DF битом, будут выполнять фрагментацию.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 09:53

и что же тогда делать в этом случае? Если провайдер рекомендует выставлять значение MTU на 1492

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:01

> и что же тогда делать в этом случае? Если провайдер рекомендует выставлять
> значение MTU на 1492
Хорошо, давайте в таком случае приступим к поиску вашей неисправности.
Для начала опишите ваши конфигурацию, как именно подключен ваш узел к сети интернет, какая ОС у вас установлена на вашем узле, какое оконечное устройство вы используете для подключения к сети интернет провайдера.
Раз речь идёт о MTU 1492 байта, значит с большой долей вероятности мы говорим о PPPoE протоколе. Чем подробнее вы опишите вашу конфигурацию, тем понятнее будет, куда нам двигаться дальше.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 10:09

OS - Linux Mint 18.2
сетевая карта Killer Ethernet E2400
network - Ethernet PPPoE
через кабель подключённый к компьютеру
Создал в network manager dsl соединение PPPoE выставил логин и пароль по договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:15

> OS - Linux Mint 18.2
> сетевая карта Killer Ethernet E2400
> network - Ethernet PPPoE
> через кабель подключённый к компьютеру
> Создал в network manager dsl соединение PPPoE выставил логин и пароль по
> договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта
Замечательно, давайте перейдём теперь к тому, какие именно сайты вам не удаётся открыть, укажите пару таких.
И попутно выполните к одному из них команду в вашей консоли:
ping dns_address_of_site
traceroute dns_address_of_site
Делать это само-собой необходимо при подключенном PPPoE соединение, MTU 1492 является стандартным MTU, поэтому установите его, как рекомендует ваш ISP.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 10:44

например сайты linux.org.ru speedtest.net
пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:46

> например сайты linux.org.ru speedtest.net
> пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся
Покажите мне вывод команд, что я написал выше, я проанализирую их.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 10:57

kool@hous25:~$ ping linux.org.ru
PING linux.org.ru (178.248.233.6) 56(84) bytes of data.
64 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.0 ms
64 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.1 ms
^C
--- linux.org.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 31.092/31.124/31.156/0.032 ms
kool@hous25:~$ traceroute linux.org.ru
traceroute to linux.org.ru (178.248.233.6), 30 hops max, 60 byte packets
1  10.254.253.253 (10.254.253.253)  0.531 ms  0.502 ms  0.647 ms
2  mx480.omkc.ru (217.25.208.197)  0.476 ms  0.615 ms  0.602 ms
3  rt1.omkc.ru (217.25.208.157)  51.538 ms  51.527 ms  51.515 ms
4  omk02.transtelecom.net (188.43.2.66)  1.946 ms  2.137 ms  2.123 ms
5  mskn06.transtelecom.net (188.43.15.238)  30.582 ms  30.571 ms  31.578 ms
6  HLL-gw.transtelecom.net (188.43.15.237)  31.079 ms  30.050 ms  30.947 ms
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:27

>[оверквотинг удален]
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *
Отсутствие ответа после 6 HLL-gw.transtelecom.net (188.43.15.237) 31.079 ms 30.050 ms 30.947 ms хопа, уже говорит о том, что проблема лежит вне вашей зоны ответственности.
Но, всё же выполните команду:
ping -s 1464 linux.org.ru
Данная команда сформирует ICMP type 8 code 0 (ICMP Request) заполненный данными расширителями, на столько, чтобы общая сумма ICMP (1464 + 8 байт) + IP (20 байт) + PPPoE (8 байт) = 1500 байт Layer 2 MTU Ethernet интерфейса.
Полученный итоговый Ethernet, после добавлении 18 байт заголовка Ethernet будет максимально допустимым для передачи через сеть вашего ISP до NAS, где будет отброшен Ethernet заголовок, а после и PPPoE заголовок. И итоговый IP пакет, который будет направлен с ISP NAS будет равен 1492 байтам.
Если в результате мы не увидим ICMP type 0 code 0 (ICMP Reply), значит вы сможете смело обратиться к вашему интернет провайдеру, предоставив ему полученную информацию, поскольку в таком случае, Layer 2 MTU вашего провайдера ниже заявленных в 1500 байт.
Если же мы увидим ICMP type 0 code 0 (ICMP Reply), значит проблема кроется на более высоких уровнях, например на транспортном уровне, в таком случае нам понадобится дамп трафика, собранный на PPPoE интерфейсе.
Но для начала покажите вывод команды, что я написал выше.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 11:30

~$ ping -s 1464 linux.org.ru
PING linux.org.ru (178.248.233.6) 1464(1492) bytes of data.
1472 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.3 ms
1472 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.2 ms
1472 bytes from 178.248.233.6: icmp_seq=3 ttl=58 time=31.2 ms
^C
--- linux.org.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 31.282/31.301/31.329/0.020 ms

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "MTU 1492" +1 +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:43

> ~$ ping -s 1464 linux.org.ru
> PING linux.org.ru (178.248.233.6) 1464(1492) bytes of data.
> 1472 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.3 ms
> 1472 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.2 ms
> 1472 bytes from 178.248.233.6: icmp_seq=3 ttl=58 time=31.2 ms
> ^C
> --- linux.org.ru ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
> rtt min/avg/max/mdev = 31.282/31.301/31.329/0.020 ms
И так, не каких проблем с Layer 3 MTU у нас стало быть нет.
Значит пора перейти к более сложной магии, мы будем снимать с вами дамп пакетов с вашего PPPoE интерфейса. Для этого выполните следующую команду:
tcpdump -s 0 -i ppp0 (ppp0 нужно заменить на ваш PPPoE интерфейс) -w mycap.pcap
Пока команда выполняется, введите в командную строку вашего браузера адрес:
https://linux.org.ru
После того, как ваш браузер закончит попытки подключится к сайту, нажмите Ctrl+C в консоли, а полученный файл можете разместить на любом удобном вам хостинге или же можете направить мне на почту zanswer сетевой пёс gmail та самая точка com. :)
P/S/ Нет, входить на какие-либо сайты в это время не желательно, если вы при это закроете текущую сессию в браузере и откроете новое окно, то будет совсем хорошо.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 11:34

при этом MTU=1492

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

20. "MTU 1492" +/–

Сообщение от karen durinyan (ok) on 26-Сен-17, 11:37

> при этом MTU=1492
try with user root
traceroute -I linux.org.ru
usually udp is blocked

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

22. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:46

>> при этом MTU=1492
> try with user root
> traceroute -I linux.org.ru
> usually udp is blocked
Not a bad idea, but in my opinion, packet dump would answer to all our questions.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 11:48

root@hous25 /home/kool # traceroute -l linux.org.ru
Cannot handle `-l' option with arg `linux.org.ru' (argc 2)
root@hous25 /home/kool # traceroute -I linux.org.ru
traceroute to linux.org.ru (178.248.233.6), 30 hops max, 60 byte packets
1  10.254.253.253 (10.254.253.253)  0.441 ms  0.621 ms  0.617 ms
2  mx480.omkc.ru (217.25.208.197)  0.607 ms  0.604 ms  0.603 ms
3  rt1.omkc.ru (217.25.208.181)  0.796 ms  0.793 ms  0.790 ms
4  omk02.transtelecom.net (188.43.2.66)  1.318 ms  1.745 ms  1.742 ms
5  mskn06.transtelecom.net (188.43.15.238)  31.601 ms  31.599 ms  31.651 ms
6  HLL-gw.transtelecom.net (188.43.15.237)  31.074 ms  30.881 ms  30.854 ms
7  178.248.233.6 (178.248.233.6)  30.835 ms  30.828 ms  30.790 ms

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

25. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:51

>[оверквотинг удален]
>  3  rt1.omkc.ru (217.25.208.181)  0.796 ms  0.793 ms
> 0.790 ms
>  4  omk02.transtelecom.net (188.43.2.66)  1.318 ms  1.745 ms
> 1.742 ms
>  5  mskn06.transtelecom.net (188.43.15.238)  31.601 ms  31.599 ms
> 31.651 ms
>  6  HLL-gw.transtelecom.net (188.43.15.237)  31.074 ms  30.881 ms
> 30.854 ms
>  7  178.248.233.6 (178.248.233.6)  30.835 ms  30.828 ms
> 30.790 ms
Наличие возможности передачи пакетов показал ещё ICMP ping, поэтому важно понять, что происходит на транспортном уровне с TCP.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

4. "MTU 1492" +/–

Сообщение от eek (ok) on 26-Сен-17, 09:50

> в настройках DSL соединении через network manager выставил параметр MTU 1492, но
> все равно некоторые сайты не открывает. Что еще можно сделать?
Не теряйте времени, звоните в службу технической поддержки вашего провайдера.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 09:53

не помогли провайдеры

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "MTU 1492" +/–

Сообщение от keir (ok) on 26-Сен-17, 11:14

> в настройках DSL соединении через network manager выставил параметр MTU 1492, но
> все равно некоторые сайты не открывает. Что еще можно сделать?
Вам нужен clamp-mss-to-pmtu (см. линк) https://www.opennet.dev/docs/RUS/LARTC/x2657.html

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 11:19

Я уже устанавливал значение MTU=63 байта и это всё равно не помогало и даже 6001 выставлял. Тот же вариант

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "MTU 1492" +/–

Сообщение от keir (ok) on 26-Сен-17, 11:27

>  Я уже устанавливал значение MTU=63 байта и это всё равно не
> помогало и даже 6001 выставлял. Тот же вариант
Хм, ну клево, че. Только я про MTU ничего не говорил и по ссылке речь не об MTU. Удачи в настройках.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:34

>>  Я уже устанавливал значение MTU=63 байта и это всё равно не
>> помогало и даже 6001 выставлял. Тот же вариант
> Хм, ну клево, че. Только я про MTU ничего не говорил и
> по ссылке речь не об MTU. Удачи в настройках.
Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, если даже он выполнит указанные в статье команды, то они не коснутся TCP SYN сегментов которые будут направленны его узлом.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

24. "MTU 1492" +/–

Сообщение от keir (ok) on 26-Сен-17, 11:50

> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально
> порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому,
> если даже он выполнит указанные в статье команды, то они не
> коснутся TCP SYN сегментов которые будут направленны его узлом.
Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:54

>> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально
>> порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому,
>> если даже он выполнит указанные в статье команды, то они не
>> коснутся TCP SYN сегментов которые будут направленны его узлом.
> Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было
> направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu
Отличная ссылка, теперь автор ветки, сможет попробовать данный вариант, хотя я бы всё таки хотел увидеть дамп. :)

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 12:07

~$ ping -c 4 -M do -s 1500 ya.ru
PING ya.ru (87.250.250.242) 1500(1528) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
--- ya.ru ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3053ms
kool@hous25:~$ ping ya.ru
PING ya.ru (87.250.250.242) 56(84) bytes of data.
64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=53 time=40.3 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=53 time=40.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=53 time=40.5 ms
^C
--- ya.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 40.219/40.366/40.517/0.261 ms
kool@hous25:~$ tracepatch ya.ru
Команда 'tracepatch' не найдена, возможно вы имели в виду:
Команда 'tracepath' из пакета 'iputils-tracepath' (main)
tracepatch: команда не найдена
kool@hous25:~$ tracepath ya.ru
1?: [LOCALHOST]                                         pmtu 1500
1:  no reply
2:  no reply
3:  no reply
4:  no reply
5:  no reply
6:  no reply

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 12:15

>[оверквотинг удален]
>  1?: [LOCALHOST]
>
>
>          pmtu 1500
>  1:  no reply
>  2:  no reply
>  3:  no reply
>  4:  no reply
>  5:  no reply
>  6:  no reply
Мы уже выяснили, что проблема лежит выше уровнем, чем IP MTU, обратите внимание на это моё сообщение № 21.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 12:18

>[оверквотинг удален]
>  1?: [LOCALHOST]
>
>
>          pmtu 1500
>  1:  no reply
>  2:  no reply
>  3:  no reply
>  4:  no reply
>  5:  no reply
>  6:  no reply
Адрес моего сообщения: https://www.opennet.dev/openforum/vsluhforumID6/2208.html#21

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 16:21

я вам отправил письмо на почтовый ящик в 16:21 МСК

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 16:37

> я вам отправил письмо на почтовый ящик в 16:21 МСК
Уже смотрю его, как только появятся комментарии, я напишу их следующим сообщением.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

32. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 17:06

буду признателен

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 17:58

>> я вам отправил письмо на почтовый ящик в 16:21 МСК
> Уже смотрю его, как только появятся комментарии, я напишу их следующим сообщением.
Некоторые записки по ходу, TCP MSS = 1460 байт, как Receive MSS, так и Send MSS:
TCP Option - Maximum segment size: 1460 bytes
Ваш узел успешно устанавливает TCP сессию с узлом linux.org.ru по порту 80:
113    0.000000    x.x.x.x    178.248.233.6    TCP    41942 → http(80) [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1415704725 TSecr=0 WS=128
114    0.031953    178.248.233.6    x.x.x.x    TCP    http(80) → 41942 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=3286174551 TSecr=1415704725 WS=512
115    0.000054    x.x.x.x    178.248.233.6    TCP    41942 → http(80) [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1415704733 TSecr=3286174551
Результатом является следующий HTTP обмен:
GET / HTTP/1.1
Host: linux.org.ru
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
HTTP/1.1 302 Found
Server: QRATOR
Date: Tue, 26 Sep 2017 13:16:33 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=15
Location: https://www.linux.org.ru/
Как мы видим, узел при этом выполняет перенаправление вас на другой HTTP URI, на HTTPS версию.
Что автоматически приводит к инициализации новой TCP сессии с узлом linux.org.ru но уже по порту 443:
128    0.214430    x.x.x.x    178.248.233.6    TCP    51902 → https(443) [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1415704797 TSecr=0 WS=128
129    0.031019    178.248.233.6    x.x.x.x    TCP    https(443) → 51902 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=3286174871 TSecr=1415704797 WS=512
130    0.000030    x.x.x.x    178.248.233.6    TCP    51902 → https(443) [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1415704805 TSecr=3286174871
Далее идёт TLS Client Hello:
131    0.000155    x.x.x.x    178.248.233.6    TLSv1    Client Hello
linux.org.ru подтверждает получение данного сегмента:
132    0.031161    178.248.233.6    x.x.x.x    TCP    https(443) → 51902 [ACK] Seq=1 Ack=194 Win=30720 Len=0 TSval=3286174905 TSecr=1415704805
После чего linux.org.ru отвечает нам уже в рамках защищённого соединения, но тут есть нюанс:
Обратите внимание, это TCP пакет номер 132, только развёрнутый, обратите внимание на Sequence number: 1 и Acknowledgment number: 194.
Internet Protocol Version 4, Src: 178.248.233.6, Dst: x.x.x.x
Transmission Control Protocol, Src Port: https (443), Dst Port: 51902 (51902), Seq: 1, Ack: 194, Len: 0
    Source Port: https (443)
    Destination Port: 51902 (51902)
    Sequence number: 1    (relative sequence number)
    Acknowledgment number: 194    (relative ack number)
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (ACK)
    Window size value: 60
    Checksum: 0xe04f [unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
А теперь следующий, пакет под номером 133:
133    0.000491    178.248.233.6    x.x.x.x    SSL    [TCP Previous segment not captured] , Continuation Data
Но самое интересно внутри, снова обратите внимание на Sequence number: 2897 и Acknowledgment number: 194.
Frame 133: 1268 bytes on wire (10144 bits), 1268 bytes captured (10144 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 178.248.233.6, Dst: 94.137.13.87
Transmission Control Protocol, Src Port: https (443), Dst Port: 51902 (51902), Seq: 2897, Ack: 194, Len: 1200
    Source Port: https (443)
    Destination Port: 51902 (51902)
    Sequence number: 2897    (relative sequence number)
    [Next sequence number: 4097    (relative sequence number)]
    Acknowledgment number: 194    (relative ack number)
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x018 (PSH, ACK)
    Window size value: 60
    Checksum: 0x7518 [unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
    TCP payload (1200 bytes)
Secure Sockets Layer
При этом размер TCP Payload = 1200 байт! Но, Sequence number уже 2897, это значит, что мы потеряли 1697 байт где-то, при значение нашего Receive MSS = 1460 байт, это значит, что по меньшей мере два сегмента.
Дальше мы видим следующую картину, linux.org.ru сообщает нам о том, что он завершает свою часть соединения:
143    4.998799    178.248.233.6    x.x.x.x    TCP    https(443) → 51902 [FIN, PSH, ACK] Seq=4097 Ack=194 Win=30720 Len=646 TSval=3286179905 TSecr=1415704813
Ваш узел какое-то время отправляет тем не менее TCP keep-alive пакеты, поскольку он свою часть соединения не закрывал.
186    10.228250    x.x.x.x    178.248.233.6    TCP    [TCP Keep-Alive] 51902 → https(443) [ACK] Seq=193 Ack=1 Win=33408 Len=0 TSval=1415708620 TSecr=3286174905 SLE=2897 SRE=4744
Но в итоге и он посылает пакет для завершения соединения, причём в виде быстрого завершения соединения, через RST флаг:
220    1.023881    x.x.x.x    178.248.233.6    TCP    51902 → https(443) [RST, ACK] Seq=194 Ack=1 Win=33408 Len=0 TSval=1415709644 TSecr=3286174905 SLE=2897 SRE=4744
И того мы имеем следующую картину, а именно потерю двух TCP сегментов, при этом linux.org.ru узел не получив ACK с подтверждением их получения, не осуществляет их повторную пересылку, а завершает соединение. Но, очевидно, что установить в таком случае полноценное TLS соединение вашему узлу не удаётся, поскольку он не получает полный набор байт, из которых может быть реконструирован Application Layer TLS пакет ядром.
По какой причине были потеряны два недостающих TCP сегмента, с точки зрения вашего узла установить не возможно. Можно, было бы установить Receive MSS скажем в 1400 байт, но, как мы выяснили ранее, linux.org.ru прекрасно получает и отправляет обратно ICMP пакеты с Layer 3 PDU размером 1492 байта. При размере Receive MSS равным 1460 байт, мы имеем Layer 3 PDU размером 1490 байт.
Отсюда я рекомендую вам открыть повторный кейс у вашего интернет провайдера, вы можете передать им сделанный вами дамп, для анализа или они могут выполнить тестирование собственными силами.
P/S/ Можно было бы конечно предположить, что по какой-то причине эти два TCP сегмента не были просто отражены в дампе, но увы, ваш узел подтвердил получение только данного набора байт TCP Option - SACK 2897-4744.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "MTU 1492" +/–

Сообщение от universite (ok) on 26-Сен-17, 18:29

Переведу вышенаписанное :)
Проблемы с (прозрачным) DPI, установленным вашим ISP.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

37. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 18:52

> Переведу вышенаписанное :)
> Проблемы с (прозрачным) DPI, установленным вашим ISP.
Вполне себе вариант, учитывая, что потерь пакетов мы на прошлых этапах не обнаружили.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

35. "MTU 1492" +/–

Сообщение от ego on 26-Сен-17, 18:44

Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону они не смогли проконсультировать

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

36. "MTU 1492" +/–

Сообщение от zanswer CCNA RS and S on 26-Сен-17, 18:50

> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону
> они не смогли проконсультировать
Замечательно, учитывая, что у вас Linux узел, он сможет увидеть всю картину своими глазами в любых ракурсах, без необходимости устанавливать дополнительное программное обеспечение.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

39. "MTU 1492" +/–

Сообщение от ego on 28-Сен-17, 20:24

не помогло. Спец тоже не шарит в этом. Причем на windows 7 всё прекрасно работает и роутинг отличный без ошибок с с примерами тех же сайтов. А у меня всё даже хуже. Сегодняшний переход на нового провайдера ничего не изменил. Всё осталось по прежнему. За одним исключением. openner.ru теперь на новом провайдере тоже не грузится. Теперь из-под VPN только писать. Может в сетевом конфиге что-то не так?

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "MTU 1492" –1 +/–

Сообщение от Дмитрий (??) on 27-Сен-17, 17:28

> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону
> они не смогли проконсультировать
выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernet на 8 байт,
iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

40. "MTU 1492" +/–

Сообщение от ego on 28-Сен-17, 20:27

>> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону
>> они не смогли проконсультировать
> выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernet
> на 8 байт,
> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
> iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
простите не увидел вашего сообщения. А можно это сделать скриптом при загрузке?

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

41. "MTU 1492" +/–

Сообщение от ACCA (ok) on 30-Сен-17, 06:51

> выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernet
Мало - не много. Ничего страшного не должно происходить. А происходит НЁХ из-за кривого transparent proxy у провайдера/ов.
Рабочая гипотеза - в винде 7 стоит автораспознавание прокси в сети, потому она нанюхалась провайдера и использует его прокси в явном виде. В минте эта шняга выключена, да и работает по-другому, потому можно/нужно описать прокси руками.
Без ссылки на прокси у провайдера дикие потери пакетов из-за того, что пытаются сделать transparent, а не получается. С VPN они пока не суются, потому и работает.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

42. "MTU 1492" +/–

Сообщение от ego on 01-Окт-17, 08:29

> Мало - не много. Ничего страшного не должно происходить. А происходит НЁХ
> из-за кривого transparent proxy у провайдера/ов.
> Рабочая гипотеза - в винде 7 стоит автораспознавание прокси в сети, потому
> она нанюхалась провайдера и использует его прокси в явном виде. В
> минте эта шняга выключена, да и работает по-другому, потому можно/нужно описать
> прокси руками.
> Без ссылки на прокси у провайдера дикие потери пакетов из-за того, что
> пытаются сделать transparent, а не получается. С VPN они пока не
> суются, потому и работает.
да я это заметил на 2х провайдерах. пришлось из кладовки маршрутизатор доставать. всё отлично стало. Спасибо. Можно закрыть тему

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "MTU 1492"	+/–
Сообщение от zanswer CCNA RS and S on 26-Сен-17, 07:46
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но > все равно некоторые сайты не открывает. Что еще можно сделать? А почему вы установили Layer 3 MTU именно в такое значение и самое главное зачем? Каждый Internet Host RFC 1122: Requirements for Internet Hosts -- Communication Layers, кроме случаев, когда это запрещено или по каким-то причинам блокируется, выполняет Path MTU Discovery, RFC 1191: Path MTU Discovery. Иными словами, узел сам пытается определить максимальный Layer 3 MTU. И всё же, если вы считаете, что проблема у вас с MTU, установите его в значение 1400 байт, рекомендуемое MTU для случаев, когда используются протоколы туннелирования.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 09:31
	выставил значением 1400 не помогает
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 09:47
	> выставил значением 1400 не помогает Значит ваша проблема лежит вне поля Layer 3 MTU, к тому же, маршрутизаторы кроме опять же случая с установленным DF битом, будут выполнять фрагментацию.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 09:53
	и что же тогда делать в этом случае? Если провайдер рекомендует выставлять значение MTU на 1492
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:01
	> и что же тогда делать в этом случае? Если провайдер рекомендует выставлять > значение MTU на 1492 Хорошо, давайте в таком случае приступим к поиску вашей неисправности. Для начала опишите ваши конфигурацию, как именно подключен ваш узел к сети интернет, какая ОС у вас установлена на вашем узле, какое оконечное устройство вы используете для подключения к сети интернет провайдера. Раз речь идёт о MTU 1492 байта, значит с большой долей вероятности мы говорим о PPPoE протоколе. Чем подробнее вы опишите вашу конфигурацию, тем понятнее будет, куда нам двигаться дальше.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	8. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 10:09
	OS - Linux Mint 18.2 сетевая карта Killer Ethernet E2400 network - Ethernet PPPoE через кабель подключённый к компьютеру Создал в network manager dsl соединение PPPoE выставил логин и пароль по договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:15
	> OS - Linux Mint 18.2 > сетевая карта Killer Ethernet E2400 > network - Ethernet PPPoE > через кабель подключённый к компьютеру > Создал в network manager dsl соединение PPPoE выставил логин и пароль по > договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта Замечательно, давайте перейдём теперь к тому, какие именно сайты вам не удаётся открыть, укажите пару таких. И попутно выполните к одному из них команду в вашей консоли: ping dns_address_of_site traceroute dns_address_of_site Делать это само-собой необходимо при подключенном PPPoE соединение, MTU 1492 является стандартным MTU, поэтому установите его, как рекомендует ваш ISP.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 10:44
	например сайты linux.org.ru speedtest.net пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:46
	> например сайты linux.org.ru speedtest.net > пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся Покажите мне вывод команд, что я написал выше, я проанализирую их.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 10:57
	kool@hous25:~$ ping linux.org.ru PING linux.org.ru (178.248.233.6) 56(84) bytes of data. 64 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.0 ms 64 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.1 ms ^C --- linux.org.ru ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 31.092/31.124/31.156/0.032 ms kool@hous25:~$ traceroute linux.org.ru traceroute to linux.org.ru (178.248.233.6), 30 hops max, 60 byte packets 1 10.254.253.253 (10.254.253.253) 0.531 ms 0.502 ms 0.647 ms 2 mx480.omkc.ru (217.25.208.197) 0.476 ms 0.615 ms 0.602 ms 3 rt1.omkc.ru (217.25.208.157) 51.538 ms 51.527 ms 51.515 ms 4 omk02.transtelecom.net (188.43.2.66) 1.946 ms 2.137 ms 2.123 ms 5 mskn06.transtelecom.net (188.43.15.238) 30.582 ms 30.571 ms 31.578 ms 6 HLL-gw.transtelecom.net (188.43.15.237) 31.079 ms 30.050 ms 30.947 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	15. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:27
	>[оверквотинг удален] > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * Отсутствие ответа после 6 HLL-gw.transtelecom.net (188.43.15.237) 31.079 ms 30.050 ms 30.947 ms хопа, уже говорит о том, что проблема лежит вне вашей зоны ответственности. Но, всё же выполните команду: ping -s 1464 linux.org.ru Данная команда сформирует ICMP type 8 code 0 (ICMP Request) заполненный данными расширителями, на столько, чтобы общая сумма ICMP (1464 + 8 байт) + IP (20 байт) + PPPoE (8 байт) = 1500 байт Layer 2 MTU Ethernet интерфейса. Полученный итоговый Ethernet, после добавлении 18 байт заголовка Ethernet будет максимально допустимым для передачи через сеть вашего ISP до NAS, где будет отброшен Ethernet заголовок, а после и PPPoE заголовок. И итоговый IP пакет, который будет направлен с ISP NAS будет равен 1492 байтам. Если в результате мы не увидим ICMP type 0 code 0 (ICMP Reply), значит вы сможете смело обратиться к вашему интернет провайдеру, предоставив ему полученную информацию, поскольку в таком случае, Layer 2 MTU вашего провайдера ниже заявленных в 1500 байт. Если же мы увидим ICMP type 0 code 0 (ICMP Reply), значит проблема кроется на более высоких уровнях, например на транспортном уровне, в таком случае нам понадобится дамп трафика, собранный на PPPoE интерфейсе. Но для начала покажите вывод команды, что я написал выше.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	17. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:30
	~$ ping -s 1464 linux.org.ru PING linux.org.ru (178.248.233.6) 1464(1492) bytes of data. 1472 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.3 ms 1472 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.2 ms 1472 bytes from 178.248.233.6: icmp_seq=3 ttl=58 time=31.2 ms ^C --- linux.org.ru ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 31.282/31.301/31.329/0.020 ms
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	21. "MTU 1492"	+1 +/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:43
	> ~$ ping -s 1464 linux.org.ru > PING linux.org.ru (178.248.233.6) 1464(1492) bytes of data. > 1472 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.3 ms > 1472 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.2 ms > 1472 bytes from 178.248.233.6: icmp_seq=3 ttl=58 time=31.2 ms > ^C > --- linux.org.ru ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > rtt min/avg/max/mdev = 31.282/31.301/31.329/0.020 ms И так, не каких проблем с Layer 3 MTU у нас стало быть нет. Значит пора перейти к более сложной магии, мы будем снимать с вами дамп пакетов с вашего PPPoE интерфейса. Для этого выполните следующую команду: tcpdump -s 0 -i ppp0 (ppp0 нужно заменить на ваш PPPoE интерфейс) -w mycap.pcap Пока команда выполняется, введите в командную строку вашего браузера адрес: https://linux.org.ru После того, как ваш браузер закончит попытки подключится к сайту, нажмите Ctrl+C в консоли, а полученный файл можете разместить на любом удобном вам хостинге или же можете направить мне на почту zanswer сетевой пёс gmail та самая точка com. :) P/S/ Нет, входить на какие-либо сайты в это время не желательно, если вы при это закроете текущую сессию в браузере и откроете новое окно, то будет совсем хорошо.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	19. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:34
	при этом MTU=1492
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	20. "MTU 1492"	+/–
	Сообщение от karen durinyan (ok) on 26-Сен-17, 11:37
	> при этом MTU=1492 try with user root traceroute -I linux.org.ru usually udp is blocked
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	22. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:46
	>> при этом MTU=1492 > try with user root > traceroute -I linux.org.ru > usually udp is blocked Not a bad idea, but in my opinion, packet dump would answer to all our questions.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	23. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:48
	root@hous25 /home/kool # traceroute -l linux.org.ru Cannot handle `-l' option with arg `linux.org.ru' (argc 2) root@hous25 /home/kool # traceroute -I linux.org.ru traceroute to linux.org.ru (178.248.233.6), 30 hops max, 60 byte packets 1 10.254.253.253 (10.254.253.253) 0.441 ms 0.621 ms 0.617 ms 2 mx480.omkc.ru (217.25.208.197) 0.607 ms 0.604 ms 0.603 ms 3 rt1.omkc.ru (217.25.208.181) 0.796 ms 0.793 ms 0.790 ms 4 omk02.transtelecom.net (188.43.2.66) 1.318 ms 1.745 ms 1.742 ms 5 mskn06.transtelecom.net (188.43.15.238) 31.601 ms 31.599 ms 31.651 ms 6 HLL-gw.transtelecom.net (188.43.15.237) 31.074 ms 30.881 ms 30.854 ms 7 178.248.233.6 (178.248.233.6) 30.835 ms 30.828 ms 30.790 ms
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	25. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:51
	>[оверквотинг удален] > 3 rt1.omkc.ru (217.25.208.181) 0.796 ms 0.793 ms > 0.790 ms > 4 omk02.transtelecom.net (188.43.2.66) 1.318 ms 1.745 ms > 1.742 ms > 5 mskn06.transtelecom.net (188.43.15.238) 31.601 ms 31.599 ms > 31.651 ms > 6 HLL-gw.transtelecom.net (188.43.15.237) 31.074 ms 30.881 ms > 30.854 ms > 7 178.248.233.6 (178.248.233.6) 30.835 ms 30.828 ms > 30.790 ms Наличие возможности передачи пакетов показал ещё ICMP ping, поэтому важно понять, что происходит на транспортном уровне с TCP.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору

4. "MTU 1492"	+/–
Сообщение от eek (ok) on 26-Сен-17, 09:50
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но > все равно некоторые сайты не открывает. Что еще можно сделать? Не теряйте времени, звоните в службу технической поддержки вашего провайдера.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	6. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 09:53
	не помогли провайдеры
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

13. "MTU 1492"	+/–
Сообщение от keir (ok) on 26-Сен-17, 11:14
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но > все равно некоторые сайты не открывает. Что еще можно сделать? Вам нужен clamp-mss-to-pmtu (см. линк) https://www.opennet.dev/docs/RUS/LARTC/x2657.html
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	14. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:19
	Я уже устанавливал значение MTU=63 байта и это всё равно не помогало и даже 6001 выставлял. Тот же вариант
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	16. "MTU 1492"	+/–
	Сообщение от keir (ok) on 26-Сен-17, 11:27
	> Я уже устанавливал значение MTU=63 байта и это всё равно не > помогало и даже 6001 выставлял. Тот же вариант Хм, ну клево, че. Только я про MTU ничего не говорил и по ссылке речь не об MTU. Удачи в настройках.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	18. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:34
	>> Я уже устанавливал значение MTU=63 байта и это всё равно не >> помогало и даже 6001 выставлял. Тот же вариант > Хм, ну клево, че. Только я про MTU ничего не говорил и > по ссылке речь не об MTU. Удачи в настройках. Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, если даже он выполнит указанные в статье команды, то они не коснутся TCP SYN сегментов которые будут направленны его узлом.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	24. "MTU 1492"	+/–
	Сообщение от keir (ok) on 26-Сен-17, 11:50
	> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально > порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, > если даже он выполнит указанные в статье команды, то они не > коснутся TCP SYN сегментов которые будут направленны его узлом. Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	26. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:54
	>> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально >> порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, >> если даже он выполнит указанные в статье команды, то они не >> коснутся TCP SYN сегментов которые будут направленны его узлом. > Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было > направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu Отличная ссылка, теперь автор ветки, сможет попробовать данный вариант, хотя я бы всё таки хотел увидеть дамп. :)
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	27. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 12:07
	~$ ping -c 4 -M do -s 1500 ya.ru PING ya.ru (87.250.250.242) 1500(1528) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 --- ya.ru ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3053ms kool@hous25:~$ ping ya.ru PING ya.ru (87.250.250.242) 56(84) bytes of data. 64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=53 time=40.3 ms 64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=53 time=40.2 ms 64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=53 time=40.5 ms ^C --- ya.ru ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 40.219/40.366/40.517/0.261 ms kool@hous25:~$ tracepatch ya.ru Команда 'tracepatch' не найдена, возможно вы имели в виду: Команда 'tracepath' из пакета 'iputils-tracepath' (main) tracepatch: команда не найдена kool@hous25:~$ tracepath ya.ru 1?: [LOCALHOST] pmtu 1500 1: no reply 2: no reply 3: no reply 4: no reply 5: no reply 6: no reply
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	28. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 12:15
	>[оверквотинг удален] > 1?: [LOCALHOST] > > > pmtu 1500 > 1: no reply > 2: no reply > 3: no reply > 4: no reply > 5: no reply > 6: no reply Мы уже выяснили, что проблема лежит выше уровнем, чем IP MTU, обратите внимание на это моё сообщение № 21.
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	29. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 12:18
	>[оверквотинг удален] > 1?: [LOCALHOST] > > > pmtu 1500 > 1: no reply > 2: no reply > 3: no reply > 4: no reply > 5: no reply > 6: no reply Адрес моего сообщения: https://www.opennet.dev/openforum/vsluhforumID6/2208.html#21
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	30. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 16:21
	я вам отправил письмо на почтовый ящик в 16:21 МСК
	Ответить \| Правка \| ^ к родителю #29 \| Наверх \| Cообщить модератору