OSPFv2 минимум лаба

В прошлом посте про OSPFv2 я описал некую базовую информацию по протоколу. Сегодня попытаемся настроить все это на Juniper. Множим VMx'ы и вперед.
OSPF какой-то очень непростой. Я снова думал, что уж лабу-то я за недельку сколочу, даже со своей нехваткой времени. Как выяснилось, Cisco и Juniper имплементируют OSPF немного по разному. Ну и тема сама по себе довольно масштабная.

В заголовок к посту нужно было ставить следующую картинку из AT&T презентации.

Особо рассусоливать не будем. Строю я все, как обычно, на голом ESXi. Мне очень нравится UNL, например, но в процессе я хочу ещё немножко разобраться в ESXi подходе к виртуализации. Наступить на больше граблей. Двух зайцев, так сказать, убить.

Включаем виртуалки, соединяем все это vSwitch'ами, расстраиваемся от использованной оперативки, но все ворочается.

 

Будем использовать топологию из прошлого поста, я немного перерисовал её.

Можно открыть в новом окне и обращатся к картинке по мере прочтения

Базовая конфигурация

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

show configuration | display set
set system host-name O1
set system root-authentication encrypted-password "$1$H7QSbc8x$gmAQdANmVu2E8y2DqvA/Q0"
set interfaces em2 unit 0 family inet address 10.10.0.1/24
set interfaces lo0 unit 0 family inet address 10.0.10.1/32

Backbone Area

Настроим все маршрутизаторы в area 0 - O1, O2, O3 и O4. Делается это одной командой. Даем её на каждом роутере в backbone area.

set protocols ospf area 0.0.0.0 interface em2.0

Посмотрим состояние соседей у O3

root@O3> show ospf neighbor detail
Address          Interface              State     ID               Pri  Dead
10.10.0.4        em2.0                  Full      10.0.10.4        128    36
  Area 0.0.0.0, opt 0x52, DR 10.10.0.3, BDR 10.10.0.2
  Up 00:00:47, adjacent 00:00:47
10.10.0.2        em2.0                  Full      10.0.10.2        128    36
  Area 0.0.0.0, opt 0x52, DR 10.10.0.3, BDR 10.10.0.2
  Up 00:03:54, adjacent 00:03:14
10.10.0.1        em2.0                  Full      10.0.10.1        128    35
  Area 0.0.0.0, opt 0x52, DR 10.10.0.3, BDR 10.10.0.2
  Up 00:03:54, adjacent 00:03:09

Как видно, соседство от O3 к каждому из роутеров в этой зоне успешно поднялось. Состояние каждого соседа Full, что намекает нам на то, что O3 либо DR, либо BDR. В выводе можно увидеть однозначную информацию об этом - DR 10.10.0.3, BDR 10.10.0.2.

Почему O4 не DR, ведь он имеет приоритет 128 и наивысший RouterID 10.10.0.4? Дело а том, что я немного замешкался перед тем как настроить OSPF на нем. За это время оставшиеся маршрутизаторы успели прийти к согласию. Потом пришел O4, но, как я и писал в прошлом посте, перевыборов не произошло. Займемся тюнингом чуть позже, сейчас настроим другие зоны.

К слову, выражения area 0 и area 0.0.0.0 тождественны.

Regular Area 1

На O2 и O5 делаем примерно следующую конфигурацию.

root@O2# set protocols ospf area 1 interface em3.0 interface-type p2p

Как видно, я указал interface-type p2p. В этой зоне нет других маршрутизаторов, поэтому и линк такого типа. Напомню, никаких DR/BDR тут быть не может.

root@O5> show ospf neighbor detail
Address          Interface              State     ID               Pri  Dead
10.10.1.1        em2.0                  Full      10.0.10.2        128    35
  Area 0.0.0.1, opt 0x52, DR 0.0.0.0, BDR 0.0.0.0
  Up 00:02:57, adjacent 00:02:57

Как видно DR и BDR значения выставлены в нули. Но соседство поднялось и это прекрасно. Пока хорошо идем.

Totally Stub Area 2

Напомню, в эту зону, как в stub area, не будут передаваться Type 5 LSA о внешних маршрутах. Однако в нашем случае, это Tottaly Stub Area, и это значит, что даже информация о других OSPF областях содержащаяся в Type 3 LSA сюда передаваться не должна. То есть, ABR O3 не должен генерировать суммарные LSA в эту зону, так и напишем. В одну строку уместить конфигурацию уже не получиться.

root@O3# set protocols ospf area 2 stub no-summaries
root@O3# set protocols ospf area 2 interface em3.0 interface-type p2p

На O6 мы так же должны указать, что данная область является тупиковой. Иначе он не будет отправлять Stub Flag и соседство не сформируется. no-summaries ключ нам уже не нужен, потому что эта конфигурация применима только для ABR, ведь именно он не будет генерировать LSA Type 3.

root@O6# set protocols ospf area 0.0.0.2 stub
root@O6# set protocols ospf area 0.0.0.2 interface em2.0 interface-type p2p


Смотрим соседство.

root@O6> show ospf neighbor detail
Address          Interface              State     ID               Pri  Dead
10.10.2.1        em2.0                  Full      10.0.10.3        128    33
  Area 0.0.0.2, opt 0x50, DR 0.0.0.0, BDR 0.0.0.0
  Up 00:00:33, adjacent 00:00:33

Отлично.

Чуть ниже я заметил, что я забыл добавить дефолтный маршрут в эту зону на О3. Нужно ещё вот так сделать, иначе в area 2 будет совсем грустно.

root@O3# set protocols ospf area 2 stub default-metric 2

 

 NSSA Area 3

Настраиваем O4 и O7 маршрутизаторы в зоне NSSA. Особых отличий от Stub зоны нет.


root@04# set protocols ospf area 3 nssa
root@04# set protocols ospf area 3 interface em3.0 interface-type p2p

root@O7# set protocols ospf area 3 nssa
root@O7# set protocols ospf area 3 interface em2.0 interface-type p2p

Смотрим соседство.

root@O7> show ospf neighbor detail
Address          Interface              State     ID               Pri  Dead
10.10.3.1        em2.0                  Full      10.0.10.4        128    34
  Area 0.0.0.3, opt 0x50, DR 0.0.0.0, BDR 0.0.0.0
  Up 00:01:05, adjacent 00:01:05

Отлично.

Stub Area 4

Конфигурация stub area особо ничем не отличается. Это как stub no-summary только без no-summary.

root@O5# set protocols ospf area 4 stub
root@O5# set protocols ospf area 4 interface em3.0 interface-type p2p

root@O8#set protocols ospf area 0.0.0.4 stub
root@O8#set protocols ospf area 0.0.0.4 interface em2.0 interface-type p2p

Соседство? Есть.

root@O8> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.10.4.1        em2.0                  Full      10.0.10.5        128    30

Networks

Пока что мы установили соседство между роутерами и автоматически добавили "линковые" сети в процесс. Хотелось бы, что бы loopback адреса тоже были доступны. Для этого нам нужно аналогично добавить lo0.0 интерфейс в ту или иную область. Конфиг для всех роутеров будет выглядеть примерно вот так.

root@O1# set protocols ospf area 0 interface lo0.0

root@O2# set protocols ospf area 0 interface lo0.0

root@O3# set protocols ospf area 0 interface lo0.0

