Типы LSA в OSPFv2 (часть 2)

Закончили мы с вами вчера на формате LSA, на том, что LSA у нас есть разных типов. Эти LSA распространяются в некоторой области. LSA первого, второго, третьего, четвёртого типов распространяются в пределах региона. LSA пятёрка распространяется во всей автономной системе. В LSA первого и второго типов у нас содержится топологическая информация, кто на кого каким интерфейсом смотрит. Первая LSA, LSA типа 1, нужна для того, чтобы каждый роутер про себя мог рассказать что-то. LSA второго типа нужна для того, чтобы не все роутеры дружили по схеме каждый на каждого в средах с множественным доступом, типа Ethernet. LSA третьего типа нужна для того, чтобы передавать маршрутную информацию между регионами. И поэтому она фактически будет нести в себе информацию в таком дистанц-векторном стиле. Роутер анонсирует некоторую сеть, которая известна за его спиной. Он показывает суммарную стоимость, поэтому LSA-ка трёшка называется summary LSA.

И каждый роутер может построить кратчайший маршрут до того, кто такую LSA-ку придумал, то есть до ABR-а. И дальше сложить стоимость, какая получилась до ABR-а, с тем, что было анонсировано в LSA-ке трёшке, и получить стоимость до удалённой сети. Дальше LSA-ка пятёрка будет содержать в себе внешнюю маршрутную информацию, которая была импортирована в OSPF из каких-то других маршрутных источников. Например, из EIGRP, или из Connected, или из Static, или из BGP. И LSA-ка четвёрка будет нужна для того, чтобы понять узлам, как добраться до того, кто придумал эту внешнюю адресную информацию, до ASBR-а. Когда мы говорим про LSA-ки первого типа, они будут содержать в себе информацию о том, кто на наш роутер смотрит и какие IP-сети подключены непосредственно к нашему роутеру. Эта LSA-ка будет называться Router LSA. У неё есть определённый формат.

Не надо запоминать, какой формат у этой LSA-ки будет. Я просто вам здесь показываю его справочно для того, чтобы вы понимали, что в этой LSA-ке может быть и чего в этой LSA-ке быть не может. Для того, чтобы у вас потом картинка в голове сложилась, что именно там лежит, что за мясо там будет передаваться. LSA-ка будет выровнена по границе 4-х байт, традиционно для протоколов стека интернета. И первый байт будет с флагами. Это поле флагов. Там из интересующих флагов будет интересовать нас флаг E. Это значит, что роутер импортирует в OSPF какие-то внешние маршруты. Если этот флаг выставлен в единичку, то роутер говорит: я не просто роутер, я не просто вижу такими интерфейсами таких соседей. Я ещё и какие-то внешние маршруты вбрасываю в OSPF. И буковка B означает, что роутер является ABR-ом, что у него есть какие-то интерфейсы, которые смотрят в другие регионы. Когда у нас есть роутер в нашем регионе, мы можем построить кратчайший маршрут до каждого из этих роутеров.

И плюс к тому мы можем сказать, что некоторые роутеры вбрасывают какие-то дополнительные маршруты. B будет означать, что роутер вбрасывает LSA-ки трёшки. E будет означать, что роутер вбрасывает LSA-ки пятёрки. Это, конечно, информация слегка лишняя. Можно было бы и без неё обойтись. Но на всякий случай решили сделать. Дальше ещё один байт с резервированными флагами. Они все пока нулевые. Потом когда-нибудь, может быть, придумают что-то, для чего это поле может пригодиться. Но пока что там нули. Потом указывается number of links. Это количество интерфейсов, которыми роутер на что-то смотрит. Либо на соседей, либо на какие-то сетки с пользователями. У нас есть интерфейсы, мы этими интерфейсами на роутере смотрим в разные стороны. Здесь показывается, сколько у нас тех интерфейсов, про которые OSPF хотел бы рассказать своим соседям. И дальше это первые 4 байта, такой заголовок. Дальше идёт само мясо.

Идёт рассказ про каждый из интерфейсов, который у нас есть. Показывается link ID — это просто номер. Показывается какое-то содержимое. Про содержимое сейчас отдельно расскажу. Тип link может быть одним из четырёх значений. Первая — единичка. Это просто обычный сосед. Мы рассказываем, что нас зовут, допустим, роутер R1. И у нас есть интерфейс, которым мы смотрим на роутер R2. Этого соседа мы должны будем найти в базе. Найти его LSA-ку первого типа. И говорим, что у нас есть прямое соседство с какой-то соседней LSA-кой. При сборке пазла надо просто найти LSA-ку первого типа, соответствующую тому, что там будет написано. Единичка — это самое простое соседство. Соседство point-to-point. Если у нас двоечка, значит то же самое — соседство есть, но это соседство фактически с LSA-кой двойкой. Когда у нас роутер говорит, у меня есть соседство второго типа, линк второго типа, это значит, что нам нужно найти LSA-ку двойку.

LSA-ку двойку, в которой будет указано, какие ещё соседи в этом канале есть. Когда у нас есть общая среда передачи данных, например, Ethernet, мы дружим с LSA-кой второго типа, а LSA-ка второго типа дружит уже со всеми остальными роутерами в этом канале. Фактически это означает, что мы дружим со всеми роутерами, которые к LSA-ке двойке подключены. Поэтому надо найти при сборке пазла эту LSA-ку второго типа и дальше посмотреть, на кого она будет соседними интерфейсами смотреть. Если у нас есть пользовательская сетка, здесь есть Network A, где есть пользователи, то на этом интерфейсе никаких соседств нет, но на этом интерфейсе есть Connected-адреса. И, например, 10.0.0.0/24 сетка есть. Мы про неё хотим рассказать, что к нашему интерфейсу эта сеть подключена. В этом случае LinkType будет 3. И четвёртое — Virtual Link — это способ среплицировать базу нулевого региона.

