... Отправка зеркала трафика настраивается на коммутаторе.
Желательно отсылать только один тип трафика - либо тэгированный, либо нет.
В случае, если используется тэгированный трафик, лучше ограничиться десятью VLAN, если их больше - это может (с небольшой вероятностью, но всё же) повлечь проблемы с Linux при рестарте сети при работающем потоке пакетов и стоит поискать способ снимать тэги при отправке зеркала.
Захват трафика в iptables и передача модулю фильтрации на Carbon Reductor производится с помощью bridge, ebtables и нескольких опций ядра, выставляющихся при старте Carbon Reductor автоматически. Всё что требуется в таком случае - выполнить пошагово [настройку сканирования зеркала трафика.|reductor5:Сеть]
Правильно будет настроить зеркало трафика с указанием в качестве source ports - абонентских портов, не считая порта в который подключен Carbon Reductor, а режим захвата RX-only.
В случае, если трафик Carbon Reductor не будет попадать к нему же в зеркало, вы сможете без опасений использовать опцию NOTRACK, значительно снижающую нагрузку на процессор, вызываемую обработкой трафика.
Указание одного порта идущего к вышестоящему оборудованию в TX\- или Both-режиме приведёт к [созданию петли.|reductor5:ethX received packet with own address as source address]
У некоторых вендоров оборудования разное толкование TX и RX, поэтому не забывайте проверять tcpdump'ом что зеркало прилетает правильное, а не задом наперёд (ответы от сайтов, вместо запросов, например).
|
Нужно постараться организовать прямую видимость с Редуктора абонентской сети (directly connect), то бишь, как вариант - несколько интерфейсов/саб-интерфейсов на редукторе, с которых будут видеться те или иные сегменты сети. Если такого не будет, то, очевидно, пакеты будут улетать в дефолт, то бишь на ваш маршрутизатор, который уже будет перенаправлять пакеты с редиректами и/или tcp-reset-ами куда нужно, что замедлит доставку пакета абонентам.
|
