Манипуляции с маршрутами в EIGRP

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

Сделать, например, воображаемый маршрут в сторону Null 0 интерфейса. Можно отправлять только некоторое подмножество маршрутов, которые у вас есть в таблице топологии. Не обязательно отправлять вообще все. Это, опять же, не OSPF, где наврать не получится. Здесь вы вольны фильтровать маршруты на входе, на выходе. Можно делать всё что угодно. Главное не устроить петлю. Можно подменять метрики маршрутов. Например, у вас есть маршрут в таблице маршрутизации. Вы его начинаете отправлять, а сосед начинает его принимать и изменять ему метрику. Он начинает увеличивать bandwidth или увеличивать delay. Не увеличивать bandwidth, а увеличивать именно саму метрику, само число. EIGRP такие штуки делать позволяет. Плюс к тому можно заниматься перекладыванием маршрутов из разных источников. Есть у вас условный RIP. И вы берёте из RIP и перекладываете маршруты в EIGRP. Сами придумываете то, чего у вас раньше в EIGRP не было.

Вы берёте из таблицы маршрутизации какие-то маршруты и рассказываете про них соседям, по сути. Так же как и в RIP, есть команда Auto Summary, которая была включена по умолчанию на старых IOS. Она вызывает проблемы. Если у вас классовые сети используются разрывные, это вызывает проблемы. На самом деле это действительно большая проблема. И большая проблема в том числе потому, что это действительно классический дизайн. Когда у вас есть сеть предприятия, у вас есть distribution-железки. Distribution-железка раз, два. Есть access-железки. И эти access-железки подключаются по таким схемам к distribution. Фактически, если здесь у вас какая-то классовая сетка и здесь у вас та же самая классовая сетка, а на уровне distribution такой классовой сети нету, вы получаете ровно то, что на слайде. Когда у нас в топологии здесь и здесь куски одной и той же классовой сети, а здесь этой классовой сети нет. На роутере, который находится внутри такого разрыва, будет приходить только целиком классовая сетка.

Отключается это командой No Auto Summary. Если вы работаете с 12-м IOS, обязательно используйте эту команду. Если у вас смешанный IOS, и 12-й, и 15-й, и вы включаете EIGRP, на всех лучше эту команду сделать. No Auto Summary выключает это поведение. Если вы работаете с 15-м IOS, то можно его включить, если вдруг оно зачем-то вам нужно. Но вряд ли оно вам нужно. Если вы его включаете, то видно будет, что на R2 в такой ситуации придёт два классовых маршрута. 10.0.0.0 по 8-й маске. Понятное дело, что в этом случае он трафик будет балансировать. Особенно если он ещё per-packet балансировку выдаст, вообще будет замечательно. Если балансировка будет per-destination, то хотя бы половина соединений будет проходить куда надо, а иначе будет только половина пакетов. С агрегацией маршрутов, если вы захотите пересылать не те маршруты, которые у вас есть, а какие-то большие, чтобы не посылать кучу мелочёвки, EIGRP умеет работать. Так же как в случае с RIP, будет работать команда Summary Address на интерфейсе.

Но опять же, EIGRP и RIP – это образцово-показательные дистанц-векторные протоколы, поэтому неудивительно, что у них настройка идёт похожая. На интерфейсе можно указать команду IP Summary Address. Дальше указываете номер автономной системы, в нашем случае сотая. И дальше указываете суммарную сетку, которую вы хотите посылать. Так, пардон. Немножко лишнего захватил. Вот эта сетка. В нашем случае 10.0.0.0 по маске 255.255.0.0 – это 10.0.0.0/16. Если вы захотите отправить хотя бы один компонент в этой большой сетке в интерфейс, на котором вы прописываете такой Summary Address, то вместо всех мелких компонентов будет отправляться только эта большая одна суммарка. Если вы хотите, вы можете указать административное расстояние. Это не обязательно делать, но если хотите, можно 250, например, задать. По умолчанию будет административное расстояние 5. Если вы хотите сделать суммарный маршрут, и этот суммарный маршрут будет 0.0.0.0,

то есть у вас есть, например, роутер, который смотрит в интернет, и вы хотите вместо всего отправить только дефолтный маршрут какому-то соседу, в этом случае вы должны будете сделать Summary Address, EIGRP чего-то там, 0.0.0.0 по маске 0.0.0.0. И надо будет убедиться, что административное расстояние для того маршрута, который вы сделали, будет достаточно хорошим. Почему я говорю, что это нужно сделать? Если у вас есть статический дефолт 0.0.0.0, который вы руками прописали, static, у него будет административное расстояние 1. И, конечно, дефолтная пятёрка его не затмит. Вы придумаете воображаемый маршрут, пытаетесь поставить его в таблицу маршрутизации, он у вас не вставится, но это не проблема, потому что в таблице маршрутизации эта сетка есть, пусть и не EIGRP-шная. И дальше вы эту суммарку начинаете отсылать своим соседям. Маршрут в таблице есть, всё хорошо. В то же время, если этот маршрут, допустим, придёт по OSPF или по BGP,

то у него будет административное расстояние 20, а 20 – это уже больше, чем 5. Поэтому, когда вы придумываете такую суммарку, у неё административное расстояние пятёрка по умолчанию, и она заменяет маршрут BGP-шный. Раньше по BGP приходил дефолт, и вы направляли весь трафик в интернет. Сейчас вы сделали такую суммарку, и у вас трафик до всех сетей блэкхолится, потому что в таблице маршрутизации вместо BGP-шного маршрута будет стоять маршрут на интерфейс Null 0. Поэтому в некоторых ситуациях нужно будет административное расстояние для такой суммарки проставлять. Чаще всего как раз для восьминулёвки. Дальше. Метрика по умолчанию – наименьшая метрика его компонентов. Так же как и в RIP, если у вас есть несколько отдельных компонентов, которые вы хотите анонсировать, и вы говорите, не надо отдельно мелочёвку анонсировать, анонсирую суммарку, RIP просто говорил: я бы, если отправлял мелочёвку,