Мы про неё будем говорить потом отдельно, но это фактически такой виртуальный интерфейс, который будет протягиваться между роутерами, которые напрямую друг с другом не соединены. Такой виртуальный псевдопровод, которым можно подружиться по нулевому региону. Если у вас LinkType первого типа, то вы в LinkData указываете, с кем вы будете дружить. Просто LSA-ID соседа. И двойка — то же самое. LinkStateID той LSA-ки, которая будет соседней при сборке пазла. Если у вас LinkType будет стоять 3, то есть вы интерфейсом смотрите на какую-то Connected-сетку, то в LinkData вы указываете свой IP-шник. И дальше показывается поле «число TOS». Это количество возможных вариантов метрики для этого интерфейса. Потому что в OSPF, так же как в IGRP, когда-то была гениальная идея сделать различные таблицы маршрутизации для различных типов трафика.

И для типа трафика, допустим, обычного можно было сделать одну таблицу. Для типа трафика какого-то необычного, например, голосового, можно было сделать другую таблицу. И вы могли указать, что у вас соседство с роутером есть, и в этом соседстве по-разному должны будут оцениваться интерфейсы для разного типа трафика. Например, можно было сказать, что голосовой трафик через этот интерфейс пропускать желательно, а какой-то другой трафик нежелательно. По факту это всё не взлетело, поэтому обычно здесь количество возможных вариантов метрики будет единичка, что вы только одну топологию указываете, и дальше вы указываете: метрика на этом интерфейсе, которым мы смотрим либо на соседа, либо напрямую на пользовательскую сетку, будет, например, 10 копеек. Если у нас обнаружен роутер с ID-шником 1.1.1.1, и у нас есть LSA второго типа, в которой есть роутер R2 с ID-шником 2.2.2.2. Здесь будет какой-то, допустим, 192.168.1.1 — ID-шник LSA второго типа.

В этом случае мы указываем, что у нас link type будет 2, link ID — 192.168.1.1. И в link data — какая-то информация, которая относится именно к конкретной LSA. Если у нас есть LSA первого типа, и в ней соседство первого и второго типов, это значит, что у нас есть соседние роутеры, и с этими соседними роутерами мы как-то заблаговременно подружились. Четыре разных типа соседства, которые могут быть установлены в LSA первого типа. Что мы рассказываем внутри LSA первого типа? Что либо у нас есть роутер, который смотрит напрямую прямым проводом на другой соседний роутер, у нас установлено point-to-point соседство, либо у нас есть наш роутер, который смотрит на LSA второго типа, а она смотрит на какие-то другие роутеры.

В ней перечислено, какие соседства есть, и всё это один и тот же широковещательный канал, одна и та же multi-access среда. Если у нас link state type 1, это прямое соседство. Если у нас link state type 2, значит, мы находим LSA 2 и с ней уже указываем, кто на этом интерфейсе у нас будет соседями. Такое соседство через LSA 2 будет называться транзитная сеть. Если у нас есть пользователи, к этим пользователям подключен какой-то IP-шник, 10.0.0.0/24, например, сетка у нас есть, то такая штука будет называться Stub Network. Это тип трёшка, тип соседства трёшка. И четвёртый — Virtual Link, про который дальше будет идти речь. Это способ организовать виртуальный интерфейс, который будет относиться к нулевому региону, который протягивается между роутерами, не принадлежащими к нулевому региону. Например, у нас есть два роутера, первый и второй. Здесь у нас есть один кусок нуля, и здесь есть другой кусок нуля.

Разрывный ноль делать плохо, потому что маршруты, которые между нулём и не нулём будут перекладываться в виде LSA 3, они не будут распространяться по всей сети. Здесь у нас зародилась какая-то сеть Network A, к примеру. Какой-то роутер, который её придумал, делает LSA 1 типа. Маршрут про сетку A перекладывается в нулевой регион в виде LSA 3. Всё, что зародилось в нуле в виде LSA 1 типа, во все остальные регионы анонсируется в LSA 3. Но потом другой роутер, который будет видеть эту LSA 3, он эту LSA 3 обратно в ноль, в свой экземпляр нуля, перекладывать уже не будет. Поэтому для того, чтобы среплицировать таблицы топологии нулевого региона, у нас образуется такой псевдопровод. По этому псевдопроводу LSA 1 типа перекладывается в базу нулевого региона, и здесь у нас LSA 1 типа за сетку A будет присутствовать. Это оригинальная LSA, которая была в другом разрывном куске нуля.

Дальше трафик по факту, конечно же, будет ходить через настоящие линки, относящиеся к первому региону, но, по крайней мере, таблицы среплицированы будут в любом случае. Про virtual link ещё раз расскажу, когда будем говорить чуть подробнее. Сейчас это просто общая концепция, которая нужна для того, чтобы показать, зачем это всё и как оно выглядит. Внутри LSA 1 типа у нас есть 4 вида интерфейсов. Интерфейс, который смотрит напрямую на соседний роутер, интерфейс, который смотрит, условно говоря, на свитч, в котором есть, возможно, несколько других роутеров, интерфейс, который смотрит на пользователей, и воображаемый интерфейс, который смотрит на другой ABR. Оба роутера, если у них есть virtual link, они по определению ABR-ы, потому что у них есть интерфейсы в нуле, и у них есть база нулевого региона, которую надо среплицировать с другим, и есть интерфейсы вне нуля, и надо среплицировать с другим роутером, который вне нуля находится, базу нулевого региона. Поэтому оба роутера будут по определению ABR-ами, и для того, чтобы на ABR-ах среплицировать таблицу LSDB нулевого региона, как раз виртуальный псевдоинтерфейс virtual link будет использоваться.

Если мы будем передавать network LSA, то здесь будет всё очень просто. Формат у неё примитивно простой. Сначала показывается 4-байтовое поле network mask, и потом показываются ID-шники тех роутеров, которые у нас подключены. Опять же, в ситуации, когда роутер первый смотрит на LSA-ку второго типа с ID-шником, например, 192.168.1.1. У этой LSA-ки есть ID-шник, и это фактически IP-шник DR-а. И для того, чтобы понять, какая маска у всех роутеров, которые подключены к этой LSA-ке, у нас показывается отдельно маска и показывается attached router's ID. Если у нас здесь был 1.1.1.1, потом 2.2.2.2, 3.3.3.3 и так далее. Все роутеры, которые к этой LSA-ке двойке подключены: R2, R3, R4.

IP-шники на этих интерфейсах видны из LSA-ки первого типа. В LSA-ке первого типа IP-шники показываются. Забыл сказать, где у нас здесь. Здесь link ID — это идентификатор LSA-ки, а link data — это IP-шник, который у нас на этом интерфейсе висит. Так что IP-шники берутся из LSA-ки первого типа, а маска берётся из LSA-ки второго типа. Когда другой DR, если вдруг основной DR дохнет, BDR становится DR-ом. Когда BDR будет видеть, что основной DR сдох, фактически содержимое LSA-ки, которое он будет выпускать, не изменится от того, что основной DR дохнет. Поэтому переключение между DR-ами происходит безболезненно. Дальше. У такой LSA-ки ID-шник — это будет IP-шник того, кто её придумал, IP-шник DR-а. И advertising router ID — это будет router ID DR-а.

Далее. Давайте попробуем посмотреть на LSA-ки первого и второго типов в роутерах. Я сейчас возьму и покажу просто экран настоящей циски и покажу, как эти LSA-ки выглядят. И заодно в Wireshark-е посмотрим, как они передаются. Мы, несмотря на то, что не делали лабу на OSPF, сейчас я тогда быстренько подниму между двумя роутерами OSPF и посмотрим, как оно работает. Я поднял OSPF на паре роутеров, они подружились между собой. И сейчас я буду вам показывать, как выглядят LSA-ки первого типа. Просто чтобы сказать, что я сделал: я поднял OSPF командой network 0.0.0.0 255.255.255.255 area 0. Я включил в OSPF нулевой регион все интерфейсы на роутерах R1 и R2. Естественно, что у нас только один единственный нулевой регион. Естественно, что в этом регионе у нас всего два роутера. Поэтому я ожидаю, что у нас будет LSA-ка первого типа, выпущена каждым роутером R1 и R2. Более того, я ожидаю, что у нас будет LSA-ка второго типа, связывающая эти два роутера, потому что связаны они по Ethernet, а Ethernet — это multi-access среда.

А в multi-access среде у нас возможен множественный доступ. Поэтому я ожидаю, что у нас действительно в OSPF заведётся две роутерные LSA-ки первого типа и одна LSA-ка второго типа. И я не ожидаю, что у нас на этих роутерах будут какие-то другие LSA-ки. Поэтому проверяю. Show IP OSPF database. Да, всё как и ожидалось. Две LSA-ки первого типа и одна LSA-ка второго типа. Если мы захотим собрать пазл из этих трёх LSA-ек, то сделать это будет довольно просто. Первую LSA-ку я могу попросить показать ту, которая была выпущена моим роутером. Это тип LSA-ки, LSA-ка первого типа. Self-originate. Та самая LSA-ка, которую выпустил мой роутер. И вот у неё содержимое. Это LSA-ка первого типа, выпущенная в нулевом регионе. Моим собственным роутером — я это знаю, потому что заказывал отображение LSA-ки, выпущенной моим роутером. Придумал её роутер с ID-шником 10.15.2.2.

И придумал он её про себя. LinkStateID — про что рассказывает роутер 10.15.2.2. Оба этих пункта — это ID-шники того роутера, который её придумал. Дальше. Number of links. Мы видели, что действительно такое поле есть. И показывается содержимое мяса каждой LSA-ки. LinkID — если у нас пользовательская сетка, Stub Network, значит, мы в эту сетку смотрим интерфейсом. У нас на ней висит IP-шник. Показывается LinkID — это идентификатор того, куда мы смотрим, на какую сетку мы смотрим. Здесь показывается IP-шник, который висит у нас на интерфейсе. Я почему-то догадываюсь, что это IP-шник loopback. И я почему-то догадываюсь, что да, действительно, на loopback у нас никаких соседств нет. И действительно, если у нас OSPF включён на loopback, соседств там нет. IP-шник там есть. Поэтому роутер говорит: я по OSPF вижу интерфейс. На этом интерфейсе есть пользовательская сетка.

Там могут быть пользователи. Но пока что там никаких других сущностей, кроме пользователей, не образовалось. И он говорит, что у меня есть IP-шник 10.15.2.2. Он это указывает в LinkID. В LinkData указывается маска 255.255.255.255. Это именно для пользовательских сетей характерно, что в LinkID указывается IP-шник, в LinkData указывается маска. И дальше указывается, что у нас метрика всего одна. Мультитопологии, ID метрик нет. И метрика будет единичка. Для Type of Service 0 у нас метрика 1. Это интерфейс, который стоит 1 копейку. Дальше второй блок рассказывает тоже про пользовательскую сетку. Интерфейс имеет IP-шник 10.2.15.0. И маска там 255.255.255.0. Это уже явно не loopback. Это уже явно какой-то другой интерфейс. Судя по всему, интерфейс между моим R2 и каким-то центральным роутером.

Поскольку на центральном Core 2 OSPF не включён, то мы говорим: да, у нас интерфейс есть, IP-шник на нём есть. Множественный доступ на нём может быть. Соседей, правда, не образовалось, но тем не менее. Поэтому пока что это Stub Network. И показывается, что мультитопологии метрики мы не используем, MTID. Поэтому метрика у нас всего одна, относящаяся к Type of Service 0. И у неё будет метрика 10. Для OSPF от Cisco это характерное значение 10 для 100-мегабитных интерфейсов. Абсолютно аналогично ещё один интерфейс 10.15.24.0/24 — IP-шник сети и маска. Абсолютно аналогично эта сетка 10.15.14.0/24 — IP-шник сети и маска. И тоже всё с метрикой 10. И вот последний пункт. Link connected to a transit network. Transit network означает, что мы смотрим на LSA второго типа.

Это LSA первого типа. Всё это — рассказ про LSA первого типа, который придумал роутер сам про себя. И он говорит: я вижу в качестве соседства LSA второго типа. Эта LSA будет иметь ID-шник 10.15.2.2. И у неё будет указано, кто ещё в этом интерфейсе присутствует, с кем по факту у нас одновременно со всеми будет устанавливаться соседство. Также показывается метрика. И что интересно, показывается IP-шник наш на интерфейсе. В link data указывается router interface address. Это наш собственный IP-шник. Вот это IP-шник, здесь написано адрес. А вот это — IP-шник DR. Но IP-шник DR на самом деле он просто случайно совпадает. Более правильно сказать, что это ID-шник LSA второго типа, у которого ID-шник совпадает с IP-шником DR. Для того, чтобы понять, кто еще в этом интерфейсе есть,

мы должны будем заказать отображение LSA второго типа. Network. У нас здесь просто, у нас здесь LSA всего одна. Но если бы мы вдруг захотели отобразить именно конкретную LSA, мы бы сказали ID-шник той LSA. И вот здесь показывается, что есть у нас действительно LSA второго типа, к которой подключен роутер с ID-шником 1015.22 и с ID-шником 1015.11. То есть роутер наш смотрит на LSA второго типа, и к этой LSA второго типа подключен еще другой роутер. Маска сети 24. И исходя из того, что у нас есть вот эта 24 маска, и исходя из того, что в LSA первого типа указаны IP-шники, соответственно, мы можем сказать, что вот 1015.12.0 – это сетка, которая доступна за вот LSA второго типа. Все роутеры в этой сети будут присутствовать. У одного из роутеров IP-шник 1015.12.2, у другого, ну, наверное, там какой-то еще. Мы сейчас это узнаем.

Опять же, мы заказываем роутерную LSA-ку за тот следующий роутер, который в цепочке должен быть. Вот его ID-шник 1015.11. И здесь показывается про тот самый второй роутер, который действительно подключен к этой же LSA-ке с таким же ID-шником, и вот его IP-шник будет 1015.12.1. У него тоже метрика 10 копеек. Вот. Ну и пачка, да, стаб-нетворков. То есть у него есть какие-то интерфейсы. На этих интерфейсах включился OSPF, но соседей не обнаружен. Вот. Если бы вдруг у нас эти роутеры дружили между собой на Point-to-Point канале, ну, например, по PPP, или, например, по туннелю какому-то, ГРЭшному, обычному, не до-MVPN-овскому, или, наконец, если бы администратор взял и поменял свойства вот этого Ethernet-линка, к которым соединены роутеры, на то, что в этом линке не могут образоваться другие пользователи. Давайте я сейчас так и сделаю. Я зайду на наши роутеры. Enable.

Interface E0.112 IP, OSPF, Network Type, Point-to-Point. Так, соответственно, сейчас развалилось. IP, OSPF, Network Point-to-Point. Вот. Я с двух сторон поменял свойства интерфейса, сказал, что OSPF должен трактовать это как Point-to-Point link, например, как PPP-шный канал или как что-то еще. То есть канал, в котором невозможен множественный доступ. И, соответственно, вот это приведет сейчас к тому, что LSA-ки первого типа у нас будут немножко другие. И вместо Transit Network показывается, что вот у нас связь с одним единственным роутером. В предыдущей версии этой LSA-ки роутер рассказывал, что он видит сетку с множественным доступом,

например, Ethernet, в которой может быть больше двух участников. Поэтому выпускает DR LSA-ки второго типа и говорит, к этой LSA-ки второго типа, к этому, условно говоря, каналу, к этому свечу подключено два роутера. Сейчас мы говорим, что у нас, если есть Point-to-Point link, то в этом Point-to-Point link не может быть множественного доступа. Поэтому если кто-то обнаружен, то это вот единственный, кто в этом канале может быть обнаружен вообще. Поэтому сейчас у нас LSA-ки второго типа больше нету. Два роутера смотрят друг на друга напрямую. Вот этот вот роутер R1 говорит, что я вижу сразу ID-шник 10.15.2.2. Ну и показывается IP-шник того интерфейса, которым мы смотрим на соседа. Если я сейчас захочу посмотреть свою собственную LSA-ку, то здесь будет то же самое, что у нас есть интерфейс, который смотрит напрямую на ID-шник 10.15.1.1 без промежуточных транзитных LSA-ки второго типа. Я сейчас сделал упрощение топологии. Сказал, что на интерфейсе Ethernet между двумя роутерами LSA-ка второго типа нам не нужна.

И действительно, если у вас всего два роутера, LSA-ка второго типа нам только усложняет ситуацию. Она не нужна, она усложняет сборку пазла и никакой пользы не приносит. Если у вас прямым патч-кордом Ethernet-овским соединены два роутера, да, по умолчанию роутеры не знают, что это прямой патч-корд. Они думают, что это может быть там в разрыве где-то есть свитч, хаб, что-то еще. К этому свитчу хабу потом может кто-то дополнительно подключиться. Но если вы им поможете, скажете, что, ребят, это прямой патч-корд, не переживайте, там никто больше не образуется, то роутеры могут избавиться от LSA-ки второго типа и упростить себе сборку пазла, ускорить сборку топологии, ускорить подсчет кратчайшего пути между двумя узлами. И, соответственно, сейчас у нас в таблице будет только две LSA-ки первого типа и уже не будет LSA-ки второго типа. То есть вот ShowIP OSPF Database показывает, что две LSA-ки первого типа есть, а LSA-ка второго типа пропала. Так, это что касалось LSA первого и второго типов.

