port limits что это
port limit
Смотреть что такое «port limit» в других словарях:
Port Moody—Coquitlam—Port Coquitlam — (formerly known as Port Moody Coquitlam) only was a federal electoral district in British Columbia, Canada, that was represented in the Canadian House of Commons from 1997 to 2004. Demographics GeographyIt initially consisted of: * the eastern… … Wikipedia
Port of Miami Tunnel — Artist s conception of the Watson Island entrance completed Overview Location Miami, Florida Status Under construction Route … Wikipedia
Port Colborne — City Former bank building on West Street in Port Colborne[1] … Wikipedia
Port of Miami (album) — Port of Miami Studio album by Rick Ross Released August 8, 2006 … Wikipedia
Port of Miami — Студийный альбом Рика Росса … Википедия
Port of Tanjung Pelepas Highway — Federal Route 177 Port of Tanjung Pelepas Highway Route information Existed: 1996 – present History … Wikipedia
Port Moody—Westwood—Port Coquitlam — Infobox Canada electoral district province = British Columbia caption = Port Moody Westwood Port Coquitlam in relation to other Greater Vancouver federal electoral ridings. fed status = active fed district number = 59021 fed created = 2003 fed… … Wikipedia
Port Talbot — infobox UK place country = Wales welsh name=Aberafan/Porth Talbot constituency welsh assembly= official name= Port Talbot unitary wales= Neath Port Talbot lieutenancy wales= West Glamorgan constituency westminster= Aberavon post town= PORT TALBOT … Wikipedia
Port — This article is about a facility for the loading and unloading of ships. For other uses, see Port (disambiguation). Seaport, a 17th Century depiction by Claude Lorrain, 1638 … Wikipedia
Ограничение скорости передачи трафика. Policer или shaper, что использовать в сети?
Когда речь заходит об ограничении пропускной способности на сетевом оборудовании, в первую очередь в голову приходят две технологи: policer и shaper. Policer ограничивает скорость за счёт отбрасывания «лишних» пакетов, которые приводят к превышению заданной скорости. Shaper пытается сгладить скорость до нужного значения путём буферизации пакетов. Данную статью я решил написать после прочтения заметки в блоге Ивана Пепельняка (Ivan Pepelnjak). В ней в очередной раз поднимался вопрос: что лучше – policer или shaper. И как часто бывает с такими вопросами, ответ на него: всё зависит от ситуации, так как у каждой из технологий есть свои плюсы и минусы. Я решил разобраться с этим чуточку подробнее, путём проведения нехитрых экспериментов. Полученные результаты подкатом.
И так, начнём с общей картинки разницы между policer и shaper.
Как видно, policer срезает все пики, shaper же делает сглаживание нашего трафика. Достаточно неплохое сравнение между policer и shaper можно найти здесь.
Обе технологии в своей основе используют механизм токенов (token). В этом механизме присутвует виртуальное ограниченное по размеру ведро (token bucket), в которое с некой регулярностью поступают токены. Токен, как проездной, расходуется для передачи пакетов. Если токенов в ведре нет, то пакет отбрасывается (могут выполняться и другие действия). Таким образом, мы получаем постоянную скорость передачи трафика, так как токены поступают в ведро в соответствии с заданной скоростью.
Скорость сессии обычно меряется в отведённый промежуток времени, например, за 5 сек или 5 минут. Брать мгновенное значение бессмысленно, так как данные всегда передаются на скорости канала. При этом если мы будем делать усреднение за разные временные интервалы, мы получим разные графики скорости передачи данных, так как трафик в сети не равномерный. Я думаю, любой с этим сталкивался, строя графики в системе мониторинга.
Механизм токенов позволяет обеспечить гибкость в настройке ограничения скорости. Размер ведра влияет на то, как мы будем усреднять нашу скорость. Если ведро большое (т.е. токенов там может скопиться много), мы позволим трафику сильнее «выпрыгивать» за отведенные ограничения в определённые моменты времени (эквивалент усреднения на большем промежутке времени). Если размер ведра маленький, то трафик будет более равномерный, крайне редко превышая заданный порог (эквивалент усреднения на маленьком промежутке времени).
В случае policer’а наполнение ведра происходит каждый раз, когда приходит новый пакет. Количество токенов, которые загружаются в ведро, зависит от заданной скорости policer’а и времени, прошедшего с момента поступления последнего пакета. Если токенов в ведре нет, policer может отбросить пакеты или, например, перемаркировать их (назначить новые значения DSCP или IPP). В случае shaper’а наполнение ведра происходит через равные промежутки времени независимо от прихода пакетов. Если токенов не хватает, пакеты попадают в специальную очередь, где ждут появления токенов. За счёт этого имеем сглаживание. Но если пакетов приходит слишком много, очередь shaper’а в конечном счёте переполняется и пакеты начинают отбрасываться. Стоит отметить, что приведённое описание является упрощённым, так как и policer и shaper имеют вариации (детальный разбор данных технологий займёт объём отдельной статьи).
Эксперимент
А как это выглядит на практике? Для этого соберём тестовый стенд и проведём следующий эксперимент. Наш стенд будет включать устройство, которое поддерживает технологии policer и shaper (в моём случае – это Cisco ISR 4000; подойдёт устройство любого вендора аппаратное или программное, которое поддерживает данные технологии), генератор трафика iPerf и анализатор трафика Wireshark.
Сначала посмотрим на работу policer. Настроим ограничение скорости равным 20 Мбит/с.
В iPerf запускаем генерацию трафика в рамках четырёх потоков, используя протокол TCP.
Средняя скорость составила 17.1 Мбит/с. Каждая сессия получила разную пропускную способность. Обусловлено это тем, что настроенный в нашем случае policer не различает потоки и отбрасывает любые пакеты, которые превышают заданное значение скорости.
С помощью Wireshark собираем дамп трафика и строим график передачи данных, полученный на стороне отправителя.
Чёрная линия показывают суммарный трафик. Разноцветные линии – трафик каждого потока TCP. Прежде чем делать какие-то выводы и углубляться в вопрос, давайте посмотрим, что у нас получится, если policer заменить на shaper.
Настроим shaper на ограничение скорости 20 Мбит/с.
При настройке используем автоматическое выставляемое значение размера ведра токенов BC и BE равное 8000. Но меняем размер очереди с 83 (по умолчанию в версии IOS XE 15.6(1)S2) на 200. Сделано это сознательно, чтобы получить более чёткую картину, характерную для shaper’а. На этом вопросе мы остановимся более подробно в подкате «Влияет ли глубина очереди на нашу сессию?».
В iPerf запускаем генерацию трафика в рамках четырёх потоков, используя протокол TCP.
Средняя скорость составила 19.3 Мбит/с. При этом каждый поток TCP получил примерно одинаковую пропускную способность.
С помощью Wireshark собираем дамп трафика и строим график передачи данных, полученный на стороне отправителя.
Чёрная линия показывают суммарный трафик. Разноцветные линии – трафик каждого потока TCP.
Сделаем первые промежуточные выводы:
Начнём c графиков, на которых отображаются пакеты с привязкой ко времени их передачи. Первый график – policer’а, второй – shaper’а.
Из графиков видно, что пакеты в случае shaper передаются более равномерно по времени. При этом в случае policer видны скачкообразные разгоны сессии и периоды пауз.
Анализ TCP сессии при работе policer
Посмотрим поближе на сессию TCP. Будем рассматривать случай policer’а.
Протокол TCP в своей работе опирается на достаточно большой набор алгоритмов. Среди них для нас наиболее интересными являются алгоритмы, отвечающие за управление перегрузками (congestion control). Именно они отвечают за скорость передачи данных в рамках сессии. ПК, на котором запускался iPerf, работает под управлением Windows 10. В Windows 10 в качестве такого алгоритма используется Compound TCP (CTCP). CTCP в своей работе позаимствовал достаточно многое из алгоритма TCP Reno. Поэтому при анализе TCP сессии достаточно удобно посматривать на картинку с состояниями сессии при работе алгоритма TCP Reno.
На следующей картинке представлен начальный сегмент передачи данных.
Чтобы посмотреть параметры TCP, можно воспользоваться PowerShell.
Смотрим, какой глобальный шаблон TCP используется в нашей системе по умолчанию.
В режиме TCP slow-start размер окна (cwnd) увеличивается каждый раз при получении ACK. При этом оно не может превысить значение awnd. За счёт такого поведения, мы имеем практически экспоненциальный рост количества передаваемых пакетов. Наша TCP сессия разгоняется достаточно агрессивно.
После получения трёх Dup ACK наша TCP сессия переходит в фазу восстановления после потери (loss recovery, включающую алгоритмы Fast Retransmit/Fast Recovery). Отправитель устанавливает новое значение ssthresh = cwnd/2 (32K) и делает окно cwnd = ssthresh+3*MSS.
Как только было отправлено количество пакетов, укладывающихся в окно cwnd, система останавливается. Для продолжения передачи данных ей нужны новые ACK (не Dup ACK). Но ACK не приходят. Все повторные пакеты отбрасываются policer’ом, так в ведре закончились токены, а времени, чтобы их восполнить, прошло слишком мало.
В алгоритме Compound TCP для регулирования скорости передачи используется окно отправителя (sending window — wnd), которое зависит от двух взвешенных величин: окна перегрузки (cwnd) и окна задержки (delay window — dwnd). Cwnd, как и раньше, зависит от полученных ACK, dwnd зависит от величины задержки RTT (round trip time). Окно wnd растёт только один раз за период времени RTT. Как мы помним, в случае slow-start окно cwnd росло при получении каждого ACK. Поэтому в режиме congestion avoidance сессия разгоняется не так быстро.
Анализ TCP сессии при работе shaper
Теперь давайте посмотрим поближе на сегмент передачи данных для случая shaper. Для наглядности возьмём аналогичный масштаб, как и для графика policer на Рис.6.
Из графика мы видим всё ту же лесенку. Но размер ступенек стал существенно меньше. Однако если приглядеться к графику на Рис. 10, мы не увидим небольших «волн» на конце каждой ступеньки, как это было на Рис. 9. Такие «волны» были следствием потери пакетов и попыток их передачи заново.
Рассмотрим начальный сегмент передачи данных для случая shaper.
Происходит установление сессии. Далее начинается разгон в режиме TCP slow-start. Но этот разгон более пологий и имеет ярко выраженные паузы, которые увеличиваются в размере. Более пологий разгон обусловлен тем, что размер ведра по умолчанию для shaper всего (BC+BE) = 20 000 байт. В то время как для policer размер ведра — 625 000 байт. Поэтому shaper срабатывает существенно раньше. Пакеты начинают попадать в очередь. Растёт задержка от отправителя к получателю, и ACK приходят позже, чем это было в случае policer. Окно растёт существенно медленнее. Получается, что чем больше система передаёт пакетов, тем больше их накапливается в очереди, а значит, тем больше задержка в получении ACK. Имеем процесс саморегуляции.
Через некоторое время окно cwnd достигает значения awnd. Но к этому моменту у нас накапливается достаточно ощутимая задержка из-за наличия очереди. В конечном итоге при достижении определённого значения RTT наступает равновесное состояние, когда скорость сессии больше не меняется и достигает максимального значения для данного RTT. В моём примере среднее RTT равно 107 мс, awnd=64512 байт, следовательно, максимальная скорость сессии будет соответствовать awnd/RTT= 4.82 Мбит/с. Примерно такое значение нам и выдал iPerf при измерениях.
Но откуда берутся ярко выраженные паузы в передаче? Давайте посмотрим на график передачи пакетов через устройство с shaper в случае, если у нас всего одна TCP сессия (Рис.12). Напомню, что в нашем эксперименте передача данных происходит в рамках четырёх TCP сессий.
На этом графике очень хорошо видно, что нет никаких пауз. Из этого можно сделать вывод, что паузы на Рис.10 и 11 обусловлены тем, что у нас одновременно передаётся четыре потока, а очередь в shaper одна (тип очереди FIFO).
На Рис.13 представлено расположение пакетов разных сессий в очереди FIFO. Так как пакеты передаются пачками, они будут располагаться в очереди таким же образом. В связи с этим задержка между поступлением пакетов на приёмной стороне будет двух типов: T1 и T2 (где T2 существенно превосходит T1). Общее значение RTT для всех пакетов будет одинаковым, но пакеты будут приходить пачками, разнесёнными по времени на значение T2. Вот и получаются паузы, так как в момент времени T2 никакие ACK к отправителю не приходят, при этом окно сессии остаётся неизменным (имеет максимальное значение равное awnd).
Логично предположить, что, если заменить одну общую очередь FIFO на несколько для каждой сессии, никаких ярко выраженных пауз не будет. Для такой задачи нам подойдёт, например, очередь типа Weighted Fair Queuing (WFQ). В ней для каждой сессии создаётся своя очередь пакетов.
Из общего графика мы сразу видим, что графики всех четырёх TCP сессий идентичны. Т.е. все они получили одинаковую пропускную способность.
А вот и наш график распределения пакетов по времени передачи ровно в том же масштабе, что и на Рис. 11. Никаких пауз нет.
Стоит отметить, что очередь типа WFQ позволит нам получить не только более равномерное распределение пропускной способности, но и предотвратить «забивание» одного типа трафика другим. Мы всё время говорили про TCP, но в сети также присутствует и UDP трафик. UDP не имеет механизмов подстройки скорости передачи (flow control, congestion control). Из-за этого UDP трафик может с лёгкостью забить нашу общую очередь FIFO в shaper’е, что драматически повлияет на передачу TCP. Напомню, что, когда очередь FIFO полностью заполнена пакетами, по умолчанию начинает работать механизм tail-drop, при котором отбрасываются все вновь пришедшие пакеты. Если у нас настроена очередь WFQ, каждая сессия пережидает момент буферизации в своей очереди, а значит, сессии TCP будут отделены от сессий UDP.
Самый главный вывод, который можно сделать после анализов графиков передачи пакетов при работе shaper’а – у нас нет потерянных пакетов. Из-за увеличения RTT скорость сессии адаптируется к скорости shaper’а.
Конечно! Изначально (если кто-то об этом ещё помнит) мы изменили глубину очереди с 83 (значение по умолчанию) на 200 пакетов. Сделали мы это для того, чтобы очереди хватило для получения достаточного значения RTT, при котором суммарная скорость сессий становиться примерно равна 20 Мбит/с. А значит, пакеты «не вываливаются» из очереди shaper’а.
При глубине в 83 пакета очередь переполняется быстрее, нежели достигается нужное значение RTT. Пакеты отбрасываются. Особенно ярко это проявляется на начальном этапе, когда у нас работает механизм TCP slow-start (сессия разгоняется максимально агрессивно). Стоит отметить, что количество отброшенных пакетов несравнимо меньше, чем в случае с policer, так как увеличение RTT приводит к тому, что скорость сессии растёт более плавно. Как мы помним, в алгоритме CTCP размер окна в том числе зависит от значения RTT.
Графики утилизации пропускной способности и задержки при работе policer и shaper
В заключение нашего небольшого исследования построим ещё несколько общих графиков, после чего перейдём к анализу полученных данных.
График утилизации пропускной способности:
В случае policer мы видим скачкообразный график: сессия разгоняется, потом наступают потери, и её скорость падает. После чего всё повторяется снова. В случае shaper наша сессия получает примерно одинаковую пропускную способность на протяжении всей передачи. Скорость сессии регулируется за счёт увеличения значения RTT. На обоих графиках вначале можно наблюдать взрывной рост. Он обусловлен тем, что наши вёдра изначально полностью заполнены токенами и TCP-сессия, ничем не сдерживаемая, разгоняется до относительно больших значений (в случае shaper это значение в 2 раза меньше).
График задержки RTT для policer и shaper (по-хорошему, это первое о чём мы вспоминаем, когда говорим про shaper):
В случае policer (первый график) задержка RTT для большинства пакетов минимальна, порядка 5 мс. На графике также присутствуют существенные скачки (до 340 мс). Это как раз моменты, когда пакеты отбрасывались и передавались заново. Тут стоит отметить, как Wireshark считает RTT для TCP трафика. RTT – это время между отправкой оригинального пакета и получением на него ACK. В связи с этим, если оригинальный пакет был потерян и система передавала пакет повторно, значение RTT растёт, так как точкой отсчёта является в любом случае момент отправки оригинального пакета.
В случае shaper задержка RTT для большинства пакетов составила 107 мс, так как они все задерживаются в очереди. Есть пики до 190 мс.
Выводы
Итак, какие итоговые выводы можно сделать. Кто-то может заметить, что это и так понятно. Но наша цель была копнуть чуточку глубже. Напомню, что в эксперименте анализировалось поведение TCP-сессий.
Если policer настроен ближе к получателю, наша сеть фактически занимается прокачкой бесполезного трафика, который будет в итоге отброшен policer’ом. Например, в разрезе глобальной сети интернет это может является проблемой, так как трафик режется зачастую ближе к получателю.
Вообще наличие очереди может достаточно негативно сказываться на работе приложений – так называемый эффект излишней сетевой буферизации (Bufferbloat). Поэтому с глубиной очереди надо быть аккуратными.
В этом году при поддержке Google было проведено исследование, в котором анализировался негативный эффект работы policer’а в сети интернет. Было определено, что от 2% до 7% потерь видео трафика по всему Миру вызвано срабатыванием policer’а. Потери пакетов при непосредственной работе policer’а составили порядка 21%, что в 6 раз больше, чем для трафика, который не подвержен срабатыванию данной технологии. Качество видео трафика, который подвергся обработке policer’ом, хуже, чем в случае, если policer не срабатывал.
Для борьбы с негативным эффектом работы policer’а предлагаются следующие меры в зависимости от точки их применения.
Для контент-провайдеров предлагается ограничивать скорость отправки трафика на сервере, чтобы избегать включения policer’а. Но на практике оценить реальную скорость канала не всегда просто. Второй метод — избегать взрывной передачи трафика за счёт модификации алгоритмов TCP: использовать TCP Pacing (отправлять пакеты с привязкой к RTT, а не к моменту получения ACK) и изменить схему работы фазы loss recovery (на каждый полученный ACK слать только один новый пакет).
Технологии безопасности сети на 2-ом уровне OSI. Часть 1
Казалось бы, получив доступ во внутреннюю сеть, злоумышленник может относительно беспрепятственно исследовать соседние узлы, собирать передаваемую информацию и в общем уже все потеряно.
Тем не менее при корректном подходе к контролю уровня доступа можно существенно осложнить упомянутые процедуры. При этом грамотно подготовленная сетевая инфраструктура, заметив зловредную аномалию, об этом своевременно сообщит, что поможет снизить ущерб.
Под катом перечень механизмов, которые помогут выполнить данную функцию.
Хотелось бы привести общую выжимку без лишних Вики-обоснований, но с описанием вариаций конфигурации, тем не менее иногда отступаю в ликбез, что бы стороннему читателю статья показалась более дружелюбной.
Статья выходила объемной, и, по-моему, слишком большие статьи не читаются, а складываются в долгий ящик с мыслью «как-нибудь осилю». Поэтому материал пришлось разделить, и при должном успехе составлю вторую часть с менее распространенными (по крайней мере у нас) технологиями.
Предполагаю, что данный вендор самый процентуально распространенный, да и самый информационно богатый, и вызывает бОльшую заинтересованность у начинающих изучать подобные темы.
Тем не менее, уверен, что после усвоения каждой конкретной технологии на циске, корректно составить конфигурацию у другого вендора не составит труда, если у Вас есть 30 мин. и обычный User Guide.
Считаю, что информация не дублирует уже существующую на хабре, хотя что-то похожее можно встретить тут и тут.
Port Security
Описание
Технология предназначена для контроля подключенных к коммутатору устройств и предотвращения аномалий или атак, нацеленных на переполнения таблицы MAC-адресов (CAM table overflow).
С помощью Port Security устанавливается максимальное количество MAC адресов на конкретный свитчпорт (сетевой порт, оперирующий на 2-ом уровне OSI) или VLAN, и контролируется доступ по заданным MAC-адресам.
Способы работы с MAC-адресами:
Действия в случае превышения полномочий:
Конфигурация
Port-Security может быть активирован только, если тип свитчпорта явно задан (т.е. или Access, или Trunk). Если порт динамический (что уже неправильно), Port-Security на нем включить не получиться.
Access порты
Технология задается посредством команды switchport port-security… в режиме конфигурации конкретного интерфейса, доступные опции:
В результате все выглядит примерно так:
— Если хотим разрешить неизвестно какие маки, лимитируя их количество 5-ю, ставим максимум на 5 и не задаем ничего статически. Опционально указываем время жизни.
— Если известно, что за устройство стоит на втором конце провода и больше ничего там не будет и быть не должно — максимум=1, адрес прописываем статически.
— Если ждем нового работника с новым ПК или лень узнавать MAC-адрес, ставим Sticky, после подключения перепроверяем.
Trunk порты
Проверка
Не прибегая к show run информация касательно Port-Security может быть найдена:
Команда проводит проверку актуальной информации о таблице MAC-адрессов. Например, нынешнее количество записей в таблице для конкретного VLAN’a и объем доступных записей проверяется посредством show mac address-table count vlan :
DHCP snooping
Описание
Технология предотвращает использование не авторизированного DHCP сервера в сети, что позволяет например произвести атаку человек-посередине (man-in-the-middle, MITM). Еще защищает сеть от атак на истощение DHCP (DHCP starvation/exauction), которая имхо не особо актуальна.
Технология следит за DHCP коммуникацией в сети, которая (в основном) состоит из четырех пакетов:
Очень немаловажно, что после активации DHCP snooping, коммутатор начинает следить за DHCP коммуникацией в сети и отождествлять выданные IP адреса с MAC-адресами запрашивающих устройств, складируя данную информацию в таблицу DHCP snooping binding.
Конфигурация
Под доверенным интерфейсом вводится команда ip dhcp snooping trust :
Для предотвращения DHCP starvation под не доверенными интерфейсами указывается частота получаемых клиентских запросов с помощью ip dhcp snooping limit rate :
Важно не занизить данную характеристику, чтобы не порезать валидный трафик. Циска советует использовать число «10».
После этого указываем конкретный VLAN для работы DHCP snooping’a и включаем непосредственно саму технологию командой без опций:
Проверка
Dynamic ARP inspection
Описание
Технология предназначена для предотвращения ARP spoofing/poisoning атак, которая является базовым способом организации перехвата трафика (опять же атака человек-посередине/MITM), находясь в одном широковещательном домене с жертвой.
Конфигурация
Что бы эффективно предотвратить ARP spoofing, коммутатор должен иметь информацию о связке MAC-адрес/IP-адрес. Как упоминалось выше, данная информация хранится в таблице DHCP snooping. По этому корректная конфигурация эти две технологии практически всегда использует вместе.
При совместном использовании с DHCP snooping, технология активируется в режиме глобальной конфигурации командой:
После этого в данном VLAN’е будет разрешен трафик только тех устройств, которые фигурируют в таблице DHCP snooping.
В случае, если устройства НЕ используют DHCP, необходимо проводить дополнительные меры. ARP inspection позволяет использовать статические записи. Для этого создаются списки доступа ARP, создается который из режима глобальной конфигурации командой:
Синтаксис отдельной записи ниже:
помимо указания единичного MAC-адреса, в arp access-list’е можно указать диапазон. И это делается посредством !обратных ARP! масок:
Под таким arp access-list’ом указываются все необходимые статические записи. Далее технология активируется не как прежде, а с опцией filter:
Отдельный интерфейс(ы) можно пометить как доверенные. На этих интерфейсах ARP inspection проводиться не будет:
Практически всегда доверенными устанавливаются Trunk порты (главное об этом не забыть перед активированием всего механизма). Но в этом случае важно поднять установленный по умолчанию лимит ARP сообщений — он равен 15, и может быть слишком узким, особенно для транка. Советую поставить 100-ку:
Опционально можно добавить дополнительные проверки на соответствие MAC адресов в заголовках ARP и Ethernet. Делается это командой ip arp inspection validate :
Функционал по каждой опции отдельно можно прочитать тут.
Проверка
Проверить статус технологии, включена ли, использует ли список доступа, статус проверки дополнительных опций и т.п. информацию:
Полезные опции у предыдущей команды (добавить в конце строки) — statistics (показывает счетчики дропов и т.п.) и interfaces (доверенные интерфейсы, лимиты ARP сообщений).
Source Guard
Описание
В случае, если нет нужды проверять всю подсеть по ARP inspection, но хотелось бы защитить от подобных угроз пару-тройку узлов, можно использовать Source Guard. На практике их функционал дублирует друг друга, хотя и есть нюансы.
Технология привязывает заданные IP-MAC к конкретному физическому интерфейсу. В результате тоже предотвращает ARP спуфинг, а также один узел сети не сможет отправить трафик от имени другого, подменив IP и MAC адреса источника (в случае ARP inspection это возможно, хотя и не является критичным).
Конфигурация
Source Guard тоже использует таблицу DHCP snooping. Она содержит не только связку IP-MAC, но и еще интерфейс, за которым находится конкретный узел.
Если узлы опять же не используют DHCP, в режиме глобальной конфигурации создается мануальная запись:
Source Guard активируется непосредственно на интерфейсе:
Проверка
Проверка записей, которые использует технология, проводится командой:
show ip source binding
Что полезно, команда выводит как мануальные записи, так и взятые из таблицы DHCP snooping.
Список интерфейсов, на которых Source Guard активирован, выводится командой:
show ip verify source