root@O4# set protocols ospf area 0 interface lo0.0

root@O5# set protocols ospf area 1 interface lo0.0

root@O6# set protocols ospf area 2 interface lo0.0

root@O7# set protocols ospf area 3 interface lo0.0

root@O8# set protocols ospf area 4 interface lo0.0

Virtual-link O8 - O2

Каждая область в OSPF должна иметь связность с area 0. Для этого мне придется настроить virtual-link через O5. Ок. Но мне стало интересно почему так.

Да, весь прикол в том, что между зонами OSPF работает как distance-vector прококол.

То есть в нашем случае O1 отправляет LSA Type1 со своим адресом 10.0.10.1, его получает O2. Это видно на выводе ниже.

root@O2> show ospf database area 0 router lsa-id 10.0.10.1 detail

    OSPF database, Area 0.0.0.0

 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len

Router   10.0.10.1        10.0.10.1        0x80000026  1091  0x22 0xc0d1  48

  bits 0x0, link count 2

  id 10.10.0.3, data 10.10.0.1, Type Transit (2)

    Topology count: 0, Default metric: 1

  id 10.0.10.1, data 255.255.255.255, Type Stub (3)

    Topology count: 0, Default metric: 0

  Topology default (ID 0)

    Type: Transit, Node ID: 10.10.0.3

      Metric: 1, Bidirectional

Он является ABR и его святая обязанность передать эти знания в другие зоны, такие как area 1, например. Как мы уже знаем, ABR передает LSA Type3 в другие зоны. То есть O5 получит такой Network Summary LSA от O2. Его можно посмотреть ниже.

root@O5> show ospf database area 1 netsummary | match 10.0.10.1

Summary  10.0.10.1        10.0.10.2        0x80000014  1678  0x22 0xc538  28

Здесь и можно рассмотреть distance-vector логику. О5 при получении такого LSA просто добавляет к стоимости указанной в этом LSA свою стоимость для достижения O2 в своей области. То есть, если грубо, О5 ничего не знает про топологию нулевой зоны, он просто знает куда слать трафик и сколько это будет стоить. Такое поведение чревато петлями маршрутизации. Если мы не знаем про топологию соседней зоны, мы не можем быть уверены, что там нет петли. Для обхода этой проблемы, в OSPF должна быть топология типа "Звезда", где петли исключены "by design", что называется.

Это все в теории, а вот что происходит на практике?

Мы уже видели, что LSA Type 3 от O2 был доставлен до О5. Дальше интереснее, O5 по факту тоже считает себя ABR, ведь он располагается на границе зон 1 и 4. Так ли это? Безусловно.

root@O5> show ospf overview

Instance: master

  Router ID: 10.0.10.5

  Route table index: 0

  Area border router

В моем представлении, ABR при получении Network Summary "перегенирирует" его в другую зону, как парой абзацев раньше это сделал O2.

Но нет, О8 так и не узнает про 10.0.10.1 из area0. В LSDB у О8 будет только информация из area1. Убедимся в этом.

root@O8> show ospf database

    OSPF database, Area 0.0.0.4

 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len

Router   10.0.10.5        10.0.10.5        0x80000017  2984  0x20 0x256c  48

Router  *10.0.10.8        10.0.10.8        0x80000015  1981  0x20 0xd57   60

Summary  10.0.10.5        10.0.10.5        0x80000014  1984  0x20 0x9f5a  28

Summary  10.10.1.0        10.0.10.5        0x80000014  1484  0x20 0xb44b  28

Непонятно... После некоторых поисков, выяснилось, что Cisco и Juniper ведут себя в этой ситуации по разному. Этот вопрос неплохо отражен, например, на этом форуме, в том числе в этой теме, или в RFC3509.

Если кратко, то я нашел следующую информацию.

• Роутер Juniper считает себя ABR в случае, когда у него есть интерфейсы в две или более области. Это мы видели в предыдущем выводе - O5 считает себя ABR, потому что имеет интерфейсы в две зоны. Т.е. в нашем примере, LSA3 из area 1 будут отправлены в area 4. Но вот роутеры в area 4 не добавят такие префиксы в таблицу маршрутизации, они ожидают увидеть их из нулевой области. Обсуждалось здесь.

• Роутер Cisco считает себя ABR, когда у него есть интерфейсы в разные области, но один из этих зон должна быть backbone. В случае с Cisco, LSA3 из area1 даже и не дошли бы до area4.

Однако в моей лабе ситуация совсем иная. O1 не знает про О8 и наоборот. Судя по той информации, которую я сумел найти LSA Type 3 должны добраться до O8, но этого не происходит.

Более того, я нашел прям точное описание такого поведения в книге "OSPF and ISIS: Choosing an IGP for Large-Scale networks. Книга эта коммерческая, так что цитировать не возьмусь...

В моем случае ясно видно, что роутер не регенирирует полученные LSA Type 3 в другие зоны, если только они не получены или не отправляются в area0.

Как видно, О1 отправит Type1, О2 его получит и сгенерирует Type3 в area1, О5 получив такой LSA уже ничего не предпримет... Справедлива и обратная ситуация от О8 в сторону О1.

Можно открыть в отдельной вкладке крупнее

А как будуте вести себя роутеры, если дизайн будет по книжке. Скажем, пришедшие LSA Type3 от О3 будут перегенирированный роутером О2 в area1. Безусловно.

Можно открыть в отдельной вкладке крупнее

Что-то я опять закопался, чтобы исправить эту ситуацию, нужно настроить virtual-link, чтобы соединить далекую area4 с area0. Настраиваться такой линк будет между роутерами О2 и О5 через транзитную область area1. На роутере O2 мы должны связать нулевую зону с маршрутизатором О5.

root@O2# set protocols ospf area 0.0.0.0 virtual-link neighbor-id 10.0.10.5  transit-area 1

На О5 нужно применить симметричную конфигурацию

root@O5# set protocols ospf area 0.0.0.0 virtual-link neighbor-id 10.0.10.2 transit-area 1

Теперь видно, что у О2 появился новый сосед через новый интерфейс.

root@O2> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
...
10.10.1.2        vl-10.0.10.5           Full      10.0.10.5          0    34
...

Да, выводы команд становятся все больше и больше, поэтому я позволю себе сокращать их, помещая на месте пропусков "...".

Что важней, у О5 появился выход в backbone зону

root@O5> show ospf overview
Instance: master
  Router ID: 10.0.10.5
  Route table index: 0
  Area border router
  LSA refresh time: 50 minutes
...

  Area: 0.0.0.0
    Stub type: Not Stub
    Authentication Type: None
    Area border routers: 3, AS boundary routers: 1
    Neighbors
      Up (in full state): 1
...

Ну и самое инетересное, что же поменялось на О8. Как видно ниже, О5 теперь пересылает все Network Summary LSA в сторону О8.

