Практика OSPF
Last updated
Last updated
Помните, как мы мучились, настраивая маршрутизацию в прошлый раз: на каждом устройстве до каждой сети и не дай бог что-нибудь забыть. Теперь это в прошлом — да здравствуют IGP! Не будем терять время, объясняя отдельно команды, а сразу окунёмся в удивительный мир конфигурации. Такс, имеет место сейчас следующая логическая схема:
Пока нас интересует вот это большое Сибирское кольцо через Красноярск, Хабаровск и Владивосток. Здесь и на нашей уже построенной сети мы запустим OSPF. Там, где прежде была статика, нам придётся от неё отказаться и плавно перейти на динамические протоколы. Предположим, что Красноярск у нас так же подключен через «Балаган телеком», как и предыдущие точки, а далее через разных провайдеров нам организованы линки к другим городам. Кольцо замыкается в Москве через провайдера “Филькин сертификат”. Предположим, что везде между городами у нас куплен L2-VPN и IP-трафик ходит прозрачно.
Что внедрение IGP даст конкретно нашей сети? 1) Простоту конфигурации, разумеется. На каждом узле нужно знать только локальные сети, вопросом их распространения озадачится OSPF. 2) Избыточные линки, которые обеспечат нам резервирование каналов связи. Если, например, бомжи срежут оптику между Москвой и Красноярском, ни один филиал не останется без связи: весь трафик пойдёт через Владивосток
3) Автоматическое обнаружение проблем, перестроение топологии и изменение таблицы маршрутизации. Именно это обеспечивает возможность выполнения пункта 2. 4) Нет опасности создать петлю маршрутизации, когда пакет у нас будет метаться между двумя узлами, пока TTL не истечёт. При статической настройке такая ситуация более, чем возможна. 5) Удобство расширения. Представьте, что вам нужно добавить новый филиал, например в Томске и подключать его будете через Кемерово. Тогда статические маршруты вам придётся прописывать в Москве, Кемерово и в самом Томске. При использовании динамики вы настраиваете только новый маршрутизатор… и всё.
IP-план подсетей филиалов и линков Point-to-Point мы уже подготовили. Предположим, что и все начальные настройки тоже выполнили на всех узлах:
hostname
параметры безопасности (пароли на телнет, ssh)
IP-адреса линковых интерфейсов
IP адреса подсетей LAN
IP-адреса Loopback-интерфейсов.
Мы тут вводим новое понятие Loopback-интерфейса. Он будет сконфигурирован на каждом маршрутизаторе. Для этого выделена специальная подсеть 172.16.255.0/24. Нужно оно нам сейчас для OSPF, а в будущем может понадобиться для BGP, MPLS. Положа руку на сердце, сам долгое время не понимал значения этих интерфейсов. Вообще говоря, это виртуальный интерфейс, состояние которого всегда UP, независимо от состояния физических интерфейсов (если только на нём самом shutdown не выполнили). Попытаемся объяснить одну из его ролей: Вот, к примеру, есть у вас сервер мониторинга Nagios. В нём вы завели для наблюдения маршрутизатор R1 и для связи с ним использовали адрес интерфейса FE0/0 — 10.1.0.1.
На первый взгляд все прекрасно — всё работает. Но предположим теперь, что этот кабель порвали.
Благодаря динамической маршрутизации, связь до роутера А не нарушится, и он будет доступен через FE0/1. А в Nagios’е у вас будет авария, всё будет красное, повалятся смс и почта. При падении линка, IP-адрес этого интерфейса (10.1.0.1) становится недоступен. А вот если вы настроите в Nagios’е адрес Loopback-интерфейса, то тем или иным путём он всегда будет доступен, опять же благодаря динамической маршрутизации.
В качестве маски IP-адреса Loopback-интерфейса практически всегда выбирается /32, то есть 11111111.11111111.11111111.1111111 — один единственный адрес — а больше и не надо.
Поскольку все приготовления уже закончились, перед нами стоит очень простая задача: пройтись по всем маршрутизаторам и активировать процесс OSPF.
1) Первое, что нам нужно сделать — запустить процесс OSPF на маршрутизаторе:
Первым словом указываем, что запускаем протокол динамической маршрутизации, далее указываем какой именно и в последнюю очередь номер процесса (теоретически их может быть несколько на одном роутере).
Сразу после этого автоматически назначается router ID. По умолчанию это наибольший адрес Loopbaсk-интерфейсов.
2) Не оставляем это дело на самотёк. Главное правило: Router ID обязан быть уникальным. Нет, вы, конечно, можете их сделать и одинаковыми, но в этом случае у вас начнутся странности.
Одна из моих заявок была такой: на оборудовании заканчиваются метки LDP. Из 8 с гаком тысяч осталась только одна свободная. Никакие новые VPN не создавались и не работали. Разбирались, разбирались и в итоге увидели что процесс OSPF создаёт и удаляет тысячи записей в минуту в таблице маршрутизации. Топология постоянно перестраивается и на каждое такое перестроение выделяются новые метки LDP, после чего не освобождаются. А всё дело в случайно настроенных одинаковых Router ID.
Настраивать его можно, в принципе, как угодно, можно даже не настраивать, маршрутизатор назначит его сам, но для порядка мы это сделаем — в будущем обслуживать будет проще. Назначаем его в соответствии с адресом Loopback-интерфейса.
3) Теперь мы объявляем, какие сети мы будем анонсировать (передавать соседям OSPF). Обратите внимание, что в этой команде используется wildcard-маска, как в ACL
Тут остановимся подробно. Командой network мы задаём не ту сеть, что будет вещать наш маршрутизатор, мы определяем интерфейсы, участвующие в процессе. Все интерфейсы маршрутизатора, IP адреса которых попадают в настроенный диапазон 172.16.0.0 0.0.255.255 (172.16.0.0-172.16.255.255), включатся в процесс. Это означает следующее: а) с данных интерфейсов будут рассылаться Hello-сообщения, через них будут устанавливаться отношения соседства и отправляться обновления о топологии сети. б) OSPF изучает подсети данных интерфейсов и именно их будет анонсировать и следить за их состоянием. То есть не 172.16.0.0 0.0.255.255, как мы настроили, а те, что удовлетворяют этому диапазону
В нашем случае не имеет значения как мы настроим:
или
или
Все эти команды сработают одинаково в нашем случае. Поскольку у нас все локальные сети имеют адреса из сети 172.16.0.0/16, то мы будем использовать наиболее общую запись. При этом туда, разумеется, не попадёт внешний интерфейс в интернет FastEthernet0/1.6, потому что его адрес — 198.51.100.2 — не из этого диапазона. При такой настройке любой новый интерфейс, на котором вы укажете адрес из диапазона 172.16.0.0 — 172.16.255.255, автоматически становится участником процесса OSPF. Плохо это или хорошо, зависит от ваших желаний. area 0 означает принадлежность данных подсетей зоне с номером ноль (в наших примерах только такая и будет).
Area 0 это не простая зона — это так называемая Backbone-area. Это означает, что она объединяет все остальные зоны, т.е. пакет, идущий от любой ненулевой зоны в любую ненулевую, обязан проходить через area 0
Как только вы задали команду network с правильных интерфейсов слетают слова приветствия, но отвечать на них пока некому — соседей нет:
Теперь пропишем настройки OSPF в Кемерово (router ID=IP адрес Loopback интерфейса, взятый из IP-плана):
И сразу после этого вы видите в консоли сообщение
Такое же показывает и маршрутизатор в Москве:
Здесь вы можете видеть, что были успешно установлены отношения смежности и произошёл обмен LSA. Каждый маршрутизатор построил свою LSDB.
Подробная информация по соседу:
msk-arbat-gw1#sh ip OSPF neighbor detail Neighbor 172.16.255.48, interface address 172.16.2.18 In the area 0 via interface FastEthernet0/1.5 Neighbor priority is 1, State is FULL, 4 state changes DR is 172.16.2.17 BDR is 172.16.2.18 Options is 0x00 Dead timer due in 00:00:38 Neighbor is up for 00:02:51 Index 1/1, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec
Тут вся ключевая информация о состоянии соседа: Его router-id (172.16.255.48), который по сути loopback-интерфейс. Адрес интерфейса удалённой стороны, через который установлено соседство (172.16.2.18). Тип и номер физического интерфейса (FastEthernet0/1.5), текущий статус (FULL) и Dead timer. Последний не доходит до нуля, если вы за ним понаблюдаете. Его значение уменьшается, уменьшается, а потом Оп! и снова 40. Это потому что каждые 10 секунд маршрутизаторы получают сообщения Hello и обсороколяют/обнуляют Dead-интервал.
Командой show ip route мы можем посмотреть, как изменилась таблица маршрутизации:
msk-arbat-gw1#show ip route Codes: C — connected, S — static, I — IGRP, R — RIP, M — mobile, B — BGP D — EIGRP, EX — EIGRP external, O — OSPF, IA — OSPF inter area N1 — OSPF NSSA external type 1, N2 — OSPF NSSA external type 2 E1 — OSPF external type 1, E2 — OSPF external type 2, E — EGP i — IS-IS, L1 — IS-IS level-1, L2 — IS-IS level-2, ia — IS-IS inter area
— candidate default, U — per-user static route, o — ODR P — periodic downloaded static route
Gateway of last resort is 198.51.100.1 to network 0.0.0.0
172.16.0.0/16 is variably subnetted, 17 subnets, 5 masks C 172.16.0.0/24 is directly connected, FastEthernet0/0.3 C 172.16.1.0/24 is directly connected, FastEthernet0/0.2 C 172.16.2.0/30 is directly connected, FastEthernet0/1.4 S 172.16.2.4/30 [1/0] via 172.16.2.2 C 172.16.2.16/30 is directly connected, FastEthernet0/1.5 C 172.16.2.32/30 is directly connected, FastEthernet0/1.7 C 172.16.2.128/30 is directly connected, FastEthernet0/1.8 C 172.16.2.196/30 is directly connected, FastEthernet1/0.911 C 172.16.3.0/24 is directly connected, FastEthernet0/0.101 C 172.16.4.0/24 is directly connected, FastEthernet0/0.102 C 172.16.5.0/24 is directly connected, FastEthernet0/0.103 C 172.16.6.0/24 is directly connected, FastEthernet0/0.104 S 172.16.16.0/21 [1/0] via 172.16.2.2 S 172.16.24.0/22 [1/0] via 172.16.2.18 O 172.16.24.0/24 [110/2] via 172.16.2.18, 00:13:03, FastEthernet0/1.5 C 172.16.255.1/32 is directly connected, Loopback0 O 172.16.255.48/32 [110/2] via 172.16.2.18, 00:13:03, FastEthernet0/1.5 198.51.100.0/28 is subnetted, 1 subnets C 198.51.100.0 is directly connected, FastEthernet0/1.6 S* 0.0.0.0/0 [1/0] via 198.51.100.1
Кроме известных ранее сетей (C — directly connected и S — Static) у нас появились два новых маршрута с пометкой O (OSPF). Тут всё должно быть понятно, но наблюдательный читатель спросит: “почему в таблице маршрутизации присутствуют два маршрута в сеть 172.16.24.0. Почему не останется более предпочтительный статический?” и будет прав. Вообще говоря, в таблицу маршрутизации попадает только лучший маршрут до сети — по умолчанию один. Но обратите внимание, что статический Bidirectional Forwarding Detection маршрут идёт до подсети 172.16.24.0/22, а полученный от OSPF до 172.16.24.0/24. Это разные подсети, поэтому обеим нашлось место под солнцем. Дело в том, что OSPF понятия не имеет чего вы там напланировали и какой диапазон выделили — он оперирует реальными данными, то есть IP-адресом и маской:
Что у нас творится в Кемерово:
kmr-gorka-gw1#sh ip route
Gateway of last resort is 172.16.2.17 to network 0.0.0.0
172.16.0.0/16 is variably subnetted, 14 subnets, 3 masks O 172.16.0.0/24 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.1.0/24 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.2.0/30 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 C 172.16.2.16/30 is directly connected, FastEthernet0/0.5 O 172.16.2.32/30 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.2.128/30 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.2.196/30 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.3.0/24 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.4.0/24 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.5.0/24 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 O 172.16.6.0/24 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 C 172.16.24.0/24 is directly connected, FastEthernet0/0.2 O 172.16.255.1/32 [110/2] via 172.16.2.17, 00:32:42, FastEthernet0/0.5 C 172.16.255.48/32 is directly connected, Loopback0 S* 0.0.0.0/0 [1/0] via 172.16.2.17
Как видим, помимо настроенного прежде маршрута по умолчанию, тут появились все подсети из Москвы. Обратите внимание на цифры в квадратных скобках:
S 0.0.0.0/0 [1/0] O 172.16.6.0/24 [*110/2]
Первая цифра — это административная дистанция, которая у OSPF значительно больше, чем у статики и, соответственно, приоритет ниже.
На самом деле до подсети 172.16.24.0/24 трафик уже пошёл по маршруту предоставленному OSPF, потому что у него более узкая маска (24 против 22). Но попробуем удалить статические маршруты и посмотрим, что получится.
Совершенно предсказуемо всё работает:
И это прекрасно. Настроим OSPF в Питере:
Настройки, как видите, везде предельно простые. При этом замечу, что номер процесса OSFP на разных маршрутизаторах не обязательно должен быть одинаковым, но лучше, если это будет так.
На msk-arbat-gw1 у нас теперь два соседа
А вот в Питере (и в Кемерово) один:
Дело в том, что отношения смежности устанавливаются только между непосредственно подключенными устройствами (коммутаторы между ними не считаются), а spb-vsl-gw1 коммуницирует с kmr-gorka-gw1 через msk-arbat-gw1, поэтому их нет в соседях друг у друга.
Последний оплот консерватизма — spb-ozerki-gw1 сдастся вам без особых проблем, как и три маршрутизатора Сибирского кольца. Делается всё по аналогии — по сути меняется только Router ID. И не забудьте удалить статические маршруты.
