Динамическая маршрутизация. Протоколы и работа.
Содержание:
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Есть уйма материала по настройке OSPF, но для понимания сути вопроса нужно осознавать принципы работы этого протокола. Самое пожалуй смешное, что можно просто взять в руки мануалы и настроить этот протокол динамической маршрутизации, и нафиг вам не нужно понимание алгоритмов SPF или что это за LSA такое. И оно заработает. Отлично заработает, ведь на то и расчитано - на простоту. Забудьте чехарду с вланами, здесь всё проще.
Но сетевого инженера от распоследнего эникея отличает доскональное знание принципов работы своей сети, и умение не хуже того же OSPF'а построить лучший маршрут до подсети. И что характерно, его выбор совпадет с выбором этого протокола.
Здесь мы рассмотрим именно принципиальные моменты работы протокола, чтобы потом нам с вами было приятнее с ним сосуществовать. Еще можно покурить отличную статью об OSPF на xgu.ru
В общем, знакомьтесь, OSPFv2, работающий поверх IP - заточен строго под IPv4. Существует также независимый от протоколов третьего уровня OSPFv3, способный работать в среде IPv6.
Давайте рассмотрим его работу. Для примера представим такую сеть:
Для начала маршрутизаторам нужно поладить друг с другом, а для этого должны быть соблюдены некие условия. Какие? Перечислим.
1. В OSPF на подключенных к друг другу маршрутизаторах должны быть настроены одинаковые параметры Hello Interval. По дефолту в широковещательных сетях (Broadcast) типа Ethernet этот параметр равен 10 секундам. Можно сказать, что это некие KeepAlive-сообщения, которые каждые 10 секунд маршрутизаторы отправляют своим соседям, говоря как бы Hello, "Я жив!"
2. И Dead Interval также должен быть одинаковым. Обычно он составляет 4 Hello-периода, то есть 40 секунд. Если от соседа нет вестей то роутер начинаеткипиш перестроение своей локальной базы и оповещение соседей.
3. Будем кэпами, но интерфейсы, напрямую подключенные друг к другу должны находиться в одной подсети.
4. Можно дополнительно снизить нагрузку на CPU маршрутизаторов в пределах одной автономной системы, разбив её на зоны. Логично, что для налаживания отношений между маршрутизаторами номера зон должны совпадать.
5. У каждого маршрутизатора, принимающего участие в шабаше OSPF имеется свой уникальный идентификатор, именуемый Router ID. Можно на это забить и не задавать его самому, но тогда маршрутизатор выберет его самостоятельно, основывая на информации о подключенных к нему интерфейсов. По-умолчанию, выбирается высший адрес из интерфейсов, активных на момент запуска процесса OSPF. Но мы же хорошие инженеры? Мы создадим Loopback интерфейс, которому будет присвоен адрес с маской /32, который и будет назначен в качестве Router ID. С улыбкой и добротой вы вспомните об этом, когда придется что-то дебажить и/или обслуживать.
6. Размер MTU также должен совпадать.
Теперь начинается пьеса в восьми действиях и без антрактов.
•1• Пока всё тихо. Состояние OSPF — DOWN. Это первичное очень короткое состояние.
•2• Начинает дуть легкий бриз - маршрутизатор шлет Hello-пакеты на мульткастный адрес 224.0.0.5 со всех своих доступных интерфейсов, где поднят OSPF. У этих сообщений очень короткий срок жизни TTL=1, поэтому получить его способен только сосед-маршрутизатор из того же сегмента сети. Маршрутизатор R1 переходит в состояние INIT.
В приветственном пакете присутствует следующая информация:
-> Router ID
-> Hello Interval
-> Dead Interval
-> Neighbors
-> Subnet mask
-> Area ID
-> Router Priority
-> Адреса DR и BDR маршрутизаторов
-> Пароль аутентификации
Интересовать нас пока что будут только первые четыре параметра, а в данный конкретный момент только Router ID и Neighbors.
Hello-сообщение от R1 имеет на борту его Router ID, но вот Neighbors там пока нет, ведь он Чебурашка, который ищет друзей. И вот на R2 прилетает это мультикастное сообщение, после чего он добавляет R1 в свою таблицу соседей. При условии совпадения всех требуемых параметров, конечно.
И теперь R2 отправляет на R1 уже непосредственно юникастом свое Hello-сообщение, где имеется его Router ID и в списке Neigbors перечислены знакомые ему соседи. И в списке таким же соседом уже является Router ID R1.
•3• Мир, дружба, жвачка. R1 получает Hello-пакет от R2, читает его и видит свой собственный Router ID в списке соседей R2. Радуется и добавляет R2 в свой собственный список Neigbors.
Теперь между R1 и R2 взаимное соседство, ведь они друг у друга в списках. Они становятся друг к другу в отношениях смежности, и R1 переходит в состояние TWO WAY.
В этом месте происходит еще одно важное событие - выбор DR и BDR. Но давайте пока пропустим этот момент, чтобы не терять нить.
•4• И снова наступает временное затишье, маршрутизаторы переходят в состояние EXSTART. Тут происходит "обсуждение", кто среди соседей самый главный. Главным в итоге становится маршрутизатор с наибольшим Router ID — в нашем случае это R2.
•5• Главный выбран и все соседи переходят в состояние Exchange, обмениваясь DBD-сообщениями (или можно просто DD, Data Base Description), в которых содержится описание LSDB (Link State Data Base), типа "эй, я знаю про вот эти подсети!"
Давайте уж сразу затронем LSDB - это база данных о состоянии линков, если переводить совсем дословно. Первоначально маршрутизатор знает только о тех линках (читай, интерфейсах), на которых поднят OSPF. Маршрутизатор сгребает информацию о сети, собирая её топологию. Это и будет LSDB, которая должна быть одинакова у всех маршрутизаторов в зоне.
Первым свою DBD отошлет главный маршрутизатор, у нас это 2.2.2.2, а после него - 1.1.1.1.
•6• По факту получения сообщения маршрутизаторы R1 и R2 отправят подтверждение о получении DBD (называется оно LSAck), а далее сравнивают эту информацию с уже хранящейся в их LSDB. В случае нахождения различий они пошлют LSR (Link State Request) друг другу, переходя на этом этапе в состояние LOADING. В своих LSR они попросят "рассказать" подробнее о сетях, которые им еще неизвестны.
•7• R2 получает LSR от R1 и высылает LSU (Link State Update), содержащий в себе т.н. LSA (Link State Advertisement) с уже подробной информацией о запрашиваемых сетях.
И вот R1 получает недостающие данные о нужных подсетях. Теперь он формирует свою LSDB, входя в финальное состояние FULL STATE.
На момент входя всех роутеров в состояние FULL STATE они все должны будут иметь одинаковую LSDB, ведь занимались изучением одной и той же сети. В общем теперь маршрутизатор знаком со всей вашей сетью, что и куда подключено.
•8• Класс, маршрутизаторы знают всё о сети... Но это не поможет процессу маршрутизации.
Теперь OSPF, используя алгоритм Дейкстры (также называемый SPF — Shortest Path First), вычислит кратчайшие маршруты до каждого из роутеров в зоне, ведь вся её топология теперь известна. Помогут в этом метрики. Чем она ниже, тем маршрут будет лучше.
Метрика — это стоимость движения по маршруту.
Вот перед нами конкретный пример. В данной сети с R1 на R3 можно попасть напрямую или через R3. Понятное дело, что при условии одинаковых соединяющих их интерфейсов проще и быстрее сделать это напрямую. Но в случае, если между R1 и R3 адский dial-up в бешеных 56kbit, то фактическая стоимость маршрута окажется выше, и более длинный маршрут окажется быстрее и приоритетнее.
Итоговый путь будет добавлен в таблицу маршрутизации.
Теперь каждые 10 секунд маршрутизаторы будут сыпать Hello-пакетами, а раз в 30 минут - LSA, мол данные уже устарели, может обновим?
Вот так в шарообразной сети в вакууме наступило равновесие. Но сетевой инженер и суровая реальность не дадут наступить идиллии, сеть постоянно меняется, растет, расширяется, оптика рвётся узбеками на экскаваторах, мыши грызут слаботочку, а уборщица баба Дуся освобождает место в розетке для чайника. Короче говоря, постоянно меняется топология сети. И чем эта сеть больше, тем глобальнее изменения.
Конечно, будет очень странно выжидать 40-секундный Dead Interval и только потом начинать перестройку маршрутных таблиц, верно? Мы бы простили это старичку-протоколу RIP, но не актуальному алгоритму. Итак, когда падает какой-то линк (или даже несколько), маршрутизатор сразу перестраивает свою LSDB и судорожно генерирует LSU, присваивая ей номер больше, чем он был прежде (у каждой LSDB есть номер, который берётся из последнего полученного LSA).
Далее это LSU сообщение рассылается на мультикастовый адрес 224.0.0.5 и получившие его маршрутизаторы проверяют номер LSA, которые содержатся в LSU. Далее возможны следующие действия:
1. Если номер больше, чем номер текущей LSA маршрутизатора — LSDB меняется. (Версия LSDB старая, информация новая);
2. Если номер такой же, ничего не происходит. Этот маршрутизатор уже получил данный LSA по какому-то другому пути;
3 Если номер полученного LSA меньше локальной LSDB, это означает, что у маршрутизатора уже более актуальная информация, и он посылает новый LSA (на основе своей LSDB) отправителю прежнего.
После произведенных действий и внесения/отклонения изменений соседу источнику LSU отсылается LSAck (подтверждение получения ЛСУшки), соседям же отправляется изначальный LSU-пакет, без каких-либо изменений. На целевом маршрутизаторе вновь запускается SPF, а также в случае необходимости обновляется таблица маршрутизации.
Все эти действия ради поддержания актуальности информации, ведь LSDB должна быть у всех одинаковой.
Думаю, вы заметили, что все сообщения имеют подтверждения - LSAck или ответ Hello на другое Hello. OSPF ведь работает не в TCP, а убеждаться в доставке пакета как-то надо.
Ну что ж, перейдем к практике.
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Протокол OSPF
Есть уйма материала по настройке OSPF, но для понимания сути вопроса нужно осознавать принципы работы этого протокола. Самое пожалуй смешное, что можно просто взять в руки мануалы и настроить этот протокол динамической маршрутизации, и нафиг вам не нужно понимание алгоритмов SPF или что это за LSA такое. И оно заработает. Отлично заработает, ведь на то и расчитано - на простоту. Забудьте чехарду с вланами, здесь всё проще.
Но сетевого инженера от распоследнего эникея отличает доскональное знание принципов работы своей сети, и умение не хуже того же OSPF'а построить лучший маршрут до подсети. И что характерно, его выбор совпадет с выбором этого протокола.
Здесь мы рассмотрим именно принципиальные моменты работы протокола, чтобы потом нам с вами было приятнее с ним сосуществовать. Еще можно покурить отличную статью об OSPF на xgu.ru
В общем, знакомьтесь, OSPFv2, работающий поверх IP - заточен строго под IPv4. Существует также независимый от протоколов третьего уровня OSPFv3, способный работать в среде IPv6.
Давайте рассмотрим его работу. Для примера представим такую сеть:
Для начала маршрутизаторам нужно поладить друг с другом, а для этого должны быть соблюдены некие условия. Какие? Перечислим.
1. В OSPF на подключенных к друг другу маршрутизаторах должны быть настроены одинаковые параметры Hello Interval. По дефолту в широковещательных сетях (Broadcast) типа Ethernet этот параметр равен 10 секундам. Можно сказать, что это некие KeepAlive-сообщения, которые каждые 10 секунд маршрутизаторы отправляют своим соседям, говоря как бы Hello, "Я жив!"
2. И Dead Interval также должен быть одинаковым. Обычно он составляет 4 Hello-периода, то есть 40 секунд. Если от соседа нет вестей то роутер начинает
3. Будем кэпами, но интерфейсы, напрямую подключенные друг к другу должны находиться в одной подсети.
4. Можно дополнительно снизить нагрузку на CPU маршрутизаторов в пределах одной автономной системы, разбив её на зоны. Логично, что для налаживания отношений между маршрутизаторами номера зон должны совпадать.
5. У каждого маршрутизатора, принимающего участие в шабаше OSPF имеется свой уникальный идентификатор, именуемый Router ID. Можно на это забить и не задавать его самому, но тогда маршрутизатор выберет его самостоятельно, основывая на информации о подключенных к нему интерфейсов. По-умолчанию, выбирается высший адрес из интерфейсов, активных на момент запуска процесса OSPF. Но мы же хорошие инженеры? Мы создадим Loopback интерфейс, которому будет присвоен адрес с маской /32, который и будет назначен в качестве Router ID. С улыбкой и добротой вы вспомните об этом, когда придется что-то дебажить и/или обслуживать.
6. Размер MTU также должен совпадать.
Теперь начинается пьеса в восьми действиях и без антрактов.
•1• Пока всё тихо. Состояние OSPF — DOWN. Это первичное очень короткое состояние.
•2• Начинает дуть легкий бриз - маршрутизатор шлет Hello-пакеты на мульткастный адрес 224.0.0.5 со всех своих доступных интерфейсов, где поднят OSPF. У этих сообщений очень короткий срок жизни TTL=1, поэтому получить его способен только сосед-маршрутизатор из того же сегмента сети. Маршрутизатор R1 переходит в состояние INIT.
В приветственном пакете присутствует следующая информация:
-> Router ID
-> Hello Interval
-> Dead Interval
-> Neighbors
-> Subnet mask
-> Area ID
-> Router Priority
-> Адреса DR и BDR маршрутизаторов
-> Пароль аутентификации
Интересовать нас пока что будут только первые четыре параметра, а в данный конкретный момент только Router ID и Neighbors.
Hello-сообщение от R1 имеет на борту его Router ID, но вот Neighbors там пока нет, ведь он Чебурашка, который ищет друзей. И вот на R2 прилетает это мультикастное сообщение, после чего он добавляет R1 в свою таблицу соседей. При условии совпадения всех требуемых параметров, конечно.
И теперь R2 отправляет на R1 уже непосредственно юникастом свое Hello-сообщение, где имеется его Router ID и в списке Neigbors перечислены знакомые ему соседи. И в списке таким же соседом уже является Router ID R1.
•3• Мир, дружба, жвачка. R1 получает Hello-пакет от R2, читает его и видит свой собственный Router ID в списке соседей R2. Радуется и добавляет R2 в свой собственный список Neigbors.
Теперь между R1 и R2 взаимное соседство, ведь они друг у друга в списках. Они становятся друг к другу в отношениях смежности, и R1 переходит в состояние TWO WAY.
В этом месте происходит еще одно важное событие - выбор DR и BDR. Но давайте пока пропустим этот момент, чтобы не терять нить.
•4• И снова наступает временное затишье, маршрутизаторы переходят в состояние EXSTART. Тут происходит "обсуждение", кто среди соседей самый главный. Главным в итоге становится маршрутизатор с наибольшим Router ID — в нашем случае это R2.
•5• Главный выбран и все соседи переходят в состояние Exchange, обмениваясь DBD-сообщениями (или можно просто DD, Data Base Description), в которых содержится описание LSDB (Link State Data Base), типа "эй, я знаю про вот эти подсети!"
Давайте уж сразу затронем LSDB - это база данных о состоянии линков, если переводить совсем дословно. Первоначально маршрутизатор знает только о тех линках (читай, интерфейсах), на которых поднят OSPF. Маршрутизатор сгребает информацию о сети, собирая её топологию. Это и будет LSDB, которая должна быть одинакова у всех маршрутизаторов в зоне.
Первым свою DBD отошлет главный маршрутизатор, у нас это 2.2.2.2, а после него - 1.1.1.1.
•6• По факту получения сообщения маршрутизаторы R1 и R2 отправят подтверждение о получении DBD (называется оно LSAck), а далее сравнивают эту информацию с уже хранящейся в их LSDB. В случае нахождения различий они пошлют LSR (Link State Request) друг другу, переходя на этом этапе в состояние LOADING. В своих LSR они попросят "рассказать" подробнее о сетях, которые им еще неизвестны.
•7• R2 получает LSR от R1 и высылает LSU (Link State Update), содержащий в себе т.н. LSA (Link State Advertisement) с уже подробной информацией о запрашиваемых сетях.
И вот R1 получает недостающие данные о нужных подсетях. Теперь он формирует свою LSDB, входя в финальное состояние FULL STATE.
На момент входя всех роутеров в состояние FULL STATE они все должны будут иметь одинаковую LSDB, ведь занимались изучением одной и той же сети. В общем теперь маршрутизатор знаком со всей вашей сетью, что и куда подключено.
Цитата: Пара слов извинений
Да, запомнить весь этот вал аббревиатур и определений сразу едва ли удастся. Но постепенно,
повторив это не один раз вы запомните.
повторив это не один раз вы запомните.
•8• Класс, маршрутизаторы знают всё о сети... Но это не поможет процессу маршрутизации.
Теперь OSPF, используя алгоритм Дейкстры (также называемый SPF — Shortest Path First), вычислит кратчайшие маршруты до каждого из роутеров в зоне, ведь вся её топология теперь известна. Помогут в этом метрики. Чем она ниже, тем маршрут будет лучше.
Метрика — это стоимость движения по маршруту.
Вот перед нами конкретный пример. В данной сети с R1 на R3 можно попасть напрямую или через R3. Понятное дело, что при условии одинаковых соединяющих их интерфейсов проще и быстрее сделать это напрямую. Но в случае, если между R1 и R3 адский dial-up в бешеных 56kbit, то фактическая стоимость маршрута окажется выше, и более длинный маршрут окажется быстрее и приоритетнее.
Итоговый путь будет добавлен в таблицу маршрутизации.
Теперь каждые 10 секунд маршрутизаторы будут сыпать Hello-пакетами, а раз в 30 минут - LSA, мол данные уже устарели, может обновим?
Вот так в шарообразной сети в вакууме наступило равновесие. Но сетевой инженер и суровая реальность не дадут наступить идиллии, сеть постоянно меняется, растет, расширяется, оптика рвётся узбеками на экскаваторах, мыши грызут слаботочку, а уборщица баба Дуся освобождает место в розетке для чайника. Короче говоря, постоянно меняется топология сети. И чем эта сеть больше, тем глобальнее изменения.
Конечно, будет очень странно выжидать 40-секундный Dead Interval и только потом начинать перестройку маршрутных таблиц, верно? Мы бы простили это старичку-протоколу RIP, но не актуальному алгоритму. Итак, когда падает какой-то линк (или даже несколько), маршрутизатор сразу перестраивает свою LSDB и судорожно генерирует LSU, присваивая ей номер больше, чем он был прежде (у каждой LSDB есть номер, который берётся из последнего полученного LSA).
Далее это LSU сообщение рассылается на мультикастовый адрес 224.0.0.5 и получившие его маршрутизаторы проверяют номер LSA, которые содержатся в LSU. Далее возможны следующие действия:
1. Если номер больше, чем номер текущей LSA маршрутизатора — LSDB меняется. (Версия LSDB старая, информация новая);
2. Если номер такой же, ничего не происходит. Этот маршрутизатор уже получил данный LSA по какому-то другому пути;
3 Если номер полученного LSA меньше локальной LSDB, это означает, что у маршрутизатора уже более актуальная информация, и он посылает новый LSA (на основе своей LSDB) отправителю прежнего.
После произведенных действий и внесения/отклонения изменений соседу источнику LSU отсылается LSAck (подтверждение получения ЛСУшки), соседям же отправляется изначальный LSU-пакет, без каких-либо изменений. На целевом маршрутизаторе вновь запускается SPF, а также в случае необходимости обновляется таблица маршрутизации.
Все эти действия ради поддержания актуальности информации, ведь LSDB должна быть у всех одинаковой.
Цитата: Важное замечание
Маршрутизатор заметит, если линк упал физически. То есть в случае наличия между роутерами свича, падение линка не будет замечено одним из них. Но из этой ситуации есть выход.
1) Самое очевидно настроить таймеры. Тогда OSPF будет производить опросы чаще. Интервал можно уменьшать вплоть до миллисекунд.
2) Использовать протокол BFD, Bidirectional Forwarding Detection, позволяющий отслеживать состояние линков также с минимальными задержками. Связываем данный протокол с другими, и он будет передавать им актуальную информацию о проблемах с линками. Попозже поговорим о нем.
1) Самое очевидно настроить таймеры. Тогда OSPF будет производить опросы чаще. Интервал можно уменьшать вплоть до миллисекунд.
2) Использовать протокол BFD, Bidirectional Forwarding Detection, позволяющий отслеживать состояние линков также с минимальными задержками. Связываем данный протокол с другими, и он будет передавать им актуальную информацию о проблемах с линками. Попозже поговорим о нем.
Думаю, вы заметили, что все сообщения имеют подтверждения - LSAck или ответ Hello на другое Hello. OSPF ведь работает не в TCP, а убеждаться в доставке пакета как-то надо.
Цитата: На заметку
Всего есть аж семь типов LSA, завязанных на зоны (зон, кстати, пять типов). И маршрутизаторов еще в довесок четыре типа. Не забывайте также про Designated Router (DR) и Backup DR (BDR), ABR и ASBR, формулу расчета метрик и всякое другое. Теорию всего этого можно покопать отдельно.
Ну что ж, перейдем к практике.
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