отправил бы этот маршрут с метрикой 5, этот с метрикой 6, этот с метрикой 7, беру самую маленькую метрику из всех компонентов, которые у нас есть, и отправляю суммарку с метрикой самого дешёвого маршрута. EIGRP тоже так же делает. Он вычисляет feasible distance по всем компонентным маршрутам и отправляет суммарку с указанием bandwidth, delay, load, reliability – всего остального, взятого с самого дешёвого маршрута. Leak map – но это всё тема CCIE, да. Можно взять и отправить и суммарку, и какую-то мелочёвку. Но вам это не понадобится, и в реальном мире на самом деле тоже не понадобится. Иногда бывает, конечно, такое, что надо будет отправить суммарку, и надо будет, чтобы трафик до какого-то отдельного мелкого поднабора мелочёвки тоже ходил через вас, а не через кого-то другого, кто отправляет эту мелочёвку в явном виде. В этой ситуации нужно будет сказать, что когда мы отправляем суммарку, мы ещё позволяем

утечь через эту суммарку некоторым мелким маршрутам. Как понятно, делается через route map. Route map. Судя по названию, вы уже знаете, как это делается, поэтому тут рассказывать что-то дополнительно не стоит. Вы можете также заниматься и редистрибуцией маршрутов с EIGRP без особых проблем. На самом деле, когда EIGRP присылает какие-то маршруты, он делает следующее: у него есть роутер, который присылает маршрут. Этот маршрут добавляется в табличку топологии EIGRP, дальше он добавляется в таблицу маршрутизации. На самом деле абсолютно любой маршрут, который к вам приходит транзитный, проходит такой путь. Если у вас есть какой-то маршрут, который приходит по EIGRP, добавляется в вашу таблицу топологии, приходит к вам транзитный маршрут, и вы этот транзитный маршрут

складываете в таблицу маршрутизации и только оттуда начинаете отправлять этот маршрут своим соседям. Даже если у вас этот маршрут есть в таблице топологии, он по факту соседям уходит не напрямую из таблицы топологии, а только при условии, что он есть в RIB. Если EIGRP попытался принять какой-то маршрут, поставить его в таблицу маршрутизации, и ему это не удалось, он не будет этот маршрут отправлять своим соседям. Это поведение для EIGRP будет очень важное. Если, например, у вас есть на этой же системе какой-нибудь OSPF, и EIGRP что-то вам присылает, какой-то маршрут, допустим, сетка будет 10.0.0.0/16, он нам эту сетку присылает. OSPF со своей стороны тоже эту сетку в RIB вставил. И у вас OSPF почему-то с административным расстоянием

оказался не 110 штатный, а, допустим, он взял и добавил этот маршрут с административным расстоянием 80. Или, если память не изменяет, RIP мы учили вставлять с изменением административного расстояния. Пусть будет не OSPF, а RIP. И RIP прислал эту же сетку 10.0.0.0/16 с изменённым административным расстоянием, вставил в таблицу маршрутизации. EIGRP видит, что сетка есть, вставляет её в таблицу топологии, пытается добавить её в таблицу маршрутизации, и у него ничего не выходит. Он не сможет отправить эту сетку своим соседям. По факту все транзитные маршруты, которые через него проходят, он сначала пытается проверить, что они в таблицу маршрутизации воткнутся. Если вы хотите, чтобы в такой ситуации транзитные маршруты передавались, вам надо будет сделать очень странную вещь: вам надо будет настроить редистрибуцию из RIP в EIGRP. И тогда получится, что вы принимаете маршрут

EIGRP-шный, ставите его в EIGRP, после чего из RIP в EIGRP этот маршрут забираете, и после этого вы имеете право отправлять его дальше в сеть. Это ограничение у EIGRP есть: транзитные маршруты, нормальные обычные EIGRP-шные маршруты, могут пройти через роутер только если они смогли поставиться в таблицу маршрутизации. Если нет, нужно всякие костыли придумывать. Дальше, редистрибуция в EIGRP – всё хорошо, примерно так же как в RIP. Редистрибуция в EIGRP будет доступна так же, как и в RIP: из connected-маршрутов, static, динамических маршрутов любых. Можно из BGP, можно из другого экземпляра EIGRP, можно из OSPF, можно из IS-IS, можно из RIP. Соответственно, тоже можно взять маршруты, положить в EIGRP либо из глобальной

таблицы, либо из VRF. EIGRP всё это делать умеет. Для каждого маршрута, который вы вкладываете в таблицу топологии EIGRP, вы должны указать стартовую метрику, потому что если у нас есть роутер и у него с одной стороны RIP, а с другой стороны EIGRP-соседи, когда мы принимаем маршруты по RIP, мы понимаем: маршрут, и в нём написано, например, этот маршрут доступен через семь прыжков. Метрика в RIP – семёрка. Когда мы работаем с RIP-соседями, для нас это семёрка, вполне основательное и понятное число. Но когда мы начинаем отправлять такой маршрут соседям по EIGRP, мы не можем сказать: ребят, этот маршрут в семи прыжках. Мы должны рассказать, какой у него bandwidth, какой delay, какой reliability – всё должны рассказать. И нам надо каким-то образом это придумать. Из семи прыжков между роутерами мы только hop count можем вообразить, и это не всегда подходит. Поэтому нам придётся задать стартовую метрику, иначе у нас будет бесконечная метрика infinity с бесконечно большим delay, и такие

маршруты отправляться просто даже не будут. Исключение: стартовые метрики не нужно назначать, если мы берём connected-маршруты. С connected-маршрутами мы можем угадать все свойства, потому что маршрут висит на интерфейсе. Мы берём bandwidth с интерфейса, delay с интерфейса, reliability с интерфейса, load с интерфейса. Если у нас static, который по сути своей всё равно что connected, мы говорим, что у нас есть интерфейс, ip route, и дальше говорим, что сетка, допустим, 10.0.0.0 по маске 255.0.0.0, на интерфейсе tunnel 0. Это фактически всё равно что connected-сетка, тоже все настройки берутся с самого интерфейса. И соответственно, если вы берёте из другого EIGRP, из другой автономки, то EIGRP умеет перетаскивать маршруты между автономками с сохранением их метрик. Если

мы берём из одного EIGRP и перекладываем в другой – это возможно, например, сценарий, когда у вас было две сети абсолютно двух независимых предприятий, в каждом из них было EIGRP, и вы решили их состыковать между собой. Вы говорите: у нас будет два роутера, они будут перекладывать маршруты из одной автономки в другую. И в этом случае маршруты внутри каждой автономки будут сохранять свойства, пришедшие из другой автономной системы. В принципе, в этой ситуации вы вполне можете просто взять их и состыковать напрямую, но это будет предполагать, что вы должны в какой-то из автономок поменять номера автономных систем на всех роутерах. Если исторически так сложилось, что здесь использовалась автономка 100, и здесь, например, не знаю, тысячи роутеров, и вот здесь тысячи роутеров на автономке 200, проще всего будет сказать: окей, редистрибуцию сделаем на двух роутерах, настроим просто два роутера, и всё, чем перепрописывать номер автономной системы на вообще всех роутерах в какой-то одной из автономок. Можно назначить метрику на каждый маршрут, можно назначить метрику скопом.

