.png){kind=logo}
+7 (812) 718-6184
Как известно одной из задач протоколов динамической маршрутизации является обмен маршрутной информацией. В данном случае будет неважно, маршрутами, или информацией о линках идет обмен. Разберемся с процедурой определения на каких интерфейсах маршрутизатор будет принимать и отправлять сообщения того или иного протокола динамической маршрутизации. Традиционно в IPv4 почти для всех протоколов принято запускать процесс с помощью команды network.
Настройка протокола OSPF
Разберем пример:
Исходная топология с системой адресации представлена на схеме. Наша задача настроить протокол OSPF в этой сети.
Начнем с маршрутизатора R1. На нем запуск будет более информативен.
(config)#router OSPF 1
R1(config-router)#
*Mar 1 00:02:48.803: %OSPF-4-NORTRID: OSPF process 1 cannot pick a router-id.
Please configure manually or bring up an interface with an ip address.
R1(config-router)#
При попытке запуска процесса OSPF получаем уведомление о том, что процесс не может получить некий routerID. Напомню, routerID для OSPF играет очень важную роль. Именно с идентификаторами маршрутизаторов и связана в конечном итоге топология связей. Когда роутер передает информацию о линках, необходимо понимание какой это роутер? Для этого и служит значение routerID. Так же, на основе этого значения происходят выборы DR и BDR ролей. И совсем неплохо, если вы сможете контролировать эти значения и их постоянство. Поскольку смена ролей и ID маршрутизаторов будет приводить к рассылке дополнительного трафика и перезапуску алгоритма SPF. Значение routerID необходимо сконфигурировать. И сделать это можно явно задав его командой router-id.
R1(config-router)# router-id 192.168.255.254
R1(config-router)#do show ip protocols
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 192.168.255.254
Если же ID не задан в явном виде, то выбирается максимальное математическое значение из ip адресов loopback интерфейсов. Снять уже заданный routerID проблематично, даже если вы уже создали по крайней мере loopback интерфейс и назначили ему адрес. Команда no router-id эффекта не дает. Перезапуск процесса с clear ip ospf тоже без результатов. В случае если ID уже был взят с интерфейса, а затем перебит явно, то отмена работает. Так же если вообще погасить процесс, а затем запустить по новой. Но нужно учитывать, что в таком случае вы теряете все настройки по этому процессу. Отсюда делаем вывод: если необходимо изменить ID маршрутизатора, то стоит делать это командой router-id, новое значение перекроет предыдущее и если прежнее значение устанавливалось через loopback, или через команду router-id. Еще один вариант получения ID через ip адрес физического интерфейса, активного в данный момент. Такой вариант работает, когда значение не установлено явно и нет loopback интерфейса или ему не назначен адрес. Чтобы не угадывать, какой ID у роутера после перезагрузки, отключений, включений интерфейсов, создания, удаления loopback интерфейсов, в данном случае стоит явно задать значение и больше об этом не беспокоиться. Напомню, что в IPv6 значение routerID оставили четырехбайтовым и с записью в стиле IPv4. Процесс для IPv6 так же может принять значение routerID от ipv4 адреса loopback интерфейса. Но тут все те же неприятности. Отсутствие такого интерфейса или адреса не нем, смена адресов, добавление интерфейсов. Поэтому при настройке OSPFv3 однозначно рекомендую назначать ID роутера явно.
Итог. В качестве ID роутера по приоритетности снизу вверх могут быть: ip активного физического интерфейса, ip loopback интерфейса, явно указанный router-id. Предпочтительно использовать явно указанный router-id.
Теперь, когда процесс запущен, необходимо решить две задачи:
1. Определить на каких интерфейсах маршрутизатор будет отправлять и принимать информацию данного протокола маршрутизации.
2. Указать, какие маршруты (линки) будут анонсироваться данным маршрутизатором.
Обе эти задачи успешно решает команда network. Но тут есть некоторые правила.
Рассмотрим примеры:
R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 12.0.0.129 YES manual up up
FastEthernet0/1 12.0.0.1 YES manual up up
FastEthernet1/0 13.0.0.1 YES manual up up
Loopback0 172.31.255.254 YES manual up up
С учетом Loopback0 имеем 4 подключения.
Дадим команду network 13.0.0.0, без указания wildcard она в отличие от EIGRP не работает.
Используем вариант network 13.0.0.0 0.0.0.255 area 0
R1(config)#router ospf 1
R1(config-router)#network 13.0.0.0 0.0.0.255 area 0
*Mar 1 02:41:34.839: %OSPF-5-ADJCHG: Process 1, Nbr 172.31.255.253 on FastEthernet1/0 from LOADING to FULL, Loading Done
R1(config-router)#do sh ip ospf int
FastEthernet1/0 is up, line protocol is up
Internet Address 13.0.0.1/24, Area 0
Process ID 1, Router ID 172.16.0.2, Network Type BROADCAST, Cost: 1
Только один интерфейс участвует в OSPF, тот, который принадлежит объявленной сети. А какую информацию он передает соседу? Пока никакую. Для передачи информации в OSPF сначала нужно установить смежность с соседом. Запустим OSPF на соседнем роутере. Никакой дополнительной маршрутной информации на соседях не появилось.
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, FastEthernet0/0
Маршрутизаторы анонсируют информацию только об объявленной сети. Анонсируем сети 12.0.0.0.25 и 12.0.0.128.25 одной строкой network 12.0.0.0 0.0.0.255 area0.
На соседнем роутере наблюдаем:
12.0.0.0/25 is subnetted, 2 subnets
O 12.0.0.0 [110/20] via 13.0.0.1, 00:00:02, FastEthernet0/0
O 12.0.0.128 [110/20] via 13.0.0.1, 00:00:02, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, FastEthernet0/0
Как видим, информация передается обо всех линках, попавших в диапазон 12.0.0.0.0/24, а так же на интерфейсах с адресами 12.0.0.1 и 12.0.0.129 запустился процесс OSPF. Можно убедиться в этом дав команду: R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/1 1 0 12.0.0.1/25 10 DR 0/0
Fa0/0 1 0 12.0.0.129/25 10 DR 0/0
Fa1/0 1 0 13.0.0.1/24 1 DR 1/1
На маршрутизаторе R3 запустим процесс прямо на интерфейсе.
R3(config-if)#ip ospf 1 area 0
Результат аналогичный с командой network. OSPF процесс запущен, смежность установлена, линк, которому принадлежит интерфейс анонсируется. При этом не понадобилось отдельной командой запускать OSPF процесс 1.
Наконец на маршрутизаторе R2 произведем запуск следующим образом:
R2#sh ip ospf int br
R2#conf t
R2(config)#router ospf 1
R2(config-router)#network 0.0.0.0 255.255.255.255 area 0
R2(config-router)#^Z
R2#sh ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se1/0 1 0 11.0.0.1/30 64 P2P 0/0
Fa0/0 1 0 12.0.0.2/25 10 BDR 0/1
Такой подход удобен, тем, что OSPF процесс запускается одной командой на всех интерфейсах и объявления идут обо всех линках. Минус в том, что вывод сведений о том для каких линков идет анонс очень неинформативен. Плюс мы не можем не объявлять о какой-либо сети. Можно прекратить анонс через желаемый интерфейс с помощью команды passive-interface, но анонсы о линке все равно останутся. И несколько смущает вывод:
R2#sh ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se1/0 1 0 11.0.0.1/30 64 P2P 0/0
Fa0/0 1 0 12.0.0.2/25 10 BDR 1/1
Хотя видно, что соседей на Se1/0 нет, непонятно, их нет потому, что интерфейс пассивный или там действительно нет соседей. Необходимо уточнять с помощью show ip protocols.
Что будет в таком варианте, если добавить новый интерфейс в маршрутизатор? На нем сразу запустится OSPF процесс и автоматически этот линк будет включен в анонсы.
Выбор за вами. В различных ситуациях лучшим решением будет тот или иной вариант. Где-то стоит выполнять запуск явно на интерфейсе, где-то можно запустить сразу на всех интерфейсах и далее некоторые делать пассивными, где-то командой passive-interface default можно вывести все интерфейсы в пассивный режим, а некоторые активировать через no passive-interface.
В OSPF нельзя запустить команду network без указания вайлдкард маски. Вместо вайлдкард маски можно использовать и обычную, но обязательно какую-нибудь! Помните. В OSPF передается информация о линках, а не о маршрутах. Даже запуск команды network с указанием агрегированного диапазона приведет к анонсу каждого линка, входящего в этот диапазон и никакие autosummary здесь ничего не меняют в отличие от дистанционно-векторных протоколов.
Вы можете легко объявить несуществующий линк. Это не значит, что он будет анонсироваться. Еще раз напомню, при запуске network 0.0.0.0 255.255.255.255 area X, ни о каком линке 0.0.0.0 ничего не анонсируется. Так же и с другими вариантами неизвестных для данного маршрутизатора линках. Даже если мы проинсталлируем статический маршрут в сеть и объявим о ней в OSPF это ничего не даст. Роутер анонсирует только известные ему линки и те, что узнал от соседей. Для объявления информации о статическом маршруте необходимо включить редистрибьюцию статических маршрутов. Но при этом анонсировать их командой network не нужно, а при необходимости стоит применять фильтрацию.
Настройка протокола EIGRP
Теперь рассмотрим отличия с протоколом EIGRP.
Основные особенности работы протокола EIGRP, определяются тем, что он все же дистанционно-векторный протокол и объявляет маршруты, а не линки.
Схема будет, как в задаче с OSPF.
Командой network 0.0.0.0 даже без указания вайлдкард маски EIGRP процесс будет запущен на всех интерфейсах и объявляться будут все сети. Дадим команду на роутере R1. Напомню, что в EIGRP необходимо учитывать вопрос автосуммаризации. При таком запуске EIGRP и включенной автосуммаризации объявляться будут классовые варианты сетей. В этом легко убедиться проверив таблицу маршрутизации на соседнем роутере.
D 172.31.0.0/16 [90/409600] via 13.0.0.1, 00:00:14, FastEthernet0/0
D 12.0.0.0/8 [90/307200] via 13.0.0.1, 00:00:14, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, FastEthernet0/0
На R4 видим только один маршрут в сеть 12.0.0.0/8.
Если отключить суммаризацию, то все станет на свои места.
172.31.0.0/24 is subnetted, 1 subnets
D 172.31.255.0 [90/409600] via 13.0.0.1, 00:00:10, FastEthernet0/0
12.0.0.0/25 is subnetted, 2 subnets
D 12.0.0.0 [90/307200] via 13.0.0.1, 00:00:10, FastEthernet0/0
D 12.0.0.128 [90/307200] via 13.0.0.1, 00:00:10, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C 13.0.0.0 is directly connected, FastEthernet0/0
Появляются маршруты во все подсети. Без дальнейшего анализа понятно, что если объявлять любую сеть без указания маски, то трактоваться она будет по классу. Неважно, объявите вы network 12.0.0.0 или 12.0.0.128 или даже 12.0.0.129. Процесс будет запущен на всех интерфейсах, принадлежащих сети 12.0.0.0 по классу А. А объявления будут зависеть от состояния auto-summary. Если же вы укажете маску, то процесс будет запущен на всех интерфейсах, попадающих под эту маску, а сети так же будут объявляться в зависимости от auto-summary. Запуск команды network 12.0.0.129 0.0.0.0 приведет к тому, что EIGRP будет запущен только на указанном интерфейсе. При включенной суммаризации анонсироваться будет классовый вариант сети 12.0.0.0/8. Если суммаризация отключена, то только подсеть, куда входит интерфейс 12.0.0.129.
Как видим, поведение EIGRP и его запуск вполне предсказуемы. Если нужно запустить сразу на всех интерфейсах, значит используем network 0.0.0.0 или network 0.0.0.0 255.255.255.255. Сразу объявляем и все сети, но в зависимости от auto-summary.
Нужно запустить только на определенных интерфейсах, значит, объявляем диапазон классовой сетью или указанием маски или просто адрес без маски, который все равно будет трактован, как классовая сеть. EIGRP стартует на всех интерфейсах, попавших в диапазон или класс, а объявляет сети так, как они назначены на интерфейсах при отключенном суммировании или классовые при включенном.
Запуск на определенном интерфейсе выполняется с указанием сети и маски или даже явным указанием адреса интерфейса с хостовой маской. Объявления опять же зависят от автосуммаризации. Но при явном указании адреса интерфейса все равно анонсирует либо классовый маршрут, либо маршрут в подсеть, которой принадлежит данный интерфейс, но никак не маршрут к узлу.
В большинстве случаев стоит отключать автоматическую суммаризацию, если она уже не отключена, проверяйте, зависит от версии IOS.
Если желательно объявлять сети в зависимости от потребностей, то наиболее красивый вариант с объявлением подсетей с масками, непосредственно подключенными к интерфейсам. Более быстрый вариант объявление классами или надсетями. При этом вполне можно применять технику указания пассивных интерфейсов. Ну а суммаризацию стоит делать вручную. Благо в отличие от OSPF здесь ее можно выполнять на любом маршрутизаторе. Кстати, а почему в OSPF суммаризацию можно выполнять только на ABR? Попробуйте ответить себе на этот вопрос.
Углубить свои знания по теме можно на курсе Cisco ROUTE v2.0 http://edu.eureca.ru/study/course/cisco/route_v2.0/
Олег Годунов, инструктор УЦ Эврика