Динамическая маршрутизация. Протоколы и работа.
Содержание:
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
В процессе составления этого поста... Блин его же и постом назвать нельзя. В общем, в процессе компилирования этих статей в новость я подумал, что решение разбить их на части было офигенно правильным - в противном случае можно было бы лицезреть портянку просто невообразимых масштабов. А тут она еще и разбита логично.
Помните сложности с настройкой статической маршрутизации? Поди пропиши на каждом роутере маршруты до всех сетей, а если что забудешь, то потом пойди найди где и что... Забудьте, это всё каменный век, к нам на огонек зашел IGP.
Можно было бы сейчас начать разжевывать синтаксис команд, пояснять значение каждой, но мы не из таких - мы сразу кинемся на амбразуры.
Представим вот такую схему:
Пока обратим наше внимание на кольцо из трех маршрутизаторов, расположенных в Красноярске, Хабаровске и Владивостоке. Мы запускаем здесь и на уже активной сети OSPF, в связи с чем нужно выпиливать статические маршруты и переходить на динамику. Допустим, линк до Красноярска нам предоставил уже сотрудничающий с нами провайдер «Балаган телеком», а остальные города подключены через других провов, и в итоге кольцо замыкается на Москве через провайдера «Филькин сертификат». Везде между нашими роутерами поднят купленый L2-VPN, и трафик между ними ходит абсолютно прозрачно.
Что хорошего мы получим от внедрения в нашу сеть протоколов IGP? Давайте подумаем.
1. Это подарит нам простоту конфигурации. На каждом узле нужно будет знать только о локальных сетях, а уже распространять информацию о них будет OSPF.
2. Активные избыточные линки, которые обеспечат нам резервирование каналов связи. То есть перекопанная экскаватором оптика между Москвой и Красноярском не отразится на работоспособности сети - весь трафик просто пойдет через Владивосток.
3. Проблемы будут обнаруживаться в автоматическом режиме, в соответствии с чем будет перестраиваться топология и вноситься изменения в таблицы маршрутизации. Это обеспечит выполнение второго пункта.
4. Отсутствует опасность собрать петлю маршрутизации, пакеты не будут в панике метаться по маршрутам, пока не истечет их TTL. В рамках статической маршрутизации такая опасность всегда существует.
5. Простота и удобство расширения. Допустим, решили мы открыть еще один филиал, например, в Томске, а подключать его будем от Кемерово. В обычном виде пришлось бы прописывать статические маршруты в Москве, Кемрово и в самом Томске. Пользуясь технологиями динамической маршрутизации потребуется настроить только новый роутер. И всё!
В оригинальной статье Linkmeup уже подготовлен IP-план подсетей и линков Point-to-Point. Начальные настройки тоже на всех узлах выполнены:
> hostname;
> параметры безопасности (пароли на телнет, ssh);
> IP-адреса линковых интерфейсов;
> IP адреса подсетей LAN;
> IP-адреса Loopback-интерфейсов.
Тем временем все наши маршрутизаторы готовы к настройке. Приступим.
1. Для начала нужно запустить на маршрутизаторе сам процесс OSPF.
Здесь мы говорим, что запускаем протокол динамической маршрутизации, указываем его тип и номер процесса (чисто в теории их может быть поднято несколько).
Автоматом назначается Router ID, равный по-умолчанию наибольшему адресу Loopback-интерфейсов.
2. Но вот так отдавать решение о назначении Router ID маршрутизаторам нельзя. Как минимум он должен быть уникальным. Не, можно и одинаковых наклепать, но тогда готовьтесь к странностям.
В общем настраивать его можно как угодно, можно и правда оставить это на откуп маршрутизатору, но все таки порядка ради сделаем это лично. В будущем избежим возможных неприятностей. Да и обслуживать будет проще. Назначим мы его в соответствии с адресом Loopback-интерфейса:
3. Теперь давайте объявим, какие сети будут анонсироваться нашим соседям. Да, обратите внимание, что в этой команде используется wildcard-маска (обратная), прямо как в ACL:
Давайте остановимся на этом моменте поподробнее. Итак, командой network мы задаем не сеть, которую будет вещать наш маршрутизатор, а интерфейсы участвующие в процессе.
В итоге все интерфейсы маршрутизатора, чьи интерфейсы попадают в настроенный нами диапазон 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, ведь на нем висит IP 198.51.100.2, который не входит в указанный диапазон.
Также при такой настройке любой новый интерфейс с адресом из диапазона 172.16.0.0 — 172.16.255.255 автоматически станет участником процесса OSPF. Может оказаться, что вам это не было нужно... Но тут все зависит от вашего желания и настройки.
area 0 означает, что данные подсети принадлежат к соответствующей зоне под номером ноль (в нашем примере будет именно она).
Задав команду network с заданных нами интерфейсов сразу слетают приветственные Hello-пакеты. Вот только ответить на них пока некому - соседей то у нас нет:
Теперь давайте настроим OSPF на Кемеровском маршрутизаторе. Router ID будет IP-адресом Loopback интерфейса, взятый из IP-плана:
В консоли сразу появится лог-сообщение вида:
На роутере в Москве также всплывет:
Здесь видно, что отношения смежности настроены и успешно произведен обмен LSA пакетами. Каждый маршрутизатор в итоге построил свою LSDB.
Так выглядит подробная информация по соседству:
Здесь содержится вся ключевая информация о состоянии соседа:
> Router-id (172.16.255.48), который по сути является адресом loopback, интерфейса удаленной стороны, через который установлено соседство - 172.16.2.18;
> Тип и номер физического интерфейса (или сабинтерфейса). В нашему случае FastEthernet0/1.5;
> Текущий статус, опять же у нас это FULL;
> И напоследочек Dead timer, который, если за ним последить, не доходит до нуля. Его значение уменьшается, а потом снова возвращается к 40 секундам. Почему? Просто каждые 10 секунд маршрутизатор получает Hello-пакеты, обнуляя свой Dead-счетчик.
Теперь давайте скажем маршрутизатору show ip route и поглядим на изменения в таблице маршрутизации:
Помимо уже известных роутеру сетей (они здесь C — directly connected и S — Static) мы можем наблюдать два новых маршрута с буквой O (очевидно, OSPF). И как бы по идее всё понятно и замечательно, но если приглядеться, то почему в сеть 172.16.24.0 у нас два маршрута? Выше же мы говорили, что приоритет за статическим маршрутом, так почему в таблице присутствует не только он? Ваша правда. По идее в таблице маршрутизации должен быть только единственный и самый приоритетный маршрут до сети. Но приглядитесь получше - статический маршрут идет до подсети 172.16.24.0/22, а полученный через OSPF до 172.16.24.0/24. Это разные подсети, потому и оказались оба этих маршрута в таблице. OSPF же не знаю, чего вы там себе напридумывали, какой выделили диапазон - он оперирует реальными данными, IP-адресами и масками.
Смотрим теперь ситуацию на роутере в Кемерово:
Тут есть настроенный ручками маршрут по-умолчанию, но и высыпалась куча маршрутов до московских подсетей.
Обратите внимание на эти строчки:
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 на питерской железке.
Всё просто и прозрачно. Кстати, номер процесса OSPF на маршрутизаторах совсем не обязательно должен совпадать, но вам же будет проще, если они будут одинаковыми, чтобы потом не запутаться.
Смотрим ситуацию на msk-arbat-gw1, где у нас теперь два соседа:
А вот в Спб (и Кемерово само собой) только один:
Секрет прост. Отношения типа Neighbor, т.е. смежности, возникают только между непосредственно подключенными роутерами (при этом коммутаторы между ними в расчет не берутся), а вот spb-vsl-gw1 связан у нас с kmr-gorka-gw1 через msk-arbat-gw1, поэтому их нет друг у друга в соседях. Останется поднять OSPF на spb-ozerki-gw1, там всё также только Router ID надо присвоить другой.
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Практика OSPF
В процессе составления этого поста... Блин его же и постом назвать нельзя. В общем, в процессе компилирования этих статей в новость я подумал, что решение разбить их на части было офигенно правильным - в противном случае можно было бы лицезреть портянку просто невообразимых масштабов. А тут она еще и разбита логично.
Помните сложности с настройкой статической маршрутизации? Поди пропиши на каждом роутере маршруты до всех сетей, а если что забудешь, то потом пойди найди где и что... Забудьте, это всё каменный век, к нам на огонек зашел IGP.
Можно было бы сейчас начать разжевывать синтаксис команд, пояснять значение каждой, но мы не из таких - мы сразу кинемся на амбразуры.
Представим вот такую схему:
Пока обратим наше внимание на кольцо из трех маршрутизаторов, расположенных в Красноярске, Хабаровске и Владивостоке. Мы запускаем здесь и на уже активной сети OSPF, в связи с чем нужно выпиливать статические маршруты и переходить на динамику. Допустим, линк до Красноярска нам предоставил уже сотрудничающий с нами провайдер «Балаган телеком», а остальные города подключены через других провов, и в итоге кольцо замыкается на Москве через провайдера «Филькин сертификат». Везде между нашими роутерами поднят купленый L2-VPN, и трафик между ними ходит абсолютно прозрачно.
Что хорошего мы получим от внедрения в нашу сеть протоколов IGP? Давайте подумаем.
1. Это подарит нам простоту конфигурации. На каждом узле нужно будет знать только о локальных сетях, а уже распространять информацию о них будет OSPF.
2. Активные избыточные линки, которые обеспечат нам резервирование каналов связи. То есть перекопанная экскаватором оптика между Москвой и Красноярском не отразится на работоспособности сети - весь трафик просто пойдет через Владивосток.
3. Проблемы будут обнаруживаться в автоматическом режиме, в соответствии с чем будет перестраиваться топология и вноситься изменения в таблицы маршрутизации. Это обеспечит выполнение второго пункта.
4. Отсутствует опасность собрать петлю маршрутизации, пакеты не будут в панике метаться по маршрутам, пока не истечет их TTL. В рамках статической маршрутизации такая опасность всегда существует.
5. Простота и удобство расширения. Допустим, решили мы открыть еще один филиал, например, в Томске, а подключать его будем от Кемерово. В обычном виде пришлось бы прописывать статические маршруты в Москве, Кемрово и в самом Томске. Пользуясь технологиями динамической маршрутизации потребуется настроить только новый роутер. И всё!
В оригинальной статье Linkmeup уже подготовлен IP-план подсетей и линков Point-to-Point. Начальные настройки тоже на всех узлах выполнены:
> hostname;
> параметры безопасности (пароли на телнет, ssh);
> IP-адреса линковых интерфейсов;
> IP адреса подсетей LAN;
> IP-адреса Loopback-интерфейсов.
Цитата: Loopback-интерфейс
Сейчас мы с вами вводим в повествование понятие Loopback-интерфейса. Он будет сконфигурирован на каждом маршрутизаторе в нашей сети. Под данный интерфейс нами будет выделена специальная подсеть 172.16.255.0/24. Сейчас она нужна нам только ради OSPF, но в будущем при дальнейшем расширении она потребуется нам в протоколах BGP и MPLS.
Честно говоря, понятия не имел, что это такое и с чем их едят - эти лупбэк-интерфейсы. Если по существу, это виртуальный интерфейс, всегда находящийся в состоянии UP, независимо от состояния физических интерфейсов (разве что, если ему искусственно сказали shutdown). И вот какова одна из его ролей.
Допустим, у нас имеется сервер мониторинга Nagios (Zabbix, Cacti... нужное подчеркнуть), в который мы завели маршрутизатор R1, а для связи с ним использовали интерфейс FE0/0 с IP 10.1.0.1:
Круто, всё заработало и всё у нас замечательно, но вот порвался кабель:
И как бы всё круто, ведь у нас динамическая маршрутизация, связь до R1 не нарушена - он будет доступен через интерфейс FE0/1. А вот наш Nagios будет сыпать алертами и орать, что всё пропало. Линк же упал и IP 10.1.0.1 стал недоступен. Но всё меняется, если настроить на нашем сервере адрес Loopback-интерфейса, для него так или иначе конечный маршрутизатор всегда будет доступен благодаря все той же динамической маршрутизации.
В качестве маски для этого интерфейса обычно берут /32 (да-да, 11111111.11111111.11111111.1111111), т.к. всего один адрес. А больше нам и не надо.
Честно говоря, понятия не имел, что это такое и с чем их едят - эти лупбэк-интерфейсы. Если по существу, это виртуальный интерфейс, всегда находящийся в состоянии UP, независимо от состояния физических интерфейсов (разве что, если ему искусственно сказали shutdown). И вот какова одна из его ролей.
Допустим, у нас имеется сервер мониторинга Nagios (Zabbix, Cacti... нужное подчеркнуть), в который мы завели маршрутизатор R1, а для связи с ним использовали интерфейс FE0/0 с IP 10.1.0.1:
Круто, всё заработало и всё у нас замечательно, но вот порвался кабель:
И как бы всё круто, ведь у нас динамическая маршрутизация, связь до R1 не нарушена - он будет доступен через интерфейс FE0/1. А вот наш Nagios будет сыпать алертами и орать, что всё пропало. Линк же упал и IP 10.1.0.1 стал недоступен. Но всё меняется, если настроить на нашем сервере адрес Loopback-интерфейса, для него так или иначе конечный маршрутизатор всегда будет доступен благодаря все той же динамической маршрутизации.
В качестве маски для этого интерфейса обычно берут /32 (да-да, 11111111.11111111.11111111.1111111), т.к. всего один адрес. А больше нам и не надо.
Тем временем все наши маршрутизаторы готовы к настройке. Приступим.
1. Для начала нужно запустить на маршрутизаторе сам процесс OSPF.
msk-arbat-gw1(config)# router OSPF 1Здесь мы говорим, что запускаем протокол динамической маршрутизации, указываем его тип и номер процесса (чисто в теории их может быть поднято несколько).
Автоматом назначается Router ID, равный по-умолчанию наибольшему адресу Loopback-интерфейсов.
2. Но вот так отдавать решение о назначении Router ID маршрутизаторам нельзя. Как минимум он должен быть уникальным. Не, можно и одинаковых наклепать, но тогда готовьтесь к странностям.
Цитата: Минутка воспоминаний
На оборудовании заканчивались метки LDP, из целых 8000+ меток осталась только одна свободная. Новые VPN уже никакие не создавались и не работали. Ковырялись и обнаружили, что сам процесс OSPF генерирует и выпиливает тысячи записей в таблицах маршрутизации. Топология бесконечно перестраивается, и на это конечно выделяются все новые и новые LDP-метки, но при этом не освобождаются. А дело здесь как раз в случайно настроенных одинаковых Router ID.
В общем настраивать его можно как угодно, можно и правда оставить это на откуп маршрутизатору, но все таки порядка ради сделаем это лично. В будущем избежим возможных неприятностей. Да и обслуживать будет проще. Назначим мы его в соответствии с адресом Loopback-интерфейса:
msk-arbat-gw1(config-router)#router-id 172.16.255.13. Теперь давайте объявим, какие сети будут анонсироваться нашим соседям. Да, обратите внимание, что в этой команде используется wildcard-маска (обратная), прямо как в ACL:
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.255.255 area 0Давайте остановимся на этом моменте поподробнее. Итак, командой network мы задаем не сеть, которую будет вещать наш маршрутизатор, а интерфейсы участвующие в процессе.
В итоге все интерфейсы маршрутизатора, чьи интерфейсы попадают в настроенный нами диапазон 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, а те, что удовлетворяют данному диапазону:
Конкретно в нашем случае не имеет особого значения как мы произведем настройку. Так:
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.255.255 area 0Или вот так:
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.15.255 area 0А может быть вообще так:
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.255.255 area 0
msk-arbat-gw1(config-router)#network 172.16.1.0 0.0.255.255 area 0
msk-arbat-gw1(config-router)#network 172.16.2.0 0.0.255.255 area 0
.....
msk-arbat-gw1(config-router)#network 172.16.15.0 0.0.255.255 area 0В нашем случае все команды произведут одинаковый эффект.
Все локальные сети у нас входят в диапазон 172.16.0.0/16, поэтому нам будет проще и удобнее использовать самую общую запись. Само собой, там не окажется внешний интерфейс FastEthernet0/1.6, ведь на нем висит IP 198.51.100.2, который не входит в указанный диапазон.
Также при такой настройке любой новый интерфейс с адресом из диапазона 172.16.0.0 — 172.16.255.255 автоматически станет участником процесса OSPF. Может оказаться, что вам это не было нужно... Но тут все зависит от вашего желания и настройки.
area 0 означает, что данные подсети принадлежат к соответствующей зоне под номером ноль (в нашем примере будет именно она).
Цитата: Важное замечание
area 0 - это отнюдь не простая зона, а так называемая Backbone-area. Означает это, что она объединяет в себе все остальные зоны, т.е. пакет идущий из одной ненулевой зоны в другую ненулевую обязательно пройдет через area 0.
Задав команду network с заданных нами интерфейсов сразу слетают приветственные Hello-пакеты. Вот только ответить на них пока некому - соседей то у нас нет:
msk-arbat-gw1#show ip OSPF neighbor
msk-arbat-gw1#Теперь давайте настроим OSPF на Кемеровском маршрутизаторе. Router ID будет IP-адресом Loopback интерфейса, взятый из IP-плана:
kmr-gorka-gw1(config)#router OSPF 1
kmr-gorka-gw1(config-router)#router-id 172.16.255.48
kmr-gorka-gw1(config-router)#network 172.16.0.0 0.0.255.255 area 0В консоли сразу появится лог-сообщение вида:
02:27:33: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.1 on FastEthernet0/0.5 from LOADING to FULL, Loading DoneНа роутере в Москве также всплывет:
02:27:33: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.48 on FastEthernet0/1.5 from LOADING to FULL, Loading Done.Здесь видно, что отношения смежности настроены и успешно произведен обмен 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
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 у нас два маршрута? Выше же мы говорили, что приоритет за статическим маршрутом, так почему в таблице присутствует не только он? Ваша правда. По идее в таблице маршрутизации должен быть только единственный и самый приоритетный маршрут до сети. Но приглядитесь получше - статический маршрут идет до подсети 172.16.24.0/22, а полученный через OSPF до 172.16.24.0/24. Это разные подсети, потому и оказались оба этих маршрута в таблице. OSPF же не знаю, чего вы там себе напридумывали, какой выделили диапазон - он оперирует реальными данными, IP-адресами и масками.
interface FastEthernet0/0.2
ip address 172.16.24.1 255.255.255.0Смотрим теперь ситуацию на роутере в Кемерово:
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.
Все таки попробуем выпилить статически маршруты и проверим работоспособность:
msk-arbat-gw1#ping 172.16.24.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.24.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/15 msВсе работает. Круто, теперь запилим OSPF на питерской железке.
spb-vsl-gw1(config)#router OSPF 1
spb-vsl-gw1(config-router)#router-id 172.16.255.32
spb-vsl-gw1(config-router)#network 172.16.0.0 0.0.255.255 area 0Всё просто и прозрачно. Кстати, номер процесса OSPF на маршрутизаторах совсем не обязательно должен совпадать, но вам же будет проще, если они будут одинаковыми, чтобы потом не запутаться.
Смотрим ситуацию на msk-arbat-gw1, где у нас теперь два соседа:
msk-arbat-gw1#sh ip OSPF neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:39 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DROTHER 00:00:31 172.16.2.18 FastEthernet0/1.5А вот в Спб (и Кемерово само собой) только один:
spb-vsl-gw1#sh ip OSPF neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.255.1 1 FULL/DR 00:00:34 172.16.2.1 FastEthernet1/0.4Секрет прост. Отношения типа Neighbor, т.е. смежности, возникают только между непосредственно подключенными роутерами (при этом коммутаторы между ними в расчет не берутся), а вот spb-vsl-gw1 связан у нас с kmr-gorka-gw1 через msk-arbat-gw1, поэтому их нет друг у друга в соседях. Останется поднять OSPF на spb-ozerki-gw1, там всё также только Router ID надо присвоить другой.
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