Так же как в RIP, мы можем либо воспользоваться командой default metric, либо при команде redistribute указать стартовые метрики, либо воспользоваться route map. Метрики задаются при указании команды redistribute, дальше тип маршрутов, которые вы хотите перекладывать в ваш EIGRP, откуда вы забираете маршруты, точнее, какие маршруты в таблице маршрутизации вы забираете для того, чтобы положить в ваш EIGRP. И дальше вы указываете стартовые метрики: это bandwidth, выраженный в килобитах, это delay, выраженный, по-моему, в микросекундах или в десятках микросекунд, надо посмотреть. Это reliability, load и MTU. Все стартовые показатели, которые нужны для работы EIGRP. Здесь вы задаёте MTU, в принципе он не очень сильно нужен, но EIGRP всё-таки заставляет его указывать. Если вы route map будете назначать, то

вы можете на уровне отдельных маршрутов сказать, что маршруты, которые приходят из условного OSPF или из условного static, мы раскрашиваем так, с такими метриками, маршруты, которые приходят с другими свойствами, раскрашиваем как-то иначе. Опять же, если у нас есть, например, статические маршруты, мы можем их метками разметить: tag 0, 1, 2, 3, и дальше на основании этих тегов уже назначать разные стартовые метрики. Пример: у нас есть три статических маршрута, они не attached, а remote, то есть смотрят на какого-то другого соседа. И мы говорим, что у нас есть три маршрута, смотрящие на одного и того же соседа, и они раскрашены тремя разными метками: метка 1, 2 и 3. Мы создаём route map, который называем static-to-EIGRP, говорим, что у нас будет два блока: первый блок и второй блок. В первом блоке мы просто задаём метрику, говорим, что здесь скорость будет 10 гигабит, задержка единица, скорее всего это десятки

микросекунд, reliability, load, MTU. Мы пермитим такие маршруты, никак над ними не издеваемся, просто забираем статики, у которых метка единичка, и вкладываем их в EIGRP с такими стартовыми свойствами. Другой блок route map говорит: мы всё равно их пермитим, забираем маршруты с меткой 2 и выставляем им такую стартовую метрику. И заодно мы проставляем метки в EIGRP. Метки у EIGRP действительно есть, и плюс к тому они сохраняются при редистрибуции. Если вы берёте статический маршрут и он был помечен, у него была метка, то при экспорте в EIGRP эта метка сохраняется. Мы брали 10.0.1.1, мы нигде не говорили set tag, но она сохранилась. Поэтому, если вы хотите, чтобы эти метки не сохранялись, или если вы хотите настраивать эти метки как-то

кастомно, то set tag – она есть, она в том же самом блоке, что и set metric. Вы можете одновременно проставить несколько разных свойств маршрута: можете метрику проставить, можете метку проставить, можете next hop проставить – что хотите, то и делайте. И дальше приклеиваем этот route map при редистрибуции: redistribute static route-map. Кстати, в EIGRP здесь хорошо видно, что мы проставили метки. Здесь хорошо видно, что мы проставили метрики достаточно быстро. Скорость интерфейса здесь 10 гигабит, если память не изменяет, и delay здесь весьма маленький. А вот тут мы проставили set metric: один килобит, 10 тысяч delay, 0 надёжность, 255 загрузка и 1500 MTU. Это метрики максимально злые: минимальная

полоса пропускания, большая задержка, минимальная надёжность, максимальная загрузка – самый плохой маршрут, который только можно придумать. И для таких плохих маршрутов EIGRP естественно посчитал feasible distance такую кошмарную. И метку 222 – вот она, 222, в таблице маршрутизации маршруты у нас соответственно такие будут видны. Единственное, что я не совсем понимаю, почему у нас здесь метрика такая страшная взялась. Откуда она такая страшная? Должна быть 512, по-хорошему. На R2 через какой-то медленный интерфейс это дело получал, не знаю. Внешние маршруты, которые в

EIGRP появились изначально не из EIGRP, а откуда-то ещё, помечаются буковками. X означает external маршрут. Как вы помните, маршруты нормальные содержат в себе только очень ограниченное количество параметров, а внешние маршруты в EIGRP – мало того, что видно, что они внешние, там передаётся ещё откуда они взялись в EIGRP: передаётся указание, из какого протокола они взялись, передаётся, из какого экземпляра протокола, с какой автономки, из какого инстанса, и метрика, которая была в таблице маршрутизации на момент импорта этого маршрута, тоже показывается. Плюс router ID того, кто этот маршрут придумал. Поэтому в EIGRP можно легко отличить нормальные маршруты от внешних. И внешние маршруты имеют административное расстояние 170, в отличие от нормальных, которые имеют административное расстояние 90. В EIGRP на самом деле это очень сильно помогает. Как раз сценарий, когда у вас есть две разные автономные системы, и у вас есть две точки редистрибуции. Здесь, например, будет EIGRP, а справа будет что-то

другое, например условный RIP. И у вас выполняется взаимная редистрибуция и здесь, и здесь. Так вот, маршрут, который зародился где-то в EIGRP, прошёл на один из роутеров, дальше отредистрибутился в RIP, прошёл по RIP, пришёл обратно и импортировался обратно в EIGRP – он будет заведомо проигрывать оригинальному маршруту. Потому что здесь административное расстояние 90, а здесь административное расстояние 170. Маршруты, которые реэкспортированы в EIGRP, заведомо проигрывают нормальным маршрутам. Можно ли то же самое сказать про RIP? У RIP нет способа заметить, что маршрут прошёл через какую-то внешнюю маршрутную систему и вернулся обратно. Поэтому, если, например, у нас есть здесь какая-то сетка, эта сетка прошла до дальнего маршрутизатора, он её реэкспортировал, импортировал в EIGRP, дальше маршрут пришёл на другой роутер,

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

