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

Опять 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. Но очень похоже.

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас