Статическая и динамическая маршрутизация. Настройка статической маршрутизации

Описание из Вики: OSPF(англ. Open Shortest Path First) - протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology) и использующий для нахождения кратчайшего пути алгоритм Дейкстры.

Для чего нужен OSPF и как применять его на сетях, построенных на Mikrotik RouterOS, мы и рассмотрим в этой статье.

Описание работы протокола OSPF

Все, кто работал с сетями, имеющими более одной подсети (провайдеры, компании с филиалами, несколько vlan и т.д.) знают о необходимости существования маршрутов из одной сети в другую. Иначе пакеты в соединении будут просто улетать на шлюз по умолчанию и дропаться где-то в интернете.

Для тех же, кто с этим не знаком, поясню. Представьте, что мы внезапно захотели попасть из Челябинска в Киев, не имя при этом ни карты, ни навигатора. Поедем по указателям — не зря же их ставили.

Таким образом посмотрев на 10-20-100 укзателей мы рано или поздно доберемся до Киева — пакет от отправителя ушел к адресату. Сделали там все свои дела и захотели обратно домой в Челябинск — приложение обработало пакет и отправило ответ инициатору соединения. Но дорогу то мы не помним (в пакете нет никаких данных о прохождении пути. На самом деле есть намеки на это, но с помощью них нельзя восстановить путь пакета). Не беда — поедем по указателям.

Так же как и в первый раз мы каким-то образом вернемся в точку, из которой выехали. Причем, очень важно то, что вернуться мы можем по другим дорогам — на каких то начали укладывать асфальт за время нашего пребывания в Киеве и поставили знаки объезда, где-то просто затор и мы решили объехать по менее нагруженным трассам. Но мы все равно доберемся до места, пусть и затратив большее время.

Итак, мы, инкапсулированные в автомобиль — это данные, инкапсулированные в IP-пакет. Перекрестки на дороге — маршрутизаторы, подключенные к разным сетям (дорогам). А указатели на перекрестках — таблицы маршрутизации отдельных маршрутизаторов, знающие куда повернуть, чтобы попасть в ту или иную точку. И если в одну сторону мы доедем по указателям, а в другую указателей не будет, то пиши пропало — до исходной точки не доберемся. Значит, маршруты до общающихся сетей должны быть прописаны на обеих сторонах. И очень важно понимать, что дорог-маршрутов может быть несколько. И если один перекресток-маршрутизатор в ремонте, то предыдущий может послать нас в объезд, но сначала он должен узнать, что его сосед сломался. И если мы ездим по разным дорогам, значит и время пинга у нас будет разное.

Итак, с маршрутами разобрались. Теперь поговорим о дорожниках, ставящих указатели.

Статические указатели на дорогах — хорошо. Но расстояние между Челябинском и Киевом 2400 км. А значит и указателей должно быть не меньше 24 — по одному на каждые 100 км. И если на одном из перекрестков идет ремонт, необходимо внести изменения на два смежных указателя. А вероятность одновременного ремонта на 24 перекрестах весьма высока. То есть нужна отдельная бригада дорожников, меняющих указатели.

Было бы неплохо соединить все указатели в сеть и позволить им самим оценивать ситуацию на своих участках и передевать эти данные между собой. К сожалению великие и ужасные службы обслуживания дорог об этом ещё не додумались, да и вряд ли это надо — деньги то пилить не получится. А вот айтишники придумали технологии, позволяющие динамически изменять таблицы маршрутизации и обмениваться этой информацией. Эти технологии называются Протоколы Динамической Маршрутизации. И один из них — OSPF, предназначенный для обмена информацией внутри одной автономной системы — AS.

Настрока протокола OSPF на оборудовании Mikrotik

Термины и работа OSPF хорошо описаны в вики микротика. Но я осмелюсь кое-что повторить и перефразировать.
Допустим, есть следующая сеть:

Как видим, к сети 172.16.1.0 можно попасть двумя путями: через R2 и через связку R3+R4. Cost’ы, написанные возле каждого линка задают стоимость линка, своеобразный аналог параметра distance в ip-route. Чем ниже значение cost’а, тем выше вероятность того, что трафик пойдет по этому пути. Но как видно на следующем рисунке суммарная стоимость обоих маршрутов к сети 172.16.1.0 составляет 20. Так по какому же пути пойдет трафик?

В таком случае в таблице маршрутизации увидим примерно такую картину — к одной сети имеем два шлюза. И трафик должен пойти через оба шлюза. В этом случае мы можем управлять тем, куда пойдет трафик. Называется эта технология Policy Based Routing, но тема управления трафиком — это совсем другая история.

Сделать, чтобы OSPF “заработал” в Mikrotik RouterOS очень просто — нужно лишь добавить в backbone на каждом роутере в Routing — OSPF — Networks все ваши сети, между которыми вы хотите динамическую маршрутизацию и “оно заработает”.

Но мы ведь хотим управлять процессом. Тот, кто не хочет управлять дальше может не читать. Остальным — добро пожаловать!

Пример организации протокола OSPF

Рассматривать будем сеть, типичную для организации с несколькими филиалами. Имеем центральный офис (Headquarter на схеме, для краткости будем звать его ЦО) с сетью 192.168.0.0/24 (что я, кстати, не рекомендую при дефолтных настройках OSPF. Почему — скажу ниже). В ЦО расположены все основные элементы инфраструктуры — контроллер домена, сервер удаленного доступа, почтовый сервер и т.д. Все филиалы должны иметь доступ ко всем этим сервисам.

Несколько филиалов (Branche на схеме, для краткости — СП — Структурное Подразделение) с адресами 192.168.X.0/24. Между ЦО и каждым СП шифрованный туннель SSTP (или любой другой VPN) — адреса в туннелях из подсети 192.168.255.0/24 (192.168.255.10 — ЦО, 192.168.255.1 — СП1, 192.168.255.2 — СП2, …). Между филиалами связь не нужна, т.к. все службы в ЦО. Когда филиалов 3, нам легко добавить 3 маршрута на роутер в ЦО и по одному на каждый из роутеров СП. Итого 6 движений мышкой. А что если СП у нас не 3, а 33 и необходимы маршруты от каждого каждому, а ещё есть подрядчики с доступом к нескольким СП? Тут и приходит на помощь OSPF.

Кому надо “быстро и все равно как оно работает”, могут пойти по схеме, предложенной выше — добавить в backbone все свои сети.

Добавление сетей в Backbone

Почему именно backbone? Backbone в переводе с английского — хребет, позвоночник. OSPF оперирует понятиями Area (область), Autonomous System (AS, автономная система). AS — все сети, которые принадлежат вам и между которыми может работать ваш протокол динамической маршрутизации. Area — часть этой сети. На картинке ниже показана одна AS с тремя Area, одна из которых — backbone (Area 0 с ID 0.0.0.0). Каждая Area имеет свой ID, похожий на IP адрес. Backbone всегда имеет ID 0.0.0.0. Все области в OSPF должны иметь линк с backbone. Иначе ничего работать не будет.

В нашем примере мы решили долго не думать и загнать все в backbone. По большому счету это ничем не грозит и работать будет. Но если провайдер отдает одному из ваших филиалов частный адрес из 192.168.0.0/16 (192.168.18.27/29, например), то в вашей таблице маршрутизации появится сеть провайдера. И если кто-то с другой стороны провайдера использует такие же настройки (или просто указал маршрут к вашим сетям), то он сможет беспрепятственно попасть в вашу сеть. А уж случайно это сделали или намеренно — узнаете когда данные из вашей БД всплывут в интернете.

Или указать, что интерфейс, смотрящий к провайдеру будет в пассивном режиме.

Настройка OSPF в ручном режиме

Теперь поговорим о том, как сделать “правильно” — не вещать свои сети куда попало и позволить грамотно траблшутить работу OSPF.
Как мы говорили выше, каждая область имеет свой ID. Также и каждый участник OSPF имеет свой ID. По умолчаню он выставляется автоматически и выбирается из IP адресов, присвоенных интерфейсам роутера. Но нам надо проставить его в ручную, чтобы была какая-то логика в именовании и мы всегда знали откуда пришел запрос. Ставится это в Routing — OSPF — Instances — Router ID.

В нашей схеме имеется несколько областей. Как мы выяснили, основная область, соединяющая все остальные — backbone. Именно в этой области летают пакеты от одного роутера к другому, позволяющие обмениваться маршрутной информацией. Значит, этой областью должны быть туннели, соединяющие СП и ЦО, что видно на рисунке ниже.