Они содержат в себе топологическую информацию, кто на кого как смотрит. Плюс в OSPF второй версии LSA-ки и первого, и второго типов содержат в себе также и адресную информацию. Показывают, какие IP-шники висят на тех интерфейсах, которыми мы на что смотрим. Вот. В OSPF и третьей версии, я немножко забегу вперед, от этой порочной практики постарались отойти и разделили в LSA-ках. Отдельно сделали топологическую информацию, то есть какие у нас есть интерфейсы, и отдельно разнесли адресную информацию, какие на этих интерфейсах у нас висят IP-шники. И поэтому там появились отдельные типы LSA-ек, вот именно для того, чтобы разделить топологическую и адресную информацию между собой. В OSPF второй версии это все вперемешку хранится, и именно поэтому на самом деле OSPF второй версии в принципе не адаптирован для IPv6. Его просто некуда там впихнуть, это IPv6. Дальше.

По поводу summary LSA. Здесь немножко забавно, что третьи и четвертые LSA-ки, они на самом деле рассказывают про одно и то же. Как за спиной у АБРа добраться до кое-чего. В таком дистанц-векторном стиле рассказывается про нечто. И вот это вот нечто в случае с LSA-кой третьего типа рассказывает про сетку, которая доступна за спиной АБРа, а в случае с LSA-кой четверкой рассказывается про ID-шник АСБРа. Но в любом случае, что сетка, что ID-шник, они 4-байтовые, 32-битные в случае с IPv4. Поэтому в формате LSA-ки что трешки, что четверки будет все очень просто и предсказуемо. Сначала рассказывается про Network Mask и у каждой LSA-ки есть еще дополнительный заголовок, который одинаковый для всех LSA-ек. И там есть ID-шник у каждой LSA-ки. Так вот, если мы рассказываем про LSA-ку трешку, то ID-шник LSA-ки трешки будет совпадать с IP-адресом, то есть сети, про которое мы рассказываем.

Мы выпускаем LSA-ку трешку с LSA-ID 10.0.0.0. И вот значит, что это LSA-ка трешка рассказывает про сетку 10.0.0.0. Дальше, внутри самого мяса LSA-ки трешки есть вот этот вот Network Mask, в котором мы говорим, что это не просто 10.0.0.0 классовая сетка, а там 255.255.255.0. Вот, и метрика. С какой метрикой роутер знает эту сетку? Хорошо видно, что метрики для интерфейсов, из которых состоит общая стоимость пути, в случае с LSA-кой первого и второго типов, будут... Давайте вернусь немножко назад. Вот, они будут двухбайтовые, 16-битовые. И максимальная метрика на интерфейсе, которая в SPF может быть, она может быть 65536. А в случае с summary LSA метрика будет трехбайтовая.

Поэтому метрики для суммарных маршрутов, они, соответственно, будут до 16 миллионов включительно. Что, конечно, заметно больше, чем, например, в RIP, где метрика может быть максимум 15. Четырехбайтовая. Так, далее. Что еще из интересного тут можно рассказать? Да, если у нас LSA-ка четверка, то в ID-шнике будет ID-шник роутера ASBR, про который LSA-ка четверка рассказывает. И Network Mask будет нули. То есть для ASBR нет смысла рассказывать про какую-то там маску. Вот. Каждую LSA-ку кто-то придумывает. И в случае с роутерными LSA-ками, роутер каждый придумывает такую сетку сам про себя. В случае с Network LSA-кой, LSA-ку придумывает DR, и он там указывает свой роутер ID. В случае с summary LSA, что с LSA-ка трешка, что с LSA-ка четверка.

Кто придумывает эту LSA-ку, это ABR. И вот он рассказывает, что я ABR, я знаю, как добраться до кое-чего, и вы тоже через меня можете добраться. Опять же, может быть такое, что у вас будет несколько разных секций и метрик для разных типов сервис, но исключительно маловероятно, что вы с этим будете встречаться в реальном мире. То есть даже в случае с подготовкой к CCI, про это никто особо не заикается. Потому что количество сценариев, когда это в реальности использовано, ну оно примерно нулевое. Да, технологии кое-какие закладывались под то, что у нас может быть несколько разных топологий для разного типа трафика. По факту индустрия решила, что это очень сложно. Если вдруг мы хотим разные типы трафика совсем по-разному обрабатывать, это лучше сделать VRF. Так, давайте попробуем вбросить что-нибудь в OSPF второй версии, посмотреть, про что мы можем рассказать. Так, у нас есть роутер 2, и я сейчас возьму и поражу какую-нибудь сетку

для того, чтобы можно было у нас на всякие трешки увидеть. Я сейчас возьму, зайду на интерфейс, лобду окно и скажу IPOSPF1, Area 1. То есть я сделал из моего роутера АБР. У меня есть несколько интерфейсов, смотрящих в разные регионы. Еще IPOSPF Database теперь будет показывать, что у нас есть много-много-много всякого. У нас в нулевом регионе есть 2 LSA первого типа, и кроме того появилась одна LSA второго типа, то есть та самая, которая показывает, какая сетка подключена к лоббеку, потому что в первом регионе у нас один-единственный маршрут, тот самый, который коннектен на лоббеке. И кроме того, каждый роутер знает базу всех регионов, которые к нему подключены. В нашем случае роутер и нулевой регион знает, вот базу нулевого региона, и базу первого региона он тоже знает.

А в первом регионе у нас, соответственно, один роутер, вот этот вот LSA первого типа, за сам роутер 2. И вот все-все-все сетки, которые в таблице топологии были известны в нулевом регионе, роутер перекладывает в первый регион в виде LSA первого типа. Давайте я закажу вот этот вот сам link state с вот таким вот ID-шником. Это ID-шник, соответствующий IP-шнику лоббека. Меня интересует show IPv database. Здесь пропал стаб-нетворк соответствующий loopback, но появился флажок. Это роутер вбрасывает какую-то левую инфу. А в первом регионе тоже стоит указание, что это роутер у нас ABR,

