[Kato]

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

Дано:

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

Поменяли:

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

 

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

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

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

[orlik]

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

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

[Kato]

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

Edited November 28, 2016 by Kato

[Ivan_83]

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

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

 

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

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

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

[myst]

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

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

tracepath же =)

[zi_rus]

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

 

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

[Kato]

Интерфейс:

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

[zi_rus]

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

 

[stalker86]

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>

[SUrov_IBM]

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 адреса сабинтерфейса).

[stalker86]

См выше.

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

[GrandPr1de]

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

[stalker86]

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

[zi_rus]

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

[Kato]

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

[stalker86]

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

[Kato]

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

[Ivan_83]

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