Таким образом, нам необходимо выделить на каждом маршрутизаторе по две зоны — backbone и свою локальную сеть. На примере ЦО:
routing ospf area add name=Area0 area-id=192.168.0.0
routing ospf network add area=Area0 network=192.168.0.0/24
routing ospf network add area=backbone network=192.168.255.0/24

И точно так же на остальных маршрутизаторах, только заменив Area-ID, Area name и network на свои.

Теперь на каждом маршрутизаторе можем увидеть маршруты ко всем остальным сетям с буквами D и o в описании, что означает, что эти маршруты D — динамические (прилетели в резудльтате работы протоколов динамической маршрутизации) и o — из протокола OSPF.

Так мы получили простую и надежную настройку протокола динамической маршрутизации. У OSPF ещё имеется куча дополнительных настроек, таких как приоритет роутера, стоимость интерфейса, время определения состояний и многое, многое другое. Это позволяет очень гибко настроить маршрутизацию под свои нужды.

Итак, приступим.

Статей и видео о том, как настроить OSPF горы. Гораздо меньше описаний принципов работы. Вообще, тут такое дело, что OSPF можно просто настроить согласно мануалам, даже не зная про алгоритмы SPF и непонятные LSA. И всё будет работать и даже, скорее всего, прекрасно работать - на то он и рассчитан. То есть тут не как с вланами, где приходилось знать теорию вплоть до формата заголовка.
Но инженера от эникейщика отличает то, что он понимает, почему его сеть функционирует так, а не иначе, и не хуже самогo OSPF знает, какой маршрут будет выбран протоколом.
В рамках статьи, которая уже на этот момент составляет 8 000 символов, мы не сможем погрузиться в глубины теории, но рассмотрим принципиальные моменты.
Очень просто и понятно, кстати, написано про OSPF на xgu.ru или в английской википедии .
Итак, OSPFv2 работает поверх IP, а конкретно, он заточен только под IPv4 (OSPFv3 не зависит от протоколов 3-го уровня и потому может работать с IPv6).

Рассмотрим его работу на примере вот такой упрощённой сети:

Для начала надо сказать, что для того, чтобы между маршрутизаторами завязалась дружба (отношения смежности) должны выполниться следующие условия:

1) в OSPF должны быть настроены одинаковые Hello Interval на тех маршрутизаторах, что подключены друг к другу. По умолчанию это 10 секунд в Broadcast сетях, типа Ethernet. Это своего рода KeepAlive сообщения. То есть каждые 10 секунд каждый маршрутизатор отправляет Hello пакет своему соседу, чтобы сказать: “Хей, я жив”,
2) Одинаковыми должны быть и Dead Interval на них. Обычно это 4 интервала Hello - 40 секунд. Если в течение этого времени от соседа не получено Hello, то он считается недоступным и начинается ПАНИКА процесс перестроения локальной базы данных и рассылка обновлений всем соседям,
3) Интерфейсы, подключенные друг к другу, должны быть в одной подсети ,
4) OSPF позволяет снизить нагрузку на CPU маршрутизаторов, разделив Автономную Систему на зоны. Так вот номера зон тоже должны совпадать,
5) У каждого маршрутизатора, участвующего в процессе OSPF есть свой уникальный индентификатор - Router ID . Если вы о нём не позаботитесь, то маршрутизатор выберет его автоматически на основе информации о подключенных интерфейсах (выбирается высший адрес из интерфейсов, активных на момент запуска процесса OSPF). Но опять же у хорошего инженера всё под контролем, поэтому обычно создаётся Loopback интерфейс, которому присваивается адрес с маской /32 и именно он назначается Router ID. Это бывает удобно при обслуживании и траблшутинге.
6) Должен совпадать размер MTU

1) Штиль. Состояние OSPF - DOWN
В это короткое мгновение в сети ничего не происходит - все молчат.

2) Поднимается ветер: маршрутизатор рассылает Hello-пакеты на мультикастный адрес 224.0.0.5 со всех интерфейсов, где запущен OSPF. TTL таких сообщений равен одному, поэтому их получат только маршрутизаторы, находящиеся в том же сегменте сети. R1 переходит в состояние INIT .

В пакеты вкладывается следующая информация:

• Router ID
• Hello Interval
• Dead Interval
• Neighbors
• Subnet mask
• Area ID
• Router Priority
• Адреса DR и BDR маршрутизаторов
• Пароль аутентификации

И отправляет на R1 уже юникастом новое сообщение Hello, где содержится Router ID этого маршрутизатора, а в списке Neigbors перечислены все его соседи. В числе прочих соседей в этом списке есть Router ID R1, то есть R2 уже считает его соседом.

3) Дружба. Когда R1 получает это сообщение Hello от R2, он пролистывает список соседей и находит в нём свой собственный Router ID, он добавляет R2 в свой список соседей.

Теперь R1 и R2 друг у друга во взаимных соседях - это означает, что между ними установлены отношения смежности и маршрутизатор R1 переходит в состояние TWO WAY .

Общий совет по всем задачам:

Даже если Вы сразу не знаете ответа и решения, постарайтесь подумать к чему относится условие задачи:
- К каким особенностям, настройкам протокола?
- Глобальные эти настройки или привязаны к конкретному интерфейсу?
Если Вы не знаете или забыли команду, такие размышления, скорее всего, приведут Вас к правильному контексту, где Вы просто, с помощью подсказки в командной строке, можете догадаться или вспомнить как настроить то, что требуется в задании.
Постарайтесь поразмышлять в таком ключе прежде чем пойдете в гугл или на какой-то сайт в поиске команд.

Прежде чем мы перейдём к тестированию резервных линков и скорости, сделаем ещё одну полезную вещь.
Если бы у нас была возможность отловить трафик на интерфейсе FE0/0.2 msk-arbat-gw1, который смотрит в сторону серверов, то мы бы увидели, что каждые 10 секунд в неизвестность улетают сообщения Hello. Ответить на Hello некому, отношения смежности устанавливать не с кем, поэтому и пытаться рассылать отсюда сообщения смысла нет.
Выключается это очень просто:

msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2

*Не представляю, как вы до сих пор не запутались*

Кроме того, эта команда повышает безопасность - никто из этой сети не прикинется маршрутизатором и не будет пытаться поломать нас полностью.

Теперь займёмся самым интересным - тестированием.
Ничего сложного нет в настройке OSPF на всех маршрутизаторах в Сибирском кольце - сделаете сами.
И после этого картина должна быть следующей:

msk-arbat-gw1#sh ip OSPF neighbor

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

msk-arbat-gw1#sh ip route

172.16.0.0/16 is variably subnetted, 25 subnets, 6 masks



S 172.16.2.4/30 via 172.16.2.2



O 172.16.2.160/30 via 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 via 172.16.2.2
S 172.16.24.0/22 via 172.16.2.18
O 172.16.24.0/24 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 via 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:04:18, FastEthernet0/1.8
via 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:04:28, FastEthernet1/0.911

1 172.16.2.130 35 msec 8 msec 5 msec

msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Known via «OSPF 1», distance 110, metric 4, type intra area
Last update from 172.16.2.197 on FastEthernet1/0.911, 00:00:53 ago
Routing Descriptor Blocks:
* 172.16.2.197, from 172.16.255.80, 00:00:53 ago, via FastEthernet1/0.911
Route metric is 4, traffic share count is 1

Vld-gw1#sh ip route 172.16.128.0
Routing entry for 172.16.128.0/24
Known via «OSPF 1», distance 110, metric 3, type intra area
Last update from 172.16.2.193 on FastEthernet1/0, 00:01:57 ago
Routing Descriptor Blocks:
* 172.16.2.193, from 172.16.255.80, 00:01:57 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1

Msk-arbat-gw1#traceroute 172.16.128.1
Type escape sequence to abort.
Tracing the route to 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 msec
3 172.16.2.161 15 msec 13 msec 6 msec

То есть теперь Красноярска трафик достигает таким путём:

Как только вы поднимете линк, маршрутизаторы снова вступают в связь, обмениваются своими базами, пересчитываются кратчайшие пути и заносятся в таблицу маршрутизации.
На видео всё это более наглядно. Рекомендую ознакомиться .

Как любой хороший протокол, OSPF поддерживает аутентификацию - два соседа перед установлением соотношений соседства могут проверять подлинность полученных OSPF-сообщений. Оставляем на самостоятельное изучение - довольно просто.

EIGRP

Итак, чем хорош EIGRP?
- прост в конфигурации
- быстрое переключение на заранее просчитанный запасной маршрут
- требует меньше ресурсов роутера (по сравнению с OSPF)
- суммирование маршрутов на любом роутере (в OSPF только на ABR\ASBR)
- балансировка трафика на неравноценных маршрутах (OSPF только на равноценных)