не факт, что такой маршрут будет проигрывать оригинальному RIP-овскому маршруту, который может находиться довольно далеко от сети назначения. Поэтому EIGRP имеет административное расстояние разное для нормальных и внешних маршрутов, поэтому он не подвержен проблеме петли при реимпорте и проблеме с кривым способом доставить трафик в сеть назначения при реимпорте. RIP такой проблемой подвержен. EIGRP может фильтровать маршруты, которые принимает и отправляет на интерфейсах, так же как и в RIP. Можно на уровне интерфейса сказать: мы не хотим отправлять какие-то маршруты, мы не хотим принимать какие-то маршруты с помощью либо access-листов, либо prefix-листов. Можно это сделать, можно route map. Вы указываете distribute-list, дальше указываете название access-листа и ключевое слово in. Тогда на всех интерфейсах вы проверяете входящие маршруты по access-листу. Если вам что-то там не пермитится, то вы такие апдейты просто не принимаете, вы их сбрасываете.

Можно указать prefix-лист: указываете distribute-list prefix, дальше название prefix-листа. Если хотите, можете дополнительно проверить, кто прислал вам этот маршрут, по prefix-листу. И gateway вы указываете IP-шник того, кто вам это прислал. Если вы знаете заранее наперечёт IP-шники ваших neighbor-ов, то вы можете здесь как раз проверять, от кого приходят апдейты. И in – ключевое слово. Все маршруты, которые идут в направлении таблицы маршрутизации, это апдейты, которые приходят к нам, они приходят в сторону таблицы маршрутизации. Если мы будем дальше кому-то это отправлять, оно идёт на самом деле из таблицы маршрутизации, даже несмотря на то, что у EIGRP есть отдельная своя табличка топологии. Что касается фильтрации на уровне отдельного интерфейса, после in можно указать отдельный интерфейс и тем самым отфильтровать префиксы в апдейтах на уровне отдельного интерфейса.

Будьте осторожны, потому что может сложиться, например, ситуация: у вас есть три роутера в кольце, и они друг на друга вот так смотрят. И вы говорите, что у вас есть сетка A, и вы эту сетку A отправляете в один интерфейс, но не отправляете в другой. У вас получается, что эта сетка приходит на нижний роутер, и трафик до этой сети пойдёт в обход. Если вы её не зафильтруете везде, то она всё равно просочится, и трафик до этой сети всё равно может добраться. Поэтому, если вы фильтруете отправку или приём, убедитесь, что вы фильтруете одновременно на всех интерфейсах, либо вы это делаете намеренно на разных интерфейсах по-разному. Да, можно на выход, можно на вход фильтровать. Можно route map. Если вы указываете route map, то это всегда только фильтрация на вход. Если вы указываете distribute-list route-map, то на выход route map, по-моему, нельзя фильтровать.

Если вы хотите на выход фильтровать, то это либо access-list, либо prefix-list. Опять же, указываете prefix-list, что вы фильтруете на выход. Можно указать интерфейс, с которого вы хотите фильтровать. И ещё один кейс – это фильтрация маршрутов, которые будут попадать в таблицу EIGRP при редистрибуции. Опять же, указывается ключевое слово out, потому что по факту маршруты из RIB, из таблицы маршрутизации, будут попадать в EIGRP. Они будут двигаться в направлении внешнем по отношению к таблице маршрутизации. Поэтому out здесь как раз out. И указываете, откуда маршруты должны будут инспектироваться при редистрибуции. Если мы указываем redistribute OSPF1, то мы можем дополнительно distribute-листом сказать, что именно при редистрибуции из OSPF1 мы будем забирать в EIGRP. Но это мы говорим по-русски — забирать в EIGRP. А по факту таблица маршрутизации согласна будет отдать в сторону EIGRP из того, что у неё есть от OSPF1.

Дальше. Если у вас есть EIGRP, вы также, как и в RIP, мы говорили про анонс дефолт-маршрута, можете и в EIGRP тоже анонсировать дефолт. Сделать это можно несколькими способами. Первый способ — это редистрибуция. У вас есть маршрут по умолчанию. Вы говорите, мы берём redistribute, тот самый источник, который прислал нам маршрут по умолчанию, redistribute static, например. И это вполне неплохой вариант. Второй вариант — это суммарка, IP summary address. Вы берёте и говорите, суммируем что-нибудь. Можно взять специально какую-нибудь сетку, которая кривая-косая, для того чтобы её просуммировать. В этом случае, если вы делаете суммирование в 0.0.0.0, то вам, скорее всего, тот самый leak map понадобится для того, чтобы отдать и мелочёвку тоже.

С некоторой вероятностью вам это может пригодиться. Если вдруг у вас есть маршрут по умолчанию и вы суммируете сетки в 0.0.0.0, то административное расстояние надо будет поставить какое-нибудь большое, чтобы он не заменил тот маршрут по умолчанию, который у вас там уже есть. И есть ещё одна штука. Это старый способ, который по факту не работает. Способ был полезен в классовых сетях. Опять же, это тяжёлое время, деревянные игрушки прибиты к полу, 10-битовая VLAN ID, классовая маршрутизация, протокол IGRP для анонса сетей. И если у вас была классовая таблица маршрутизации, вы могли одну сетку пометить как то, что все остальные сети в мире доступны так же, как и определённые классовые сети. Маршрут типа 0.0.0.0 вы не могли добавить в таблицу. У вас в таблице маршрутизации указывались только IP-шники, и маски этих сетей угадывались автоматически по IP-шникам. Поэтому, чтобы показать, что все остальные сети в мире доступны через определённую классовую сеть,

вы помечали эту сеть звёздочкой. И если вы хотели по IGRP передать указание, что определённая классовая сетка будет сеткой по умолчанию, вы передавали указание, что эта сетка передаётся в сети. И вот эта самая какая-нибудь 192.168.168.0. Вы её в таблице маршрутизации помечали командой ip default-network. И IGRP протаскивал вам эту звёздочку вместе с сеткой 192.168.168.0. Я не шучу, это реально звёздочка. В таблице маршрутизации она звёздочкой и помечалась. И плюс дополнительно строчка gateway of last resort, и показывается IP-шник шлюза, и показывается to network, и дальше эта классовая сетка. Никогда не обращали внимания на фразу gateway of last resort is not set или что-то ещё? Это как раз формулировка, что у вас есть дефолтная сеть, default-network.

