Итак есть: DES-3226, прошивка 6.00.113.
Для DEFAULT_VLAN все порты Egress, все галки Tag сняты, VID=1.
Каждому порту присвоен PVID равный его номеру. Созданы VLANы c VID от 2 до 24, в каждый из которых включено 2 порта: 1ый порт и порт с номером, равным VID. Для обоих портов в каждой из этих VLAN снята галка Tag и поставлена галка Egress.
Сделано это для того, чтобы обмен трафиком между пользователями, сидящими за разными портами (со 2го по 24ый), был возможен _только_ через шлюз, подключенный к 1му порту. (Аналогично traffic segmentation. Просто когда это настраивалось несколько портов надо было выделить еще в одну изолированную VLAN, а traffic segmentation в DES-3226 включается только сразу на все порты)

Задача: надо в полностью автоматическом режиме отследить когда и на каком порту появляется устройство с определенным, известным MAC. Обращаю внимание - не примязать MAC к порту (это я умею ), а именно _залогировать_ когда и где.
К сожалению в логе свитча пишется скудная информащия. Логируются только попытки соединения админа и PortUp/PortDown. Через Web интерфейс можно посмотреть текущую таблицу MAC адресов с указанием к какому порту какой MAC приписан. Однако через D-View 5.1 сходу до этой информации добраться не смог.

Может кто-то подскажет способ автоматизации решения этой задачи?

PS To D-Link: А вот на www.dlink.com.tw, куда меня упорно посылал D-View, в саппорте уже есть такая строчечка:

Hot Firmware
DES-3226 Firmware 6.00.123

С нетерпением буду заглядывать на ftp.dlink.ru

Если не секрет, а зачем это нужно?
Может быть вместо покупки маршрутизатора можно это решить другим путём?

На самом деле задачка решается двумя способами, в зависимости от масштабов:

если за каждым портом потенциально возможно не более 10 компьютеров, то можно просто включить port-security на каждом порту, с автообучением на 10 адресов на порту в режиме DeleteOnReset. Соответственно, позже просматривать таблицу мак-адресов на коммутаторе, где будет видно на каком именно порту засветился искомый мак. Но в этом варианте точное время появления установить нельзя, увы, это свитч не запоминает.

Второй вариант заключается в использовании программулины, которая через определённый интервал времени, меньший или равный mac aging time (300 секунд по умолчанию), "снимает" по SNMP через BRIDGE-MIB или Q-BRIDGE-MIB с коммутатора полную таблицу мак-адресов и соответственно ищет в ней искомый мак, при нахождении пишет в лог или отчёт посылает. Вообщем, дело вкуса

Я что-то подобное когда-то давно писал, ещё для допотопных коммутаторов SVEC FD1310, скрипт на PHP отслеживал появление новых мак-адресов в сетке на управляемых коммутаторах, и перемещение по портам, ежели такое имело место быть. При нахождении чего-то новенького, слал отчёт. Сделано это было на PHP+Mysql+UCD-SNMP4 под FreeBSD. Ежели интересно, могу в принципе поделиться. С DES-3226, правда, не проверял, но по-идее должно работать, вроде BRIDGE-MIB (RFC1493) заявлен как поддерживаемый.

А касательно прошивки кстати 123й, я решил пробежаться "вперёд паровозного дыма" и влил его в один коммутатор. В "лабораторных условиях" всё вроде было нормально, как установили в сеть (около 1000 машин) - резко интерфейс управления стал тормозить, я испугался, и быстренько откатился на 113. Тормозить перестало. Вообщем, чёто странно как-то... Надо будет ещё поэкспериментировать на след. неделе.

