Думаю нестоит терять подобную тему из виду , или создать отдельную обсуждениее именно прошивок 3627 и их найденых глюках.
Подитожу последние тесты разных прошивок.
всё долго радовались прошивке 2.50.T31 , вобщем то она оказалось самой стабильной из всех бывалых до неё и некоторых после.
Но я умудрился ввести её в ступор при помощи BPR :
т.е имеем acl
create access_profile profile_id 10 ip source_ip_mask 255.255.0.0 destination_ip_mask 255.255.0.0 tcp dst_port_mask 0xFFFF

config access_profile profile_id 10 add access_id auto_assign ip source_ip 172.22.0.0 destination_ip 64.12.0.0 tcp dst_port 5190 port 1-24 permit priority 5 replace_priority replace_dscp 59 rx_rate no_limit

config access_profile profile_id 10 add access_id auto_assign ip source_ip 172.22.0.0 destination_ip 205.188.0.0 tcp dst_port 5190 port 1-24 permit priority 5 replace_priority replace_dscp 59 rx_rate no_limit


и к нему BPR
create policy_route name ICQ
config policy_route name ICQ acl profile_id 10 access_id 1 nexthop 172.22.100.1 state enable

create policy_route name ICQ205
config policy_route name ICQ205 acl profile_id 10 access_id 2 nexthop 172.22.100.1 state enable


после создания правил всё ОК , а вот при быстром включении policy_route через web интерфейс 3627 ушёл в себя и не вернулся .
тоже самоее если и через telnet забить подряд 2 последнии команды , причем отваливается не сразу , а всё продолжает работать пока вся arp таблица не почистится , т.е 5 минут еще может проработать , вобщем весь 3й уровень вываливается , после reboota всё начинает работать , без policy_route т.к соханить то неуспели.

после многих испытаний неоднократно откатывался на Т31 , после поставил 2.51-B13 и вроде всё тоже работает что работало на Т31 + BPR с темже условием работает нормально , вот только раздражали в часы пик переодические задержки в сети и ping до устройство как через 8 спутников , можно было и смерится со всем , но мы не из простых и продолжаем испытывать новые версии прошивок ( ведь всегда можно вернутся на предыдущию ).

На днях дело дошло и до 2.52-B44 , сначало порадовался что и приорететы нормально заработали и вроде потери все прикратились , да и прошивка имеет кучу дополнительных возможностей и настроек ( жаль пока без описаний что к чему ).
И тут не всё хорошо , в момент интенсивной нагрузки связь вобще начало проподать , о чем и запросил может есть чего новее , на что получено предложение откатится до т31 , долго искал в чём причина и почему в определённое время ,как по расписанию - этому расписанию действительно есть место ( я про него даже забыл ) , вернёмся на кучу сообщений назад и даже во временя когда над всем трудился 3324SR и к нему были прикручена по расписанию комманда по расписанию каждые 2 час выполнять clear arp , она и была оставлена в целях знать кол-во активных устройств в сети т.к таблица вычищается медленно ( или уже вычещалась ).
Именно clear arp и уводил 3627 с прошивкой 2.52-B44 в ступор примерно на 2 минуты , когда в ARP таблице порядка 1500 ( или более ) соотношений , а к раннему утру когда там мало кого процесс вроде проходил не сильно болезненно .
Пока откатыватся на предыдущие не буду , отключил таймер очистки , ведь в 2.52-B44 много полезностей в частности еще заметил
upload tech_support_toTFTP - сохраняет много всей информации .

Поэтому вопрос почему при clear arp ему становится плохо и он теряет весь L3 пока видемо не заполнится вся APR таблица , думаю эту ситуацию както можно смоделировать если найдёте чем забить 1500 записей и потом выполнить очистку , при этом через коммутатор маршрутизируется порядка 200 000 пакетов в сек.

т.к скрипт с таймером вырубил надо понять как данный свичь очищает свою arp таблицу сам по 1 ip как 3324 или всёже кусками по простою . ( нехочется когда-нибудь встретить CPU Load 100% из-за перепонения )

Может еще у кого есть что добавить по прошивкам в каких и чего плохо или хорошо работает .

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

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