И она нужна для того, чтобы маршрутизацию в классовом мире можно было упростить и добавить аналог сети по умолчанию. В бесклассовом мире эта штука не работает. Если вы будете использовать EIGRP в 2018, 2019, 2020 году и так далее, знайте, что эта штука не работает. Да, звёздочку она протаскивать будет, но это единственное поведение, которое будет делать команда ip default-network. Она не будет по факту заставлять маршрутизироваться весь трафик по этой сетке со звёздочкой. Сегодня уже не классовый мир, и CEF ожидает, что вы притащите именно маршрут 0.0.0.0. Звёздочка — это не маршрут 0.0.0.0. Это старый способ, который работал в классовом мире. Так что если вдруг вы будете читать старые книжки, старые, на самом деле не такие уж и старые. Кто-то тут показывал книгу по 642-902 экзамену, старый ROUTE, старый в кавычках, версия 1.1, которая была 5 лет назад.

Там ещё ip default-network в этих книжках расписывался как абсолютно живой рабочий способ. Но по факту, если вы попытаетесь это сделать, оно работать не будет. Так, что ещё можно с маршрутами сделать? Иногда нам нужно будет отключать Split Horizon, расщеплённый горизонт. Типичный пример — это DMVPN. У нас есть хаб, у нас есть споки. По умолчанию в Distance Vector протоколах мы не передаём маршруты в тот же интерфейс, через который мы их получили. Но есть проблема. У нас есть спок номер 1, спок номер 2, спок номер 3 и хаб. Мы были умненьки, мы настроили мультикаст в DMVPN. Но мультикаст в DMVPN позволяет по мультикасту обмениваться споку с хабом. Он не позволяет по мультикасту обмениваться спокам напрямую. А в EIGRP, если вы что-то посылаете, вы посылаете мультикастом, апдейты посылаете,

они идут мультикастом. Поэтому мультикастовые апдейты от спока 1 дойдут до хаба. И хаб обратно эти мультикастовые апдейты должен будет послать уже каким-то своим остальным соседям. Например, споку 2 и споку 3. И для того чтобы это всё работало, нужно будет сказать, что мы получаем апдейт по туннельному интерфейсу DMVPN, и потом обратно в этот же туннель DMVPN засовываем этот же апдейт. В EIGRP такую штуку придётся делать. Во-первых, мы должны будем настроить этот самый мультикаст. Делается это с использованием следующей штуки. На споке мы должны будем прописать ip nhrp map multicast, и дальше прописать публичный IP-шник хаба. Это будет означать, что все мультикастовые пакеты, которые посылаются в сторону туннельного интерфейса, по факту заворачиваются в этот IP-шник на транспорте. Да, Split Horizon — это именно механизм не посылать апдейты в тот интерфейс,

через который мы их получили, для того чтобы не устроить петлю. Иначе мы получим подсчёт до бесконечности. Когда у нас два роутера, один говорит, я знаю, как добраться до сети за одну копейку. Второй говорит, а я знаю, как добраться через тебя за две копейки. Формально у него в таблице эта сетка есть, и она стоит две копейки. А первый говорит, окей, раз ты знаешь, как за две копейки, я тогда буду через тебя знать за три копейки. Они начинают дальше считать до бесконечности, и в какой-то момент им надо прерваться. RIP будет бороться с этой штукой, просто говоря, что бесконечность на самом деле очень легко достижима. Бесконечность в RIP — это 15. Если они досчитали до 15, всё, сразу байники. В EIGRP им придётся довольно долго считать до бесконечности, потому что бесконечность в EIGRP — это 100. Если мы используем DMVPN, нам нужно будет аккуратненько этот самый Split Horizon отключить и теоретически сформировать предпосылки для того, чтобы на такую петлю нарваться. Но если мы отключаем Split Horizon только на хабе,

то маршруты, которые от споков приходят, хаб будет обратно посылать спокам, а споки маршруты, которые будут получать, они не будут обратно рефлектить в сторону хаба, потому что мы на хабе отключили, а на споках нет. Это важно. Мы на хабе отключаем Split Horizon, а на споках мы его не трогаем. И тогда хаб маршруты, полученные от споков, сможет другим спокам про них рассказать. Прописываем на споках, что весь мультикаст, который есть, надо отправлять хабу. Дальше он разберётся. На хабе прописываем команду ip nhrp map multicast dynamic. Это значит, что все, кто зарегистрировался в базе NHRP, будут получателями копии мультикастового трафика, потому что хаб знает все споки наперечёт. Это команды, которыми настраиваются мультикастовые взаимодействия между хабом и споками в DMVPN. А дальше начинается магия. No ip split-horizon eigrp 650001. Эта команда выключает Split Horizon.

Маршруты, которые будут приходить от споков, хаб будет обратно уже рефлектить. Тот же самый туннель. Они приходят не откуда-то сбоку, а потом их в другой бок посылают. Нет, на самом деле они приходят через интерфейс туннеля, и хаб их обратно в тот же самый интерфейс туннеля отправляет. Маршрут приходит отсюда, а дальше мы его обратно сюда же и посылаем. Если мы это будем делать, то хаб будет менять IP-шник NextHop на себя, потому что он отправляет маршрут, и он говорит: спок у нас есть, у него IP-шник 10.0.0.11, он посылает апдейт хабу, хаб говорит, у меня IP-шник 10.0.0.1, он посылает апдейт всем остальным, и все остальные видят апдейт, приходящий от IP-шника 10.0.0.1. Трафик между узлами в этом случае напрямую ходить не будет. У нас будет работать DMVPN в так называемой первой фазе, когда весь трафик ходит через хаб, потому что маршруты, которые будут в споке ставиться, на хаб,

они будут все указывать NextHop именно на него. Чтобы трафик начал ходить через споки, вам нужно будет, чтобы споки знали IP-шники друг друга. Они откуда-то должны узнать про то, что какие-то сетки доступны за спиной у других споков. Они потом с помощью NHRP узнают публичные IP-шники и начнут посылать трафик друг к дружке напрямую. Но надо ту самую магию, чтобы один спок узнал частный IP-шник другого. И для того чтобы это сделать, мы делаем хитрую штуку. No ip next-hop-self eigrp в конкретной автономной системе на интерфейсе туннеля. Эта штука говорит, что когда у нас приходит пакет с апдейтом через туннельный интерфейс, и мы обратно отправляем маршрут в этот же туннельный интерфейс, мы не проставляем себя в качестве адреса источника. Мы в IP-пакете, естественно, проставляем себя в качестве адреса источника, но в NextHop в свойствах апдейта мы проставляем оригинальный IP-шник того,