2 Lexx:
О первом варианте как-то и не подумал... Но в силу нашей специфики он сейчас не применим. 8( А с SNMP спасибо - буду хоть теперь знать в каких мибах искать.

По поводу тормозов веб-интерфейса вчера у нас тоже странность была - DES-3226 отказались вообще отвечать по IP. Пинги на устройства не проходили. При этом какой-либо особой нагрузки на сеть вроде бы небыло. Посмотреть с консоли что происходит вчера к сожалению не мог, а к сегодняшнему утру все нормализовалось. Странно что оба свитча себя так повели.

2 Arkadi, Goblins Chief:
Зачем нужно? Элементарно. Возможно была ошибка в конфигурировании устройства (свитча кстати а не маршрутизатора), которая могла позволить выполнить подмену MAC-IP одного из клиентов. Прежде чем элементарно закрыть дырку хотелось бы попробовать заловить "редиску" и применить санкции дабы другим было неповадно.

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

В подобных случаях неплохо иметь в подсети снифферок, для оперативного отслеживания состояния... Тогда точно можно говорить о нагрузке в сети...[/quote]

Да есть такое дело. Мелькало на форуме несколько раз. Наблюдал и сам неоднократно. По IP не зайти, если дать трассу, проходящуюю через свич
1 <10 мс <10 мс <10 мс 192.168.0.129
2 <10 мс <10 мс <10 мс 195.201.33.193
3 16 ms 16 ms 15 ms 192.168.0.33
4 15 ms 32 ms 15 ms 192.168.0.12
5 1859 ms 1703 ms 1969 ms 192.168.0.197 ------ это адрес на свиче
6 31 ms 16 ms 15 ms 10.26.19.21

и для полноты картины, если в этот момент с консоли сказать enable web - то все, помогает только питание
Еще немного информашки наберется - вынесу в отдельый топик.. что-то тут непонятно

Да есть такое дело. Мелькало на форуме несколько раз. Наблюдал и сам неоднократно. По IP не зайти, если дать трассу, проходящуюю через свич
1 <10 мс <10 мс <10 мс 192.168.0.129
2 <10 мс <10 мс <10 мс 195.201.33.193
3 16 ms 16 ms 15 ms 192.168.0.33
4 15 ms 32 ms 15 ms 192.168.0.12
5 1859 ms 1703 ms 1969 ms 192.168.0.197 ------ это адрес на свиче
6 31 ms 16 ms 15 ms 10.26.19.21

и для полноты картины, если в этот момент с консоли сказать enable web - то все, помогает только питание
Еще немного информашки наберется - вынесу в отдельый топик.. что-то тут непонятно [/quote]
Собирите статистику, логи... и на почту... скорее всего, прямо в Москву...

Эээ... чё т я не понял, какая ещё трассировка может быть через свитч второго уровня? Или это плавно к 3326 перешли?

По поводу 3226 ещё кстати вопросик, всё руки не доходят написать: когда на порту включается port-security, то с этого порта сам свитч перестаёт быть виден. В мануале это поведение не описано. Вот я собственно понять не могу - это bug или feature?

[quote="Lexx"]Эээ... чё т я не понял, какая ещё трассировка может быть через свитч второго уровня? Или это плавно к 3326 перешли?
/quote]

..ну фича уж больно похожая

А Admin State на порту enabled/disabled? К сожалению нет под рукой коммутатора, чтобы проверить...

Разумеется, admin state enabled. И сквозь этот порт всё работает. Т.е. в "лабораторных условиях" собрана такая конфигурация:

Все порты включены, VLAN всего один, PVID везде 1
Порт 1 подключен к сервачку, port security Disabled
На портах 2-24 включено port-security, max learning address везде 1
Рабочая станция подключается к любому понравившемуся порту (например, 13)

IP на коммутаторе - 172.20.1.206/24
IP на сервере - 172.20.1.1/24
IP на рабочей станции - 172.20.1.31/24

ping с сервера проходит и на рабочую станцию, и на коммутатор.

С рабочей станции ping проходит только на сервер, коммутатор не пингуется и даже не отображается в таблице arp.

Если делать ping test с коммутатора, то сервер также отлично пингуется, а рабочая станция нет. При этом сниффер на рабочей станции при фильтрации по мак-адресу коммутатора показывает строки вида:



После выключения port security на 13м порту все друг друга видят.

Похожие фичи к сожалению проявляются и на других устройствах D-Link. Сейчас вот заметил что из 2ух одинаковых беспроводных точек доступа 900AP+, работающих в режиме моста друг с другом одна "пропала". Ее не только не видно по IP - ее не находит и утилита-менеджер. При этом связь есть, линия прекрасно работает. Что удивительно "пропала" ближняя точка, в порт которой собственно воткнут мой свитч. А дальнюю точку я вижу как раз чечез беспроводный сегмент.