стек 3 х 3627g hw: 1a1g, topology: duplex ring, fw: r252b021, rstp, миллион интересных строчек в логе
Spanning Tree port role change (Instance:0, Port:2:26) RootPort->DesignatedPort
Spanning Tree port role change (Instance:0, Port:3:26) DesignatedPort->RootPort
бывают и TCN...
Topology changed (Instance:0, Port:2:26)
Topology changed (Instance:0, Port:3:26)
из портов для стекирования фигурирует только 26 порт...

интересное кино, но есть другое, ещё более интересное... вынимаем из модуля воткнутого в 3:1 волокно (на самом деле любой порт из свитча с boxid:2 или boxid:3), диод гаснет, но выполнив sh ports 3:1 видим линк (обращаю внимание оптики уже нет), sh stp ports 3:1 аналогично отображает forwarding, возвращаем волокно, conf ports 3:1 state disable, диод гаснет, sh ports 3:1, port state: disabled, но в connection speed/duplex/flowctrl - 1000m/full/none... более того делаем disable stp, видим вполне логичные (при наличии петель) строки в логе - possible spoofing attack с указанием портов, отключаем все эти порты через conf portnum state disable, вот только свитч это не успокаивает... так как sh fdb port 3:1 выведет таблицу мак адресов на порту

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

после перепрошивки выполняли сброс настроек, причём в том числе и параметров стека, т.е. вообще всего...

Я занимаюсь этой проблемой и напишу Вам как будет решение.

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

Хм. Странно, но проблема с ARP у меня и на 2.50T31, и на 2.51B17, и на 2.52B44 остается.
Вкратце - свич просто не отвечает на ARP запросы от соседей на свои ip, соответственно трафик не ходит.
Если ARP запись тем или иным способом в таблице появляется, то все работает, пока она не устареет.
ACL отключали, PBR тоже.
Интерфейсов около 70, primary и secondary есть.
Нагрузка процессора 10-15%, суммарный трафик 100-200 Мбит/с
BootPROM 1.10-B09
Конфиг сбрасывали после прошивки.
В логах не пишет ничего.
Если оставить 1-2 интерфейса, то все вроде работает нормально.

Ага, после некоторого расследования выяснилась следующая интимная подробность:
3627 не отвечает на ARP запрос, пришедший от имени ip адреса, не попадающего ни в одну подсетку на интерфейсах свича.

Поясню на примере:
свич - 10.0.0.10/24, default на 10.0.0.1
сервак (линух) - 10.0.0.1/24, алиасом на этом же интерфейсе - 10.1.1.1/24

Если послать пакет от имени 10.1.1.1 на свич 10.0.0.10, то получается вот такой arp запрос:

На него 3627 не отвечает. Самое интересное, что если поднять на самом свиче алиасом 10.1.1.10/24, то даже в этом случае он не отвечает.
Отвечает только если включить proxy arp (достаточно local), но алиас все равно нужен

Не совсем ясно, чей это глюк, линуха или dlink'а, пойду RFC читать.

ну дак это логично. к нему такая сеть не подключена - куда ему слать ответ? не на шлюз же - ARP работает только в пределах одной подсети.


вот это уже действительно интересно.

_________________
LiveComm

ARP это ж не IP, шлюз тут ни при чем, ответ надо слать на MAC-адрес вопрошающего.
Все остальные серваки прекрасно справляются с подобной задачей.

Проблема с ARP решена в прошивке 2.52B44?

2 LKr:
не смотря на это ARP протокол подразумевает соответствующие поля в структуре пакета.



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

_________________
LiveComm

To DU:

Решена проблема.

Может не в тему
Добрые люди подскажите где можно взять схему блока питания DGS-3627 знаю что там стоит блок питания от Cisco 3560. Очень нужно.
если есть кинте на мыло info@lentel.ru или хотябы парт намбер этого блока питания чтоб у Cisco заказать

А зачем Вам если не секрет? У Вас с ним проблемы?

Есть необходимость запитать его через RPS. Те что предлагает Делинк неподходят. Мы используем сторонние блоки питания для бесперебойного питания DES 3526 там все сделанно и в случае проподания основного питания через дополнительный блок питания подается сигнал свичу и тот отрабатывает и посылает трап и пишит в лог что отказало основное питания и работает от резервного.

http://forum.nag.ru/forum/index.php?sho ... l=Des+3526


или дайте распиновку RPS разъема для данного типа свича. Уж очень не хочется покупать DPS-500 для опытов