root@O8> show ospf database

    OSPF database, Area 0.0.0.4
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.5        10.0.10.5        0x8000001b   238  0x20 0x1d70  48
Router  *10.0.10.8        10.0.10.8        0x80000019    87  0x20 0x55b   60
Summary  10.0.10.1        10.0.10.5        0x80000001   473  0x20 0x20d   28
Summary  10.0.10.2        10.0.10.5        0x80000001   473  0x20 0xed21  28
Summary  10.0.10.3        10.0.10.5        0x80000001   473  0x20 0xed1f  28
Summary  10.0.10.4        10.0.10.5        0x80000001   473  0x20 0xe328  28
Summary  10.0.10.5        10.0.10.5        0x80000017  1998  0x20 0x995d  28
Summary  10.0.10.6        10.0.10.5        0x80000001   473  0x20 0xd92f  28
Summary  10.0.10.7        10.0.10.5        0x80000001   473  0x20 0xcf38  28
Summary  10.10.0.0        10.0.10.5        0x80000002   473  0x20 0xff0f  28
Summary  10.10.1.0        10.0.10.5        0x80000017  1492  0x20 0xae4e  28
Summary  10.10.2.0        10.0.10.5        0x80000001   473  0x20 0xe32c  28
Summary  10.10.3.0        10.0.10.5        0x80000001   473  0x20 0xd836  28

Всю ситуацию можно изобразить примерно следующим образом. О2 как бы дотягивает area0 до О5.

DR/BDR

Пришло время нулевую зону сконфигурировать в соостветсвии с картинкой. Сейчас все работает по дефолту и роли DR/BDR назначаются динамически. Нам же нужен O1 в роли DR и O3 и роли BDR. Погнали.

Помним, что контролировать назначение ролей DR/BDR мы можем средствами приоритета. Сейчас приоритет у всех одинаковый  и равен 128, поэтому роли назначаются по RouterID. Наивысший RouterID у O4, он и будет DRом. O3 - BDR. Но это зависит от порядка загрузки роутеров, что и было доказано ещё в начале лабы.

root@O1> show ospf interface extensive

Interface           State   Area            DR ID           BDR ID          Nbrs

em2.0               DRother 0.0.0.0         10.0.10.4       10.0.10.3          3

  Type: LAN, Address: 10.10.0.1, Mask: 255.255.255.0, MTU: 1986, Cost: 1

  DR addr: 10.10.0.4, BDR addr: 10.10.0.3, Priority: 128

  Adj count: 2

  Hello: 10, Dead: 40, ReXmit: 5, Not Stub

  Auth type: None

  Protection type: None

  Topology default (ID 0) -> Cost: 1

Также помним, что роль (Backup) Designated Router - свойство интерйейса, а не роутера вовсе. Поэтому настройку будет производить именно на интерфейсе. Для того чтобы сделать O1 Designated Router'ом, завышаем ему приоритет, скажем до 200. Обычно завышают до максимального значения, но мне такой подход не очень по душе.

root@O1# set protocols ospf area 0 interface em2.0 priority 200

Ну, а приоритеты O2 и O4 занизим, чтобы они не стали BDR роутерами.

root@O2# set protocols ospf area 0 interface em2.0 priority 50

root@O4# set protocols ospf area 0 interface em2.0 priority 50

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

clear ospf neighbor area 0

После рестарта смотрим "выхлоп" и убеждаемся в правильности конфигурации.

root@O1> show ospf neighbor area 0 detail

Address          Interface              State     ID               Pri  Dead

10.10.0.4        em2.0                  Full      10.0.10.4         50    32

  Area 0.0.0.0, opt 0x52, DR 10.10.0.1, BDR 10.10.0.3

  Up 00:01:51, adjacent 00:01:51

...

Теперь роутер О1 рассылает Network LSA.

root@O1> show ospf database advertising-router self

    OSPF database, Area 0.0.0.0

 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len

Router  *10.0.10.1        10.0.10.1        0x80000050   107  0x22 0xf32b  72

Network *10.10.0.1        10.0.10.1        0x8000000b   901  0x22 0xf8aa  40

Отлично.

Router ID

RouterID (RID) считается по определенным правилам

1. Берется сконфигурированный RouterID

2. Если нет - самый маленький сконфигурированный адрес на loopback'ах.

3. Нет loopback'ов - самый маленький сконфигурированный адрес на всех других интерфейсах.

Как у Cisco, только вот берется наименьший адрес, вместо наибольшего у Cisco.

Сейчас RID не настроен, но есть единсвтенный loopback. Он и выступает в роли RID. Меня такая ситуация в целом устраивает. Но на реальной сети лучше RID конфигурировать статически, потому как нет никакой гарантии, что не будет настроен второй, третий, четвертый loopback. Один из адресов на этих loopback'ах может стать новым RID.

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

set routing-options router-id 10.0.10.X

Так-то надо было в самом начале его настроить. Показываю тут в своем блоге не Best Practises. )

Authentification

Давайте-ка настроим аутентификацию. Согласно схеме между О3 и О6 будет plaintext аутентификация. Стильный модный молодежный, но уже давно кракнутый MD5 между О2 и О5.

Начнем с MD5.

root@O2# set protocols ospf area 1 interface em3.0 authentication md5 1 key SuperSecretKey

Как видно, есть здесь key-id после md5. Дело в том, что для каждого ключа можно утсановить своё время валидности и, для увеличения секьюрности, периодически менять ключи.

После коммита соседство с О5 должно потеряться. Так оно и есть, на О5 больше нет соседа 10.0.10.2

root@O5> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.10.4.2        em3.0                  Full      10.0.10.8        128    39

Настроим и на О5 аутентификацию. Key-id, к слову, должен совпадать.

root@O5# set protocols ospf area 1 interface em2.0 authentication md5 1 key SuperSecretKey

Все поднялось обратно. Как видно, поломав аутентификацию, мы сломали не только соседство между О2 и О5, но и отрезали всю четвертую зону от сети. Ведь у нас был настроен virtual-link через транзитную первую зону, где O2 и O5 являются ABRаим. Так что с этим нужно быть аккуратнее в реальной жизни.

root@O5> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.10.1.1        em2.0                  Full      10.0.10.2        128    36
10.10.4.2        em3.0                  Full      10.0.10.8        128    36
10.10.1.1        vl-10.0.10.2           Full      10.0.10.2          0    38

Теперь plaintext между O3 и О6.

root@O3# set protocols ospf area 2 interface em3.0 authentication simple-password SuperKey
root@O6# set protocols ospf area 2 interface em2.0 authentication simple-password SuperKey

Juniper использует термин simple-password вместо цисковского plain-text.

Соседство О6 и О3 снова в Full.

root@O6> show ospf neighbor detail
Address          Interface              State     ID               Pri  Dead
10.10.2.1        em2.0                  Full      10.0.10.3        128    33
  Area 0.0.0.2, opt 0x50, DR 0.0.0.0, BDR 0.0.0.0
  Up 02:34:40, adjacent 02:34:40

 

More networks

На картинке есть ещё подсети вида 10.11, которые пока не вовлечены в процесс. К сожалению, пойти протаренным путем с созданием лупбеков я не могу, потому что на vMX разрешено создание только одного unit0 под lo0. Ну ок, добавим второй адрес на lo0.0. RouterID ведь сконфигурирован статически. )

