Перейти к содержимому
Калькуляторы

Опять MTU

Здравствуйте.

Дано:

Сервер доступа с поднятым NAT (интерфейс без тэга) - (порт без тэга) L3-switch, который является для всех default route.

Поменяли:

Другой сервер доступа с поднятым NAT (интерфейс с тэгом) - (порт с тэгом) тот же L3-switch.

 

После переключения маршрута по умолчанию на свиче с первого сервера на второй наблюдаем странную проблему "сайты тупят, не открываются, пинг идёт".

Делаем вывод, что как-то связано с MTU (VLAN 4 байта etc...)

Подскажите, пожалуйста инструментарий для диагностики данной проблемы кроме "сайты тупят...". Не до конца понимаю, в какой же момент MTU интерфейсов надо менять, зависит ли как-то какой MTU на интерфейсе L3-свича. И является ли спасением включение Jumbo-frame на интерфейсах L3-свича? Теория теорией, но вот хотелось бы практических примеров.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ping и traceroute должно быть достаточно. ищите где и сколько байт не пролезает.

Вообще коммутатор должен авоматом учитывать теги и номраьно пропускать пакеты с нужным MTU

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

orlik, тут проблема в том, как же всё-таки правильно проверять? Я должен пинговать каждый IP-адрес в списке узлов tracert с флагом DF? Мне непонятна сама методика поиска.

Изменено пользователем Kato

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кажется 1472 должен пинг без фрагментации пролезать, если пролезает значит у тебя всё ок.

Дальше трейсроутом пытаешься такие пинги слать по маршруту, где оборвётся - там и косяк.

 

То что стало с тэгом - повлиять не должно, там запас на 2-3 тэга обычно.

Если лень разбираться можешь на сервере поставить tcpmssfix = 1400, как минимум проблема должна уйти.

А вообще, посмотри ошибки на портах и убедись что линки на обоих концах имеют одинаковую скорость и дуплекс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ping и traceroute должно быть достаточно. ищите где и сколько байт не пролезает.

Вообще коммутатор должен авоматом учитывать теги и номраьно пропускать пакеты с нужным MTU

tracepath же =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообще коммутатор должен авоматом учитывать теги и номраьно пропускать пакеты с нужным MTU

 

коммутатор скорее всего так и делает, а на сервере поди мту не подняли и фрагментацию запретили

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интерфейс:

vlan123: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 
options=303<RXCSUM,TXCSUM,TSO4,TSO6> 
ether 00:1e:67:ff:ff:ff 
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> 
media: Ethernet autoselect (1000baseT <full-duplex>) 
status: active 
vlan: 123 parent interface: igb1

 

igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 
options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO> 
ether 00:1e:67:ff:ff:ff 
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> 
media: Ethernet autoselect (1000baseT <full-duplex>) 
status: active

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ping -D -s 1472 xx.yy.126.4

PING 195.78.126.4 (xx.yy.126.4): 1472 data bytes

1480 bytes from xx.yy.126.4: icmp_seq=0 ttl=64 time=0.280 ms

1480 bytes from xx.yy.126.4: icmp_seq=1 ttl=64 time=0.265 ms

1480 bytes from xx.yy.126.4: icmp_seq=2 ttl=64 time=0.243 ms

1480 bytes from xx.yy.126.4: icmp_seq=3 ttl=64 time=0.225 ms

 

 

ifconfig vlan122

vlan122: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=3<RXCSUM,TXCSUM>

 

 

ifconfig lagg0

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

 

ifconfig igb0

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>

options=400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Kato, доброго Вам времени суток.

 

Вероятнее всего, что физический интерфейс сервера, "сквозь" которого проходит тегированный траффик,

имеет значение MTU=1500. Попробуйте увеличить (если драйвер позволяет) MTU физического интерфейса

до MTU=1504 (VLAN добавляет 4 байта (размер тега)), а самому сабинтерфейсу, на котором терминируется

VLAN, оставить MTU=1500.

 

Сталкивался с похожей проблемой во FreeBSD, при терминирование VLAN на сабинтерфейс.

Разрешилась после настройки:

 

Физический интерфейс сервера:

stge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1504

 

Сабинтерфейс «внутри системы»:

vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

 

Проверку прохождения IP пакетов при канале с MTU=1500, под ОС Windows можно проверить командой:

ping x.x.x.x -l 1472 –f (до IP адреса сабинтерфейса).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

См выше.

При мту 1500 на интерфейса чреез vlan у меня спокойно проходит пинг 1472 байта с запретом фрагментации

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня на фре теги тоже нормально бегают с MTU 1500 байт

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Собственно на пингвине тоже самое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

так что, пинг в обе стороны от сервера идет нормально? или что?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С обоих серверов до клиента 1472 проходят нормально.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С какими аргументами Вы запускали ping с обоих сторон и с каких OS?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

stalker86 параметрами, запрещающими фрагментацию пакетов. На FreeBSD и Windows XP.

 

C:\bat>mtupath.exe mail.ru

MTU path scan to mail.ru (217.69.139.200), ttl=64, limit=48
# 16 processing - best MSS 1472 (estimated MTU 1500) [uUUUUuUuuUuuuuuu]
# 01 nearest minimum MTU on local interface

       #1 MSS IN RANGE     1 <==  1471 ==>  1472
       #2 MSS EXCEEDED  1473 <== 14911 ==> 16384

[WARNING] Could not confirm contact with peer; path may be incomplete

 

Я уже начинаю склоняться к мысли, что это может быть не MTU. Но очень похоже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так иди проверяй физику, линки и пр.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.