[default_vlan]

Приветствую всех.

Достала ошибка в логах. 

Цитата

Sep 19 20:20:30.510: %SW_MATM-4-MACFLAP_NOTIF: Host *** in vlan 1 is flapping between port Gi0/1 and port Gi0/10

В целом, на работе сети не сказывается, но хотелось бы убрать это. 

nmap'ом собрал все маки в сети и оказалось, что некоторый cisco 3548 и 2950 имеют такой же ip, что и некоторое беспроводное оборудование + snr 2950.

 

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

Как быть?
Спасибо.

[azhur]

10 минут назад, default_vlan сказал:

некоторый cisco 3548 и 2950 имеют такой же ip, что и некоторое беспроводное оборудование + snr 2950.

Дак IP или MAC?

Одинаковых МАК-ов в одной L2-сети быть не должно.

Если оно таки есть, то или ленивые китайцы недоперемудрили, или где-то МАК вручную задан.

Ну или всё-таки неправильно данные собрали.

Какие маки-то повроряются, может "служебные" какие-то?

[pingz]

Либо петля. 

[alibek]

1 час назад, pingz сказал:

Либо петля. 

99% без "либо".

Повторяющиеся MAC-адреса — это уж совсем махровый noname.

В Cisco и SNR такого не должно быть.

[UglyAdmin]

Бывает, что убитый порт на Д-Линках разных моделей отражает пакеты назад.

В порту ничего не вставлено, а линк горит. Лечится закрытием порта.

Если в таком порту оборудование или клиент - работает, но с большими потерями.

 

[megahertz0]

35 минут назад, alibek сказал:

99% без "либо".

Повторяющиеся MAC-адреса — это уж совсем махровый noname.

В Cisco и SNR такого не должно быть.

Не факт. У меня был случай когда в одном отеле стояла пара десятков точек доступа WiFi, сведенных в одну и ту же циску 3750. Точки работали в режиме local forwarding без тоннеля до контроллера. В случае, если клиент, к примеру, ехал через все здание на лифте, то его устройство поочередно прыгало с точки на точку то в логах была такая же запись.

У любого свитча есть aging time для таблицы маков и циска, видя что мак изучен с одного порта и внезапно появляется на другом, делает вывод о флапинге мака о чем и сообщает. Для того чтобы однозначно сделать вывод о петле нужно использовать либо Spanning tree, либо Loopback detection.

[Butch3r]

Всё в одном влане (в 1ом) ?

[default_vlan]

В 24.09.2018 в 13:08, Butch3r сказал:

Всё в одном влане (в 1ом)

Да. Сетка изначально была разношерствная - 3Com, Foundry, cisco, snr, nortel, пара устройств ubquiti.

На группу клиентов выдается свой vlan.

 

В 24.09.2018 в 09:31, azhur сказал:

Дак IP или MAC?

mac. Под конец дня пальцы путаются.

 

В 24.09.2018 в 11:29, alibek сказал:

99% без "либо".

нет петли. Проверял

 

Еще интересно то, что данная проблема фиксируется только на cisco. Другие вендоры это в логах не пишут.

 

[alibek]

2 минуты назад, default_vlan сказал:

Еще интересно то, что данная проблема фиксируется только на cisco. Другие вендоры это в логах не пишут.

Это не проблема, это информация (notify).

Можно выключить в настройках, если мешает.

Или включить в других вендорах, если нужно.

 

3 минуты назад, default_vlan сказал:

нет петли

Если устройства не мигрируют по сети (например подключаясь к разным точкам доступа), то почти наверняка есть.

Просто она может быть неожиданной.

Мы однажды нашли петлю через wifi-мост абонентского cpe.

[default_vlan]

5 минут назад, alibek сказал:

Просто она может быть неожиданной.

 

Я перепроверил все устройства уровня агрегации и 3 раза перетряс уровень ядра. Пока что остается предположение, что у кого-то из клиентов, на тех же wifi-маршрутизаторах, используются эти маки.

Если у меня появляется петля, то foundry заваливается под 99% процентов, но этого не происходит.

Изменено 25 сентября, 2018 пользователем default_vlan