кто нам такой апдейт прислал. У нас на каждый маршрут можно прописать IP-шник NextHop. И к нам приходит апдейт от 10.0.0.11. Мы обратно в туннель посылаем, что ребята, я вам посылаю от 10.0.0.1 апдейт, но вы, когда будете в таблицу маршрутизации его ставить, NextHop прописываете 10.0.0.11. И все споки в этом случае будут знать, какие сетки за спиной у кого находятся. Это будет называться фаза 2. Фаза 2 — это трафик между споками ходит напрямую. Фаза номер 1 — весь трафик ходит через хаб, при этом у нас хаб сильно загружен. Фаза номер 2 — трафик ходит через споки. И в таблице маршрутизации на всех споках у нас полная ясность есть. И сколько у нас споков есть, сколько они нам маршрутов присылают, все эти маршруты распространяются на все споки. Разве мы не MAC подменяем? Нет, мы не MAC подменяем. Мы в туннельных интерфейсах — сложности с MAC-ами есть определённые.

Туннельный интерфейс — он нарисованный. У него MAC-ов нету. У него есть IP-шник, куда мы это отправляем. И всё. Так что с MAC-ами здесь сложно. И таким образом мы говорим, что для того чтобы споки могли построить полную таблицу, мы указываем, кто на кого как будет смотреть, кто какие сетки по факту заявляет. И в фазе 2 у нас действительно трафик начинает ходить, минуя хаб. Через хаб по факту ходит только мультикаст. Похоже на логику Route Reflector. Да. На самом деле он и есть. Последняя фаза, это фаза 3, будет предполагать, что у нас в таблицах маршрутизации на споках только дефолт. В этом случае нам нужно будет сделать так, чтобы хаб не присылал отдельную мелочёвку спокам, чтобы он присылал только дефолтный маршрут, а дальше чтобы споки каким-то образом узнавали, когда они пытаются послать трафик по этому дефолту,

что на самом деле некоторые сетки нужно будет отправлять в сторону других споков. Для того чтобы отправить дефолт вместо кучи мелочёвки, мы используем команду ip summary-address. Она у меня не влезла здесь на слайд, поэтому я сократил её до ip summary. Указываем eigrp 650001, указываем суммарный маршрут, и для того чтобы он нам свой собственный дефолт не испортил, указываем ему административное расстояние 250. И дальше начинается магия третьей фазы DMVPN. Указываем команду ip nhrp redirect. Эта штука будет отправлять так называемые шорткаты, когда у нас начинает ходить трафик через нас, который мы на самом деле знаем, что не надо через нас посылать. Этот дефолтный маршрут приходит на все споки. Спок номер один говорит, я бы хотел добраться до сети 10.0.0.2. Что он делает? Он просто пакет тупо посылает. Говорит, 10.0.0.2 в качестве адреса получателя, там 0.0.1.2. Приходит такой пакет на хаб. Хаб его обратно отправляет по сети назначения.

Этот пакет по факту через хаб прошёл, но встречный пакет идёт — NHRP Redirect. В следующий раз пакеты до такой сети, пожалуйста, посылай напрямую споку 2. По большому счёту это аналогично тому, что мы бы послали маршрут изначально, и тогда даже первый пакет до хаба бы не дошёл. Но между отправкой настоящего EIGRP маршрута и между отправкой этого сообщения NHRP Redirect, точнее shortcut, будет большая разница. И разница будет заключаться в том, что сообщения NHRP shortcut попадают сразу в CEF. В таблице маршрутизации show ip route на споке при этом будет видно только дефолтный маршрут. А все эти Redirect Shortcut по факту будут появляться только в show ip cef. И эта штука будет намного быстрее работать. Таким хитрым манёвром можно будет добиться довольно неплохой производительности. В таблице маршрутизации маршрутов мало, а в CEF — что там CEF себя нагрузит, пусть нагружает.

На споке для того чтобы эти шорткаты принимались, нужно будет сказать команду ip nhrp shortcut. ip nhrp redirect на хабе — когда к тебе приходит пакет, который не стоило тебе отправлять, отправляй сообщение «ходи туда, не ходи сюда». А для того чтобы принимать такие сообщения на споке, мы говорим ip nhrp shortcut. И мы согласны принимать такие сообщения и согласны вставлять их в таблицу ускорителя CEF для обработки трафика. По факту CEF начинает обрастать теми маршрутами, которых нет в RIB. Потому что они есть не в RIB, они есть в этих самых NHRP Shortcut. Это будет фаза 3. Фаза 3 предполагает, что у нас в таблице маршрутизации только дефолт, а всякие кривые-косые пути между споками у нас сидят отдельно в таблице CEF. Если вы хотите поиграть с административным расстоянием, у вас есть такая возможность.

По умолчанию надо будет знать стандартное административное расстояние 90 и 170 для внутренних и внешних маршрутов. И если вы создаёте суммарку, summary address, то этот виртуальный маршрут, который создаётся для всей агрегированной сети, будет иметь административное расстояние 5, если вы его не задаёте ручками. Мы на предыдущем слайде буквально проставляли ручками административное расстояние 250, чтобы такой нулевой маршрут заведомо проигрывал любому другому маршруту. Если вы хотите, вы можете поменять административное расстояние для EIGRP. Полезно это делать в ситуации, когда вы, например, обновляете протокол динамической маршрутизации при миграции. У вас есть сейчас какая-то сеть, вы хотите перейти на другой протокол, и в этом случае вам как раз нужно будет, чтобы два протокола сосуществовали между собой. Если вдруг вам надо будет повысить или понизить административное расстояние для EIGRP, как раз можно будет использовать команду distance eigrp.

И дальше две циферки — внутренние и внешние маршруты. Команда distance имеет немножко странный синтаксис. Если вы просто указываете distance, пробел, eigrp, то все маршруты EIGRP будут обрабатываться однотипно. Если вы указываете distance и дальше циферку, то вы указываете, что это административное расстояние будет работать для каких-то кастомных маршрутов. Одна команда distance eigrp — все EIGRP маршруты. Другая команда distance с циферкой. И тогда вы задаёте кастомные маршруты, которые должны получить административное расстояние 180. Задаются: эталонный IP шлюза, IP-шник, wildcard-маска IP-шника шлюза и access-list, которым вы пробегаете через апдейты, которые приходят от соседей и которые будут добавляться в таблицу маршрутизации. В нашем случае мы видим, что сначала мы задали всем маршрутам административное расстояние 80 и 160.

