Пример из жизни, место где ip-sla действительно выручает - на 4500X SVI клиента, в который сроучена крупная сеть (/24 и больше), сам клиент при этом физически включен дальше в другой коммутатор. Соответственно при падении клиента, SVI остается живым и маршрут остается в таблице. Коммутатор при этом начинает генерировать арпы в гигантских количествах, одно из ядер сразу становится в полку. Ограничение арпов контрол плейном эту проблему не решает, так как ограничивает все арпы вообще. А вот привязка трекинга к нужному маршруту отлично избавляет от таких проблем
Я с nfdump "игрался" и правда очень давно. Но, насколько я помню, там тяжело было с группированием данных по автономным системам. Может сейчас конечно это уже не так. Собственно тогда же пробовал и nfsen. Nfsen заточен совсем под другую статистику и он не подошел. Но на nfdump может и правда нужно взглянуть еще раз.
Там проблема не сколько в самом коллекторе, а в утилитах, которые анализируют данные коллектора. Flow-Tools силен своими отчетами, где можно группировать трафик по различным параметрам. Он это делает достаточно быстро, и это позволило, в принципе, без огромных трудозатрат сделать такого рода web приложение. NFDump этого лишен. И если уходить от flow-tools, то скорее всего куда-то в другую сторону.
не в обиду fastnetmon (очень крутой проект с множеством фич), но я не нашел в нем возможности (по крайней мере в бесплатной версии) сгруппировать трафик, к примеру, аналогично репорту ip-destination-address/ip-source/destination-port и повесить порог на это правило (есть возможность вешать пороги на весь трафик к IP и на tcp/udp протокол). Что не очень подходит конкретно нам. Львиная доля атак укладывающих мелких клиентов отлавливается только этим правилом. Кроме того, есть несколько больше свободы в выборе этих правил. Но все, конечно, гораздо проще и скуднее в плане поддержки протоколов и функций.
Не понял сарказм или нет :) Но блэк-холл у себя и анонс этого IP с блэкхольным комьюнити провайдерам выше спасает. 20 гигабит это чуть ли не половина нашей емкости внешних каналов.
Вот для решения такой спорной задачи и нужен приоритет. Причем, когда вы меняете приоритет, он обязан быть кратным 4096
Чуть поправлю. В классическом Spanning Tree он может быть любым. Кратным 4096 он должен быть в per vlan STP, так как от двуйбатового поля Bridge Priority 12 последних бит откусили под номер vlan, соответственно под приоритет остается всего 4 первых бита. Отсюда такое ограничение
Пример из жизни, место где ip-sla действительно выручает - на 4500X SVI клиента, в который сроучена крупная сеть (/24 и больше), сам клиент при этом физически включен дальше в другой коммутатор. Соответственно при падении клиента, SVI остается живым и маршрут остается в таблице. Коммутатор при этом начинает генерировать арпы в гигантских количествах, одно из ядер сразу становится в полку. Ограничение арпов контрол плейном эту проблему не решает, так как ограничивает все арпы вообще. А вот привязка трекинга к нужному маршруту отлично избавляет от таких проблем
Добавил поддержку NFDUMP
Я с nfdump "игрался" и правда очень давно. Но, насколько я помню, там тяжело было с группированием данных по автономным системам. Может сейчас конечно это уже не так. Собственно тогда же пробовал и nfsen. Nfsen заточен совсем под другую статистику и он не подошел. Но на nfdump может и правда нужно взглянуть еще раз.
Спасибо, посмотрю.
Там проблема не сколько в самом коллекторе, а в утилитах, которые анализируют данные коллектора. Flow-Tools силен своими отчетами, где можно группировать трафик по различным параметрам. Он это делает достаточно быстро, и это позволило, в принципе, без огромных трудозатрат сделать такого рода web приложение. NFDump этого лишен. И если уходить от flow-tools, то скорее всего куда-то в другую сторону.
Чуть поправлю. В классическом Spanning Tree он может быть любым. Кратным 4096 он должен быть в per vlan STP, так как от двуйбатового поля Bridge Priority 12 последних бит откусили под номер vlan, соответственно под приоритет остается всего 4 первых бита. Отсюда такое ограничение