и он рассказывает про единственную connected-сетку, которая есть. Это сетка лоббека. Это две разные LSA. Вот эта LSA в нулевом регионе, вот эта LSA в первом регионе. Ну, соответственно, с LSA первого типа мы уже подразбирались. Show IPv database summary 101522. Это LSA третьего типа с ID-шником 101522. Такая LSA есть только в нулевом регионе. И, соответственно, вот она показывается. У нас показывается ID-шник LSA, про что оно рассказывает, про 101522. И оно совпадает с IP-шником сети, про который идет рассказ. Поскольку на лоббеке у нас 101522 по 32 маске, то вот ID-шник LSA совпадает с IP-шником сети, про который рассказывает LSA третьего типа. Advertising роутера, кто ее придумал? Это ID-шник того роутера, про который знает, как добраться до такой сети. И Network Mask 32-ая.

Это вот фактически единственное мясо, которое передается в LSA третьего типа. Ну, еще Метрика передается. Вот Метрика. Он рассказывает, что за моей спиной есть такая сетка в другом регионе. Я вам не скажу, как до нее добраться, но она стоит у меня за спиной одну копейку. Вот. Если у вас будет LSA-ка четверка, то она будет иметь точно такой же формат. Единственное, что изменится, вот здесь вот LSType будет стоять не Summer, Links, а Summary ASBR. LinkStateID будет указывать, про что рассказ идет, про ID-шник ASBR. Advertising роутер по-прежнему будет ABR. И Network Maza будет ноль, потому что в случае с ASBR у ASBR нет маски. Метрика при этом будет такая же. Так. Ну и надо бы еще, наверное, LSA-ки пятерки вбросить и посмотреть, к чему это приведет. Пятерки и заодно забегая вперед, семерки будут иметь, опять же, одинаковый формат. Опять же, у них будет указываться LSA-ID, совпадающий с IP-шником сети, про который идет рассказ, так же, как в трешке.

Network Mask, 32-битная маска, такая же, как в трешке. Дальше. Первый флаг, это указывает на тип метрики. Если там ноль, то это метрика первого типа, или так называемый E1, LSA-ка пятерка. Если там единица, то это E2, то есть метрика типа 2. Метрика первого типа, это значит, что метрика, которая здесь вот будет указана, она построена по сопоставимой с OSPF-ом формуле. Если там E2 метрика, то, соответственно, эта метрика несопоставимая, ну, фактически, вот как я говорил, выражена в долларах. То есть, да, у нас копеечки и доллары. И когда нам говорит какой-то роутер, что знает эту сетку за копейки, вот мы говорим, окей, ты знаешь сетку за копейки, я знаю, как забраться на тебя за копейки, я могу сложить твои копейки со своими копейками. Но если роутер говорит нам, что знает сетку, выраженную в долларах, мы говорим, понял, значит, не дурак, копейки уже здесь не роляют. И, да, мы выбираем из нескольких LSA-ек ту, которая стоит меньше в долларах, а дальше уже до нее строим маршрут за копейки, неважно, сколько копеек там будет.

Так, метрика 32, пардон, метрика 24-битная, то есть 16 миллионов максимальное значение может быть. И дальше два интересных поля, с которыми мы раньше не сталкивались и которые, на мой взгляд, являются убер-костылями. Костыли заключаются в следующем. Если у вас есть LSA-ка пятерка, это означает, что какой-то роутер ASBR имеет доступ в какую-то внешнюю сеть. Соответственно, здесь вот у нас сетка, в которой сидят пользователи, не знаю, 192, 168, 1, 0, по 24-й маске. И вот он про нее рассказывает, говорит, я знаю, как до нее добраться. Но он считает, что лучше будет, если вы будете ходить до этой сети через какой-то другой роутер, который стесняется выбрасывать маршруты сам. Вот у нас есть какой-то другой роутер, и у этого роутера есть какой-то IP-шник, ну не знаю, 10, 0, 0, 1.

И вот ASBR говорит, пожалуйста, когда вы будете ходить до этой сети, вы, пожалуйста, ходите через вот этот вот IP-шник 10, 0, 0, 1. И вот этот вот IP-шник указывается в forwarding address. Это именно IP-адрес, до которого надо будет строить маршрут. И тогда, когда этот forwarding address прописан не в нули, то вы будете метрику транспортную внутреннюю в ASBR, которая за копейки считать, именно до вот этого вот IP-шника. Ну а если вы, соответственно, видите там нули, то вы считаете метрику до ASBR. В реальности не используйте эту штуку, она вредительская. И, ну да, откровенный такой костыль, потому что у вас здесь OSPF есть, и здесь идет редистрибуция. А дальше OSPF строит кратчайший маршрут до сюда, для того, чтобы добраться до какой-то внешней сети. То есть если вот этот вот роутер в OSPF есть, почему он сам редистрибуцию не сделает, казалось бы, да? Ну вот в каких-то сценариях кому-то это оказалось полезным, кому-то это оказалось нужным, и ради этого в стандарт эту фиговину добавили.

Ну, в реальности не надо так делать. Если у вас настолько много маршрутов, что там приходится их редистрибутить, и при том вы хотите, чтобы на некоторых роутерах редистрибуция проходила, на некоторых нет, но трафик ходил через что-то еще. Это значит, что ваша топология не готова к использованию OSPF. Вам нужно использовать что-то куда более подконтрольное, какой-то протокол, который адаптирован под ситуацию вида. Сюда анонсируем, сюда не анонсируем, здесь дружим, здесь не дружим. Это протокол BGP. Поэтому если у вас вот что-то наподобие такого есть, когда есть топология, в которой есть какие-то роутеры, которые выполняют редистрибуцию, есть какие-то роутеры, через которые должен выходить, используйте BGP, он под это предназначен. В OSPF-е такую костыль добавили. Но этот костыль, он реально костыль из костылей. Из всех концепций, которые в OSPF-е есть, концепция forwarding address, она самая дурацкая. Не забывайте, пожалуйста, что OSPF это протокол link state.