И нормальные маршруты, которые просто буковкой D показываются — административное расстояние 80. А это административное расстояние 160, потому что это маршрут внешний. Но потом мы сказали, что нам хочется пропустить через некий дополнительный фильтр маршруты и назначить административное расстояние 180, невзирая на next hop, тем маршрутам, которые проходят через фильтр ACL distance 180. И допустим, предположим, он назначил на все маршруты. Все маршруты заперметил, поэтому мы всем маршрутам проставили AD 180. Если вы хотите, вы можете дополнительно здесь, в указании gateway IP gateway mask, сделать проверку на этот адрес. Если вдруг маршрут приходит с next hop в ASI и маршрут до какой-то конкретной сетки, то мы ему административное расстояние выставляем вот такое. Не надо играть с административным расстоянием до тех пор, пока у вас не появляется такая острая потребность.

И эта потребность может быть в ситуации, когда либо вы хотите, чтобы для некоторых сетей работал EIGRP, для некоторых OSPF. Соответственно, в такой ситуации нужно будет указать, какие конкретно маршруты вы хотите, чтобы предпочитались где. Ещё один типичный пример — это как раз миграция между протоколами. Когда вы создаёте в сети ситуацию, когда у вас работают одновременно два протокола — и EIGRP, и OSPF, типичный пример. В этом случае при миграции в протокол дистанц-векторный, например в EIGRP, вам нужно будет сделать так, чтобы EIGRP получил административное расстояние больше, чем тот протокол, который у вас сейчас используется. Сначала везде разворачиваете EIGRP, но задираете ему административное расстояние, чтобы он не влиял на работу текущих маршрутов. Потом, когда у вас всё развёрнуто, все соседства построены, вы редистрибутите на всех роутерах в EIGRP все маршруты.

Тогда EIGRP начинает этими маршрутами обмениваться, и после этого начинаете постепенно убирать старый протокол, начиная с края сети. Соответственно, в какой-то момент, когда вы заканчиваете убирать старый протокол, вы остаётесь только с чистым EIGRP, меняете административное расстояние, и миграция получается завершена. В остальных случаях не надо трогать стандартные административные расстояния. Они подобраны достаточно неплохо, и для 99.99% случаев они подходят без особых модификаций. По поводу стабов. Я уже показал, как они работают. Вы можете объявить маршрутизатор стабом, и тогда они не будут транзитными для маршрутов. Стабу никогда не будут отправляться query, поэтому если у вас есть маршрутизатор-стаб, то он никогда не будет причиной того, что маршрут зависнет в stuck in active. Потому что stuck in active — это ситуация, когда вы отправили query, и вам не вернулся reply.

Если стаб-маршрутизатору попытаетесь всё-таки отправить query, он немедленно скажет reply, что через меня до этой сети добраться нельзя. Но другие маршрутизаторы будут видеть, что сосед — стаб, и просто не будут ему отправлять query. Сами стабы при этом могут отправлять апдейты, могут принимать эти апдейты. Они в свою таблицу топологии складывают всё, как будто бы они были нормальными роутерами. Но анонсируют из этой таблицы далеко не всё. Во-первых, они анонсируют по умолчанию connected маршруты — те, которые они сами командой network зародили в таблице топологии. Про них они расскажут. И они анонсируют по умолчанию summary маршруты — те, которые они сами просуммировали. Если у нас есть маршруты в таблице топологии, мы по умолчанию про них рассказываем, только если они наши собственные. Но если про них кто-то другой рассказал, мы их не рассказываем. Но мы можем заставить роутер рассказать про сетку-суммарку.

Connected и summary маршруты по умолчанию как раз рассказываются. Всё остальное не рассказывается. Если вы будете выполнять редистрибуцию, то вы можете сказать EIGRP stub redistributed. Тогда вы будете анонсировать в том числе и те маршруты, которые вы сами порождаете в EIGRP. Сами внешние свои маршруты будете рассказывать. При этом чужие редистрибьютные маршруты вы не будете рассказывать. Есть ещё один нюанс: если вы редистрибьютите маршруты какие попало, то они попадают под redistributed. Если вы редистрибьютите маршруты статические, то для них есть специальное отдельное правило, что вы можете включить отдельно отправку тех маршрутов, которые вы редистрибьютили из статических маршрутов из таблицы маршрутизации. Как это всё выглядит в реальной жизни? У вас есть роутер.

Давайте напишу stub. Обычный классический stub анонсирует connected и анонсирует summary. У него есть доступ во всю остальную EIGRP-шную сеть. EIGRP. И у него есть какая-то своя сетка A. Он её зародил в таблице топологии в EIGRP, потому что включил на этом интерфейсе команду network, и он про эту сетку рассказывает, что я знаю сеть A. Это обычный нормальный EIGRP-шный маршрут, абсолютно нормальный, живой, который он сам придумал. Если вдруг есть какой-то другой способ выйти во внешний мир, и оттуда приходят какие-то сетки, например сеть B, stub-роутер про неё запомнит информацию, что можно до неё добраться через внешний мир, но анонсировать её он не будет, потому что это будет означать, что через него можно добраться до этой сети. Это значит, что этот роутер будет транзитным, а транзитным stub-роутер никогда быть не может. В то же время иногда бывает нужно стать транзитным роутером. Например, в ситуации, если у вас есть что-то вот такого плана —

филиал, в котором есть несколько роутеров. И здесь есть сетка B, которая по факту к тому же филиалу будет относиться. И роутер присылает нам анонс, говорит: я хочу тебе рассказать про то, что у меня есть сетка B. Этот роутер будет знать, что до неё можно добраться, но не будет про неё ничего рассказывать, потому что это чужая транзитная сетка, он про неё ничего не рассказывает по умолчанию. Но он может сказать: давайте мы просуммируем все наши сетки, которые у нас есть в таблице, и отправим суммарку. Возьмём, например, если у нас правильно задизайнена сеть филиала, у нас сетка A и сетка B будут принадлежать одному и тому же блоку. Например, здесь у нас будет 10.1.1.0/24, а здесь 10.1.2.0/24. Мы возьмём и скажем: всё это на самом деле одна большая сетка 10.1.0.0/16. Мы можем анонсировать суммарку 10.1.0.0/16.

