У меня установлен DES-3828, на нескольких портах которого прописаны IP адреса вида 192.168.ХХХ.1, но при сканировании клиентских подсетей в списке адресов появляется адрес вида 192.168.ХХХ.0, который судя по всему оказывается на коммутаторе.

Т.е. это нормальный интерфейс,

Обмен пакетами с 192.168.124.1 по с 32 байтами данных:
Ответ от 192.168.124.1: число байт=32 время=1мс TTL=255
Ответ от 192.168.124.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.124.1: число байт=32 время=1мс TTL=255
Ответ от 192.168.124.1: число байт=32 время=1мс TTL=255

а это откуда-то появившийся

Обмен пакетами с 192.168.124.0 по с 32 байтами данных:
Ответ от 192.168.124.0: число байт=32 время=1мс TTL=255
Ответ от 192.168.124.0: число байт=32 время=7мс TTL=255
Ответ от 192.168.124.0: число байт=32 время=1мс TTL=255
Ответ от 192.168.124.0: число байт=32 время=1мс TTL=255

Что с этим делать и нормальное ли это? Если не нормально, то как убрать ложный интерфейс?

Маска на ipif какая?

255.255.255.0

Версия прошивки?

если не ошибаюсь то 192.168.134.0 то же самое что 192.168.134.255 то есть это пакет с мак-адресов назначения ff-ff-ff-ff-ff-ff, эдакий бродкастовый пинг. )

Build 3.00.B57 (с аналогичной прошивкой на 3852 такой же глюкс)

Я вычислил когда это возникает. Для моделирования такой ситуации надо сделать два IP интерфейса на vlan, и у того, который Secondary = True будет возникать такой IP адрес, причем в моем случае самое зло не в том что возникает IP, а в том что он маршрутизируется за машину клиента

пример:
1 <1 мс <1 мс <1 мс 192.168.100.19
2 1 ms 1 ms 1 ms 192.168.100.93
3 1 ms 1 ms 1 ms 192.168.124.102
4 1 ms 1 ms 1 ms 192.168.124.0 - здесь такого адреса на самом деле нет, а если клиент 124.102. выключится, то система найдет другого клиента за которого закинет этот адрес.

Если клиентов нет вообще, то сам коммутатор ответит нам, это выглядит так

1 2 ms <1 мс <1 мс 192.168.100.19
2 1 ms 1 ms 1 ms 192.168.100.93
3 1 ms 1 ms 1 ms 192.168.26.0

Как бы это пофиксить?

система никого не ищет, а принимает за ответ того чей придет первый.

когда вы делаете tracert 192.168.124.0 свич посылает ICMP пакет с dst_mac ff:ff:ff:ff:ff:ff и кто первый ответит от того типа и ответ (так винда показывает),
фряха если не ошибаюсь показывает все ответы то есть запрос один а ответов несколько. Если клиентов нет то ответит сам коммутатор по той причине что винда показывает только один ответ, а коммутатор отвечает самым последним (CPU слабый по сравнению с компами).
Это нелья пофиксить, так работает протокол, вопрос в том зачем вам сканировать адреса .0 и .255 ?

Просто интересно почему такого нет на интерфейсах, у которых Secondary = False? Нулевой адрес он конечно же есть, но он не отвечает и не должен отвечать.

Мне кажется такого вообще бы не должно было быть, как в случае с ответами от Secondary = True интерфейсов.

Попробуйте пожалуйста прошивку которую я Вам выслал.

Спасибо. Попробую. По результатам отпишусь.

Вобщем перепрошил, но адрес вида 192.168.XXX.0 на интерфейсе Secondary = True остается и по прежнему трассируется за клиента.

Появилась отдельная настройка на Zero TTL, чтобы трейс не зависел от SIM, ну и еще кое-что по мелочи.

С новой прошивкой постоянный EXHAUSTED mode и высокая загрузка CPU. Сеть вечером под нагрузкой практически ложится.

Откатываюсь обратно на 3.00.b57.

А у Вас управление в отдельном VLAN-е?

Конечно в отдельном.

Коммутатор выполняет роль роутера собирая в себя IP подсети (интерфейсы коммутатора являются шлюзами клиентов) и маршрутизирует их. Трафик вечером на основном гигабитном интерфейсе в сторону клиентов от 200 до 300 МБит/с.

Т.е. правильно ли я понял что интерфейс System не учатствует в процессе маршрутизации клиентского трафика и доступ в управляющую подсеть из других запрещён?

Да, совершенно верно. Доступ к System запрещен всеми возможными способами (он в отдельном vlan, стоят запреты на обращение в подсеть System в ACL и CPU Interface Filtering), только один компьютер напрямую подключается к нему отдельным кабелем для управления.

На прошивке 3.00.b57 все снова заработало как надо (если не учитывать странного поведения secondary = true интерфейса о котором велась речь изначально).

Но этот интерфейс не исчез и на новой прошивке.

Я правильно понимаю что в новых прошивках типа 4.05.B09 коммутаторы могут являться DHCP серверами?

Правильно понимаете. А Вы не могли бы подробно описать топологию и выслать конфиг той конфигурации где у вас сразу проявилась высокая загрузка?