Мы решили перевести одну из записей блога Ивана Пепельняка, в которой разбирается ряд популярных мифов про EIGRP:
- “EIGRP это гибридный протокол маршрутизации”. Если я правильно помню, это началось с первой презентации EIGRP много лет назад и обычно понимается как «EIGRP взял лучшее от link-state и distance-vector протоколов». Это совершенно не так. У EIGRP нет никаких отличительных особенностей link-state. Правильно будет говорить «EIGRP это продвинутый distance-vector- протокол маршрутизации».

- “EIGRP это distance-vector протокол”. Неплохо, но не до конца верно тоже. EIGRP отличается от других DV способом, которым обрабатывает потерянные маршруты (или маршруты с возрастающей метрикой). Все остальные протоколы пассивно ждут обновления информации от соседа (некоторые, например, RIP, даже блокируют маршрут для предотвращения петель маршрутизации), в то время как EIGRP ведет себя активнее и запрашивает информацию сам.

- “EIGRP сложен во внедрении и обслуживании”. Неправда. В свое время, EIGRP в больших сетях с низкоскоростными линками было сложновато правильно внедрить, но ровно до того момента, как были введены stub routers. С ними (а также несколькими исправлениями работы DUAL-алгоритма), он не чуть не хуже, чем OSPF.

- “Как и LS протоколы, EIGRP хранит таблицу топологии маршрутов, которыми обменивается”. Просто удивительно, насколько это неверно. EIGRP не имеет вообще никакого понятия о том, что находится дальше ближайших соседей, в то время как LS протоколы точно знают топологию всей области, к которой они подключены.

- “EIGRP это DV протокол, который действует, как LS”. Неплохая попытка, но по-прежнему, абсолютно неверно. LS протоколы строят таблицу маршрутизации, проходя через следующие шаги:
- каждый маршрутизатор описывает сеть, исходя из информации, доступной ему локально (его линки, подсети, в которых он находится, соседи, которых он видит) посредством пакета (или нескольких), называемого LSA (в OSPF) или LSP (IS-IS)
- LSA распространяются по сети. Каждый маршрутизатор должен получить каждую LSA, созданную в его сети. Информация, полученная из LSA, заносится в таблицу топологии.
- каждый маршрутизатор независимо анализирует свою таблицу топологии и запускает SPF алгоритм для подсчета лучших маршрутов к каждому из других маршрутизаторов
Поведение EIGRP даже близко не напоминает эти шаги, поэтому непонятно, с какой стати он «действует, как LS»

Единственное, что делает EIGRP - это хранит информацию, полученную от соседа (RIP сразу же забывает то, что не может быть использовано в данный момент). В этом смысле, он похож на BGP, который тоже хранит все в таблице BGP и выбирает лучший маршрут оттуда. Таблица топологии (содержащая всю информацию, полученную от соседей), дает EIGRP преимущество перед RIP – она может содержать информацию о запасном (не используемом в данный момент) маршруте.

Теперь чуть ближе к теории работы:

Каждый процесс EIGRP обслуживает 3 таблицы:
- Таблицу соседей (neighbor table), в которой содержится информация о “соседях”, т.е. других маршрутизаторах, непосредственно подключенных к текущему и участвующих в обмене маршрутами. Можно посмотреть с помощью команды show ip eigrp neighbors
- Таблицу топологии сети (topology table), в которой содержится информация о маршрутах, полученная от соседей. Смотрим командой show ip eigrp topology
- Таблицу маршрутизации (routing table), на основе которой роутер принимает решения о перенаправлении пакетов. Просмотр через show ip route

Метрика.
Для оценки качества определенного маршрута, в протоколах маршрутизации используется некое число, отражающее различные его характеристики или совокупность характеристик- метрика. Характеристики, принимаемые в расчет, могут быть разными- начиная от количества роутеров на данном маршруте и заканчивая средним арифметическим загрузки всех интерфейсов по ходу маршрута. Что касается метрики EIGRP, процитируем Jeremy Cioara: “у меня создалось впечатление, что создатели EIGRP, окинув критическим взглядом свое творение, решили, что все слишком просто и хорошо работает. И тогда они придумали формулу метрики, что бы все сказали “ВАУ, это действительно сложно и профессионально выглядит”. Узрите же полную формулу подсчета метрики EIGRP: (K1 * bw + (K2 * bw) / (256 - load) + K3 * delay) * (K5 / (reliability + K4)), в которой:
- bw это не просто пропускная способность, а (10000000/самая маленькая пропускная способность по дороге маршрута в килобитах) * 256
- delay это не просто задержка, а сумма всех задержек по дороге в десятках микросекунд * 256 (delay в командах show interface, show ip eigrp topology и прочих показывается в микросекундах!)
- K1-K5 это коэффициенты, которые служат для того, чтобы в формулу “включился” тот или иной параметр.

Страшно? было бы, если бы все это работало, как написано. На деле же из всех 4 возможных слагаемых формулы, по умолчанию используются только два: bw и delay (коэффициенты K1 и K3=1, остальные нулю), что сильно ее упрощает - мы просто складываем эти два числа (не забывая при этом, что они все равно считаются по своим формулам). Важно помнить следующее: метрика считается по худшему показателю пропускной способности по всей длине маршрута .

Интересная штука получилась с MTU: довольно часто можно встретить сведения о том, что MTU имеет отношение к метрике EIGRP. И действительно, значения MTU передаются при обмене маршрутами. Но, как мы можем видеть из полной формулы, никакого упоминания об MTU там нет. Дело в том, что этот показатель принимается в расчет в довольно специфических случаях: например, если роутер должен отбросить один из равнозначных по остальным характеристикам маршрутов, он выберет тот, у которого меньший MTU. Хотя, не все так просто (см. комментарии).

Определимся с терминами, применяемыми внутри EIGRP. Каждый маршрут в EIGRP характеризуется двумя числами: Feasible Distance и Advertised Distance (вместо Advertised Distance иногда можно встретить Reported Distance, это одно и то же). Каждое из этих чисел представляет собой метрику, или стоимость (чем больше-тем хуже) данного маршрута с разных точек измерения: FD это “от меня до места назначения”, а AD- “от соседа, который мне рассказал об этом маршруте, до места назначения”. Ответ на закономерный вопрос “Зачем нам надо знать стоимость от соседа, если она и так включена в FD?”- чуть ниже (пока можете остановиться и поломать голову сами, если хотите).

У каждой подсети, о которой знает EIGRP, на каждом роутере существует Successor- роутер из числа соседей, через который идет лучший (с меньшей метрикой), по мнению протокола, маршрут к этой подсети. Кроме того, у подсети может также существовать один или несколько запасных маршрутов (роутер-сосед, через которого идет такой маршрут, называется Feasible Successor). EIGRP- единственный протокол маршрутизации, запоминающий запасные маршруты (в OSPF они есть, но содержатся, так сказать, в “сыром виде” в таблице топологии- их еще надо обработать алгоритмом SPF), что дает ему плюс в быстродействии: как только протокол определяет, что основной маршрут (через successor) недоступен, он сразу переключается на запасной. Для того, чтобы роутер мог стать feasible successor для маршрута, его AD должно быть меньше FD successor’а этого маршрута (вот зачем нам нужно знать AD). Это правило применяется для того, чтобы избежать колец маршрутизации.

Предыдущий абзац взорвал мозг? Материал трудный, поэтому еще раз на примере. У нас есть вот такая сеть:

С точки зрения R1, R2 является Successor’ом для подсети 192.168.2.0/24. Чтобы стать FS для этой подсети, R4 требуется, чтобы его AD была меньше FD для этого маршрута. FD у нас ((10000000/1544)*256)+(2100*256) =2195456, AD у R4 (с его точки зрения это FD, т.е. сколько ему стоит добраться до этой сети) = ((10000000/100000)*256)+(100*256)=51200. Все сходится, AD у R4 меньше, чем FD маршрута, он становится FS. *тут мозг такой и говорит: “БДЫЩЬ”*. Теперь смотрим на R3- он анонсирует свою сеть 192.168.1.0/24 соседу R1, который, в свою очередь, рассказывает о ней своим соседям R2 и R4. R4 не в курсе, что R2 знает об этой подсети, и решает ему рассказать. R2 передает информацию о том, что он имеет доступ через R4 к подсети 192.168.1.0/24 дальше, на R1. R1 строго смотрит на FD маршрута и AD, которой хвастается R2 (которая, как легко понять по схеме, будет явно больше FD, так как включает и его тоже) и прогоняет его, чтобы не лез со всякими глупостями. Такая ситуация довольно маловероятна, но может иметь место при определенном стечении обстоятельств, например, при отключении механизма “расщепления горизонта” (split-horizon). А теперь к более вероятной ситуации: представим, что R4 подключен к сети 192.168.2.0/24 не через FastEthernet, а через модем на 56k (задержка для dialup составляет 20000 usec), соответственно, добраться ему стоит ((10000000/56)*256)+(2000*256)= 46226176. Это больше, чем FD для этого маршрута, поэтому R4 не станет Feasible Successor’ом. Но это не значит, что EIGRP вообще не будет использовать данный маршрут. Просто переключение на него займет больше времени (подробнее об этом дальше).