Вся прелесть link state протокола заключается в том, что у вас маршруты строятся по карте топологии. Карта топологии состоит из LSEC первого и второго типов. Поэтому если у вас есть OSPF, внутри регион он все маршруты считает по-честному. И вот внутри региона OSPF является link state протоколом. Как только вы начинаете перекладывать маршруты между регионами, между разными источниками маршрутной информации, между OSPF и EGRP, это все дистанц-векторное поведение. Вам лучше использовать протокол, который изначально дистанц-векторный. Все вот эти концепции вида давайте перекладывать LSEC трешки, давайте перекладывать LSEC пятерки, давайте перекладывать как можно добраться за моей спиной до кого-то там еще. Поведение чисто дистанц-векторное и оно убивает всю идею, всю красоту OSPF. А OSPF очень красивый протокол. Но вот когда его начинают обвешивать всякой вот этой вот хренью вроде forwarding address, он таковым быть перестает. Поэтому да, в реальности, если вы не работаете в какой-то вот прям совсем наркоманской среде, то скорее всего у вас forwarding address никогда вам в голову не придет использовать.

Ну да, если что, вот он такой может быть, да. Действительно в LSEC пятерки такая штука есть. И еще внешние маршруты LSEC пятерки можно будет проштамповать, можно будет поставить метку, тег, так же как в RIP, так же как в EJRP, так же как в статические маршруты. Вот в SPF, да, такая штука есть. Маршруты внутренние, LSEC первого типа, третьего типа, там таких меток нет. А в LSEC пятерках равных семерках маршруты можно проштамповать, прокрасить метками и тем самым, например, вот как раз защититься от сценария петли в RIP, когда у нас маршруты, которые есть между двумя автономными системами в двух точках будут реплицироваться. Вот здесь будет взаимная редистрибуция и здесь будет взаимная редистрибуция. То, соответственно, те маршруты, которые по SPF прошли и обратно в RIP собираются вкладываться, вот SPF не будет редистрибутить обратно в RIP. Так, Advertising Crowder ID это ID-шник ASBR, то есть кто придумал такие маршруты.

LinkState ID это IP-шник того, про что мы рассказываем. Ну, все достаточно просто. Так, если у нас есть LSEC пятерки, давайте сейчас попробуем показать, как они выглядят. Так, нам потребуется что-нибудь вбросить. Show IP... Есть статики. Есть статики, да. IP-Route. Я делаю воображаемый маршрут. Мне от него нужно просто, чтобы он был в таблице, чтобы show IP-Route static мне показывало что-нибудь. Show IP-Route static. Мне не нужно, чтобы этот маршрут работал, мне нужно, чтобы он был. Маршрут будет занулять трафик, но трафик, в общем, не важно, будет ходить, не будет, мне сейчас не важно. Я хочу из этого статического маршрута сделать LSEC пятерку.

Роутер. Так. И, соответственно, смотрим на то, что у нас получилось. Show IP-Route static. LSEC нулевого региона. Вот это вот. Здесь у нас есть две LSEC первого типа, одна LSEC третьего типа. LSEC первого региона. Одна LSEC первого типа. Куча LSEC третьего типа. Все, что было известно в нуле, переложилось вне ноль в виде LSEC трешек. И LSEC одна LSEC пятерка. Обратите внимание, по всем остальным LSEC показывается, в каком регионе они придумали. Область распространения LSEC первого, второго, третьего, четвертого типа – это регион. А LSEC пятерки распространяются везде, во всех регионах. Поэтому LSEC пятерка здесь у нас показывается без указания региона. Про что придумана такая LSEC?

Про сетку 10.15.2.222. Кто ее придумал? 10.15.2.2. И здесь можно заказать детали. External. Вот. Показывается маска сети. Слэш 32. Показывается метрика по умолчанию. LSEC вбрасывает метрику второго типа. Larger than any link state path. То есть, вот эта вот метрика второго типа, она более важная, чем метрика OSPF-овская нативная внутренняя. Внутренняя метрика в копейках выражается, а вот эта вот метрика, она в долларах. Она несравнимо важнее, чем метрика в копейках. То есть, даже если там у нас будет 100 копеек, 200 копеек, миллион копеек, все равно метрика в долларах будет важнее. Доллары круче. Метрика 20. Опять же, по умолчанию. Forward address. Это вот тот самый forwarding address. Он поставлен нулями. External road tag. Опять же, маршруты мы не красили. Они тоже проставлены нулями. LSA-капятерка распространяется везде, между всеми роутерами, в том числе и на R1.

Label. Show. IP. OSPF. Database. Вот показывается, что да, LSA-капятерка у нас прибежала. И опять же, обратите внимание, она не принадлежит никакому региону. Так. Есть ли у меня loopback? Show. IP. Интерфейс. Есть loopback. Conf.t. Интерфейс. Loopback. 0. IP. OSPF. 1. Area. 2. Я из первого региона. Сейчас тоже АБР сделаю. И у меня будет второй регион, в который вбрасывается информация из нуля. То есть на первый роутер по нулю пришли маршруты, переложились вне 0. И, соответственно, у нас появляется некоторое дополнительное количество LSA-ек. Show. IP. OSPF. Database. Раньше показывал, что у нас только нулевой регион и еще одна пятерка. Сейчас у нас есть нулевой регион, второй регион и пятерка.

