[mikezzzz]

Добрый день,

 

имеется кольцо, состоящее из рута (Cisco) и 5 DGS 3420/3426. С DGSов живет множество более мелких DES и тп. Через DGS реализуется маршрутизация до подсетей с DESами (с помощью пары десятков IpIf на каждом из DGS).

Все коммутаторы мониторятся на доступность с помощью ICMP. В последнее время некоторые коммутаторы DES, живущие с дальнего, от рута, DGS 3420 периодический не пропинговываются, что вызывает ложное срабатывание системы мониторинга. На интерфейсах ошибок и дропов нет, кольцо работает стабильно.

 

Пробовали обновлять/менять DGS 3420, результат тот же.

 

О коммутаторе:

 

Device Type : DGS-3420-28SC Gigabit Ethernet Switch

MAC Address :

IP Address : x.x.x.x (Manual)

VLAN Name : manag

Subnet Mask : 255.255.255.0

Default Gateway : x.x.x.1

Boot PROM Version : Build 1.00.006

Firmware Version : Build 1.70.B018

Hardware Version : B1

Serial Number :

System Name :

System Location :

System Uptime : 4 days, 10 hours, 12 minutes, 43 seconds

System Contact :

Spanning Tree : Enabled

GVRP : Disabled

IGMP Snooping : Disabled

MLD Snooping : Disabled

RIP : Disabled

RIPng : Disabled

VLAN Trunk : Disabled

Telnet : Enabled

Web : Disabled

SNMP : Enabled

SSL Status : Disabled

SSH Status : Disabled

802.1X : Disabled

Jumbo Frame : On

CLI Paging : Disabled

MAC Notification : Disabled

Port Mirror : Disabled

SNTP : Enabled

VRRP : Disabled

HOL Prevention State : Enabled

Syslog Global State : Enabled

Single IP Management : Disabled

Password Encryption Status : Enabled

DNS Resolver : Disabled

 

 

Дополнительно известно, что с данного DGS живет несколько больше DES, чем с других. ARP таблица процентов на 30% поболее.

Так же, если несколько раз настойчиво сказать clear arpentry, то часть свичей DES не пропингуется.

 

Утилита arping показала следующее:

 

arping в менеджмент сети до "нормального" DGS 3420

D:\>arp-ping.exe -s 10.10.10.1 10.10.10.2 -t -n 20
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 2.375ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.032ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.090ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.044ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.063ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.010ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.007ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.060ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.046ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.042ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.056ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.026ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 9.895ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.065ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.033ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.305ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.042ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.050ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.033ms
Reply that AC:F1:DF:93:36:00 is 10.10.10.2 in 10.038ms

 

arping до проблемного DGS 3420

D:\>arp-ping.exe -s 10.10.10.1 10.10.10.3 -t -n 20
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 4.441ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1120.029ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 4.021ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1120.115ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 2.397ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 10.036ms
No response.  3120.011ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 2120.806ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 4.111ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1120.044ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 4.030ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1120.034ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 4.111ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 10.028ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1120.022ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 4.020ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 10.077ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 10.015ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1120.014ms
Reply that 6C:19:8F:29:7E:00 is 10.10.10.3 in 1113.938ms

 

Show cpu port ничего интересного, похожего на flood каким-либо служебным трафиком, не показывает.

Cpu utilization особых спайков так же не рисует. QoS не применяется. Кольцевые линки 10G и перегруза не фиксируется.

На DGS 3420 используется только один статичный default маршрут до циски.

 

Кроме проблемы с мониторингом, других вопросов к данному сегменту сети нет.

 

upd

 

выяснилось следующее, в кольце из 6 DGS 3420/3426, на коммутаторе где разрыв STP (порт в BLK) и дроп пакетов, и происходит данная проблема, касается и 3420 и 3426, на разных прошивках.

Вопрос что с этим делать.

[mikezzzz]

отписывал на D-link форуме. но там все тухлоглухо

 

что еще удалось узнать...

 

1) если кольцо разорвать (положить порт), то проблема уходит

2) если снять большинство VLAN с противположного от Blocked порта, то проблема уходит

3) на порт валится около 5к пакетов мультикаста (igmp выключен), если мультикаст убрать (см п.2), то проблема остается

4) если использовать arping без опции broadcast (через unicast), то проблема не наблюдается, если использовать с опцией broadcast, то ответы доходят через раз

5) пробовали снять span с порта в состоянии Blocked, заметили, что можно снимать как RX так и TX направление, хотя никакого TX там нет :)

 

возникает странное чувство, что DGS перед тем как дропнуть входящий трафик на Alternate порт, затрачивает какие-то свои ресурсы на его обработку

[NikAlexAn]

А на cisco при этом проц в полку не упирается?