соседство

Роутеры не разговаривают о маршрутах с кем попало - прежде чем начать обмениваться информацией, они должны установить отношения соседства. После включения процесса командой router eigrp с указанием номера автономной системы, мы, командой network говорим, какие интерфейсы будут участвовать и одновременно, информацию о каких сетях мы желаем распространять. Незамедлительно, через эти интерфейсы начинают рассылаться hello-пакеты на мультикаст- адрес 224.0.0.10 (по умолчанию каждые 5 секунд для ethernet). Все маршрутизаторы с включенным EIGRP получают эти пакеты, далее каждый маршрутизатор-получатель делает следующее:
- сверяет адрес отправителя hello-пакета, с адресом интерфейса, из которого получен пакет, и удостоверяется, что они из одной подсети
- сверяет значения полученных из пакета K-коэффициентов (проще говоря, какие переменные используются в подсчете метрики) со своими. Понятно, что если они различаются, то метрики для маршрутов будут считаться по разным правилам, что недопустимо
- проверяет номер автономной системы
- опционально: если настроена аутентификация, проверяет соответствие ее типа и ключей.

Если получателя все устраивает, он добавляет отправителя в список своих соседей, и посылает ему (уже юникастом) update-пакет, в котором содержится список всех известных ему маршрутов (aka full-update). Отправитель, получив такой пакет, в свою очередь, делает то же самое. Для обмена маршрутами EIGRP использует Reliable Transport Protocol (RTP, не путать с Real-time Transport Protocol, который используется в ip-телефонии), который подразумевает подтверждение о доставке, поэтому каждый из роутеров, получив update- пакет, отвечает ack -пакетом (сокращение от acknowledgement- подтверждение). Итак, отношение соседства установлены, роутеры узнали друг у друга исчерпывающую информацию о маршрутах, что дальше? Дальше они будут продолжать посылать мультикаст hello-пакеты в подтверждение того, что они на связи, а в случае изменения топологии- update-пакеты, содержащие сведения только об изменениях (partial update).

Теперь вернемся к предыдущей схеме с модемом.

R2 по каким-то причинам потерял связь с 192.168.2.0/24. До этой подсети у него нет запасных маршрутов (т.е. отсутствует FS). Как всякий ответственный роутер с EIGRP, он хочет восстановить связь. Для этого он начинает рассылать специальные сообщения (query- пакеты) всем своим соседям, которые, в свою очередь, не находя нужного маршрута у себя, расспрашивают всех своих соседей, и так далее. Когда волна запросов докатывается до R4, он говорит “погодите-ка, у меня есть маршрут к этой подсети! Плохонький, но хоть что-то. Все про него забыли, а я-то помню”. Все это он упаковывает в reply-пакет и отправляет соседу, от которого получил запрос (query), и дальше по цепочке. Понятное дело, это все занимает больше времени, чем просто переключение на Feasible Successor, но, в итоге, мы получаем связь с подсетью.

А сейчас опасный момент: может, вы уже обратили внимание и насторожились, прочитав момент про эту веерную рассылку. Падение одного интерфейса вызывает нечто похожее на широковещательный шторм в сети (не в таких масштабах, конечно, но все-таки), причем чем больше в ней роутеров, тем больше ресурсов потратится на все эти запросы-ответы. Но это еще пол-беды. Возможна ситуация и похуже: представим, что роутеры, изображенные на картинке- это только часть большой и распределенной сети, т.е. некоторые могут находится за много тысяч километров от нашего R2, на плохих каналах и прочее. Так вот, беда в том, что, послав query соседу, роутер обязан дождаться от него reply. Неважно, что в ответе- но он должен прийти. Даже если роутер уже получил положительный ответ, как в нашем случае, он не может поставить этот маршрут в работу, пока не дождется ответа на все свои запросы. А запросы-то, может, еще где-нибудь на Аляске бродят. Такое состояние маршрута называется stuck-in-active. Тут нам нужно познакомится с терминами, отражающими состояние маршрута в EIGRP: active\passive route. Обычно они вводят в заблуждение. Здравый смысл подсказывает, что active значит маршрут “активен”, включен, работает. Однако тут все наоборот: passive это “все хорошо”, а состояние active означает, что данная подсеть недоступна, и маршрутизатор находится в активном поиске другого маршрута, рассылая query и ожидая reply. Так вот, состояние stuck-in-active (застрял в активном состоянии) может продолжатся до 3 минут! По истечение этого срока, роутер обрывает отношения соседства с тем соседом, от которого он не может дождаться ответа, и может использовать новый маршрут через R4.

История, леденящая кровь сетевого инженера. 3 минуты даунтайма это не шутки. Как мы можем избежать инфаркта этой ситуации? Выхода два: суммирование маршрутов и так называемая stub-конфигурация.

Вообще говоря, есть еще один выход, и он называется фильтрация маршрутов (route filtering). Но это настолько объемная тема, что впроу отдельную статью под нее писать, а у нас и так уже пол-книги получилось в этот раз. Поэтому на ваше усмотрение.

Как мы уже упоминали, в EIGRP суммирование маршрутов можно проводить на любом роутере. Для иллюстрации, представим, что к нашему многострадальному R2 подключены подсети от 192.168.0.0/24 до 192.168.7.0/24, что очень удобненько суммируется в 192.168.0.0/21 (вспоминаем binary math). Роутер анонсирует этот суммарный маршрут, и все остальные знают: если адрес назначения начинается на 192.168.0-7, то это к нему. Что будет происходить, если одна из подсетей пропадет? Роутер будет рассылать query-пакеты с адресом этой сети (конкретным, например, 192.168.5.0/24), но соседи, вместо того, чтобы уже от своего имени продолжить порочную рассылку, будут сразу в ответ слать отрезвляющие реплаи, мол, это твоя подсеть, ты и разбирайся.

Второй вариант- stub- конфигурация. Образно говоря, stub означает “конец пути”, “тупик” в EIGRP, т.е., чтобы попасть в какую-то подсеть, не подключенную напрямую к такому роутеру, придется идти назад. Роутер, сконфигурированный, как stub, не будет пересылать трафик между подсетями, которые ему стали известны от EIGRP (проще говоря, которые в show ip route помечены буквой D). Кроме того, его соседи не будут отправлять ему query-пакеты. Самый распространенный случай применения- hub-and-spoke топологии, особенно с избыточными линками. Возьмем такую сеть: слева- филиалы, справа- основной сайт, главный офис и т.п. Для отказоустойчивости избыточные линки. Запущен EIGRP с дефолтными настройками.

А теперь “внимание, вопрос”: что будет, если R1 потеряет связь с R4, а R5 потеряет LAN? Трафик из подсети R1 в подсеть главного офиса будет идти по маршруту R1->R5->R2(или R3)->R4. Будет это эффективно? Нет. Будет страдать не только подсеть за R1, но и подсеть за R2 (или R3), из-за увеличения объемов трафика и его последствий. Вот для таких-то ситуаций и придуман stub. За роутерами в филиалах нет других роутеров, которые вели бы в другие подсети, это “конец дороги”, дальше только назад. Поэтому мы с легким сердцем можем сконфигурировать их как stub’ы, что, во-первых, избавит нас от проблемы с “кривым маршрутом”, изложенной чуть выше, а во-вторых, от флуда query-пакетов в случае потери маршрута.

Существуют различные режимы работы stub-роутера, задаются они командой eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

По умолчанию, если просто дать команду eigrp stub, включаются режимы сonnected и summary. Интерес представляет режим receive-only, в котором роутер не анонсирует никаких сетей, только слушает, что ему говорят соседи (в RIP есть команда passive interface, которая делает то же самое, но в EIGRP она полностью отключает протокол на выбранном интерфейсе, что не позволяет установить соседство).

Важные моменты в теории EIGRP, не попавшие в статью:

• В EIGRP можно настроить аутентификацию соседей
• Концепция graceful shutdown

Практика EIGRP

“Лифт ми Ап” купили фабрику в Калининграде. Там производят мозги лифтов: микросхемы, ПО. Фабрика очень крупная - три точки по городу - три маршрутизатора соединены в кольцо.

