По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В одном из прошлых статей мы рассмотрели способы фильтрации маршрутов для динамического протокола маршрутизации EIGRP. Следует отметить, что EIGRP проприетарная разработка Cisco, но уже открыта другим производителям. OSPF же протокол открытого стандарта и поддерживается всем вендорами сетевого оборудования. Предполагается, что читатель знаком с данным протоколом маршрутизации и имеет знания на уровне CCNA. OSPF тоже поддерживает фильтрацию маршрутов, но в отличии от EIGRP, где фильтрацию можно делать на любом маршрутизаторе, здесь она возможна только на пограничных роутерах, которые называются ABR (Area Border Router) и ASBR (Autonomous System Boundary Router). Причиной этому является логика анонсирования маршрутов в протоколе OSPF. Не вдаваясь в подробности скажу, что здесь маршруты объявляются с помощью LSA (Link State Advertisement). Существует 11 типов LSA, но рассматривать их мы не будем. По ходу статьи рассмотрим только Type 3 LSA и Type 5 LSA. LSA третьего типа создаются пограничными роутерами, которые подключены к магистральной области (backbone area) и минимум одной немагистральной. Type 3 LSA также называются Summary LSA. С помощью данного типа LSA ABR анонсирует сети из одной области в другую. В таблице базы данных OSPF они отображается как Summary Net Link States: Фильтрация LSA третьего типа говорит маршрутизатору не анонсировать сети из одной области в другую, тем самым закрывая доступ к сетям, которые не должны отображаться в других областях. Видео: протокол OSPF (Open Shortest Path First) за 8 минут Для настройки фильтрации применяется команда area area-num filter-list prefix prefix-list-name {in | out} в интерфейсе конфигурации OSPF. Как видно, здесь применяются списки префиксов или prefix-list, о которых мы говорили в предыдущей статье. Маршрут не анонсируется если попадает под действие deny в списке префиксов. Камнем преткновения в данной команде являются ключевые слова in и out. Эти параметры определяют направление фильтрации в зависимости от номера области, указанного в команде area are-num filter. А работают они следующим образом: Если прописано слово in, то маршрутизатор предотвращает попадание указанных сетей в область, номер которого указан в команде. Если прописано слово out, то маршрутизатор фильтрует номера сетей, исходящих из области, номер которого указан в команде. Схематически это выглядит так: Команда area 0 filter-list in отфильтрует все LSA третьего типа (из областей 1 и 2), и они не попадут в area 0. Но в area 2 маршруты в area 1 попадут, так как нет команд вроде area 2 filter-list in или area 1 filter-list out. Вторая же команда: area 2 filter-list out отфильтрует все маршруты из области 2. В данном примере маршрутная информация из второй области не попадёт ни в одну из областей. В нашей топологии, показанной на рисунке, имеются две точки фильтрации, то есть два пограничных маршрутизатора: При чем каждый из этих маршрутизаторов будет фильтровать разные сети. Также мы здесь используем обе ключевых слова in и out. На ABR1 напишем следующие prefix-list-ы: ip prefix-list FILTER-INTO-AREA-34 seq 5 deny 10.16.3.0/24 ip prefix-list FILTER-INTO-AREA-34 seq 10 permit 0.0.0.0/0 le 32 А на ABR2 ip prefix-list FILTER-OUT-OF-AREA-0 seq 5 deny 10.16.2.0/23 ge 24 le 24 ip prefix-list FILTER-OUT-OF-AREA-0 seq 10 permit 0.0.0.0/0 le 32 Теперь проверив таблицу маршрутизации на R3, увидим, что маршрут до сети 10.16.3.0 отсутствует: Теперь поясним, что мы сказали маршрутизатору. В конфигурации ABR1 первый prefix-list с действием deny совпадет только с маршрутом, который начинается на 10.16.3.0, а длина префикса равна 24. Второй же префикс соответствует всем остальным маршрутам. А командой area 34 filter-list prefix FILTER-INTO-AREA-34 in сказали отфильтровать все сети, которые поступают в 34 область. Поэтому в базе OSPF маршрута в сеть 10.16.3 через R1 не будет. На втором же маршрутизаторе пошли другим путём. Первый команда ip prefix-list FILTER-OUT-OF-AREA-0 seq 5 deny 10.16.2.0/23 ge 24 le 24 совпадет с маршрутами, который начинается на 10.16.2.0 и 10.16.3.0, так как указан /23. На языке списка префиксов означает взять адреса, которые могут соответствовать маске 255.255.254.0, а длина префикса адреса равна 24. А командой area 0 out сказали отфильтровать все LSA 3 типа, которые исходят из области 0. На первый взгляд кажется сложным, но если присмотреться, то все станет ясно. Фильтрация маршрутов в OSPF через distribute-list Фильтрация LSA третьего типа не всегда помогает. Представим ситуацию, когда в какой-то области 50 маршрутизаторов, а нам нужно чтобы маршрутная информация не попала в таблицу только 10 роутеров. В таком случае фильтрация по LSA не поможет, так как он фильтрует маршрут исходящий или входящий в область, в нашем случае маршрут не попадёт ни на один маршрутизатор, что противоречит поставленной задаче. Для таких случаев предусмотрена функция distribute-list. Она просто не добавляет указанный маршрут в таблицу маршрутизации, но в базе OSPF маршрут до сети будет. В отличии от настройки distribute-list в EIGRP, в OSPF нужно учесть следующие аспекты: Команда distribute-list требует указания параметров in | out, но только при применении in фильтрация будет работать. Для фильтрации команда может использовать ACL, prefix-list или route-map. Можно также добавить параметр interface interface-type-number, чтобы применить фильтрацию для конкретного интерфейса. Внесем некоторые изменения в конфигурацию маршрутизатора R3, чтобы отфильтровать маршрут до сети 10.16.1.0: Как видно на выводе, до применения prefix-list-а, в таблице маршрутизации есть маршрут до сети 10.16.1.0. Но после внесения изменений маршрут исчезает из таблицы, но вывод команды show ip ospf database | i 10.16.1.0 показывает, что в базе OSPF данный маршрут существует. Фильтрация маршрутов на ASBR Как уже было сказано в начале материала, ASBR это маршрутизатор, который стоит между двумя разными автономными системами. Именно он генерирует LSA пятого типа, которые включают в себя маршруты в сети, находящиеся вне домена OSPF. Топология сети показана ниже: Конфигурацию всех устройств из этой статьи можно скачать в архиве по ссылке ниже. Скачать конфиги тестовой лаборатории Как видно из рисунка, у нас есть два разных домена динамической маршрутизации. На роутере ASBR настроена редистрибюция маршрутов, то есть маршруты из одно домена маршрутизации попадают во второй. Нам нужно отфильтровать маршруты таким образом, чтобы сети 172.16.101.0/24 и 172.16.102.0/25 не попали в домен EIGRP. Все остальные, включая сети точка-точка, должны быть видны для пользователей в сети EIGRP. Для фильтрации Cisco IOS нам дает всего один инструмент route-map. О них мы подробно рассказывали в статье и фильтрации маршрутов в EIGRP. Можно пойти двумя путями. Либо запрещаем указанные маршруты, в конце добавляем route-map с действием permit, который разрешит все остальные, либо разрешаем указанным в списке префиксов маршруты, а все остальное запрещаем (имейте ввиду, что в конце любого route-map имеется явный запрет deny). Покажем второй вариант, а первый можете протестировать сами и поделиться результатом. Для начала создаем списки префиксов с разрешёнными сетями: ip prefix-list match-area0-permit seq 5 permit 172.16.14.0/30 ip prefix-list match-area0-permit seq 10 permit 172.16.18.0/30 ip prefix-list match-area0-permit seq 15 permit 172.16.8.1/32 ip prefix-list match-area0-permit seq 20 permit 172.16.4.1/32 ip prefix-list match-area0-permit seq 25 permit 172.16.48.0/25 ip prefix-list match-area0-permit seq 30 permit 172.16.49.0/25 ip prefix-list match-area3-permit seq 5 permit 172.16.103.0/24 ge 26 le 26 Еще раз отметим, что фильтрация LSA Type 5 делается только на ASBR маршрутизаторе. До внесения изменений на маршрутизаторе R1 видны сети до 101.0 и 102.0: Применим изменения на ASBR: Проверим таблицу маршрутизации R1 еще раз: Как видим, маршруты в сеть 101.0 и 102.0 исчезли из таблицы. На этом, пожалуй, завершим это материал. Он и так оказался достаточно большим и сложным. Удачи в экспериментах!
img
Ansible один из двух (наряду с SaltStack) наиболее популярных программных комплексов третьей волны, которые позволяют удалённо управлять конфигурациями. Тем не менее, в сегменте сетевого оборудования лидирует наш сегодняшний герой (если о ПО можно так сказать). В первую очередь это вызвано тем, что Ansible не поставит перед пользователем задачи устанавливать агент на хостинги, требующие от него управления. Тем паче ежели Ваш аппарат взаимодействует с ними через CLI, то Ansible это то, что доктор прописал. Одним выстрелом три "электронных зайца" Вообще, прежде чем знакомить уважаемых читателей со сценарием работы в данном программном комплексе, позвольте перечислить несколько его достоинств: Ansible позволяет параллельно подключать по SSH к устройствам (пользователь может сам определить их число). Ansible может передавать задачи на подключённые машины. Ansible способен разбивать машины, входящих в систему, на подгруппы и передавать специальных задачи для каждой подгруппы. Конечно, указаны не все достоинства Ansible. Просто в данных 3 пунктах, как мне кажется, отражена основная суть работы в данной среде. Выполняя эти три задачи, система автоматически освобождает Вас от головной боли по делегированию задач и функций в компании. Время деньги, как говорится. Сценарии Ну и переходим к основному блюду нашего материала - сценариям (playbook). Они состоят из двух частей набора команд для выполнения (play) и конкретных команд (task). Они выполняются друг за другом. Все записи данных осуществляются с помощью YAMLа. К несомненным плюсам его использования следует отнести то, что он гораздо лучше воспринимается людьми, нежели тот же самый JSON. Ежели Вы больше привыкли Вы к Python, то тут у Вас не возникнет проблем с адаптацией, так как синтаксис у них схожий. А вот так происходит процесс написания сценария (комментарии даны построчно к выводу): Имя сценария обязательный элемент для любого сценария; Сценарий применяется к машинам в подгруппе cisco-routers; Выключение режима сбора событий в конкретной машине (если не выключить данный режим, то система потратит много времени на решение ненужных задач); В разделе task указывается список команд для каждого конкретного случая; После чего происходит выполнение команды: PLAY [Run show commands on routers] *************************************************** TASK [run sh ip int br] *************************************************************** changed: [192.168.100.1] changed: [192.168.100.3] changed: [192.168.100.2] TASK [run sh ip route] **************************************************************** changed: [192.168.100.1] changed: [192.168.100.3] changed: [192.168.100.2] PLAY [Run show commands on switches] ************************************************** TASK [run sh int status] ************************************************************** changed: [192.168.100.100] TASK [run sh vlans] ******************************************************************* changed: [192.168.100.100] PLAY RECAP **************************************************************************** 192.168.100.1 : ok=2 changed=2 unreachable=0 failed=0 192.168.100.100 : ok=2 changed=2 unreachable=0 failed=0 192.168.100.2 : ok=2 changed=2 unreachable=0 failed=0 192.168.100.3 : ok=2 changed=2 unreachable=0 failed=0 И запускаем проверку выполнения команд: SSH password: PLAY [Run show commands on routers] *************************************************** TASK [run s hip int br] *************************************************************** Changed: [192.168.100.1] => {“changed”: true, “rc”: 0, “stderr”: “Shared connection To 192.168.100.1 closed. ”, “stdout”: “ Interface IP-Address OK? Method Status Protocol Ethernet0/0 192. 168.100.1 YES NVRAM up up Ethernet0/1 192.168.200.1 YES NVRAM up up Loopback0 10.1.1.1 YES manual up up ”, “stdout_lines “: [“”, “Interface IP-Address OK? Method Status Protocol”, “Ethernet0/0 192.168.100.1 YES NVRAM up up “, “Ethernet0/1 192.168.200.1 YES NVRAM up up “, “Loopaback0 10.1.1.1 YES manual up up “]} А что внутри? А теперь поговорим о начинке сценария. Основу составляют переменные. Это могут быть данные о машине, выводы команд, а также их можно вводить вручную. Главное не забывать правила написания имён. Их всего два: имена всегда должны состоять из букв, цифр и нижнего подчёркивания; имена всегда должны начинаться с буквы. Переменные могут быть определены разными способами: Инвентарным файлом [cisco-routers] 192.168.100.1 192.168.100.2 192.168.100.3 [cisco-switches] 192.168.100.100 [cisco-routers:vars] ntp_server=192.168.255.100 log_server=10.255.100.1 PLAYBOOKом -name: Run show commands on router: hosts: cisco-routers gather_facts: false vars: ntp_server: 192.168.255.100 log_server: 10.255.100.1 tasks: -name: run sh ip int br raw: s hip int br | ex unass -name: run s hip route raw: sh ip route Специальными файлами, созданными для групп: [cisco-routers] 192.168.100.1 192.168.100.2 192.168.100.3 [cisco-switches] 192.168.100.100 Или группами каталогов |– group_vars _ | |– all.yml | | |–cisco-routers.yml | Каталог с переменными для групп устройств | |–cisco-switches.yml _| | |–host vars _ | |–192.168.100.1 | | |–192.168.100.2 | | |–192.168.100.3 | Каталог с переменными для устройств | |–192.168.100.100 _| | |–myhosts | Инвертарный файл Команда register позволяет сохранять результаты выполнений модулей в переменные. После чего переменная может быть использована в шаблонах, принятиях решений о выполнении заданного сценария. --- - name: Run show commands on routers hosts: cisco-routers gather_facts: false tasks: -name: run s hip int br raw: s hip int br | ex unass register: sh_ip_int_br_result --- debug отображает информацию в стандартном потоке вывода в виде произвольной строки, переменной или фактах о машине. --- - name: Run show commands on routers hosts: cisco-routers gather_facts: false tasks: -name: run s hip int br raw: sh ip int br | ex unass register: sh_ip_int_br_result -name: Debug registered var debug: var=sh_ip_int_br_result.stdout_lines После чего результатом работы станет следующее: SSH password: PLAY [Run show commands on routers] *************************************************** TASK [run sh ip int br] *************************************************************** changed: [192.168.100.1] changed: [192.168.100.2] changed: [192.168.100.3] TASK [Debug registered var] *********************************************************** ok: [192.168.100.1] => { “sh_ip_int_br_result.stdout_lines”: [ “”, “Interface IP-Address OK? Method Status Protocol”, “Ethernet0/0 192.168.100.1 YES NVRAM up up “, “Ethernet0/1 192.168.200.1 YES NVRAM up up “, “Loopback0 10.1.1.1 YES manual up up “ ] } ok: [192.168.100.2] => { “sh_ip_int_br_result.stdout_lines”: [ “”, “Interface IP-Address OK? Method Status Protocol”, “Ethernet0/0 192.168.100.1 YES NVRAM up up “, “Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “, “Loopback0 10.1.1.1 YES manual up up “ ] } ok: [192.168.100.3] => { “sh_ip_int_br_result.stdout_lines”: [ “”, “Interface IP-Address OK? Method Status Protocol”, “Ethernet0/0 192.168.100.3 YES NVRAM up up “, “Ethernet0/2 192.168.200.1 YES NVRAM administratively down down “, “Loopback0 10.1.1.1 YES manual up up “, “Loopback10 10.255.3.3 YES manual up up “ ] } PLAY RECAP **************************************************************************** 192.168.100.1 : ok=2 changed=1 unreachable=0 failed=0 192.168.100.2 : ok=2 changed=1 unreachable=0 failed=0 192.168.100.3 : ok=2 changed=1 unreachable=0 failed=0 Вместо заключения Можно ещё долго приводить примеры работы в системе, но ещё один факт так сказать "вишенка на торте". К плюсам Ansible следует отнести и то, что заданную команду система может выполнять практически до бесконечности. Пока не наступит требуемый результат трансформации не прекратятся. Пользователю можно не беспокоиться - программа сама всё сделает за Вас, а Вы можете заниматься другими делами.
img
Эта статья завершает нашу серию лекций по пониманию EIGRP рассмотрением двух последних тем: Идентификатор роутера EIGRP Требования к соседству EIGRP Предыдущие статьи цикла: Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка Часть 2. Про соседство и метрики EIGRP Часть 2.2. Установка K-значений в EIGRP Часть 3. Конвергенция EIGRP – настройка таймеров Часть 4. Пассивные интерфейсы в EIGRP Часть 5. Настройка статического соседства в EIGRP Начнем мы наше обсуждение с рассмотрения идентификатора роутера EIGRP. EIGRP Router ID Каждый EIGRP-спикер роутер имеет ассоциируемый router ID EIGRP (RID). RID - это 32-битное значение, записанное в десятичном формате с точками, например IPv4-адрес. RID EIGRP определяется, когда процесс EIGRP начинает выполняться. Интересно, что EIGRP использует те же шаги для определения RID, что и OSPF. Ниже показаны последовательные шаги определения RID: Шаг 1. Применить заданное значение RID. Шаг 2. Если RID не настроен, используйте самый старший IPv4-адрес на loopback интерфейсе, находящийся в состоянии up/up. Шаг 3. Если ни один loopback интерфейс не настроен с IPv4-адресом, используйте самый высокий IPv4-адрес на non-loopback интерфейсе. Интересно, что в то время, как EIGRP требует, чтобы роутер имел RID, значение RID играет очень тривиальную роль в процессе EIGRP. Соседи EIGRP могут дублировать RID и устанавливать соседство EIGRP между ними, хотя лучше всего назначать уникальные RID соседям EIGRP. Однако, прежде чем мы чрезмерно минимизируем RID, есть один очень важный момент, когда роутер нуждается в уникальном RID роутера. В частности, если мы вводим внешние маршруты в процесс маршрутизации EIGRP, роутер, выполняющий это перераспределение, нуждается в уникальном RID. Настройка и проверка Router ID EIGRP Чтобы сделать схему сетевой адресации более интуитивно понятной, вы можете выбрать ручную настройку RID EIGRP на определенном роутере. Это можно сделать с помощью команды EIGRP router-id rid, как показано на роутере OFF1 и показано в следующем примере: OFF1#conf term Enter configuration commands, one per line. End with CNTL/Z. OFF1(config)#router eigrp 1 OFF1(config-router)#eigrp router-id 1.1.1.1 OFF1(config-router)#end OFF1# Обратите внимание на выходные данные в приведенном выше примере, что мы вручную установили RID роутера OFF1 на 1.1.1.1. Команды проверки, которые позволяют нам просматривать RID роутера, включают: show ip eigrp topology и show ip protocols, как показано в следующих примерах: Требования к соседству Одной из основных проблем, возникающих при устранении неполадок в сети EIGRP, является установление соседства. EIGRP имеет несколько требований, как и OSPF. Однако EIGRP и OSPF немного отличаются по своим предпосылкам соседства. В таблице ниже перечислены и противопоставлены правила установления соседства как для EIGRP, так и для OSPF. Требования EIGRP OSPF иметь возможность отправлять пакеты на другой сервер Да Да Первичный адрес интерфейса (не вторичный адрес) должен быть включен в ту же подсеть, что и сеть, сопоставляемая оператором network. Да Да Интерфейс, соединенный с соседом не должен быть пассивным. Да Да Необходимо использовать ту же автономную систему (для EIGRP) или process-ID (для OSPF) при настройке роутера. Да Нет Таймер Hello и таймер Hold (для EIGRP) или Dead таймер (дляOSPF)максимально совпадать. Нет Да Соседи должны аутентифицироваться друг с другом, если аутентификация настроена. Да Да Должно быть в той же зоне N/A Да IP MTU совпадает. Нет Да К-значения совпадают Да N/A Идентификаторы роутеров (rid) должны быть уникальными Нет Да
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59