В управляющих вланах на руте и на DGS-ах proxy-arp выключен?

[mikezzzz]

на руте проблем не фиксируется, proxy arp проверял, везде выключен (на DGS и на руте), снифил управляющий влан - кроме arp по броадкасту ничего интересного не увидел

[rdc]

У свича есть внутренний шейпер броадкастов в сторону его процессора.

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

Это начинает нарушать работу ARP в отношении маршрутизации самим свичом.

Размыкание кольца приводит к тому, что полоса броадкастов в адрес процессора этого свича падает вдвое, и из-за этого проблема и прекращается.

 

Сделано это всё для предотвращения перегрузок процессора в высоконагруженных сетях.

ARP умеет неоднократно перезапрашивать, делает это заранее, поэтому на обычном транзитном трафике это отражаться не должно.

Транзитных пакетов всё это не касается, они проходят как есть.

[zhenya`]

А вылечили ли это на 3420? Арпы из транзитных планов падали одно время на цпу

[rdc]

так тут арпы не транзитные, а на интерфейсах самого свича в L3

 

впрочем, даже если транзитные падают на CPU, транзиту это никак не мешает. только управлению

[darkagent]

впрочем, даже если транзитные падают на CPU, транзиту это никак не мешает. только управлению

Увы нет. В какой-то момент железка рискует превратиться в тыкву, убив при этом весь транзит. По этой причине когда-то давно пришлось отказаться от 3620-28sc/3420-28sc на серьезном транспорте. Правда на тот момент софт еще относительно сырой был, и сейчас все может уже серьезно поменялось, но осадочек остался.

[mikezzzz]

Добрый день, друзья!

 

Размыкание кольца приводит к тому, что полоса броадкастов в адрес процессора этого свича падает вдвое, и из-за этого проблема и прекращается.

 

мне кажется это поведение немного странным, разве состояние Blocked не подразумевает жесткого дропа всего кроме BPDU?

 

самое интересное, что есть кольцо бОльшего размера и данная проблема на "конечном" DGS не фиксируется

 

кол-во pps на проблемном дгс

Unicast RX            10624368                      15
Multicast RX          2480179048                    5026
Broadcast RX          93429974                      231

 

и на DGS из схожего кольца

Unicast RX            641711573                     850
Multicast RX          1357240329                    509
Broadcast RX          1592559672                    234

 

т.е. broadcast примерно на одном уровне.. (отдельно стоит заметить, что на одном из DGS еще и кучка Unicast - lol what??)

 

в целом, я с этой теорией broadcastа согласен, по поведению очень похоже, но не понятно почему Cpu interface filtering не помогает при зарезании broadcast в транзит VLAN

[FATHER_FBI]

Была у меня схожая проблема в кольце, решилась она после того как на всех участниках кольца по выключал ихние фишки типа DDOS Protection, кстати по рекомендации инженеров от D-Link, они сами сказали что когда строится кольца с длинками, лучше вырубать DoS Attack Prevention и им подобные.

[Butch3r]

отписывал на D-link форуме. но там все тухлоглухо

Пишите в support@dlink.ru + привлекайте регионального менеджера к решению данного вопроса.

[dmvy]

на DGS-3612/27 при количестве ARP больше 1000 начинаются проблемы на L3-уровне. В том числе растет нагрузка на CPU. По этой причине оказались от L3 на этих коммутаторах в пользу cisco 3550g.

В вашем случае попробуйте увеличить время жизни arp-записи, если она смотрит только на коммутаторы, которые не часто меняются.

[mikezzzz]

отписывал на D-link форуме. но там все тухлоглухо

Пишите в support@dlink.ru + привлекайте регионального менеджера к решению данного вопроса.

 

давно обращались, нам намекнули, что если даже будет ТТ, то с крайним низким приоритетом.

а воз и ныне )

к слову, пытались они воспроизвести проблему, не вышло.

предложили им в наш офис подъехать - ответ выше

Edited September 24, 2015 by mikezzzz

[Butch3r]

отписывал на D-link форуме. но там все тухлоглухо

 

Пишите в support@dlink.ru + привлекайте регионального менеджера к решению данного вопроса.

 

 

давно обращались, нам намекнули, что если даже будет ТТ, то с крайним низким приоритетом.

а воз и ныне )

к слову, пытались они воспроизвести проблему, не вышло.

предложили им в наш офис подъехать - ответ выше

 

не буду комментировать, но нам так ни разу не отвечали. В любом случае нужен ТТ, далее пишется претензия на имя директора в Москву. Очень хорошо действует )

[rdc]

мне кажется это поведение немного странным, разве состояние Blocked не подразумевает жесткого дропа всего кроме BPDU?

Для транзитного трафика - подразумевает.

А для трафика в адрес CPU - нифига не подразумевает, он же должен слушать BPDU при любом раскладе.

 

т.е. broadcast примерно на одном уровне

Мультикаст - частный случай броадкаста.

BPDU же мультикастовые.

[mikezzzz]

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

почему cpu interface filtering никак не решает проблему? шейпер работает до CPU interface filtering?

 

есть еще cpu_protect фич, для чего все эти инструменты если есть тупо шейпер который все сам делает не спрашивая никого :)

Edited September 25, 2015 by mikezzzz

[g3fox]

"состояние Blocked" У вас STP или RSTP?

5kpps мультикаста у вас на каком порту? на том, который discading? С другой стороны от этой цепочки, на DGS у вас тоже 5kpps мультикаста?

[mikezzzz]

STP Bridge Global Settings
---------------------------
STP Status           : Enabled
STP Version          : RSTP

 

про мультикаст - да

[mikezzzz]

новый апдейт )

 

нашел забавную фичу vlan_counter на DGS, посмотрел top talkers в Bcast и Mucast, обнаружилось 4 мультикаст и 12 бкаст вланов.

снес их с интерфейса напротив Blocked порта и проблема ушла, вернул мультикаст вланы - проблема не вернулась,

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

добавляешь 2-3 броадкаст влана - начинает терять arp запросы.

 

как-то так получается, вообще никак

[xcme]

После очистки ARP у вас DGS не может отправить/принять ARP-пакет или же DES на доступе не может ответить на ARP-запрос?

Включите на коммутаторах DES функцию Gratuitous ARP и выставьте минимальные таймеры. В результате коммутаторы начнут анонсировать себя сами. На DGS разрешите прием таких ARP (если он настраивается, но это вообще просто проверить). После этого снова обнулите таблицу ARP и станет понятно кто именно не справляется.

 

А так я согласен с rdc. Надо контролировать пакеты, попадающие на обработку CPU. Когда залочил всякий сомнительный трафик с такой проблемой больше не сталкивался.

Edited September 25, 2015 by xcme

[g3fox]

попадающие на обработку CPU

 

Так у ТС они не то чтобы на CPU попадать.. они в input buffer дропаться должны.

Там порт в состоянии discrading.

 

Кстати, я вспомнил, как я помогал нашим инженерам СПД поборть проблему.

В какой-то момент у нас стало плохо нескольким коммутаторам DGS-3420-2[68].

Причём они могли находиться в цепочке, три штуки друг за другом. Могло быть плохо крайним, а в другой цепочке - наоборот.

 

Долго не могли понять в чём проблема. В итоге нашли некоторую зависимость. Проблема отсутствовала на коммутаторах с прошивкой "Build 1.00.B026".

Для теста накатили её на проблемном коммутаторе, и он стал нормально работать.

Далее я начал сравнивать конфиги, и зацепился взглядом за настройки IPMB.

Потыкался на коммутаторе, и выяснил, что версии IPMB разные:

Firmware Version           : Build 1.70.B017

Command: show address_binding

Roaming state     : Enabled
Trap/Log          : Disabled
DHCP Snoop(IPv4)  : Disabled
DHCP Snoop(IPv6)  : Disabled
ND Snoop          : Disabled
Autosave state    : Enabled
Save Filename     : dhcpsnp.cfg
Function Version  : 3.95


Firmware Version           : Build 1.00.B026

Command: show address_binding

Trap/Log          : Disabled
DHCP Snoop(IPv4)  : Disabled
DHCP Snoop(IPv6)  : Disabled
ND Snoop          : Disabled
Function Version  : 3.92

 

В итоге мы по-быстрому задаунгрейдили прошивки и пошли спокойно спать.

А на следующий день сделали удалённое зеркало, и впалили в транзитном влане, который не терминируется ни на одном из проблемных коммутаторов по 3-му уровню, большой поток ARP-пакетов, примерно 2500 pps.

Протестировали в лабе данную ситуацию на разных версиях софта - в последнем, на тот момент, проблемы тоже не было (DGS3420_Run_1_70_B026).

На 1.70.B024, 1.70.B017, 1.50.018 - были проблемы, а на 1.70.B026 и 1.00.B026 Всё замечательно.

 

Попробуйте, ради интереса одну из тех, с которыми у нас проблема решалась.

[rdc]

Там порт в состоянии discrading

Повторюсь - он discarding только для транзита/роутинга.

CPU его всё равно слушает - на предмет BPDU.

[Butch3r]

hol включен или выключен?

[mikezzzz]

включен