Но вот незадача - на них уже запущен EIGRP в качестве протокола динамической маршрутизации. Причём адресация конечных узлов совсем из другой подсети - 10.0.0.0/8. Все другие параметры (линковые адреса, адреса лупбэк интерфейсов) мы поменяли, но несколько тысяч адресов локальной сети с серверами, принтерами, точками доступа - работа не на пару часов - отложили на потом, а в IP-плане зарезервировали на будущее для Калининграда подсеть 172.16.32.0/20.

Сейчас у нас используются такие сети:

Как настраивается это чудо? Незамысловато, на первый взгляд:

router eigrp 1
network 172.16.0.0 0.0.255.255
network 10.0.0.0

В EIGRP обратную маску можно задавать, указывая тем самым более узкие рамки, либо не задавать, тогда будет выбрана стандартная маска для этого класса (16 для класса B - 172.16.0.0 и 8 для класса 8 - 10.0.0.0)

Такие команды даются на всех маршрутизаторах Автономной Системы. АС определяется цифрой в команде router eigrp, то есть в нашем случае имеем АС №1. Эта цифра должна быть одинаковой на всех маршрутизаторах (в отличии от OSPF).

Но есть в EIGRP серьёзный подвох: по умолчанию включено автоматическое суммирование маршрутов в классовом виде (в версиях IOS до 15).
Сравним таблицы маршрутизации на трёх калининградских маршрутизаторах:

Сеть 10.0.0.1/24 подключена у нас к klgr-center-gw1 и он о ней знает:

klgr-center-gw1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:35:23, Null0
C 10.0.0.0/24 is directly connected, FastEthernet1/0

Но не знает о 10.0.1.0/24 и 10.0.2.0/24/

Klgr-balt-gw1 знает о своих двух сетях 10.0.1.0/24 и 10.0.2.0/24, но вот сеть 10.0.0.0/24 он куда-то спрятал.

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:42:05, Null0
C 10.0.1.0/24 is directly connected, FastEthernet1/1.2
C 10.0.2.0/24 is directly connected, FastEthernet1/1.3

Они оба создали маршрут 10.0.0.0/8 с адресом next hop Null0.

А вот klgr-center-gw2 знает, что подсети 10.0.0.0/8 находятся за обоими его WAN интерфейсами.

D 10.0.0.0/8 via 172.16.2.41, 00:42:49, FastEthernet0/1
via 172.16.2.45, 00:38:05, FastEthernet0/0

Что-то очень странное творится.
Но, если вы проверите конфигурацию этого маршрутизатора, то, вероятно, заметите:

router eigrp 1
network 172.16.0.0
network 10.0.0.0
auto-summary

Во всём виновато автоматическое суммирование. Это самое большое зло EIGRP. Рассмотрим более подробно, что происходит. klgr-center-gw1 и klgr-balt-gw1 имеют подсети из 10.0.0.0/8, они их суммируют по умолчанию, когда передают соседям.
То есть, например, msk-balt-gw1 передаёт не две сети 10.0.1.0/24 и 10.0.2.0/24, а одну обобщённую: 10.0.0.0/8. То есть его сосед будет думать, что за msk-balt-gw1 находится вся эта сеть.
Но, что произойдёт, если вдруг на balt-gw1 попадёт пакет с адресатом 10.0.50.243, о котором тот ничего не знает? На этот случай и создаётся так называетмый Blackhole-маршрут:
10.0.0.0/8 is a summary, 00:42:05, Null0
Полученный пакет будет выброшен в эту чёрную дыру. Это делается во избежание петель маршрутизации.
Так вот оба эти маршрутизатора создали свои blackhole-маршруты и игнорируют чужие анонсы. Реально на такой сети эти три девайса друг друга так и не смогут пинговать, пока… пока вы не отключите auto-summary.

Первое, что вы должны сделать при настройке EIGRP:

router eigrp 1
no auto-summary

На всех устройствах. И всем будет хорошо:

Klgr-center-gw1:

C 10.0.0.0 is directly connected, FastEthernet1/0
D 10.0.1.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 via 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1

10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 is directly connected, FastEthernet1/1.2
C 10.0.2.0 is directly connected, FastEthernet1/1.3

klgr-center-gw2:

10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 via 172.16.2.41, 00:11:48, FastEthernet0/1

Настройка передачи маршрутов между различными протоколами

Наша задача организовать передачу маршрутов между этими протоколами: из OSPF в EIGRP и наоборот, чтобы все знали маршрут до любой подсети.
Это называется редистрибуцией (перераспределением) маршрутов.

Для её осуществления нам нужна хотя бы одна точка стыка, где будут запущены одновременно два протокола. Это может быть msk-arbat-gw1 или klgr-balt-gw1. Выберем второй.

Из EIGRP в OSPF:

klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

Смотрим маршруты на msk-arbat-gw1:

msk-arbat-gw1#sh 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

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2 10.0.0.0/8 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 via 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 is variably subnetted, 30 subnets, 5 masks
O E2 172.16.0.0/16 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
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
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
O E2 172.16.2.36/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
O 172.16.2.160/30 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:13:21, FastEthernet1/0.911
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
O 172.16.24.0/24 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 via 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 is directly connected, Loopback0
O 172.16.255.48/32 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
via 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
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 via 198.51.100.1

Вот те, что с меткой Е2 - новые импортированные маршруты. Е2 - означает, что это внешние маршруты 2-го типа (), то есть они были введены в процесс OSPF извне

Теперь из OSPF в EIGRP. Это чуточку сложнее:

klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500

Без указания метрики (вот этого длинного набора цифр) команда выполнится, но редистрибуции не произойдёт.

Импортированные маршруты получают метку EX в таблице маршрутизации и административную дистанцию 170, вместо 90 для внутренних:

klgr-gw2#sh ip route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 30 subnets, 4 masks
D EX 172.16.0.0/24 [170 /33280] via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [90 /30720] via 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 is directly connected, FastEthernet0/0
D 172.16.2.40/30 via 172.16.2.37, 00:38:59, FastEthernet0/0
via 172.16.2.46, 00:38:59, FastEthernet0/1
….

Вот так, казалось бы незамысловато это делается, но простота поверхностная - редистрибуция таит в себе много тонких и неприятных , когда добавляется хотя бы один избыточный линк между двумя разными доменами.
Универсальный совет - старайтесь избегать редистрибуции, если это возможно. Тут работает главное жизненное правило - чем проще, тем лучше.

Маршрут по умолчанию

Теперь самое время проверить доступ в интернет. Из Москвы он прекрасно себе работает, а вот если проверить, например из Петербурга (помним, что мы удалили все статические маршруты):

PC>ping linkmeup.ru

Pinging 192.0.2.2 with 32 bytes of data:

Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.

Ping statistics for 192.0.2.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Это связано с тем, что ни spb-ozerki-gw1, ни spb-vsl-gw1, ни кто-либо другой в нашей сети не знает о маршруте по умолчанию, кроме msk-arbat-gw1, на котором он настроен статически.
Чтобы исправить эту ситуацию, нам достаточно дать одну команду в Москве:

msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information originate

После этого по сети лавинно распространяется информация о том, где находится шлюз последней надежды.

Интернет теперь доступен:

PC>tracert linkmeup.ru

Tracing route to 192.0.2.2 over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Полезные команды для траблшутинга

1) Список соседей и состояние связи с ними вызывается командой show ip ospf neighbor

msk-arbat-gw1:

Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Или для EIGRP: show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) С помощью команды show ip protocols можно посмотреть информацию о запущенных протоколах динамической маршрутизации и их взаимосвязи.

Klgr-balt-gw1:

Routing Protocol is «EIGRP 1 »

Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: EIGRP 1, OSPF 1
Automatic network summarization is in effect
Automatic address summarization:
Maximum path: 4
Routing for Networks:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distance: internal 90 external 170

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 172.16.255.64
It is an autonomous system boundary router
Redistributing External Routes from,
EIGRP 1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.2.32 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.255.64 110 00:00:23
Distance: (default is 110)

4) Для отладки и понимания работы протоколов будет полезно воспользоваться следующими командами:
debug ip OSPF events
debug ip OSPF adj
debug EIGRP packets

Попробуйте подёргать разные интерфейсы и посмотреть, что происходит в дебаге, какие сообщения летят.

Задача №7
На последок комплесная задачка.
На последнем совещании Лифт ми Ап было решено, что сеть Калининграда необходимо также переводить на OSPF.
Переход должен быть совершен без разрывов связи. Было решено, что лучшим вариантом будет параллельно с EIGRP поднять OSPF на трёх маршрутизаторах Калининграда и после того, как будет проверено, что вся информация о маршрутах Калининграда распространилась по остальной сети и наоборот, отключить EIGRP. за логотип сайта.

