unicast пакеты попадают на все порты коммутатора

[metalsoft]

Доброго времени суток!

Есть в сети видеорегистратор 10.128.0.107/24. Так же на одном из домов стоят камеры 10.131.15.(25 и 26)/24, подключенные к коммутатору 10.131.15.254/24. Все работает, как надо. Но когда по какой-то причине 10.131.15.254 недоступен, с видеорегистратора начинают массово валиться пакеты TCP Retransmission, причем валятся они на совершенно левый коммутатор (наш офисный) на все порты. Пакеты Unicast, src ip 10.128.0.7, dst ip 10.131.15.25(26), мак адреса тоже правльные (мак роутера и мак камеры). КАК? и почему они попадают на офисные компы с адресами 10.128.1.0/24??? В сети много свитчей и камер, но такую картину наблюдаю только, когда недоступен этот конкретный.

[VolanD666]

Как версия: переполняется таблица на коммутаторе и он начинает штормить

[passer]

скорее это unknown unicast шпарит

 

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

[bqd]

unknown unicast возникает когда dst-mac нет в FDB (CAM) возможно камеры молчат и запись в CAM протухает

поток этой беды можно ограничить если внести статическую запись мак адресов камер в конфиг свича

как то так

mac-address-table static 0011.2233.4455 vlan 100 interface ethernet 1/2

[metalsoft]

Спасибо за подсказки! Понятно, в какую сторону копать. Остался только один вопрос: почему этого не происходит, когда падают другие коммутаторы? Свитчей и камер такой модели/прошивки в сети много, но ситуация повторяется второй раз и именно с этим свитчом.

[VolanD666]

18 часов назад, bqd сказал:

unknown unicast возникает когда dst-mac нет в FDB (CAM) возможно камеры молчат и запись в CAM протухает

поток этой беды можно ограничить если внести статическую запись мак адресов камер в конфиг свича

как то так

mac-address-table static 0011.2233.4455 vlan 100 interface ethernet 1/2

Очень плохой совет, не делайте так...

 

30 минут назад, metalsoft сказал:

Спасибо за подсказки! Понятно, в какую сторону копать. Остался только один вопрос: почему этого не происходит, когда падают другие коммутаторы? Свитчей и камер такой модели/прошивки в сети много, но ситуация повторяется второй раз и именно с этим свитчом.

Ну чтобы ответить на этот вопрос надо видеть схему, надо понимать на чем построено, надо представлять какие технологии используются. И исходя из этого, сделать нормальный дебаг и придумывать решение. А так это просто гадание.

[Pinkbyte]

On 8/21/2020 at 9:41 AM, metalsoft said:

Спасибо за подсказки! Понятно, в какую сторону копать. Остался только один вопрос: почему этого не происходит, когда падают другие коммутаторы? Свитчей и камер такой модели/прошивки в сети много, но ситуация повторяется второй раз и именно с этим свитчом.

Потому что другие коммутаторы(возможно других вендоров/моделей/аппаратный ревизий/прошивки/еще_чего_то_сложно_гадать_когда_они_не_озвучены_вообще) могут иметь другую логику таймаута записей в FDB

[sheft]

зарезать на коммутаторах unknown unicast -если адресат недоступен/отключен, значит трафик на него и не нужен

[NiTr0]

В 21.08.2020 в 09:41, metalsoft сказал:

Свитчей и камер такой модели/прошивки в сети много, но ситуация повторяется второй раз и именно с этим свитчом.

на свиче fdb запись протухает раньше чем arp запись в камере. если есть крутилка - увеличьте таймаут изученных мак-адресов.

[pingz]

5 копеек 

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

 

З.ы. так же есть такая вещь как ваершарк можно посмотреть, что хочет регистратор. Так же можно, заменить камеры и те которые стояли поставить в офисе и потестить.

З.з.ы. сегментация сети залог успеха большой сети.