Для начала сконфигурим второй адрес на О1. Получилось как-то так

    lo0 {
        unit 0 {
            family inet {
                address 10.0.10.1/32;
                address 10.11.0.1/16;

Теперь О1 передает информацию о подключенных сетях в Router LSA.

root@O1> show ospf database advertising-router self lsa-id 10.0.10.1 extensive

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *10.0.10.1        10.0.10.1        0x80000050  1541  0x22 0xf32b  72
  bits 0x0, link count 4
  id 10.10.0.1, data 10.10.0.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 10.0.10.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 10.11.0.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 10.11.0.0, data 255.255.0.0, Type Stub (3)
    Topology count: 0, Default metric: 0

Такой LSA доходит до О2, например, и тот добавляет эти маршруты в свою таблицу.

root@O2> show ospf route detail
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
...
10.11.0.0/16       Intra Network    IP            1 em2.0         10.10.0.1
  area 0.0.0.0, origin 10.0.10.1, priority medium
10.11.0.1/32       Intra Network    IP            1 em2.0         10.10.0.1
  area 0.0.0.0, origin 10.0.10.1, priority medium

Ну и генерирует в area1 Network Summary LSA. Ничего необычного.

root@O2> show ospf database advertising-router self area 1 netsummary

    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Summary *10.11.0.0        10.0.10.2        0x80000001  2108  0x22 0xdf31  28
Summary *10.11.0.1        10.0.10.2        0x80000001  2108  0x22 0xd53a  28

Интересно будет на О5, который, как видно ниже, получает данные об этих префиксах из двух зон, из нулевой (от О1) и первой (от О2). Так получилось, потому что О5 фактически соединен с нулевой зоной через виртуальный линк.

root@O5> show ospf database

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.1        10.0.10.1        0x80000050  2104  0x22 0xf32b  72
...
    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Summary  10.11.0.0        10.0.10.2        0x80000001  2142  0x22 0xdf31  28
Summary  10.11.0.1        10.0.10.2        0x80000001  2142  0x22 0xd53a  28
...

Выбирает О5, к слову, префикс пришедший через виртуальный линк из area0...

root@O5> show ospf route
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
...
10.11.0.0/16       Intra Network    IP            2 em2.0         10.10.1.1
10.11.0.1/32       Intra Network    IP            2 em2.0         10.10.1.1

root@O5> show route extensive match-prefix 10.11.0.1/32

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
10.11.0.1/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.11.0.1/32 -> {10.10.1.1}
        *OSPF   Preference: 10
                Next hop type: Router, Next hop index: 330
                Address: 0x940fe68
                Next-hop reference count: 22
                Next hop: 10.10.1.1 via em2.0, selected
                Session Id: 0x1
                State: <Active Int>
                Age: 50:36      Metric: 2
                Validation State: unverified
                Area: 0.0.0.0
                Task: OSPF
                Announcement bits (1): 0-KRT
                AS path: I

Прикольно... Хотя next-hop, конечно же, 10.10.1.1. Это О2 - другой конец virtual-link'a.

Как порядочный ABR, который имеет выход в нулевую зоны, О5 передает данные о 10.11.0.0 в четвертую область.

root@O5> show ospf database area 4 netsummary advertising-router self

    OSPF database, Area 0.0.0.4
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Summary *10.11.0.0        10.0.10.5        0x80000002   480  0x20 0xf31a  28
Summary *10.11.0.1        10.0.10.5        0x80000002   344  0x20 0xe923  28

А как там дела у О6, он же находится в Totally Stub Area, в которой никакие Network Summary не доходят.

root@O6> show ospf database

    OSPF database, Area 0.0.0.2
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.3        10.0.10.3        0x80000037  2567  0x20 0xacce  48
Router  *10.0.10.6        10.0.10.6        0x80000037  1343  0x20 0x4c02  60

В итоге, О6 сейчас не может пинговать даже нулевую зону. А все потому что я забыл добавить дефолтный маршрут в эту область от О3... блин...

root@O3# set protocols ospf area 2 stub default-metric 2

Воо, так намного лучше.

root@O6> show ospf database

    OSPF database, Area 0.0.0.2
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.3        10.0.10.3        0x80000038   264  0x20 0xaacf  48
Router  *10.0.10.6        10.0.10.6        0x80000037  2007  0x20 0x4c02  60
Summary  0.0.0.0          10.0.10.3        0x80000001    34  0x20 0x91d   28

Опять отвлекся. Добавляем все префиксы с картинки в сеть.

В итоге, будет так.

root@O1> show ospf route | match /16
10.11.0.0/16       Intra Network    IP            0 lo0.0
10.12.0.0/16       Intra Network    IP            1 em2.0         10.10.0.2
10.13.0.0/16       Intra Network    IP            1 em2.0         10.10.0.3
10.14.0.0/16       Intra Network    IP            1 em2.0         10.10.0.4
10.15.0.0/16       Inter Network    IP            2 em2.0         10.10.0.2
10.16.0.0/16       Inter Network    IP            2 em2.0         10.10.0.3
10.17.0.0/16       Inter Network    IP            2 em2.0         10.10.0.4
10.18.0.0/16       Inter Network    IP            3 em2.0         10.10.0.2

ASBRs

Два роутера в нашей сети имеют выходы во "внешний мир". Речь идет о О1 и О7. С первым все довльно просто, а вот О7 находится у нас в NSSA зоне. Это stub зона, в которой может находится ASBR. О7 будет генерировать Type7 LSA, ну а ближайший ABR O4 будет конвертировать такой LSA в Type5. 

Я ещё ничего не настраивал, но заметил важную особенность.

root@O2> show ospf database asbrsummary detail

    OSPF database, Area 0.0.0.1

 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len

ASBRSum *10.0.10.4        10.0.10.2        0x8000004b  2033  0x22 0x2b97  28

  mask 0.0.0.0

  Topology default (ID 0) -> Metric: 1

Как видно, О2 генерирует Type 4 ASBR Summary LSA в первую область... Этот тип LSA который отправляется ABRом для того чтобы рассказать другим роутерам про ASBR на сети. 

Почему так? 

Ситуация примерно слудующая. Мы сконфигурировали NSSA, эти изменения увидели все роутеры в backbone зоне. Единственная причина конфигурировать NSSA - располагать ASBR в ней. Роутеры это понимают. Каждый ABR теперь должен передать в другие зоны знания о том, что за роутером 10.0.10.4 в area3 находится выход из OSPF домена (или автономной системы). В нашем случае, О1 не будет ничего отправлять, потому как у него нет выходов в другие области, О3 был бы рад передать, но ему нет смысла, в Tottaly Stub area такие LSA не передаются. А вот О2 есть куда отправить такой LSA, ведь у него есть самая обычная area1. Более подробное объяснение такого поведения можно прочитать в этом посте на packetlife.net.

Не могу не задать себе вопрос, а как О2 понимает, что О4 сконфигурировал NSSA на своем интерйесе? Блин, я так никогда лабу не закончу... Врубаем Promiscuous Mode на vSwitch'е, в который подключены роутеры area 0, врубаем в свитч специально обученую XPшку и расчехляем Wireshark.

Дело в том, что О7 после того как NSSA зона была сконфигурирована, отсылает специальный флаг E в своем Type1 LSA. Это видно на картинке ниже.

Более того, это видно даже в в консоли О7, но, к сожалению, не так очевидно. Мы видим, bits 0x2.

root@O7> show ospf database advertising-router self router detail

    OSPF database, Area 0.0.0.3

 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len

Router  *10.0.10.7        10.0.10.7        0x80000003   985  0x20 0x3de5  84

  bits 0x2, link count 5

...

О4 тоже знает про NSSA, ведь на нем настроен линк в эту зону. Именно поэтому он тоже рассказывает своим соседям в нулевой зоне про то, что у него есть выход в другую AS.В том числе и роутеру О2. Как видно ниже, он говорит про то, что он является ABR и ASBR роутером. Последнее утверждение не совсем корректно, ну да ладно.

Полученый LSA видно в консоли О2 со всеми этимми флагами. bits 0x3.

root@O2> show ospf database area 0 router lsa-id 10.0.10.4 detail

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.4        10.0.10.4        0x80000006   161  0x22 0xd080  72
  bits 0x3, link count 4

О2, получив такой LSA, сгенерирует в первую область LSA Type 3. Но он также отправит LSA Type 4, чтобы рассказать про то, что выход из автономной системы находится за роутером О4. Это мы и видели чуть выше.

root@O2> show ospf database asbrsummary detail

    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
ASBRSum *10.0.10.4        10.0.10.2        0x8000004b  2033  0x22 0x2b97  28

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

Пора уже добавить внешние маршруты. Понятно, что на О7 никаких коннектов к другим автономным сисетмам нет. Поэтому мы просто добавим пачку статических маршрутов и экспортируем их в OSPF. Попробуем так

root@O7# set routing-options static route 172.16.0.0/24 discard
...

root@O7# set routing-options static route 172.16.6.0/24 discard 

Далее создаем полиси (вот где дейтвительно Juniper way...). Пока не будем заморачиваться и экспортнем все статические маршруты.

root@O7# set policy-options policy-statement 172.16_TO_OSPF from protocol static
root@O7# set policy-options policy-statement 172.16_TO_OSPF then accept

Добавляем на экспорт в OSPF

root@O7# set protocols ospf export 172.16_TO_OSPF

Итак, O7 как и ожидалось отправил Type 7 NSSA External LSA.

root@O7> show ospf database nssa

    OSPF database, Area 0.0.0.3
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
NSSA    *172.16.0.0       10.0.10.7        0x80000001   759  0x28 0x8d2a  36
NSSA    *172.16.1.0       10.0.10.7        0x80000001   759  0x28 0x8234  36
NSSA    *172.16.2.0       10.0.10.7        0x80000001   759  0x28 0x773e  36
NSSA    *172.16.3.0       10.0.10.7        0x80000001   759  0x28 0x6c48  36
NSSA    *172.16.4.0       10.0.10.7        0x80000001   759  0x28 0x6152  36
NSSA    *172.16.5.0       10.0.10.7        0x80000001   759  0x28 0x565c  36
NSSA    *172.16.6.0       10.0.10.7        0x80000001   759  0x28 0x4b66  36

О4 получив такую красоту из area3 переконвертировал их в обычный Type5 и отправил в area0

root@04> show ospf database area 0

    OSPF database, Area 0.0.0.0
...
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern  *172.16.0.0       10.0.10.4        0x80000001  1015  0x22 0x16ac  36
Extern  *172.16.1.0       10.0.10.4        0x80000001  1015  0x22 0xbb6   36
Extern  *172.16.2.0       10.0.10.4        0x80000001  1015  0x22 0xffc0  36
Extern  *172.16.3.0       10.0.10.4        0x80000001  1015  0x22 0xf4ca  36
Extern  *172.16.4.0       10.0.10.4        0x80000001  1015  0x22 0xe9d4  36
Extern  *172.16.5.0       10.0.10.4        0x80000001  1015  0x22 0xdede  36
Extern  *172.16.6.0       10.0.10.4        0x80000001  1015  0x22 0xd3e8  36

Как я писал в предыдущем посте, Type 5 LSA передаются по всем зонам. Так, например, О2 получив от О4 внешние префиксы отправит их в area1 с тем же значением Advertised Router. Обратите внимание, ASBR Summary LSA все ещё не месте.

root@O2> show ospf database area 1

    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
ASBRSum *10.0.10.4        10.0.10.2        0x80000001    33  0x22 0xbf4d  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   172.16.0.0       10.0.10.4        0x80000001  1141  0x22 0x16ac  36
Extern   172.16.1.0       10.0.10.4        0x80000001  1141  0x22 0xbb6   36
Extern   172.16.2.0       10.0.10.4        0x80000001  1141  0x22 0xffc0  36
Extern   172.16.3.0       10.0.10.4        0x80000001  1141  0x22 0xf4ca  36
Extern   172.16.4.0       10.0.10.4        0x80000001  1141  0x22 0xe9d4  36
Extern   172.16.5.0       10.0.10.4        0x80000001  1141  0x22 0xdede  36
Extern   172.16.6.0       10.0.10.4        0x80000001  1141  0x22 0xd3e8  36

О8 не должен получить такие маршруты, потому как он находится в stub area. Собственно, так оно и есть.

root@O8> show ospf database

    OSPF database, Area 0.0.0.4
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.5        10.0.10.5        0x80000054   432  0x20 0xaaa9  48
Router  *10.0.10.8        10.0.10.8        0x80000053   804  0x20 0x3993  84
Summary  10.0.10.1        10.0.10.5        0x80000001    33  0x20 0x20d   28
Summary  10.0.10.2        10.0.10.5        0x80000001   464  0x20 0xed21  28
Summary  10.0.10.5        10.0.10.5        0x80000051  2434  0x20 0x2597  28
Summary  10.10.0.0        10.0.10.5        0x80000001    33  0x20 0x20e   28
Summary  10.10.1.0        10.0.10.5        0x80000051   664  0x20 0x3a88  28
Summary  10.11.0.0        10.0.10.5        0x80000001    33  0x20 0xf519  28
Summary  10.11.0.1        10.0.10.5        0x80000001    33  0x20 0xeb22  28
Summary  10.12.0.0        10.0.10.5        0x80000001   464  0x20 0xdf2f  28
Summary  10.12.0.1        10.0.10.5        0x80000001   464  0x20 0xd538  28
Summary  10.15.0.0        10.0.10.5        0x8000001d  2302  0x20 0x7977  28
Summary  10.15.0.1        10.0.10.5        0x8000001d  2037  0x20 0x6f80  28

Ну про О6 и говорить не стоит, у него LSDB ещё скучней.

root@O6> show ospf database

    OSPF database, Area 0.0.0.2
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.3        10.0.10.3        0x8000005a  1356  0x20 0x66f1  48
Router  *10.0.10.6        10.0.10.6        0x80000058  2301  0x20 0xe9ed  84
Summary  0.0.0.0          10.0.10.3        0x80000001   159  0x20 0x91d   28

Осталось настроить аналогичную редистрибуцию на О1.

root@O1# set routing-options static route 192.168.0.0/24 discard

...

root@O1# set routing-options static route 192.168.6.0/24 discard

root@O1# set policy-options policy-statement 192.168_TO_OSPF from protocol static
root@O1# set policy-options policy-statement 192.168_TO_OSPF then accept

root@O1# set protocols ospf export 192.168_TO_OSPF

Как там на О5, например. В целом, все ожидаемо хорошо.

root@O5> show ospf database area 0

    OSPF database, Area 0.0.0.0
...
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   172.16.0.0       10.0.10.4        0x80000004   197  0x22 0x10af  36
Extern   172.16.1.0       10.0.10.4        0x80000004    79  0x22 0x5b9   36
Extern   172.16.2.0       10.0.10.4        0x80000003  1003  0x22 0xfbc2  36
Extern   172.16.3.0       10.0.10.4        0x80000003  1003  0x22 0xf0cc  36
Extern   172.16.4.0       10.0.10.4        0x80000003  1003  0x22 0xe5d6  36
Extern   172.16.5.0       10.0.10.4        0x80000003  1003  0x22 0xdae0  36
Extern   172.16.6.0       10.0.10.4        0x80000003  1003  0x22 0xcfea  36
Extern   192.168.0.0      10.0.10.1        0x80000001   111  0x22 0xa88b  36
Extern   192.168.1.0      10.0.10.1        0x80000001   111  0x22 0x9d95  36
Extern   192.168.2.0      10.0.10.1        0x80000001   111  0x22 0x929f  36
Extern   192.168.3.0      10.0.10.1        0x80000001   111  0x22 0x87a9  36
Extern   192.168.4.0      10.0.10.1        0x80000001   111  0x22 0x7cb3  36
Extern   192.168.5.0      10.0.10.1        0x80000001   111  0x22 0x71bd  36
Extern   192.168.6.0      10.0.10.1        0x80000001   111  0x22 0x66c7  36

Я писал в прошлом посте, про то, что External LSA бывают двух типов

• Type 1 - к анонсируемой стоимости будут добавляться стоимости линков по пути, 

• Type 2 - стоимость добавляться не будет.

В Juniper по умолчанию будет анонсироваться Type 2. 

Если посмотреть метрику на О1, О2 и О5, то она будет одинаковой и равна нулю. Как видно, у Juniper ситуация с метрикой немного иная, нежели чем в Cisco. Об этом позже.

root@O1> show ospf database lsa-id 192.168.0.0 detail | match Type
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
    Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

root@O2> show ospf database lsa-id 192.168.0.0 detail | match Type
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
    Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

root@O5> show ospf database lsa-id 192.168.0.0 detail | match Type
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
    Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

В таблицу маршрутизации будут внесены метрики из LSA. На О5, например, метрика в таблице машрутизации так и останется равной нулю.

root@O5> show ospf route extern network 192.168.0.0
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
192.168.0.0/32     Ext2  Network    IP            0 em2.0         10.10.1.1

Поменяем тип на первый и посмотрим что получиться. К слову, не так-то уж просто это сделать. В циске как-то проще, а вот в Juniper придется изменять policy-statement. Поменяем тип метрики и назначим значение 10 для примера.

policy-options {
    policy-statement 192.168_TO_OSPF {
        from protocol static;
        then {
            metric 10;
            external {
                type 1;
            }
            accept;
        }
    }
}

Далее будем смотреть как поведет себя O2. Видно, что тип метрики сменился, а сама метрика передается от О1 равной 10.

root@O2> show ospf database lsa-id 192.168.0.0 detail
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   192.168.0.0      10.0.10.1        0x80000004  2180  0x22 0x8324  36
  mask 255.255.255.255
  Topology default (ID 0)
    Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

В теории, О2 должен добавить свою стоимость до О1 и добавить такой маршрут в таблицу маршрутизации. Так и есть, О2 добавляет к 10 единицу и добавляет маршрут с метрикой 11 в свою таблиц маршрутизации.

root@O2> show ospf route extern network 192.168.0.0
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
192.168.0.0/32     Ext1  Network    IP            11 em2.0         10.10.0.1

Тоже самое произойдет и на О5, но метрика в таблице машрутизации уже будет равна 12.

root@O5> show ospf route extern network 192.168.0.0

Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop

                   Type  Type       Type            Interface     Address/LSP

192.168.0.0/32     Ext1  Network    IP           12 em2.0         10.10.1.1

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

root@O5> show ospf route extern

Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop

                   Type  Type       Type            Interface     Address/LSP

172.16.0.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

172.16.1.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

172.16.2.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

172.16.3.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

172.16.4.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

172.16.5.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

172.16.6.0/24      Ext2  Network    IP            0 em2.0         10.10.1.1

192.168.0.0/32     Ext1  Network    IP            2 em2.0         10.10.1.1

192.168.1.0/24     Ext1  Network    IP            2 em2.0         10.10.1.1

192.168.2.0/24     Ext1  Network    IP            2 em2.0         10.10.1.1

192.168.3.0/24     Ext1  Network    IP            2 em2.0         10.10.1.1

192.168.4.0/24     Ext1  Network    IP            2 em2.0         10.10.1.1

192.168.5.0/24     Ext1  Network    IP            2 em2.0         10.10.1.1

192.168.6.0/24     Ext1  Network    IP            2 em2.0         10.10.1.1

 

Default route

Из прошлой лабораторки перекочевал маршрут по умолчанию на О1. Давайте и его добавим в процесс. Настраивается добавляение дефолтного маршрута практически так же как и редистрибуция.

Сначала нужно создать этот самый маршрут на роутере. Это мы уже делали раньше. Но теперь мы будет использывать ключ no-install. Машруты с таким ключом не будут установлены в таблицу маршрутизации.

root@O1# set routing-options static route 0.0.0.0/0 discard no-install

Создаем полиси, куда так же добавляем маршрут по умолчанию. Но на этот раз добавляем фильтр, где указываем, что мы хотим пропускать только 0.0.0.0/0  и ничего больше.

root@O1# set policy-options policy-statement DEFAULT_ROUTE from protocol static

root@O1# set policy-options policy-statement DEFAULT_ROUTE from route-filter 0.0.0.0/0 exact

root@O1# set policy-options policy-statement DEFAULT_ROUTE then accept

Ну и крепим такую политику на OSPF процесс на экспорт. То есть, у нас таких политк уже две.

Одной политикой редистрибуцируются внешние маршруты, второй - дефолтный маршрут. 

root@O1# set protocols ospf export DEFAULT_ROUTE

После чего О1 начнет анонсировать дефотлный маршрут в сеть как внешний маршрут со вторым типом.

root@O1> ...abase advertising-router self external lsa-id 0.0.0.0 detail
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern  *0.0.0.0          10.0.10.1        0x80000002    51  0x22 0x5844  36
  mask 0.0.0.0
  Topology default (ID 0)
    Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

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

root@O8> traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  10.10.4.1 (10.10.4.1)  0.319 ms  14.784 ms  7.026 ms
 2  10.10.1.1 (10.10.1.1)  4.121 ms  77.541 ms  0.427 ms
 3  10.10.0.1 (10.10.0.1)  50.893 ms  105.610 ms  25.262 ms
 4  10.10.0.1 (10.10.0.1)  51.201 ms !H  11.853 ms !H  28.309 ms !H

 

Summarization/Filtering

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

Сначала про суммаризацию. Итак, в OSPFе можно настраивать суммаризацию на границах зон. Уже сейчас такая суммаризация настроена в сторону зон 4, 6 и 7. По факту, во вторую зону, например, все префиксы суммируются до 0.0.0.0/0. Но мы про другое. 

Тут стоит опять немного отвлечься. Взглянул я на топологию, и понял, что для адекватного суммирования, надо было делать немного по другому. Но уже поздно, поэтому я добавлю ещё несколько подсетей на О8, чтобы потом их проссумировать.

root@O8# set interfaces lo0 unit 0 family inet address 10.19.0.1/16

Теперь взглянем на то, как видит сети О8, скажем, О1.

root@O1> show ospf database

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Summary  10.18.0.0        10.0.10.5        0x80000005  1334  0x22 0x7191  28
Summary  10.18.0.1        10.0.10.5        0x80000005  1188  0x22 0x679a  28
Summary  10.19.0.0        10.0.10.5        0x80000001    31  0x22 0x6d98  28
Summary  10.19.0.1        10.0.10.5        0x80000001    31  0x22 0x63a1  28

А надо ли О1 знать про то, что 10.18.0.0/16 и 10.19.0.0/16 "сидят" за О5. Конечно нет. Гораздо эффективнее было бы ссумировать эти два префикса до 10.18.0.0/15. Это и сделаем на О5. Помним, что О5 по факту имеет выход к первой зоне через виртуальный линк.

protocols {
    ospf {
...
        }
        area 0.0.0.0 {
            virtual-link neighbor-id 10.0.10.2 transit-area 0.0.0.1;
        }
    }
}

Указываем, что в area 4 находятся адреса, которые можно проссумировать до 10.18.0.0/15.

Я сначала некоторое время букосвал и пытался дать такую команду в area 0, но это был неверный подход.

root@O5# set protocols ospf area 4 area-range 10.18.0.0/15

О1 перестал видеть 4 LSA. Вместо них одна красивая проссумированная LSA с маской 255.254.0.0.

root@O1> show ospf database lsa-id 10.18.0.0 detail

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary  10.18.0.0        10.0.10.5        0x80000008   433  0x22 0x6799  28
  mask 255.254.0.0
  Topology default (ID 0) -> Metric: 1

Ок. Теперь займемся внешними маршрутами. Зачем, скажем, всей сети знать про 7 префиксов 172.16.

root@O1> show ospf database external
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Extern   172.16.0.0       10.0.10.4        0x80000006  1018  0x22 0xcb1   36
Extern   172.16.1.0       10.0.10.4        0x80000006   942  0x22 0x1bb   36
Extern   172.16.2.0       10.0.10.4        0x80000006   866  0x22 0xf5c5  36
Extern   172.16.3.0       10.0.10.4        0x80000006   791  0x22 0xeacf  36
Extern   172.16.4.0       10.0.10.4        0x80000006   715  0x22 0xdfd9  36
Extern   172.16.5.0       10.0.10.4        0x80000006   639  0x22 0xd4e3  36
Extern   172.16.6.0       10.0.10.4        0x80000006   563  0x22 0xc9ed  36
...

Ведь достаточно только знать кому отправлять трафик для их достижения. Как насчет суммаризации и здесь. Суммирование external машрутов немного сложнее. Нужно настроить полиси (surprise!) на О7.

Проссумировать все маршруты на О7 довольно просто. Давайте усложним задачу.

Например, добавим ещё пачку статических маршрутов.

root@O7# set routing-options static route 100.0.0.0/16 discard
root@O7# set routing-options static route 100.1.0.0/16 discard
root@O7# set routing-options static route 100.2.0.0/16 discard
root@O7# set routing-options static route 100.3.0.0/16 discard

Они автоматом проэкспортируются в OSPF процесс. На подопытном О1 их видно.

root@O1> show ospf database external
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Extern   100.0.0.0        10.0.10.4        0x80000001   187  0x22 0x8298  36
Extern   100.1.0.0        10.0.10.4        0x80000001   187  0x22 0x76a3  36
Extern   100.2.0.0        10.0.10.4        0x80000001   187  0x22 0x6aae  36
Extern   100.3.0.0        10.0.10.4        0x80000001   187  0x22 0x5eb9  36
Extern   172.16.0.0       10.0.10.4        0x80000002  1827  0x22 0x14ad  36
Extern   172.16.1.0       10.0.10.4        0x80000005  2057  0x22 0x3ba   36
Extern   172.16.2.0       10.0.10.4        0x80000005  1903  0x22 0xf7c4  36
Extern   172.16.3.0       10.0.10.4        0x80000005  1750  0x22 0xecce  36
Extern   172.16.4.0       10.0.10.4        0x80000005  1673  0x22 0xe1d8  36
Extern   172.16.5.0       10.0.10.4        0x80000005  1596  0x22 0xd6e2  36
Extern   172.16.6.0       10.0.10.4        0x80000005  1519  0x22 0xcbec  36
Extern   172.16.7.0       10.0.10.4        0x80000002  1980  0x22 0xc6f3  36
...

Ок. Мы хотим проссумировать все 172.16. префиксы до 172.16.0.0/21 и оставить как есть все 100ые префиксы.

Первое. Создаем aggregate route.

root@O7# set routing-options aggregate route 172.16.0.0/21

Далее создаю Policy Statement. Однако тут надо ввести ещё один уровень иерархии. Сейчас пропишем наш полиси в первом term'e.

root@O7# set policy-options policy-statement EXTERNAL_SUMMARY term AGGR_TO_OSPF to protocol ospf
root@O7# set policy-options policy-statement EXTERNAL_SUMMARY term AGGR_TO_OSPF then accept

В конфиге это выглядит следующим образом

policy-options {

    policy-statement EXTERNAL_SUMMARY {

        term AGGR_TO_OSPF {

            to protocol ospf;

            then accept;

        }

    }

}

Применяем, смотрим со стороны О1.

root@O7# set protocols ospf export EXTERNAL_SUMMARY

root@O1> show ospf database external
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Extern   100.0.0.0        10.0.10.4        0x80000001   417  0x22 0x8298  36
Extern   100.1.0.0        10.0.10.4        0x80000001   417  0x22 0x76a3  36
Extern   100.2.0.0        10.0.10.4        0x80000001   417  0x22 0x6aae  36
Extern   100.3.0.0        10.0.10.4        0x80000001   417  0x22 0x5eb9  36
Extern   172.16.0.0       10.0.10.4        0x80000002  2057  0x22 0x14ad  36
Extern   172.16.1.0       10.0.10.4        0x80000005  2287  0x22 0x3ba   36
Extern   172.16.2.0       10.0.10.4        0x80000005  2133  0x22 0xf7c4  36
Extern   172.16.3.0       10.0.10.4        0x80000005  1980  0x22 0xecce  36
Extern   172.16.4.0       10.0.10.4        0x80000005  1903  0x22 0xe1d8  36
Extern   172.16.5.0       10.0.10.4        0x80000005  1826  0x22 0xd6e2  36
Extern   172.16.6.0       10.0.10.4        0x80000005  1749  0x22 0xcbec  36
Extern   172.16.7.0       10.0.10.4        0x80000002  2210  0x22 0xc6f3  36
Extern   172.16.7.255     10.0.10.4        0x80000001     5  0x22 0xa51d  36
...

root@O1> show ospf database external lsa-id 172.16.7.255 detail
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   172.16.7.255     10.0.10.4        0x80000001   176  0x22 0xa51d  36
  mask 255.255.248.0
  Topology default (ID 0)
    Type: 2, Metric: 0, Fwd addr: 10.0.10.7, Tag: 0.0.0.0

Видно, что ссумировать получилось. Только вот и другие префиксы, коорые входят в суммарный, тоже приходят. Именно по этой причине, нужно дописать ещё один терм в полиси и отфильтровать их.

Для начала нужно создать prefix-list, в котором описать те префиксы, которые мы будем обрабатывать.

root@O7# set policy-options prefix-list DROP_UNSUMMARY 172.16.0.0/24

...

root@O7# set policy-options prefix-list DROP_UNSUMMARY 172.16.6.0/24

policy-options {
    prefix-list DROP_UNSUMMARY {
        172.16.0.0/24;
        172.16.1.0/24;
        172.16.2.0/24;
        172.16.3.0/24;
        172.16.4.0/24;
        172.16.5.0/24;
        172.16.6.0/24;
        172.16.7.0/24;
    }

Затем создаем ещё одинм term в уже созданном policy-statement EXTERNAL_SUMMARY

root@O7# set policy-options policy-statement EXTERNAL_SUMMARY term DROP_UNSUM from prefix-list DROP_UNSUMMARY
root@O7# set policy-options policy-statement EXTERNAL_SUMMARY term DROP_UNSUM then reject

Смотрим на итоговый policy-statement.

policy-statement EXTERNAL_SUMMARY {
        term AGGR_TO_OSPF {
            to protocol ospf;
            then accept;
        }
        term DROP_UNSUM {
            from {
                prefix-list DROP_UNSUMMARY;
            }
            then reject;
        }

Выглядит неплохо, однако в таком случае, ситуация не поменяется. Сработает первое правило, до второго дело просто не дойдет. Меняем порядок правил.

root@O7# insert policy-options policy-statement EXTERNAL_SUMMARY term DROP_UNSUM before term AGGR_TO_OSPF

Проверяем на О1.

root@O1> show ospf database external
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Extern   100.0.0.0        10.0.10.4        0x80000001   885  0x22 0x8298  36
Extern   100.1.0.0        10.0.10.4        0x80000001   885  0x22 0x76a3  36
Extern   100.2.0.0        10.0.10.4        0x80000001   885  0x22 0x6aae  36
Extern   100.3.0.0        10.0.10.4        0x80000001   885  0x22 0x5eb9  36
Extern   172.16.0.0       10.0.10.4        0x80000002  2525  0x22 0x14ad  36
Extern   172.16.1.0       10.0.10.4        0x80000005  2755  0x22 0x3ba   36
Extern   172.16.2.0       10.0.10.4        0x80000005  2601  0x22 0xf7c4  36
Extern   172.16.3.0       10.0.10.4        0x80000005  2448  0x22 0xecce  36
Extern   172.16.4.0       10.0.10.4        0x80000005  2371  0x22 0xe1d8  36
Extern   172.16.5.0       10.0.10.4        0x80000005  2294  0x22 0xd6e2  36
Extern   172.16.6.0       10.0.10.4        0x80000005  2217  0x22 0xcbec  36
Extern   172.16.7.0       10.0.10.4        0x80000002  2678  0x22 0xc6f3  36
Extern   172.16.7.255     10.0.10.4        0x80000001   473  0x22 0xa51d  36
...

Ничего не поменялось... Если кратко, то мы двумя разными политиками инжектим сначала /24 роуты, а потом ещё и суммарный.

protocols {
    ospf {
        export [ 172.16_TO_OSPF EXTERNAL_SUMMARY ];
        area 0.0.0.3 {
            nssa;
            interface em2.0 {
                interface-type p2p;
            }
            interface lo0.0;
        }
    }
}

Уберем 172.16_TO_OSPF с экспорта и все должно стать хорошо.

root@O7# delete protocols ospf export 172.16_TO_OSPF

root@O1> show ospf database external
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
...
Extern   100.0.0.0        10.0.10.4        0x80000001  1435  0x22 0x8298  36
Extern   100.1.0.0        10.0.10.4        0x80000001  1435  0x22 0x76a3  36
Extern   100.2.0.0        10.0.10.4        0x80000001  1435  0x22 0x6aae  36
Extern   100.3.0.0        10.0.10.4        0x80000001  1435  0x22 0x5eb9  36
Extern   172.16.0.0       10.0.10.4        0x80000003   386  0x22 0xc4f4  36
...

root@O1> show ospf database external lsa-id 172.16.0.0 detail
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   172.16.0.0       10.0.10.4        0x80000003   500  0x22 0xeed8  36
  mask 255.255.248.0
  Topology default (ID 0)
    Type: 2, Metric: 0, Fwd addr: 10.0.10.7, Tag: 0.0.0.0

Про то как обрабатываются полиси у Juniper написано здесь, здесь и здесь.

Metric (cost)

Во всех примерах видно, что Juniper использует несколько другой подход к расчету стоимости, и он отличается от Cisco.

По дефолту в Juniper:

Metric = 0 ставится на все looppack интерфейсы

Metric = 1 имею все интерфейсы, быстрее чем 100Mbps. 

Все верно, в таком случае, все интерфейсы от 100 и выше получат одинаковую метрику. 100G и 1G будут иметь одинаковую метрику. Получается прям как IS-IS.

В некоторых ситуациях это недопустимо. Выхода два:

1. Назначать метрики руками

2. Указать reference-bandwidth, что включит похожее на Cisco поведение.

Второй вариант интереснее, его и включим. Будем смотреть в лицо 100G реальности и укажем reference-bandwith равный 100g. Таким образом,получим примерно следующую картину по Metric'ам.
100G - 1
40G - 3 (округляется до большего от 2,5)
10G - 10
1G - 100
100M - 1000
10M - 10000

Производить манипуляции будем на О1. Смотрим, как чейчас выглядит информация по маршрутам. Видно, что добраться до соседа по области стоит 1 "попугай".

root@O1> show ospf route 10.0.10.2
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
10.0.10.2          Intra Area BR    IP            1 em2.0         10.10.0.2
10.0.10.2/32       Intra Network    IP            1 em2.0         10.10.0.2

Видно также что О2 передает метрику равной нулю, а О2 добавялет к ней единицу. Получается такой hop-count принцип.

root@O1> show ospf database lsa-id 10.0.10.2 router detail

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   10.0.10.2        10.0.10.2        0x80000019   778  0x22 0xd03d  84
  bits 0x1, link count 5
...
  id 10.0.10.2, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0

Устанавливаем reference-bandwith в 100G.

root@O1# set protocols ospf reference-bandwidth 100g

О2 все так же шлет нам нолик, на нем же reference-bandwidth не настроен. Но вот О1 ведет себя уже по другому. Когда он запускает SPF алгоритм, он смотрит на bandwidth на порту в сторону О2 и видит там 1000mbps.

root@O1> show interfaces em2 | match speed
  Type: Ethernet, Link-level type: Ethernet, MTU: 2000, Speed: 1000mbps

Далее он калькулирует метрику по простой формуле reference-bandwidth/configured-bandwidth. В нашем случае 100G/1G = 100. Проверяем.

root@O1> show ospf route 10.0.10.2
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
10.0.10.2          Intra Area BR    IP          100 em2.0         10.10.0.2
10.0.10.2/32       Intra Network    IP          100 em2.0         10.10.0.2

Заключение

Пожалуй, здесь стоит закончить этот пост. Конечно, многое осталось за кадром. Пишу это в каждом своем посте, но как иначе?..

Получилось довольно хардкорно и не очень ориентировано на читателя. В посте много текста и вывода и не так уж много картинок. К сожелению, часто просто не хватает времени даже толком вычитать текст, не говоря уж про рисование картинок.

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

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

Если у вас есть мысли по поводу статьи, можно оставлять их в комментариях.

Хочу поблагодарить тех, кто дочитал до конца. )