OSPF

EIGRP

route redistribution

packet tracer

сети для самых маленьких

Добавить метки

О чем эта статья

В статье описываются протоколы динамической маршрутизации, использующие для определения оптимальности того или иного маршрута различные алгоритмы – дистанционно-векторный и состояния связи. Приведен пример настройки конфигурации протокола OSPF для пакета Quagga. Описаны особенности демонов маршрутизации routed и gated.

Преимущества и недостатки динамической маршрутизации

Динамическая маршрутизация используется преимущественно в средних и крупных сетях со сложной, часто меняющейся инфраструктурой, где прежде всего важна оперативность отслеживания и устранения проблем связи. Это достигается за счет программного управления таблицами маршрутизации при помощи демонов (в unix-подобных системах для этих целей используются процессы routed и gated). Периодический обмен информацией между маршрутизаторами осуществляется с помощью соответствующих протоколов - на основании полученных данных корректируются записи в таблицах маршрутизации.

Использование протоколов динамической маршрутизации значительно сокращает затраты труда системного администратора по обслуживанию сети. Однако следует принимать во внимание тот факт, что при этом повышается нагрузка на процессоры маршрутизаторов и, как следствие, на сеть в целом. Отчасти данная проблема решается за счет использования динамической балансировки сетевой нагрузки и прописывания статических маршрутов отдельным сегментам сети. Но динамическая маршрутизация обладает и другим серьезным недостатком - возрастает риск DDOS-атак или перехвата сетевого трафика. В данных условиях повышение безопасности сети становится одной из приоритетных задач системного администратора.

Внутри- и междоменные протоколы динамической маршрутизации

По мере разрастания локальной сети вопрос эффективной организации динамической маршрутизации становится более актуальным из-за ограничения объема памяти маршрутизаторов и, как следствия, снижения быстродействия в результате увеличения нагрузки на сеть. Для его решения используется понятие «автономная система» (AS), которое представляет собой совокупность локальных сетей, объединенных единой маршрутной политикой. Протоколы, осуществляющие маршрутизацию внутри автономных систем в пределах домена, - RIP/RIPv2, IS-IS, IGRP, OSPF - входят в соответствующую группу «Interior Routing Protocols». В свою очередь, протоколы, выполняющие функцию организации маршрутизации между AS и являющиеся, своего рода, пограничными, или междоменными, - EGP, BGP - объединяются в группу Exterior Routing Protocols.

RIP (Routing Information Protocol) относится к протоколам дистанционного-векторного типа, использующим узел назначения и число хопов (переходов между транзитными узлами) до него в качестве простейшей метрики маршрутизации. В маршрутные таблицы RIP записывается информация об IP-адресах узла назначения и ближайшего шлюза, а также таймерах маршрута. Каждые 30 секунд маршрутизаторы отправляют широковещательные RIP-сообщения с текущими данными своей маршрутной таблицы, обновляя, таким образом, информацию о сети. В Unix и GNU/Linux поддержку протокола RIP первой версии (RIPv1) осуществляет демон маршрутизации routed.

Одним из недостатков протокола RIP является слабая проработка механизма обнаружения неработающих транзитных узлов, в частности, в самом формате RIP-сообщения не предусмотрено какого-либо флага, который бы фиксировал данное изменение сети. Для выявления проблемы для каждого транзитного узла существует период TTL (Time-to-Live), равный шестикратному периоду рассылки векторов по сети. Маршрут считается недоступным, если по истечении указанного времени он не смог отправить соответствующий RIP-сообщение. На практике обновление маршрутных таблиц подобным образом происходит достаточно медленно и не синхронизировано. Нередко это приводит к появлению маршрутных петель, когда из-за образовавшихся некорректных записей в маршрутных таблицах пакеты начинают циркулировать между узлами вплоть до истечения их собственного TTL.

RIP является одним из старейших протоколов динамической маршрутизации, в силу чего его возможности зачастую уступают более современным аналогам. Он прост в настройке, однако имеет ограничение на число хопов (всего 15). Это делает невозможным его использование в крупных сетях, несмотря на доработку протокола до версии RIPv2, в которой была добавлена поддержка VLSM-адресации (масок подсетей переменной длины), multicast-рассылки и возможность агрегации маршрутов. Тем не менее, RIPv2 может использоваться в малых и средних сетях как альтернатива статической маршрутизации.

Более эффективным способом организации динамической маршрутизации внутри AS является использование протоколов состояния связи (link-state protocols). При этом метрикой маршрутизации служит не узел назначения и его удаленность от источника, а коэффициент качества обслуживания канала ближайших маршрутизаторов, или «соседей». Решение об оптимизации маршрута принимается на основании данных о пропускной способности, периоде задержки, надежности и общей загрузке канала, что позволяет обслуживать средние и крупные сети со сложной инфраструктурой.

К протоколам состояния связи относится OSPF (Open Shortest Part First) , являющийся усовершенствованной версией протокола IS-IS и получивший широкое распространение в TCP/IP-сетях. Помимо стандартной поддержки VLSM-адресации, multicast-рассылки, возможности агрегации маршрутов и использования аутентификации, OSPF учитывает в формате рассылаемых сообщений данные поля TOS (Type-of-Service) для вычисления альтернативных маршрутов согласно текущему состоянию каналов связи. В Unix и Gnu/Linux OSPF входит в список протоколов, поддерживаемых демоном маршрутизации gated и пакетом GNU Zebra 1 или его усовершенствованной версией Quagga 2 .

Каждый маршрутизатор хранит информацию о состоянии соседних транзитных узлов, а также общую базу данных о топологии сети, представленную в виде графа. Актуальность состояния связей между соседними маршрутизаторами поддерживается за счет частого (от 10 до 30 секунд) обмена короткими hello-сообщениями. Информация об изменениях топологии всей сети передается с периодичностью раз в 30 минут отдельными пакетами «router links advertisment». Важной особенностью OSPF является поддержка разделения AS на несколько сегментов сети, каждый из которых имеет выделенный маршрутизатор (DR – Designated Router) и резервный (BDR – Backup Designated Router). Узлы, входящие в отдельный сегмент сети, получают информацию только от DR, который, в свою очередь, обменивается данными с другими выделенными маршрутизаторами. Такой метод позволяет поддерживать актуальность маршрутных таблиц и более эффективно распределять сетевую нагрузку.

При всех своих преимуществах, OSPF обладает некоторыми недостатками. В частности, даже при отсутствии ограничения на количество транзитных узлов в сети, не рекомендуется создавать отдельные сегменты, в которых количество маршрутизаторов превышает 50. В этом случае более эффективным будет равномерное распределение меньшего числа транзитных узлов по разным сегментам.

BGP (Border Gateway protocol) , или BGP4, является на сегодняшний день единственным междоменным протоколом, способным передавать информацию между отдельными AS. Он обеспечивает функционирование сети Интернет, используя для передачи данных маршруты, проходящие через наименьшее число AS. При этом каждые 30 секунд для проверки работоспособности узла происходит широковещательная рассылка TCP-пакетов (KEEPALIVE). Полученная информация добавляется в маршрутные таблицы только после инкрементного обновления. В дальнейшем AS обмениваются текущими изменениями.

Алгоритм работы BGP4 похож на векторно-дистанционный, с той разницей, что вектор пути ориентируется на номер сети и набор атрибутов, позволяющих принимать решение о выборе оптимального маршрута. В их число входят обязательные атрибуты AS_PATH (список AS, через которые должен проходить пакет) и NEXT_HOP (адрес следующего BGP-маршрутизатора), а также дополнительные параметры, отвечающие за агрегацию маршрутов, приоритет AS и маршрутизаторов и т. д.

BGP4 также поддерживает CIDR – бесклассовую маршрутизацию. В Unix и GNU/Linux BGP4, как и OSPF, настраивается при помощи gated или Quagga.

Демоны маршрутизации routed и gated

Routed 3 – стандартный демон маршрутизации, поддерживающий только протокол RIPv1. Он прост в использовании, так как не требует дополнительной настройки и самостоятельно вносит изменения в маршрутную таблицу при обнаружении более оптимальных маршрутов. Тем не менее, он обладает рядом недостатков, в частности, отсутствием поддержки других протоколов, неудобством при одновременном использовании статических и динамических маршрутов. В этом плане предпочтение отдается демону gated 4 , который обладает более широкими возможностями. В число поддерживаемых им протоколов входят RIPv2, OSPF, BGP4 и некоторые другие. Вместе с тем настройка конфигурационного файла /etc/gated.conf, в котором прописываются не только опции самого демона, но и настройки протоколов и маршрутов, и чей синтаксис схож с языками программирования, может показать достаточно сложной тем, кто впервые сталкивается с настройкой маршрутизации при помощи данной утилиты.

