Добрый день.Банальный вопрос, но что-то всю голову сломал.
Есть Catalyst 6500, есть на нём Vlan 103.
Делаю
monitor session 1 source interface gi3/32
monitor session 1 destination remote vlan 131В порт Gi3/32 включено оборудование с одним IP и одним mac адресом.
Смотрю в wireshark.
Почему-то на этот порт поступает трафик, который не предназначен для этого хоста.
Не широковещательный, а обычный уникаст трафик между другими хостами.
Причем периодами. То ничего нет, то вдруг посыпалось. До 40 мбит чужого трафика.
Т.е. получается свитч работает как хаб.Почему так может происходить?
>[оверквотинг удален]
> monitor session 1 source interface gi3/32
> monitor session 1 destination remote vlan 131
> В порт Gi3/32 включено оборудование с одним IP и одним mac адресом.
> Смотрю в wireshark.
> Почему-то на этот порт поступает трафик, который не предназначен для этого хоста.
> Не широковещательный, а обычный уникаст трафик между другими хостами.
> Причем периодами. То ничего нет, то вдруг посыпалось. До 40 мбит чужого
> трафика.
> Т.е. получается свитч работает как хаб.
> Почему так может происходить?Unknown unicast flooding.
Читаем до просветления:
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-...
> Банальный вопрос, но что-то всю голову сломал.Ответ тоже банальный: куда слать unicast траффик если в таблице МАКов такого еще пока или уже нет?
Такое очень часто случается со всякими видеокамерами с кривым софтом, которым клиент сказал слать RTP и сам уснул/отключился, а камера старается вовсю, не смотря на то, что от клиента давно ничего не приходило.Особенно прекрасно когда в сети есть сегменты, подключенные низкоскоростными модемами. Таких лучще в отдельные виланы.
>> Банальный вопрос, но что-то всю голову сломал.
> Ответ тоже банальный: куда слать unicast траффик если в таблице МАКов такого
> еще пока или уже нет?
> Такое очень часто случается со всякими видеокамерами с кривым софтом, которым клиент
> сказал слать RTP и сам уснул/отключился, а камера старается вовсю, не
> смотря на то, что от клиента давно ничего не приходило.да не, там трафик постоянно активных хостов. типа web серверов и концентраторов vpn,
которые всегда онлайн.
>> Банальный вопрос, но что-то всю голову сломал.
> Ответ тоже банальный: куда слать unicast траффик если в таблице МАКов такого
> еще пока или уже нет?
> Такое очень часто случается со всякими видеокамерами с кривым софтом, которым клиент
> сказал слать RTP и сам уснул/отключился, а камера старается вовсю, не
> смотря на то, что от клиента давно ничего не приходило.
> Особенно прекрасно когда в сети есть сегменты, подключенные низкоскоростными модемами.
> Таких лучще в отдельные виланы.Поддержу, встречал тонну shdsl и vdsl модемов, которые весь трафик пересылали обратно, образуя петлю.
Так же подобная ситуация возможна когда на роутере нет ARP записи о хосте, для которого предназначается этот unicast трафик, в связи с чем он шлет его бродкастом, и еще, возможно, на одном из центральных коммутаторов заполнилась таблица маков. В этом случае действия будут аналогичными, как при случае отсуствия ARP записи
> Поддержу, встречал тонну shdsl и vdsl модемов, которые весь трафик пересылали обратно,
> образуя петлю.хм, у меня, конечно, кабельных модемов нет, но есть удалённый сегмент сети, дотянутый l2 через wan
> Так же подобная ситуация возможна когда на роутере нет ARP записи о
> хосте, для которого предназначается этот unicast трафик, в связи с чем
> он шлет его бродкастом,А не должен он в таком случае сначала узнать mac получателя?
там в пакетах виден мак получателя и он не 0000000000
>> Поддержу, встречал тонну shdsl и vdsl модемов, которые весь трафик пересылали обратно,
>> образуя петлю.
> хм, у меня, конечно, кабельных модемов нет, но есть удалённый сегмент сети,
> дотянутый l2 через wan
>> Так же подобная ситуация возможна когда на роутере нет ARP записи о
>> хосте, для которого предназначается этот unicast трафик, в связи с чем
>> он шлет его бродкастом,
> А не должен он в таком случае сначала узнать mac получателя?
> там в пакетах виден мак получателя и он не 0000000000Кто он? Коммутатор? А если хост назначения вообще траффик не генерит? Он не обязан.
>
> Кто он? Коммутатор? А если хост назначения вообще траффик не генерит? Он
> не обязан.маршрутизатор
хост назначения - концентратор vpn, на нём сотня клиентов висит. не мог свитч его забыть.
>>
>> Кто он? Коммутатор? А если хост назначения вообще траффик не генерит? Он
>> не обязан.
> маршрутизатор
> хост назначения - концентратор vpn, на нём сотня клиентов висит. не мог
> свитч его забыть.Ты с топологией сперва определись. То, что на порту есть какой-то МАК еще не означает что в него нельзя форвардить unicast flood. Флуд идет по всем портам в вилане и транкам.
> Ты с топологией сперва определись. То, что на порту есть какой-то МАК
> еще не означает что в него нельзя форвардить unicast flood. Флуд
> идет по всем портам в вилане и транкам.так а зачем флудить если мак-то известен коммутатору?
>> Ты с топологией сперва определись. То, что на порту есть какой-то МАК
>> еще не означает что в него нельзя форвардить unicast flood. Флуд
>> идет по всем портам в вилане и транкам.
> так а зачем флудить если мак-то известен коммутатору?Читаем теорию по коммутации.
По-проще написано в ниже в моем комменте
>> Ты с топологией сперва определись. То, что на порту есть какой-то МАК
>> еще не означает что в него нельзя форвардить unicast flood. Флуд
>> идет по всем портам в вилане и транкам.
> так а зачем флудить если мак-то известен коммутатору?Чтобы понять что к чему, нужно правильно сформулировать вопросы.
В исходном сообщении, почему-то от другого пользователя, спрашивалось "Почему-то на этот порт поступает трафик, который не предназначен для этого хоста."О том, что в таблице маков присутствует/отсутствует МАК назначения - ни слова. Телепаты в отпуске. Нагадать можно что угодно.
>> Поддержу, встречал тонну shdsl и vdsl модемов, которые весь трафик пересылали обратно,
>> образуя петлю.
> хм, у меня, конечно, кабельных модемов нет, но есть удалённый сегмент сети,
> дотянутый l2 через wan
>> Так же подобная ситуация возможна когда на роутере нет ARP записи о
>> хосте, для которого предназначается этот unicast трафик, в связи с чем
>> он шлет его бродкастом,
> А не должен он в таком случае сначала узнать mac получателя?
> там в пакетах виден мак получателя и он не 0000000000а причем тут 0000000000?
Бродкаст выглядит в назначении FFFFFFFFFFFF
Да и внимательно читаем мой пункт №2, но разжую: если таблица коммутации полна и/или мак назначения отсутствует в оной - коммутатор НЕ МЕНЯЯ АДРЕС НАЗНАЧЕНИЯ В ПАКЕТЕ рассылает бродкастом пакет во все линки, кроме исходного (данное утверждение не справедливо для говнокоммутаторов типа телесинов да длинков)
> бродкастом пакет во все линки, кромеправильный термин - флуд (flood)
>> бродкастом пакет во все линки, кроме
> правильный термин - флуд (flood)К*в, те же яйца, вид сбоку;)
>[оверквотинг удален]
> monitor session 1 source interface gi3/32
> monitor session 1 destination remote vlan 131
> В порт Gi3/32 включено оборудование с одним IP и одним mac адресом.
> Смотрю в wireshark.
> Почему-то на этот порт поступает трафик, который не предназначен для этого хоста.
> Не широковещательный, а обычный уникаст трафик между другими хостами.
> Причем периодами. То ничего нет, то вдруг посыпалось. До 40 мбит чужого
> трафика.
> Т.е. получается свитч работает как хаб.
> Почему так может происходить?Может что-то подобное? http://habrahabr.ru/post/155265/
В любом случае, такое необходимо отлавливать и пресекать.
>[оверквотинг удален]
>> В порт Gi3/32 включено оборудование с одним IP и одним mac адресом.
>> Смотрю в wireshark.
>> Почему-то на этот порт поступает трафик, который не предназначен для этого хоста.
>> Не широковещательный, а обычный уникаст трафик между другими хостами.
>> Причем периодами. То ничего нет, то вдруг посыпалось. До 40 мбит чужого
>> трафика.
>> Т.е. получается свитч работает как хаб.
>> Почему так может происходить?
> Может что-то подобное? http://habrahabr.ru/post/155265/
> В любом случае, такое необходимо отлавливать и пресекать.Ответил же еще в первом сообщении, что это Unknown unicast flooding.
Причин может быть несколько, но вы действительно думаете, что на C6500 с любым супом быть коллизия хэшей? Это же сколько маков он в него вдувает тогда.
>[оверквотинг удален]
>>> Причем периодами. То ничего нет, то вдруг посыпалось. До 40 мбит чужого
>>> трафика.
>>> Т.е. получается свитч работает как хаб.
>>> Почему так может происходить?
>> Может что-то подобное? http://habrahabr.ru/post/155265/
>> В любом случае, такое необходимо отлавливать и пресекать.
> Ответил же еще в первом сообщении, что это Unknown unicast flooding.
> Причин может быть несколько, но вы действительно думаете, что на C6500 с
> любым супом быть коллизия хэшей? Это же сколько маков он в
> него вдувает тогда.Так коллизия хешей может быть и при полупустой MAC-таблице.
>
> Ответил же еще в первом сообщении, что это Unknown unicast flooding.
> Причин может быть несколькоПоясните, пожалуйста, если я правильно понимаю значение слова unknown, это значит, что в мак таблице свитча не должно быть маков узлов получателей для которых сыпется трафик.
т.е. они должны по каким-то причинам пропасть.
Насколько я понял, для хоста, который постоянно активен это может быть, например, событие TC от spanning tree?А, если, всё-таки, маки в таблице свитча есть, то какие еще могут быть причины?
> А, если, всё-таки, маки в таблице свитча есть, то какие еще могут
> быть причины?Похоже я разобрался.
У меня два бордера, которые смотрят внутренним интерфейсом в этот VLAN.
Имеет место ассиметричный роутинг. И как вы правильно подсказали это один из сценариев возникновения unknown unicast flood.Привёл в соответствие arp timeout на роутерах к aging-time на свитчах и флуд пропал.
Всем спасибо.
>> А, если, всё-таки, маки в таблице свитча есть, то какие еще могут
>> быть причины?
> Похоже я разобрался.
> У меня два бордера, которые смотрят внутренним интерфейсом в этот VLAN.
> Имеет место ассиметричный роутинг. И как вы правильно подсказали это один из
> сценариев возникновения unknown unicast flood.
> Привёл в соответствие arp timeout на роутерах к aging-time на свитчах и
> флуд пропал.
> Всем спасибо.скажите пожалуйста, к чему привели? agging time сделали 4 часа или arp timeout 5 минут?
или какой-то свой интервал подобрали одинаковый для agging и arp timeout?
ну, и если можно, то почему именно тот или иной вариант выбрали?
> ну, и если можно, то почему именно тот или иной вариант выбрали?сделал 5 минут арп на роутерах.
основная причина - свитчей много, а роутеров всего два.
сеть не высоконагруженная, чуть больше арпа никак не скажется.
>> ну, и если можно, то почему именно тот или иной вариант выбрали?
> сделал 5 минут арп на роутерах.
> основная причина - свитчей много, а роутеров всего два.
> сеть не высоконагруженная, чуть больше арпа никак не скажется.спасибо за ответ.