Из интересного, в нулевом регионе 2 роутера и 2 суммарки. Все действительно так. В втором регионе 1 роутер и куча суммарок, LSA-ек 3-шек. И плюс еще появляется LSA-ек 4-ка. В втором регионе не знают, как добраться до роутера 10-15-2-2. Там такого роутера ID нет. Вот у нас все роутеры, которые известны во втором регионе, только 10-15-1-1. А здесь у нас 10-15-2-2. Поэтому АБР рассказывает всем роутерам второго региона, как можно добраться до автора вот этой LSA-ек. 10-15-2-2. Если мы закажем Show.IP.OSPF. Database External. LSA-ек 5. Здесь показывается, что до сетки 10-15-2-2-2 можно добраться. Стоит это 20 долларов. И плюс еще сколько стоит добраться до АБР. И соответственно АБР будет 10-15-2.

АСБР будет стоить 10-15-2-2. Как добраться до 10-15-2-2? Заказываем. АСБР. Саммери 10-15-2-2. То есть как до него добраться. До него можно добраться через АБР. Кто придумал такую сетку? АБР 10-15-1-1. Он уже известен внутри региона. Он может добраться до АСБР за 10 копеечек. Нетворк маска у АСБР отсутствует. Ну соответственно что здесь еще? LinkStateID. Это ID-шник АСБР. Здесь показан адрес. На самом деле не адрес. На самом деле это именно ID-шник. И как-то вот так. Можно ли поменять external на Type-1 и показать пятерку в LSDB? Легко.

Давайте тогда чтобы это сделать. Я сейчас покажу вот такую штуку. Show IP Road. Здесь найду OSPF-овский маршрут. Не понял. Show IP Road. То есть пев. OSPF. Где 10-15-2-222. Так. 10-15-2-222. А, он в EGRP пробежал. Смотрите, какой интересный маневр. Да. У меня этот интерфейс был в EGRP. И поэтому когда OSPF притащил этот маршрут, сказал, да, что я знаю, как до него добраться. OSPF административное расстояние 110, а в EGRP административное расстояние 90. Поэтому его дистрибутер, все честно. ЛСА-5 в базе есть. OSPF посчитал, как можно добраться до этого маршрута.

Сказал, самый выгодный способ это ходить вон туда. А дальше пришел EGRP и сказал, нет, братец, я тебе лучше скажу, как ходить. Да, я скажу тоже, ходи туда же. Но, тем не менее, в таблицу маршрутизации будет добавлен маршрут не OSPF, а именно EGRP. Потому что у EGRP административное расстояние будет 90. Давайте... О, не знаю, чтобы сделать такого плохого. Давайте EGRP административное расстояние поменяем. Такого еще не делали. Роутер. EGRP. CCNP. Роутер. Роутер. Так. address family IPv4 Unicast Autonomous System 65000 По-моему, это Topology Distance Distance Соответственно, если я захочу для отдельных маршрутов поменять, я здесь указываю циферку. Если я хочу для всех маршрутов поменять, я указываю EGRP.

И я сейчас сделаю так, чтобы EGRP не мог побороть OSPF направив бросить маршруты в таблицу маршрутизации. Да, я говорю, что OSPF у нас имеет административное расстояние 110. Поэтому я EGRP говорю, что у него маршруты будут иметь административное расстояние 120 для внутренних, нативных EGRP маршрутов. И, например, 170 для внешних. Поэтому EGRP сейчас будет проигрывать OSPF. И у меня в таблице маршрутизации OSPF притащит свой external маршрут. Так. Вот он. То есть EGRP переустанавливает соседство, и маршрут действительно появился. E2 маршрут, метрика второго типа. В таблице маршрутизации указано административное расстояние 110. И метрика вот те самые доллары, которые указаны в LSA 5. Чтобы сейчас было покрасивее.

10, 15, 2, 222. Так. Пардон. Отдай. Слово OSPF пытается трактовать как имя узла. Вот. Детали этого маршрута в таблице маршрутизации. Показано, что маршрут известен из OSPF первого экземпляра. Административное расстояние 110. Метрика в долларах 20. Плюс еще 10 копеек стоит добраться до того, кто ее придумал. То есть в таблице маршрутизации у нас обе метрики на самом деле хранятся. И внешняя метрика за доллары, и внутренняя метрика за копейки. Но поскольку тип двойка, то, соответственно, эти метрики между собой не складываются. И в случае, если у нас есть несколько LSA-к-двоек, между которыми надо будет выбрать второго типа, то мы сравниваем их исключительно по долларам. В нашем случае выбирать не приходится. У нас только одна LSA-к-пятерка за доллар есть.

Поэтому мы говорим «Окей». Доллары так доллары. 20 долларов. И плюс еще 10 копеек. Дальше. Если вдруг я захочу поменять в настройке роутер-оспф1. Роутер-оспф1. Предистрибьют. Я же здесь могу задать метрику. Метрик. Type 1. Я вместо пятерки второго типа сейчас вбрасываю пятерку первого типа. И, соответственно, show IP-оспф-датабейс-экстернал у нас показывает все то же самое, что и раньше. Но вот здесь вот циферка единилась на изменицу. Раньше здесь вот в скобочках показывало, что метрика второго типа заведомо дороже, чем любая внутренняя метрика. Здесь показывается метрика единичка в скобоках сравнимо со внутренней метрикой. То есть это получается тоже как бы выражено в кавычках в копейках. Пусть не по-честному по считанной копейке, но все-таки какие-то копейки, которые ну как-то сравнивать между собой можно.

Поэтому, когда у нас в таблице маршрутизации на соседе будет смотреться такой же маршрут, у нас показывается, что тип LSA будет первого типа, метрика 30. В LSA написано 20, плюс 10 копеек добраться до того, кто ее придумал, плюс метрики одинаковой природы, поэтому их можно сложить. Поэтому в таблице маршрутизации маршрут будет стоить 30 копеек. Вот show IP road SPF 30 копеек. Ну и метрика, да, будет Е1. Так, это вот что касается содержимого самих LSA. Не надо заучивать на экзамене, что там внутри есть, в каком порядке поля, как называются, какие флаги. Но хотя бы просто представлять в общих чертах, что можно положить в SPF, что нельзя, вы должны. Так, да, вот такой вот. Продолжение следует...