По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитатей первую часть статьи про траблшутинг NAT/PAT на Cisco.
В этой части мы рассмотрим проблемы DHCP.
Урок 1
Вот новый сценарий, позвольте мне сначала объяснить его:
Зеленая зона - это наша локальная сеть, так что это наш NAT inside.
Красная область - это Интернет, поэтому это наш NAT outside.
Предполагается, что хост - это компьютер с шлюзом по умолчанию 192.168.12.2.
Наш маршрутизатор NAT подключен к маршрутизатору ISP.
Маршрутизатор ISP назначил нам подсеть 172.16.1.0 / 24, которую мы собираемся использовать для трансляции NAT.
BGP был настроен между NAT и маршрутизатором ISP для доступа к сети 192.168.34.0/24.
Предполагается, что веб-сервер прослушивает TCP-порт 80 и использует 192.168.34.3 в качестве шлюза по умолчанию.
Однако пользователи нашей локальной сети жалуются на то, что не могут подключиться к веб-серверу. Давайте проверим нашу конфигурацию NAT:
Мы можем убедиться, что трансляция работает:
Inside local IP-адрес нашего хоста.
Inside global находится один из IP-адресов из нашей подсети 172.16.1.0/24.
Outside local and global IP-адрес нашего веб-сервера
Эта трансляция выглядит хорошо, потому что все IP-адреса верные.
Мы видим, что маршрутизатор NAT научился достигать сети 192.168.34.0 / 24 через BGP.
Наш NAT-маршрутизатор может подключаться к веб-серверу, поэтому проблема с подключением отсутствует. Однако следует помнить одну важную вещь. Пакет IP, который производит маршрутизатор NAT, выглядит следующим образом:
IP-адрес получателя является нашим веб-сервером, и с ним нет проблем. Исходный IP-адрес - 192.168.23.2, и поскольку мы получили ответ, мы знаем, что маршрутизатор ISP знает, как достичь подсети 192.168.23.0 / 24. Это важно, поскольку подсеть 192.168.23.0 / 24 напрямую подключена к маршрутизатору ISP.
Однако, если мы отправляем эхо-запрос с хост-устройства, он преобразуется из-за NAT в IP-адрес в подсети 172.16.1.0/24. Пакет IP будет выглядеть так:
Вот что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправляется маршрутизатору ISP:
Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.
Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!
ISP#debug ip packet 1
IP packet debugging is on for access list 1
ISP#conf t
ISP(config)#access-list 1 permit host 192.168.34.4
Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.
Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.
Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to...it является не маршрутизируемым и будет отброшен.
Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:
NAT(config)#ip route 172.16.1.0 255.255.255.0 null 0
NAT(config)#router bgp 1
NAT(config-router)#network 172.16.1.0 mask 255.255.255.0
Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.
Пинг прошел проблема решена!
Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.
Урок 2
Начнем с простого сценария. Маршрутизатор с левой стороны - это наш DHCP-клиент, а маршрутизатор с правой стороны - это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов ... что может быть не так?
Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.
Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо...
Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.
Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.
DHCPServer#show ip dhcp pool
Мы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.
Мы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает ... что это может значить?
Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.
DHCPServer(config)#service dhcp
Включим сервис.
Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.
Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!
Итог урока: если все в порядке, убедитесь, что служба DHCP работает.
Урок 3
Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP
Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief.
DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown
Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.
Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит...
DHCPServer#debug ip dhcp server packet
Включим отладку, чтобы увидеть, что происходит.
Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?
Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.
Чтобы доказать это, мы можем включить отладку
Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.
DHCPServer(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.
Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.
Если вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Вот и все ... проблема решена!
Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.
3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.
В первой статье серии EIGRP мы познакомились с функциями EIGRP, рассмотрели пример базовой конфигурации и набор команд проверки. Сегодня, в этой статье, мы углубимся в понимание того, как EIGRP устанавливает соседство, изучает маршрут к сети, определяет оптимальный маршрут к этой сети, и пытается ввести этот маршрут в таблицу IP-маршрутизации маршрутизатора.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Следующие статьи из цикла:
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Операции EIGRP могут быть концептуально упрощены в три основных этапа:
Этап 1. Обнаружение соседей: посредством обмена приветственными сообщениями EIGRP-спикер маршрутизаторы обнаруживают друг друга, сравнивают параметры (например, номера автономной системы, K-значения и сетевые адреса) и определяют, должны ли они образовывать соседство.
Этап 2. Обмен топологиями: если соседние EIGRP маршрутизаторы решают сформировать соседство, они обмениваются своими полными таблицами топологии друг с другом. Однако после установления соседства между маршрутизаторами передаются только изменения существующей топологии. Этот подход делает EIGRP намного более эффективным, чем протокол маршрутизации, такой как RIP, который объявляет весь свой список известных сетей через определенные интервалы времени.
Этап 3. Выбор маршрутов: как только таблица топологии EIGRP маршрутизатора заполнена, процесс EIGRP проверяет все изученные сетевые маршруты и выбирает лучший маршрут к каждой сети. EIGRP считает, что сетевой маршрут с самой низкой метрикой является лучшим маршрутом к этой сети.
Очень важно, что в когда вы читаете вышеописанные этапы, подробно описывающее обнаружение соседей EIGRP, обмен топологией и выбор маршрута, должны понимать, что в EIGRP, в отличие от OSPF, нет понятия назначенного маршрутизатора (DR) или резервного назначенного маршрутизатора (BDR).
Обнаружение соседей и обмен топологиями
Чтобы лучше понять, как маршрутизатор EIGRP обнаруживает своих соседей и обменивается информацией о топологии с этими соседями, рассмотрим рисунок ниже.
Шесть шагов, изображенных на рисунке выше, выполняются следующим образом:
Шаг 1. Маршрутизатор OFF1 хочет видеть, есть ли какие-либо EIGRP-спикер маршрутизаторы вне его интерфейса Gig 0/1, с которым он мог бы, возможно, сформировать соседство. Таким образом, он осуществляет многоадресную рассылку приветственного сообщения EIGRP (EIGRP Hello) на хорошо известный EIGRP multicast-адрес 224.0.0.10 с просьбой к любым EIGRP-спикер маршрутизаторам, идентифицировать себя.
Шаг 2. После получения приветственного сообщения маршрутизатора OFF1 маршрутизатор OFF2 отправляет одноадресное сообщение обновления (unicast Update message)обратно на IP-адрес маршрутизатора OFF1 10.1.1.1. Это сообщение обновления содержит полную таблицу топологии EIGRP маршрутизатора OFF2.
Шаг 3. Маршрутизатор OFF1 получает обновление маршрутизатора OFF2 и отвечает одноадресным сообщением подтверждения (Acknowledgement (ACK), отправленным на IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 4. Затем процесс повторяется, и роли меняются местами. В частности, маршрутизатор OFF2 отправляет приветственное сообщение на адрес многоадресной рассылки EIGRP 224.0.0.10.
Шаг 5. Маршрутизатор OFF1 отвечает на приветственное сообщение маршрутизатора OFF2 одноадресным обновлением (unicast Update), содержащим полную таблицу топологии EIGRP маршрутизатора OFF1. Это unicast Update достигается IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 6. Маршрутизатор OFF2 получает информацию о маршрутизации маршрутизатора OFF1 и отвечает одноадресным сообщением ACK, отправленным на IP-адрес маршрутизатора OFF1 10.1.1.1.
На этом этапе было установлено соседство EIGRP между маршрутизаторами OFF1 и OFF2. Маршрутизаторы будут периодически обмениваться приветственными сообщениями, чтобы подтвердить, что сосед каждого маршрутизатора все еще присутствует. Однако это последний раз, когда маршрутизаторы обмениваются своей полной информацией о маршрутизации. Последующие изменения топологии объявляются через частичные обновления, а не полные обновления, используемые во время создания соседства. Кроме того, обратите внимание, что сообщения обновления во время установления соседа были отправлены как одноадресные сообщения. Однако будущие сообщения обновления отправляются как многоадресные сообщения, предназначенные для 224.0.0.10. Это гарантирует, что все EIGRP-спикер маршрутизаторы на сегменте получают сообщения об обновлении.
EIGRP имеет преимущество перед OSPF в том, как он отправляет свои сообщения об обновлении. В частности, сообщения об обновлении EIGRP отправляются с использованием надежного транспортного протокола ( Reliable Transport Protocol (RTP). Это означает, что, в отличие от OSPF, если сообщение обновления будет потеряно при передаче, он будет повторно отправлено.
Примечание: аббревиатура RTP также относится к Real-time Transport Protocol (RTP), который используется для передачи голосовых и видеопакетов.
Выбор маршрута
Маршруты, показанные в таблице топологии EIGRP, содержат метрическую информацию, указывающую, насколько "далеко" она находится от конкретной целевой сети. Но как именно рассчитывается эта метрика? Расчет метрики EIGRP немного сложнее, чем с RIP или OSPF. В частности, метрика EIGRP по умолчанию является целочисленным значением, основанным на пропускной способности и задержке. Также, вычисление метрики может включать и другие компоненты. Рассмотрим формулу вычисления метрики EIGRP:
Обратите внимание, что расчет метрики включает в себя набор K-значений, которые являются константами, принимающие нулевые значения или некоторые положительные целые числа. Расчет также учитывает пропускную способность, задержку, нагрузку и надежность (bandwidth, delay, load, reliability). Интересно, что большая часть литературы по EIGRP утверждает, что метрика также основана на Maximum Transmission Unit (MTU). Однако, как видно из формулы расчета метрики, MTU отсутствует. Так в чем же дело? Учитывает ли EIGRP MTU интерфейса или нет?
В самом начале разработки EIGRP, MTU был обозначен как Тай-брейкер, если два маршрута имели одинаковую метрику, но разные значения MTU. В такой ситуации был бы выбран маршрут с более высоким MTU. Таким образом, хотя сообщение об обновлении EIGRP действительно содержит информацию MTU, эта информация непосредственно не используется в расчетах метрик.
Далее, давайте рассмотрим каждый компонент расчета метрики EIGRP и tiebreaking MTU:
Bandwidth (Пропускная способность): значение пропускной способности, используемое в расчете метрики EIGRP, определяется путем деления 10 000 000 на пропускную способность (в Кбит / с) самого медленного канала вдоль пути к целевой сети.
Delay (Задержка): в отличие от полосы пропускания, которая представляет собой "самое слабое звено", значение задержки является кумулятивным. В частности, это сумма всех задержек, связанных со всеми интерфейсами, которые используются чтобы добраться до целевой сети. Выходные данные команды show interfaces показывают задержку интерфейса в микросекундах. Однако значение, используемое в расчете метрики EIGRP, выражается в десятках микросекунд. Это означает, что вы суммируете все задержки выходного интерфейса, как показано в выводе show interfaces для каждого выходного интерфейса, а затем делите на 10, чтобы получить единицу измерения в десятки микросекунд.
Reliability (Надежность): надежность-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает на надежность связи. Например, значение надежности 255 указывает на то, что связь надежна на 100 процентов (то есть 255/255 = 1 = 100 процентов).
Load (Нагрузка): как и надежность, нагрузка-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает, насколько занята линия. Например, значение нагрузки 1 указывает на то, что линия загружена минимально (то есть 1/255 = 0,004 1%)
MTU: хотя он не отображается в Формуле вычисления метрики EIGRP, значение MTU интерфейса (которое по умолчанию составляет 1500 байт) переносится в сообщение обновления EIGRP, которое будет использоваться в случае привязки (например, два маршрута к целевой сети имеют одну и ту же метрику, но разные значения MTU), где предпочтительно более высокое значение MTU.
Для улучшения запоминания используйте следующий алгоритм Big Dogs Really Like Me. Где B в слове Big ассоциируется с первой буквой в слове Bandwidth. Буква D в слове Dogs соответствует первой букве D в слове Delay, и так далее.
Однако по умолчанию EIGRP имеет большинство своих K-значений равными нулю, что значительно упрощает расчет метрики, учитывая только пропускную способность и задержку. В частности, значения K по умолчанию являются:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
Если мы подставим эти дефолтные значения K в расчет метрики EIGRP, то значение каждой дроби будет равно нулю, что сводит формулу к следующему:
Чтобы закрепить знания по вычислению метрики, давайте проведем расчет метрики и посмотрим, соответствует ли она нашей таблице топологии EIGRP. Рассмотрим топологию, показанную на рисунке ниже.
Предположим, что мы хотим вычислить метрику для сети 198.51.100.0/24 от роутера OFF1 для маршрута, который идет от OFF1 до OFF2, а затем выходит в целевую сеть. Из топологии мы можем определить, что нам нужно будет выйти с двух интерфейсов маршрутизатора, чтобы добраться от маршрутизатора OFF1 до сети 198.51.100.0 /24 через маршрутизатор OFF2. Эти два выходных интерфейса являются интерфейсами Gig0/1 на маршрутизаторе OFF1 и интерфейсом Gig0/3 на маршрутизаторе OFF2. Мы можем определить пропускную способность и задержку, связанные с каждым интерфейсом, изучив выходные данные команд show interfaces, приведенных в следующем примере.
Определение значений пропускной способности и задержки интерфейса на маршрутизаторах OFF1 и OFF2
Из приведенного выше примера мы видим, что оба выходных интерфейса имеют пропускную способность 1 000 000 Кбит/с (то есть 1 Гбит/с). Кроме того, мы видим, что каждый выходной интерфейс имеет задержку в 10 микросекунд. Значение пропускной способности, которое мы вводим в нашу формулу вычисления метрики EIGRP, - это пропускная способность самого медленного канала на пути к целевой сети, измеряемая в Кбит/с. В нашем случае оба выходных интерфейса имеют одинаковую скорость соединения, то есть мы говорим, что наша "самая медленная" связь составляет 1 000 000 Кбит/с.
Для примера ниже показаны общие значения по умолчанию для пропускной способности и задержки на различных типах интерфейсов маршрутизатора Cisco.
Общие значения по умолчанию для пропускной способности и задержки интерфейса:
Наше значение задержки может быть вычислено путем сложения задержек выходного интерфейса (измеренных в микросекундах) и деления на 10 (чтобы дать нам значение, измеренное в десятках микросекунд). Каждый из наших двух выходных интерфейсов имеет задержку в 10 микросекунд, что дает нам суммарную задержку в 20 микросекунд. Однако мы хотим, чтобы наша единица измерения была в десятках микросекунд. Поэтому мы делим 20 микросекунд на 10, что дает нам 2 десятка микросекунд. Теперь у нас есть два необходимых значения для нашей формулы: пропускная способность = 1 000 000 Кбит/с и задержка = 2 десятка микросекунд. Теперь давайте добавим эти значения в нашу формулу:
Вычисленное значение показателя EIGRP составляет 3072. Теперь давайте посмотрим, является ли это фактической метрикой, появляющейся в таблице топологии EIGRP маршрутизатора OFF1. Выходные данные команды show ip eigrp topology, выведенные на маршрутизаторе OFF1, показаны в следующем примере.
Проверка метрики EIGRP для сети 198.51.100.0/24 на маршрутизаторе OFF1
Как и предполагалось, метрика (также известная как допустимое расстояние) от маршрутизатора OFF1 до Сети 198.51.100.0 /24 через маршрутизатор OFF2 составляет 3072. Напомним, что в этом примере мы использовали значения K по умолчанию, что также является обычной практикой в реальном мире. Однако для целей проектирования мы можем манипулировать K-значениями. Например, если мы обеспокоены надежностью каналом связи или нагрузкой, которую мы могли бы испытать на линии, мы можем манипулировать нашими K-значениями таким образом, чтобы EIGRP начал бы рассматривать надежность и/или нагрузку в своем метрическом расчете. В следующей статье мы рассмотрим, как мы можем изменить эти K - значения в EIGRP по умолчанию.
Привет! Сегодня мы оговорим немного о базовой сетевой безопасности, а именно о Port-Security и о том, как его настроить на коммутаторах Cisco.
Для начала разберемся, что же вообще такое Port-Security. Port-Security – это функция коммутатора, при помощи которой мы можем указать каким устройствам можно пропускать трафик через определенные порты. Устройство определяется по его MAC-адресу.
Эта функция предназначена для защиты от несанкционированного подключения к сети и атак, направленных на переполнение таблицы MAC-адресов. При помощи нее мы можем указывать конкретные адреса, с которых разрешен доступ или указывать максимальное количество MAC-адресов, которые могут передавать трафик через порт.
Типы Port-Security
Существует несколько способов настройки port-security:
Статические MAC-адреса – MAC-адреса, которые вручную настроены на порту, из режима конфигурации порта при помощи команды switchport port-security mac-address [MAC-адрес] . MAC-адреса, сконфигурированные таким образом, сохраняются в таблице адресов и добавляются в текущую конфигурацию коммутатора.
Динамические MAC-адреса - MAC-адреса, которые динамически изучаются и хранятся только в таблице адресов. MAC-адреса, сконфигурированные таким образом, удаляются при перезапуске коммутатора.
Sticky MAC-адреса - MAC-адреса, которые могут быть изучены динамически или сконфигурированы вручную, затем сохранены в таблице адресов и добавлены в текущую конфигурацию.
Sticky MAC-адреса
Если необходимо настроить port-security со sticky MAC-адресами, которые преобразуются с из динамически изученных адресов и добавляются в текущую конфигурацию, то необходимо настроить так называемое sticky изучение. Для того чтобы его включить необходимо на интерфейсе коммутатора выполнить команду switchport port-security mac-address sticky из режима конфигурации интерфейса.
Когда эта команда введена, коммутатор преобразует все динамически изученные MAC-адреса (включая те, которые были динамически изучены до того, как было включено sticky обучение) к sticky MAC-адресам. Все sticky MAC-адреса добавляются в таблицу адресов и в текущую конфигурацию.
Также sticky адреса можно указать вручную. Когда sticky MAC-адреса настроены при помощи команды switchport port-security mac-address sticky [MAC-адрес], все указанные адреса добавляются в таблицу адресов и текущую конфигурацию.
Если sticky MAC-адреса сохранены в файле конфигурации, то при перезапуске коммутатора или отключении интерфейса интерфейс не должен будет переучивать адреса. Если же sticky адреса не будут сохранены, то они будут потеряны.
Если sticky обучение отключено при помощи команды no switchport port-security mac-address sticky , то эти адреса будут оставаться в таблице адресов, но удалятся из текущей конфигурации.
Обратите внимание, что port-security не будут работать до тех пор, пока не будет введена команда, включающая его - switchport port-security
Нарушение безопасности
Нарушением безопасности являются следующие ситуации:
Максимальное количество MAC-адресов было добавлено в таблицу адресов для интерфейса, а устройство, MAC-адрес которого отсутствует в таблице адресов, пытается получить доступ к интерфейсу.
Адрес, полученный или сконфигурированный на одном интерфейсе, отображается на другом интерфейсе в той же VLAN.
На интерфейсе может быть настроен один из трех режимов реагирования при нарушении:
Protect - когда количество MAC-адресов достигает предела, разрешенного для порта, пакеты с неизвестными исходными адресами отбрасываются до тех пор, пока не будет удалено достаточное количество MAC-адресов или количество максимально допустимых адресов для порта не будет увеличено. Уведомление о нарушении безопасности отсутствует в этом случае.
Restrict – то же самое, что и в случае Protect, однако в этом случае появляется уведомление о нарушении безопасности. Счетчик ошибок увеличивается
Shutdown – стандартный режим, в котором нарушения заставляют интерфейс немедленно отключиться и отключить светодиод порта. Он также увеличивает счетчик нарушений. Когда порт находится в этом состоянии (error-disabled), его можно вывести из него введя команды shutdown и no shutdown в режиме конфигурации интерфейса.
Чтобы изменить режим нарушения на порту коммутатора, используется команда port-security violation {protect | restrict |shutdown} в режиме конфигурации интерфейса.
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:black;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;border-color:black;}
.tg .tg-fymr{font-weight:bold;border-color:inherit;text-align:left;vertical-align:top}
.tg .tg-0pky{border-color:inherit;text-align:left;vertical-align:top}
Режим реагирования
Передача траффика
Отправка сообщения syslog
Отображение сообщения об ошибке
Увеличение счетчика нарушений
Выключение порта
Protect
Нет
Нет
Нет
Нет
Нет
Restrict
Нет
Да
Нет
Да
Нет
Shutdown
Нет
Нет
Нет
Да
Да
Настройка
Рассмотрим пример настройки:
Switch#interface fa0/1 – заходим в режим конфигурации порта
Switch(config-ig)#switchport mode access – делаем порт access
Switch(config-ig)#switchport port-security – включаем port-security
Switch(config-ig)#switchport port-security maximum 50 – задаем максимальное количество адресов на порту
Switch(config-ig)#switchport port-security mac-address sticky – включаем sticky изучение
Если мы не будем ничего уточнять и просто включим port-security командой switchport port-security в режиме конфигурации интерфейса, то максимальное количество адресов на порту будет один, sticky изучение будет выключено, а режим нарушения безопасности будет shutdown.
Проверка порта
Чтобы отобразить параметры port-security используется команда show port-security [номер_интерфейса] .
Чтобы отобразить все защищенные MAC-адреса используется команда show port-security address.