Непрохождение пакетов больше определенного размера

[alx]

После сетевого шторма, связанного с образованием колец, плата SW-01 пришла в странное состояние, когда нельзя было подключиться по SSH или открыть страницу по HTTP. Исследование показало, что короткие пакеты проходят нормально, а более длинные - нет. Так, ping -s200 xxxx работал, а ping -s300 xxxx - нет.

Судя по выводу tcpdump'а, явление было симметричным: длинные пакеты не проходили как извне к процессору платы SW-01, так и от процессора платы во внешнюю сеть. Вот попытка подключиться по ssh:

18:15:59.625897 IP 192.168.0.75.56615 > 192.168.1.58.22: Flags [S], seq 2755932079, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 757640138 ecr 0], length 0
18:15:59.626351 IP 192.168.1.58.22 > 192.168.0.75.56615: Flags [S.], seq 137816485, ack 2755932080, win 14480, options [mss 1460,sackOK,TS val 28558387 ecr 757640138,nop,wscale 3], length 0
18:15:59.626394 IP 192.168.0.75.56615 > 192.168.1.58.22: Flags [.], ack 1, win 1040, options [nop,nop,TS val 757640138 ecr 28558387], length 0
18:15:59.627374 IP 192.168.0.75.56615 > 192.168.1.58.22: Flags [P.], seq 1:39, ack 1, win 1040, options [nop,nop,TS val 757640139 ecr 28558387], length 38
18:15:59.627770 IP 192.168.1.58.22 > 192.168.0.75.56615: Flags [.], ack 39, win 1810, options [nop,nop,TS val 28558388 ecr 757640139], length 0
(далее, видимо, плата что-то нам отправляла, но мы ничего не получали)

Вот попытка запроса по HTTP:

18:17:00.475280 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [S], seq 1347444039, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 757700987 ecr 0], length 0
18:17:00.475718 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [S.], seq 1981456750, ack 1347444040, win 14480, options [mss 1460,sackOK,TS val 28618808 ecr 757700987,nop,wscale 3], length 0
18:17:00.475758 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, options [nop,nop,TS val 757700988 ecr 28618808], length 0
18:17:00.475897 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757700988 ecr 28618808], length 301
18:17:00.706245 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757701218 ecr 28618808], length 301
18:17:00.965583 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757701478 ecr 28618808], length 301
18:17:01.288082 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757701800 ecr 28618808], length 301
18:17:01.733221 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757702245 ecr 28618808], length 301
18:17:02.414970 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757702927 ecr 28618808], length 301
18:17:03.576607 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757704089 ecr 28618808], length 301
18:17:05.700559 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757706213 ecr 28618808], length 301
18:17:09.743590 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757710256 ecr 28618808], length 301
18:17:10.476651 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0
18:17:10.477041 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28628739 ecr 757700988], length 0
18:17:17.626537 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757718139 ecr 28628739], length 301
18:17:20.476590 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0
18:17:20.476938 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28638668 ecr 757700988], length 0
18:17:30.476657 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0
18:17:30.476941 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28648598 ecr 757700988], length 0
18:17:33.193606 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [P.], seq 1:302, ack 1, win 1040, options [nop,nop,TS val 757733706 ecr 28648598], length 301
18:17:40.481933 IP 192.168.0.75.41943 > 192.168.1.58.80: Flags [.], ack 1, win 1040, length 0
18:17:40.482262 IP 192.168.1.58.80 > 192.168.0.75.41943: Flags [.], ack 1, win 1810, options [nop,nop,TS val 28658533 ecr 757700988], length 0

Значения FrameSizeLimit в регистрах 0x0a80xx00 коммутатора были правильные.

Перезапись регистров командой /etc/init.d/dxsetup start не помогла. Рестарт swd не помог.

Помог софт-ресет коммутатора командой phyctl writedx 0x00000058 0x00ff4003, причем в процессе этого ресета не инициализировались ни таблицы, ни регистры. Сразу после записи в регистр 0x00000058 большие пакеты начали проходить.

[san]

Кажется Влад воспроизвёл его снова. Воспроизвелось после случайного кольцевания трафика между портами коммутатора.
192.168.1.104 (шлюз блоке настроен не корректно, поэтому подключиться можно только из подсети 192.168.1.0)

[roman_zhur]

Схема подключения:

Шаги по воспроизведению:

1. На Блоке 1 и Блоке 2 можно очистить конфигурацию.
2. Настроить RSTP:
   2.1 изменить для первого блока bridge priority так, чтобы блок стал корневым;
   2.2 на обоих блоках прописать для GE-12 в первом слоте path cost 10; для GE-12 в третьем слоте - path cost 100; поставить чекбоксы enabled.
3. Блок 1 и Блок 2 соединить согласно схеме через медные порты плат GE-12 с помощью патчкордов.
4. Дождаться, когда RSTP отработает (кольцо разорвется, один из портов на GE-12 будет заблокирован). Состояние показано на скриншотах block1_rstp.png и block2_rstp.png.
5. Достать патчкорд из GE-12 на первом месте. Дождаться, когда порт перейдет в состояние forwarding с ролью designated. На скриншотах 1-3 изменение состояний на Блоке 2.
6. Вставить патчкорд обратно в ту же GE-12 на первом месте.

[san]

Replying to roman_zhur:

Шаги по воспроизведению:

Т.к. Роман, кажется, научился воспроизводить баг, тикет переоткрываю

[alx]

Replying to san:

Т.к. Роман, кажется, научился воспроизводить баг, тикет переоткрываю

Ты забыл переоткрыть тикет. :)

[alx]

Replying to roman_zhur:

Шаги по воспроизведению:

2. Настроить RSTP:
   

Верно ли я понял, что без RSTP проблема не воспроизводится?

[alx]

Replying to roman_zhur:

Схема подключения:

Платы GE-12 являются ли обязательным элементом? Если исключить их из схемы (то есть если соединять патчкордами непосредственно платы SW-01), то проблема не воспроизводится?

[roman_zhur]

Replying to alx:

Верно ли я понял, что без RSTP проблема не воспроизводится?

Я не пробовал другие способы воспроизвести баг.

Платы GE-12 являются ли обязательным элементом? Если исключить их из схемы (то есть если соединять патчкордами непосредственно платы SW-01), то проблема не воспроизводится?

Я не пробовал менять платы GE-12 на другие платы. Если нужно, могу попробовать воспроизвести баг с платами PE-04/PE-14.
Если соединить только SW-01, то при отключении патчкорда порт SW-01 переходит в состояние "down", RSTP не работает с этим портом, баг не воспроизводится.

[alx]

Replying to roman_zhur:

Если соединить только SW-01, то при отключении патчкорда порт SW-01 переходит в состояние "down", RSTP не работает с этим портом, баг не воспроизводится.

А, да, разумно.

Но соединение между GE-12 в слотах 3 в процессе эксперимента не разрывается. Логично предположить, что эти две платы можно исключить из эксперимента, заменив прямым соединением плат
SW-01. Однако мне в такой схеме воспроизвести проблему не удалось. Проведи, пожалуйста, эксперимент, в котором вместо GE-12 в слотах 3 используется прямой линк между SW-01. Примерно так:

[roman_zhur]

провел эксперимент по твоей схеме.
в первом случае: я соединил медным патчкордом платы GE-12 на первых местах и порты eth2 на SW-01. повторил шаги, как в коммент 5. баг не воспроизвелся.
во втором случае: я соединил медным патчкордом платы GE-12 на первых местах и порты eth1 на SW-01. повторил шаги, как в коммент 5. баг воспроизвелся.

[alx]

Replying to roman_zhur:

в первом случае: я соединил медным патчкордом платы GE-12 на первых местах и порты eth2 на SW-01. повторил шаги, как в коммент 5. баг не воспроизвелся.
во втором случае: я соединил медным патчкордом платы GE-12 на первых местах и порты eth1 на SW-01. повторил шаги, как в коммент 5. баг воспроизвелся.

Для справки:

• порты 8 (eth1 на морде SW-01) работают в режиме SGMII.
• порты 9 (eth2 на морде SW-01) работают в режиме 1000BASE-X (это порт с SFP).
• порты, соединенные с платой GE-12, работают в режиме SGMII.

Закрадывается подозрение, что воспроизведение проблемы зависит от того, в каком режиме работает порт - SGMII или 1000BASE-X.

@roman_zhur, уточни, пожалуйста, в двух последних экспериментах использовались платы SW-01 с SFP?

[roman_zhur]

да, в порты eth2 обоих SW были установлены SFP BaseT

[san]

Этот баг мне кажется достаточно серьёзным.
Попытка пользователем включить RSTP с большой вероятностью приводит к переходу платы в неработоспособное состояние.
Я недавно, проводя обучение, демонстрировал RSTP и естественно наткнулся на этот баг.
Надо чинить или придумывать обходное решение.