dadv: (chuck)

Забавный случай.

Имеется vlan, внутри которого идёт клиентский трафик, в частности FTP.

Если клиент использует FTP пассивного режима - файлы льются нормально. Если активный - соединение для передачи данных не устанавливается, причем пакеты с 20-го порта сервера на динамический порт FTP-клиента уходят, но wireshark на стороне клиента показывает, что они туда не приходят.

Локализовал проблему до двух коммутаторов последней мили, уже в L2-сети. Один из них - Catalyst 3750G на распределении, отзеркалировал трафик с исходящего в сторону коммутатора доступа порта - пакеты эти вижу. Между этим каталистом и клиентом один единственный коммутатор доступа - D-Link DES 3200/10 (firmware 4.35.B016). Проверка локальным зеркалированием на нём показала, что с аплинка эти пакеты в свич приходят, но клиенту свич их не выдаёт.

Очевидно, что виноват D-Link. Удалили из его конфигурации все ACL - не помогло, перезагрузка после этого тоже не помогла. Обновление софта до свежей верии 4.36B009 ничего не изменило, как и последующий даунгрейд до 4.33.

Поменяли свич на AT-8000S/24 и проблема ушла.

dadv: (Default)

Хваленые коммутаторы Allied Telesyn AT-8000S радуют всё менее. Мало того, что даже на свежей прошивке у них периодически отключается MAC Learning (способа включить назад без ребута не нашел, ports security не используется, до ребута свич флудит юникастами во все порты vlan-а, и не дай бог вам сделать clear bridge - станет ещё хуже). Так ещё и оказалось, что DHCP Snooping у них включается максимум на 32 vlan-ах. Это у свичей, поддерживающих тысячу vlan и стекирование 24 и 48-портовых!
При попытке включить на 33-м (а часто и уже на 32-м) отказывается, говоря Resource Unavailable.

Ответ официальной поддержки с alliedtelesis.custhelp.com:

Yes, this is the amount of VLANs user can configure for DHCP snooping.

Please note that since DHCP snooping is using the same TCAM resources as access lists, if configuring access lists on the device, user will have less resources for the DHCP snooping VLANs.

Kind regards,
Frida May

dadv: (stopstupid)

#show spanning-tree interface Gi4/13

Mst Instance        Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
MST0                Desg BLK 200000    128.781  Dispute P2p

На сайте cisco.com описан Dispute Mechanism, но причин блокирования порта этим механизмом приведено только две: однонаправленный канал или некорректно настроенный EtherChannel.

В моём случае временное включение spanning-tree bpdufilter на этом транке приводило к разблокировнию порта и трафик начинал ходить нормально, да и портканалом тут не пахло. Причина оказалась банальна - на свиче с другой стороны линка был включен RSTP. Переключение в MSTP на той стороне проблему убрало полностью, spanning-tree на этой стороне перестал блокировать порт.

dadv: (Default)

Allied Telesyn AT-9000/28
facepalm.png )

Profile

dadv: (Default)
Choose your future

June 2017

M T W T F S S
   1234
56 7891011
12131415161718
19202122232425
2627282930  

Syndicate

RSS Atom

Tags

Style Credit

Powered by Dreamwidth Studios