Эту суммарку мы сами придумали, и поэтому мы про неё рассказываем. В этой суммарке, естественно, один из компонентов будет сетка 10.1.2.0. И если трафик придёт на этот stub-роутер, он, конечно, его профорвардит. Но при этом он не будет рассказывать, что я транзитный роутер, я могу вам рассказать, как добраться до сети 10.1.2.0. Отдельно 10.1.2.0 он рассказывать не будет. Редистрибьютные маршруты будут предполагать, что вы занимаетесь перекладыванием маршрутов из какого-то источника, например из OSPF в EIGRP. Вы занимаетесь редистрибуцией. Если вы включаете редистрибуцию, по умолчанию маршруты, которые вы в себя в EIGRP вкладываете, вы при этом не рассказываете про них никому. Но если вы указываете команду EIGRP stub, дальше указываете, какие типы маршрутов вы хотите анонсировать — по умолчанию connected summary — вы можете сказать: EIGRP stub connected summary redistributed.

И тогда те маршруты, которые вы вкладываете из OSPF, вы перекладываете в EIGRP и про них анонсируете апдейты своим соседям. Но по умолчанию, ещё раз подчеркну, этого не происходит. Команда будет EIGRP stub в настройке роутера, и дальше вы указываете, какие типы маршрутов вы хотите анонсировать. Эти два по умолчанию, можно их просто не писать. Если просто пишете EIGRP stub, они как раз отмечаются. Если вы хотите отправлять редистрибьютные маршруты, то указывайте redistributed. Если вы при этом редистрибьютите статические маршруты, надо будет указать отдельное слово static. Тогда обычный redistributed писать не надо, просто static. Те маршруты, которые вы сами переложили в EIGRP из таблицы со статическими маршрутами. И есть ещё один пункт — receive-only. Вы не анонсируете вообще ничего. Если вы не хотите анонсировать никакие маршруты, но вы хотите принимать маршруты, в этом случае вы можете объявить stub receive-only.

Я, честно говоря, не знаю, в каком сценарии может пригодиться receive-only. Мне как-то ни в литературе не попадалось это, ни в реальной практике. Но тем не менее возможность такая есть. У вас есть роутер, который принимает все маршруты, но не отправляет никому ничего. Даже connected. Если вы объявляете себя стабом, у вас соседства отваливаются все и переустанавливаются, потому что вы теперь начинаете заявлять себя как стаб. Примеры настройки разных вариантов стаба будут иметь следующий вид. У нас есть три роутера: R1, R2 и R3. R1 говорит, что он не стаб. R2 говорит, что он не стаб. У нас всё нормально здесь работает, реплицируется. FD001, FD002, FD03. Какие-то маршруты на лупбеках, которые они залернили, и они друг другу рассказывают, что знают эти сетки. На R1 известно про все три сети.

Первый лупбек connected, второй залернен, третий залернен, оба через R2. То же самое на R2. Оба залернены с разных сторон, на R3 оба залернены через R2. Всё логично: на R1 известны эти двое, на R2 известен этот и этот, на R3 известны эти. Если мы включаем стабы, самый простой стаб — это stub connected, то мы анонсируем те connected сетки, которые на нас известны, но при этом чужие сетки мы не передаём. В нашем случае R1 и R2 объявляются стабами, stub connected. На R1, естественно, известна своя сетка. На R2 анонсируется своя сетка. И R1 тоже анонсирует свою сетку. Поэтому на R1 видно сетку R2, но при этом R3 сетку R2 дальше не перекладывает. Он говорит: это транзитная сеть будет, я такими вещами не занимаюсь. Поэтому R1 про третий лупбек не увидит ничего. На R1 нету третьего лупбека,

на R3 нет первого лупбека. R2 при этом всё видит, потому что а почему бы ему и не видеть. Дальше. Если вы помечаете receive-only, то EIGRP фактически увидит только маршруты, которые нормальны. R2 увидит маршрут от R3, потому что R3 не стаб. Стаб R1 не принимает ничего от R2, потому что тот только принимает, не отправляет ничего сам. R2 тоже не отправляет ничего. R1 не отправляет ничего. Но зато R3 присылает на R2 что-то. Если вы включаете stub summary, то вы начинаете анонсировать суммарки. У нас есть на R3 команда IPv6 summary, что он суммирует сетку FD00::/24. И в этом случае R3 что-то нам заявляет, что он знает такую сеть.

Нет, не R3 знает такую сеть. R2 знает такую сеть и в сторону R3 отправляет эту суммарку. R2 делает эту сетку. R2 посылает эту сетку в сторону R3. При этом ту сетку, которую R1 заявил, что он знает, на R3 дальше она не пересылается. И редистрибьюты. У нас где-то возникает редистрибуция из OSPF. Маршруты, которые здесь в OSPF были изучены на R2. На R2 мы занимаемся редистрибуцией. При этом маршруты, которые мы переложили на R2 из OSPF в EIGRP, появляются на R3, появляются на R1. Но на R1, при этом если мы будем то же самое делать, то оно на R3 уже не пройдёт. R2 в этом случае увидит такие маршруты как транзитные.

И static — то же самое, только со статическими маршрутами. У нас был статический маршрут, мы занимаемся redistribute static, и у нас появляется статический маршрут в EIGRP. Это external маршрут, внешний EIGRP. Receive-only. Получить дефолты от двух соседей-бордеров. Допустим. Тоже непонятно, в каком сценарии это может пригодиться. Не знаю. Вы можете объявить роутер стабом, тем самым сократить количество запросов, сократить количество маршрутов, зависших в stuck in active, если для вас это актуально, сократить количество апдейтов — тоже немаловажный фактор. И действительно, сеть, если правильно задизайнена с учётом стабов,

особенно если у вас есть какие-то линки, которые медленные, она действительно будет намного более стабильной, чем просто обычная сеть на роутерах. Поэтому, если у вас есть EIGRP — что не у всех есть EIGRP, но если у вас он есть, и если у вас есть филиальные сетки, то размечайте свои филиалы стабами, и в большинстве ситуаций это даст вам действительно прирост по производительности. На сегодня всё. Давайте встретимся с вами в следующий раз и поговорим про то, как это настраивать. Попробуем сделать на это лабу прямо с самого начала занятия. На сегодня всё. Спасибо за внимание. Пока-пока.