Настройка протокола OSPF при помощи Quagga

Пакет Quagga , разработанный как ответвление GNU Zebra, представляет собой набор утилит, предназначенных для настройки протоколов динамической маршрутизации в unix-подобных системах. Он входит в стандартную сборку большинства дистрибутивов, поддерживает все распространенные версии протоколов (OSPFv2, OSPFv3, RIPv1, RIPv2, RIPng, BGP4) и достаточно прост в настройке и использовании. При использовании Quagga под GNU/LInux рекомендуется проверять наличие выставленных параметров ядра CONFIG_NETLINK, CONFIG_RTNETLINK и CONFIG_IP_MULTICAST – они обеспечивают взаимодействие ядра и демона zebra, а также поддержку multicast-рассылки, используемой демонами ripd и osfpd.

В зависимости от задачи, после установки пакета необходимо выставить соответствующие настройки в конфигурационном файле для активации демонов:

Демоны, активация которые не нужна, по умолчанию выставлены с параметром no. Zebra активируется всегда, так как является управляющим и отвечает за внесение изменений в маршрутную таблицу ядра, а также координирует работу остальных демонов.

Для каждой установленной службы существует возможность редактирования конфигурационных файлов через отдельный интерфейс vty, подключение к которому реализуется при помощи telnet. Для этого автоматически выделяется номер порта, информацию о котором необходимо добавить в /etc/services:

Для настройки демонов создается одноименный файл в /etc/quagga/ вида *.conf, при этом его владельцем должен быть пользователь quagga.

Запуск демонов осуществляется при помощи следующих команд:

Автономная система состоит из нескольких подсетей, объединенных тремя маршрутизаторами, которые также образуют отдельную подсеть (см. рис. 1) 5 . Один из маршрутизаторов является шлюзом по умолчанию для доступа в Интернет. Необходимо настроить динамическую маршрутизацию по протоколу OSPF между подсетями 192.168.10.0/24 и 192.168.12.0/24.

Для настройки OSPF необходимо установить пакет Quagga на каждом маршрутизаторе, а также отредактировать файл zebra.conf:

Таким же образом настраиваются конфигурационные файлы ospfd.conf:

После того как настройка закончена, необходимо запустить демоны и подключиться через telnet к tvy-интерфейсу ospfd:

Проверить работоспособность протокола можно, запустив в консоли Quagga команду show ip ospf neighbor, которая выводит список активных «соседних» маршрутизаторов. Команда show ip ospf route выводит список маршрутов, которые были получены по протоколу OSPF.

Средства мониторинга и анализа сети с динамической маршрутизацией

В большинстве случаев стандартные утилиты, при помощи которых конфигурируются протоколы динамической маршрутизации, уже содержат встроенные средства для ее мониторинга и анализа. Так, команда ospf_monitor, используемая в gated, позволяет увидеть подробную статистику по сконфигурированным маршрутным таблицам OSPF, а также информацию о соседних маршрутизаторах. Кроме того, поддержка логирования как в gated, так и в Quagga, позволяет системному администратору при создании соответствующего скрипта перенаправлять сообщения о критических ошибках на e-mail или другое средство оповещения.

Заключение

Использование динамической маршрутизации уместно в средних и крупных сетях с разветвленной и неоднородной топологией. Определенную поддержку здесь оказывают стандартные демоны либо специально разработанные утилиты, при помощи которых возможно создавать достаточно сложные конфигурации маршрутов. При этом в зависимости от поставленной задачи необходимо учитывать преимущества и недостатки каждого из протоколов динамической маршрутизации, выбранных для наиболее оптимального решения.

Статическая и динамическая маршрутизация

Статическая маршрутизация - вид маршрутизации, при котором маршруты указываются в явном виде при конфигурации маршрутизатора. Вся маршрутизация при этом происходит без участия каких-либо протоколов маршрутизации.

При задании статического маршрута указывается:

· Адрес сети (на которую маршрутизируется трафик), маска сети

· Адрес шлюза (узла), который способствует дальнейшей маршрутизации (или подключен к маршрутизируемой сети напрямую)

· (опционально) метрика (иногда именуется также "ценой") маршрута. При наличии нескольких маршрутов на одну и ту же сеть некоторые маршрутизаторы выбирают маршрут с минимальной метрикой

Статическая маршрутизация продолжает успешно использоваться при :

· -организации работы компьютерных сетей небольшого размера(1-2маршрутизатора

· -на компьютерах (рабочих станциях) внутри сети. В таком случае обычно задается маршрут шлюза по умолчанию.

· -в целях безопасности - когда необходимо скрыть некоторые части составной корпоративной сети;

· -если доступ к подсети обеспечивается одним маршрутом, то вполне достаточно использовать один статический маршрут. Такой тип сети (подсети) носит названия тупиковой сети (stub network).

Динамическая маршрутизация - вид маршрутизации, при котором таблица маршрутизации редактируется программно.

При динамической маршрутизации происходит обмен маршрутной информацией между соседними маршрутизаторами, в ходе которого они сообщают друг другу, какие сети в данный момент доступны через них. Информация обрабатывается и помещается в таблицу маршрутизации. К наиболее распространенным внутренним протоколам маршрутизации относятся:

RIP (Routing Information Protocol) - протокол маршрутной информации OSPF (Open Shortest Path First) - протокол выбора кратчайшего маршрута EIGRP (Enhanced Interior Gateway Routing Protocol) - усовершенствованный протокол маршрутизации внутреннего шлюза IGRP (Interior Gateway Routing Protocol) - протокол маршрутизации внутреннего шлюза

Протокол динамической маршрутизации выбирается исходя из множества предпосылок (скорость конвергенции, размер сети, задействование ресурсов, внедрение и сопровождение и др.) поэтому прежде всего, во внимание принимаются такие характеристики, как размер сети, доступная полоса пропускания, аппаратные возможности процессоров маршрутизирующих устройств, модели и типы маршрутизаторов.

Большинство алгоритмов маршрутизации может быть отнесено к одной из двух категорий: дистанционно-векторные протоколы (RIPv1, RIPv2, RIPng, IGRP, EIGRP, EIGRP for IPv6) и протоколы с учетом состояния канала (OSPFv2, OSPFv3, IS-IS, IS-IS for IPv6).

Вывод

Маршрутизация - процесс определения маршрута следования информации в сетях связи.

Маршрутизатор, как и, например, мост, имеет несколько портов и должен для каждого поступающего пакета решить – отфильтровать его или передать на какой-то другой порт.

Как и мосты, маршрутизаторы решают эту дачу с помощью специальной таблицы – таблицы маршрутизации. По этой таблице маршрутизатор определяет, на какой порт нужно передавать пакет, чтобы он достиг нужной подсети (не обязательно сразу). Если сеть содержит петли, в таблицах маршрутизации может быть несколько записей на одну подсеть, описывающих разные возможные маршруты.

Каждый порт маршрутизатора рассматривается, как отдельный узел сети. Другие узлы должны знать его адрес и направлять пакеты для передачи в другие подсети на этот адрес, а не просто выдавать их в канал (как при прозрачных мостах).

Каждый маршрутизатор принимает решения о направлении пересылки пакетов на основании таблицы маршрутизации. Таблица маршрутизации содержит набор правил. Каждое правило в наборе описывает шлюз или интерфейс, используемый маршрутизатором для доступа к определенной сети.

Стати́ческая маршрутиза́ция - вид маршрутизации, при котором маршруты указываются в явном виде при конфигурации маршрутизатора. Вся маршрутизация при этом происходит без участия каких-либо протоколов маршрутизации.

При задании статического маршрута указывается:

Адрес сети (на которую маршрутизируется трафик), маска сети

Адрес шлюза (узла), который отвечает за дальнейшую маршрутизацию (или подключен к маршрутизируемой сети напрямую)

(опционально) метрика (иногда именуется также "ценой") маршрута. При наличии нескольких маршрутов на одну и ту же сеть некоторые маршрутизаторы выбирают маршрут с минимальной метрикой

В некоторых маршрутизаторах возможно указывать интерфейс, на который следует направить трафик сети и указать дополнительные условия, согласно которым выбирается маршрут (например, SLA в маршрутизаторах cisco).

Достоинства

Основные:

Лёгкость отладки и конфигурирования в малых сетях.

Отсутствие дополнительных накладных расходов (из-за отсутствия протоколов маршрутизации)

Мгновенная готовность (не требуется интервал для конфигурирования/подстройки)

Предсказуемость в каждый момент времени

Недостатки

Очень плохое масштабирование (добавление (N+1)-ой сети потребует сделать 2*(N+1) записей о маршрутах, причём на большинстве маршрутизаторов таблица маршрутов будет различной, при N>3-4 процесс конфигурирования становится весьма трудоёмким).

Низкая устойчивость к повреждениям линий связи (особенно, в ситуациях, когда обрыв происходит между устройствами второго уровня и порт маршрутизатора не получает статус down).

Отсутствие динамического балансирования нагрузки

Необходимость в ведении отдельной документации к маршрутам, проблема синхронизации документации и реальных маршрутов.

Использование

В реальных условиях статическая маршрутизация используется в условиях наличия шлюза по умолчанию (узла, обладающего связностью с остальными узлами) и 1-2 сетями. Помимо этого статическая маршрутизация используется для "выравнивания" работы маршрутизирующих протоколов в условиях наличия туннеля (для того, чтобы маршрутизация трафика, создаваемого туннелем, не производилась через сам туннель).

18. Маршрутизация. Динамическая маршрутизация.

Динамическая маршрутизация - вид маршрутизации, при котором таблица маршрутизации редактируется программно. В случае UNIX-систем демонами маршрутизации; в других системах - служебными программами, которые называются иначе, но фактически играют ту же роль.

Демоны маршрутизации обмениваются между собой информацией, которая позволяет им заполнить таблицу маршрутизации наиболее оптимальными маршрутами. Протоколы, с помощью которых производится обмен информацией между демонами, называется протоколами динамической маршрутизации.

Протоколы динамической маршрутизации:

Когда маршрутизатор отправляет обновление RIP, он добавляет к метрике маршрута, которую он использует, 1 и отправляет соседу. Сосед получает обновление, в котором указано какую метрику для полученного маршрута ему использовать.

Маршрутизатор отправляет каждые 30 секунд все известные ему маршруты соседним маршрутизаторам. Но, кроме этого, для предотвращения петель и для улучшения времени сходимости, используются дополнительные механизмы:

Split horizon - если маршрут достижим через определенный интерфейс, то в обновление, которое отправляется через этот интерфейс не включается этот маршрут;

Triggered update - обновления отправляются сразу при изменении маршрута, вместо того чтобы ожидать когда истечет Update timer;

Route poisoning - это принудительное удаление маршрута и перевод в состояние удержания, применяется для борьбы с маршрутными петлями.

Poison reverse - Маршрут помечается, как не достижимый, то есть с метрикой 16 и отправляется в обновлениях.

В обновлениях RIPv2 могут передаваться до 25 сетей.

Маршрутизаторы обмениваются hello-пакетами через все интерфейсы, на которых активирован OSPF. Маршрутизаторы, совместно использующие общий канал передачи данных, становятся соседями, когда они приходят к договоренности об определенных параметрах, указанных в их hello-пакетах.

На следующем этапе работы протокола маршрутизаторы будут пытаться перейти в состояние смежности со своими соседями. Переход в состояние смежности определяется типом маршрутизаторов, обменивающихся hello-пакетами, и типом сети, по которой передаются hello-пакеты. OSPF определяет несколько типов сетей и несколько типов маршрутизаторов. Пара маршрутизаторов, находящихся в состоянии смежности, синхронизирует между собой базу данных состояния каналов.

Каждый маршрутизатор посылает объявление о состоянии канала маршрутизаторам, с которыми он находится в состоянии смежности.

Каждый маршрутизатор, получивший объявление от соседа, записывает информацию, передаваемую в нем, в базу данных состояния каналов маршрутизатора и рассылает копию объявления всем другим своим соседям.

Рассылая объявления через зону, все маршрутизаторы строят идентичную базу данных состояния каналов маршрутизатора.

Когда база данных построена, каждый маршрутизатор использует алгоритм "кратчайший путь первым" (shortest path first) для вычисления графа без петель, который будет описывать кратчайший путь к каждому известному пункту назначения с собой в качестве корня. Этот граф - дерево кратчайшего пути.

Каждый маршрутизатор строит таблицу маршрутизации, основываясь на своем дереве кратчайшего пути.

RTP управляет процессом отправки и получения пакетов EIGRP.

RTP обеспечивает:

Гарантированную доставку пакетов. Для этого используется проприетарный алгоритм Cisco, reliable multicast. Пакеты отправляются на muilticast-адрес 224.0.0.10. Каждый сосед получивший такой пакет отправляет подтверждение отправителю пакета.

Сохранение порядка пакетов. В каждом пакете используется два номера последовательности (sequence). Каждый пакет включает в себя номер присвоенный ему отправителем. Этот номер увеличивается на единицу каждый раз, когда маршрутизатор отправляет новый пакет. Кроме того, отправитель помещает в пакет номер последнего полученного пакета от получателя.

В некоторых случаях RTP использует негарантированную доставку. В таких пакетах не проставляются номера последовательностей и они не требуют подтверждения о получении.

Все сообщения EIGRP инкапсулируются в IP-пакеты, номер EIGRP в поле protocol IP-пакета - 88.

EIGRP использует 5 типов сообщений:

Hello - маршрутизаторы используют hello-пакеты для обнаружения соседей. Пакеты отправляются multicast и не требуют подтверждения о получении.

Update - содержится информация об изменении маршрутов. Они отправляются только маршрутизаторам, которых касается обновление. Эти пакеты могут быть отправлены конкретному маршрутизатору (unicast) или группе маршрутизаторов (multicast). Получение update-пакета подтверждается отправкой ACK.

Query - когда маршрутизатор выполняет подсчет маршрута и у него нет feasible successor, он отправляет query-пакет своим соседям для того чтобы определить нет ли feasible successor для этого destination у них. Обычно query-пакеты отправляются multicast, но могут быть и unicast. Получение query-пакета подтверждается отправкой ACK получателем пакета.

Reply - маршрутизатор отправляет reply-пакет в ответ на query-пакет. Reply-пакеты отправляются unicast тому, кто отправил query-пакет. Получение reply-пакета подтверждается отправкой ACK.

ACK - пакет, который подтверждает получение пакетов update, query, reply. ACK-пакеты отправляются unicast и содержат в себе acknowledgment number. Фактически это hello-пакеты, которые не передают данных. Используется негарантированная доставка.

Таблица соседей (neighbor table) - список всех соседей BGP

Таблица BGP (BGP table, forwarding database, topology database):

Список всех сетей выученных от каждого соседа

Атрибуты BGP для каждого пути

Таблица маршрутизации - список лучших путей к сетям

По умолчанию BGP отправляет keepalive-сообщения каждые 60 секунд.

Если существует несколько путей к получателю, то маршрутизатор будет анонсировать соседям не все возможные варианты, а только лучший маршрут из таблицы BGP.

Маршрутизаторы могут быть уровня 1, уровня 2 или уровня 1-2:

Маршрутизаторы уровня 1 (как internal nonbackbone маршрутизаторы в OSPF) - знают маршруты в пределах зоны в которой они соединены;

Маршрутизаторы уровня 2 (как backbone маршрутизаторы в OSPF) - знают маршруты между зонами;

Маршрутизаторы уровня 1-2 (как ABR в OSPF) - знают маршруты и в пределах зоны в которой они соединены и между зонами. Это маршрутизаторы аналогичные ABR в OSPF.

Путь соединения маршрутизаторов уровня 2 и уровня 1-2 называется backbone.

Границы зон приходятся на каналы (links). Каждый маршрутизатор принадлежит только одной зоне. Соседние маршрутизаторы определяют в одной они зоне или в разных и устанавливают соответствующие отношения соседства: уровня 1, уровня 2 или обоих.

Демоны динамической маршрутизации:

Как правило, демоны динамической маршрутизации поддерживают множество протоколов и используют информацию, полученную по одним протоколам для работы других.

Сами протоколы динамической маршрутизации можно классифицировать по нескольким критериям.

По алгоритмам:

Дистанционно-векторные протоколы (Distance-vector Routing Protocols);

Протоколы состояния каналов связи (Link-state Routing Protocols).

Иногда выделяют третий класс, усовершенствованные дистанционно-векторные протоколы (advanced distance-vector), для того чтобы подчеркнуть существенные отличия протоколов от классических дистанционно-векторных.

Компания Cisco ранее называла протокол EIGRP смешанный протокол, однако по своим принципам работы, EIGRP дистанционно-векторный протокол.

По области применения:

Междоменной маршрутизации;

Внутридоменной маршрутизации.