GRE

После того, как мы обсудили теоретическую возможность построения туннелей с использованием либо IPIP, либо GRE, давайте посмотрим на практике, как это будет выглядеть. Здесь у нас не очень большой модуль, поэтому я думаю, что мы его быстро пробежим. Это будет модуль, посвященный взаимодействию site-to-site в Cisco IOS. Мы не рассматриваем в рамках нашего курса механизмы построения remote access туннелей, всякие PPTP, L2TP и прочее. Это тема, относящаяся к безопасникам. Пусть они этим занимаются — как организовать доступ для пользователей к корпоративной сети. А задача связать между собой два офиса на предприятии встречается весьма часто, и поэтому в рамках нашего курса мы её рассматриваем. Как будет выглядеть процедура, которая требуется для связывания между собой двух роутеров с помощью виртуального туннеля?

У нас есть один офис и второй офис. Адресация, как я уже показывал, 10.0.1.0 здесь, 10.0.2.0 здесь. Нам нужно связать между собой роутеры R1 и R2 виртуальным туннелем, виртуальным проводом, если хотите. В этот провод мы будем отправлять данные, которые предназначены для второго роутера. При этом такие данные физически будут бежать всё равно по публичным маршрутам, по публичным интерфейсам, и там адреса не должны быть частными, они должны быть публичными, поэтому когда мы будем отправлять какие-то пакеты с одного роутера на другой, в качестве адреса источника мы будем задавать публичный адрес нашего интерфейса, который маршрутизируется обратно к нам, и в качестве адреса получателя будем указывать адрес другого конца туннеля. Туда пакеты будут идти с 192.0.2.1 на 203.0.1.2, обратно они будут идти с 203.0.1.2 на 192.0.2.1. Пока всё предсказуемо. Дальше.

Так же, как и в случае с физическим проводом, когда у нас есть какой-то порт, который смотрит на соседа, с настоящими физическими проводами, мы делаем включение протокола IP для того, чтобы на этом интерфейсе IP у нас начал работать. Для этого мы используем банальнейшую команду ip address. Когда мы вешаем IP-адрес на интерфейсе, мы на интерфейсе включаем обработку IP, мы создаём connected-сетку и указываем, что все остальные адреса в этой сети находятся в том же самом проводе. Поэтому, если у нас появляется виртуальный интерфейс, который смотрит на соседний роутер, у нас там должны быть адреса. И эти адреса нужно будет задать. Здесь мы используем 10.0.1.0 сетку по /24 маске. Здесь 10.0.2.0 по /24 маске. А в туннеле 10.0.0.0 по /24 маске. Здесь будет IP-шник 10.0.0.1, здесь будет IP-шник 10.0.0.2.

На каждом роутере есть три интерфейса. Один публичный и два частных. 192.0.2.1 — это адрес на публичном интерфейсе. 10.0.1.1 на интерфейсе, который у нас LAN, в кавычках. Потому что на самом деле разница между LAN и WAN не особо есть. И туннельный интерфейс. На цисках туннельный интерфейс так и будет называться tunnel. И дальше у них будет номер. Так же, как на loopback есть номер. Здесь тоже номер. И задаём эти IP-шники. Указываем, что у нас есть внутренний интерфейс, который смотрит на частную сеть 10.0.1.0. Дальше внешний интерфейс, который смотрит на публичную сеть. Нам понадобится маршрут в интернет. Здесь будет что-то типа ip route 0.0.0.0 0.0.0.0 на какой-то роутер провайдера. Здесь это не указано. И дальше та штука, которая как раз содержит всю магию GRE. Мы указываем, что у нас есть туннельный интерфейс.

Мы дальше указываем, что пакеты, которые по нему бегают, будут обрастать дополнительными заголовками. Поэтому если мы отправляем какой-то пакет туда, помимо того, что в нём передавались какие-то данные, он ещё получит, возможно, 8 байт GRE-заголовка. Дальше плюс сверху он получит ещё 20 байт дополнительного IP-заголовка. Поэтому максимальный размер передаваемых данных для того, чтобы уместиться в 1500 байт, надо будет уменьшить. Поэтому мы указываем команду ip mtu 1400. Здесь надо заметить следующее: вы можете точно рассчитать, какого размера IP-пакет вы можете в такой туннель передавать. И чаще всего это будет значение типа 1472, когда мы говорим 8 байт на GRE, 20 байт на дополнительный заголовок. И суммарный размер пакетов, которые у нас будут получаться, когда мы в такой туннель будем что-то отправлять, будет как раз 1500 байт. Но есть нюанс. Нюанс заключается в том, что гипотетически протокол IP позволяет, например, отправлять пакеты с опциями.

И если вы возьмёте IP-шные опции и будете пакеты с такими опциями отправлять в туннельный интерфейс, то тогда максимальный размер пакета может быть и больше, чем 1400 байт. И в этой ситуации будет нехорошо, если вдруг такие пакеты будут теряться. По большому счёту вы можете особо не париться на эту тему, но Cisco рекомендует даже в актуальных гайдах ставить 1400. И логика сейчас будет вот какая. Если вы захотите потом всё это дело зашифровать каким-то IPsec или чем-то ещё, заранее угадать размер полученного пакета может быть не очень легко. Понятное дело, что будет примерно столько же, сколько был оригинальный пакет, но оно может немножко отличаться. И насколько именно немножко будет отличаться, заранее сказать нельзя. Это будет сильно зависеть от конкретной технологии. Но если вы возьмёте пакет, который будет максимум 1400 байт, и вы его дополнительно зашифруете, обвешаете всякими дополнительными заголовками, чем угодно ещё,

он у вас не получится больше, чем 1420–1440 байт. Поэтому он заведомо будет меньше, чем 1472. И поэтому даже если вы его обвешаете сверху дополнительным IP-заголовком, он у вас точно гарантированно будет меньше, чем 1500. Поэтому 1400 — это цифра, рекомендованная Cisco. Следующая строчка ip tcp adjust-mss указывает, что если через этот интерфейс будут проходить SYN-пакеты, и в этих TCP SYN-пакетах будет передаваться опция указания MSS, Maximum Segment Size. Стандартный узел 10.0.1.2, когда будет передавать IP-пакет в сторону 10.0.2.2, он отправляет пакет TCP SYN, и он указывает, что размер TCP-сегмента может быть 1460 байт, плюс 20 байт TCP-заголовок, плюс 20 байт IP-заголовок.

Он указывает 1460 байт полезных данных в каждом сегменте. Когда роутер R1 будет пропускать такие пакеты в туннель, он будет говорить: не 1460, а 1360. Внутри TCP-опций он будет подправлять опцию MSS. И тогда, когда такой пакет будет получен узлом 10.0.2.2, он в ответ то же самое скажет. Роутер R2 тоже в ответ подправит своё MSS. И два этих узла будут знать, что больше чем 1360 байт TCP-вложений в этот провод вкладывать нельзя. При этом у них самих MTU 1500. Но они больше чем 1360 байт в пакеты не напихивают для того, чтобы эти пакеты нормально проходили через туннель, про который эти узлы вообще не знают. Опция adjust-mss очень полезна, и рекомендуется её использовать. Дальше. Можно указать tunnel mode gre ip. В принципе, не обязательно это делать.

По умолчанию Cisco именно используют GRE-туннели. Если вы её не укажете, всё равно будет работать именно в режиме GRE. Если захотите, можете сказать, что будете использовать GRE поверх IPv6. Если у вас есть доступ к IPv6-интернету, и вы хотите поверх IPv6-интернета поднять GRE-туннели, в них, например, IPv4 гонять, тогда здесь будет mode gre ipv6. Это IPv6 будет указанием на то, что вы упаковываете GRE-вложения, неважно какие, внутрь IPv6, а не IPv4 пакетов в публичном интернете. Дальше. Когда мы отправляем пакеты в туннель, мы должны будем указать в каждом пакете, из какого адреса и на какой адрес они идут. Указываем tunnel source и tunnel destination. Это именно то, что будет прописано в качестве адреса источника и назначения в пакетах в публичном дополнительном заголовке, который вы отправляете. Когда у нас есть узел, который хочет отправить какой-то пакет, и мы должны его пакет обрастить дополнительным заголовком —

в этом заголовке есть поля, которые заполнять надо. Два самых главных поля — какие IP-адреса ставить. Мы же не можем догадаться, какие IP-адреса ставить. Мы должны в явном виде их указать. Source и destination. Source можно указать с интерфейса, который у вас есть. В нашем случае GigabitEthernet 0/0. Кстати, здесь неправильно указано. GigabitEthernet 0/0. Вот. Ну и финальный рывок. Нам нужно, чтобы у нас таблица маршрутизации правильно работала. Самый простой вариант — запустить в таком туннеле динамическую маршрутизацию. GRE прекрасно работает с мультикастом, поэтому можно здесь, например, включить OSPF. Но если лень заморачиваться с OSPF, можно прописать статический маршрут. Просто сказать ip route 10.0.2.0 — эта сетка доступна через туннель. И с другой стороны то же самое. Сказать 10.0.1.0 — сетка доступна через туннель.

И трафик у нас будет отправляться узлом 10.0.1.2 на 10.0.2.2. Он будет доходить до роутера R1. R1 говорит: куда мы такие пакеты направляем — выход через tunnel 0. Всё, что направляется в tunnel 0, обрастает дополнительным заголовком. И получается новый IP-пакет. И этот новый IP-пакет отправляется в сеть назначения по публичному интернету. Он доходит до сети получателя. Роутер получателя видит IP protocol 47. Видит внутри GRE-заголовок. Проверяет, что GRE-заголовок корректный. Если там чексумма есть — проверяет чексумму. Достаёт содержимое. Говорит: я вижу IP-пакет, идущий на адрес 10.0.2.2. Я его направляю по таблице маршрутизации на конечный узел. GRE работает вот таким простым образом. Он простой, как барабан. Настраивается независимо на обеих сторонах. Нюанс GRE заключается в том, что у него нет никакой специальной процедуры проверки сборки GRE-туннеля.

С одной стороны у нас есть туннель. Мы с одной стороны начинаем его включать. Указываем, что интерфейс туннеля поднялся. Мы его просто создали. Interface tunnel 0. Указали, что этот туннель будет именно GRE. Или согласились с тем, что по умолчанию он GRE и есть. Прописали tunnel source, tunnel destination. Всё, у нас туннель перешёл в up. С другой стороны вы пока ещё могли вообще ничего не делать. Но интерфейс уже в up, и он позволяет отправлять пакеты в интернет до указанного вами IP-адреса. Фактически, когда вы указываете tunnel source и destination, у вас создаётся механизм инкапсуляции, и весь трафик, который отправляется в такой виртуальный интерфейс, который в up, просто оборачивается заголовками и отправляется в интернет. Или не в интернет, а куда скажете. В принципе, теоретически, у GRE есть разные хитрые механизмы, типа keepalive — до тех пор, пока сосед корректно не будет настроен, мы не поднимаемся. Если сосед внезапно выключился, мы интерфейс гасим.

Эти штуки возможны, но они не рекомендуются на самом деле. Если вы хотите, чтобы трафик по туннелю не бегал, если сосед не настроен корректно, самый простой вариант — запустить там OSPF. OSPF автоматически нащупает соседа, автоматически раз в 10 секунд будет отправлять Hello-пакеты, если в течение 40 секунд от соседа ответов нет, значит, пристреливаем соседство. И все маршруты, которые смотрели в этот туннельный интерфейс, у нас будут невалидные. При этом сам интерфейс находится постоянно в up — ничего страшного. Вот так настраивается туннельный интерфейс. Работоспособность второго конца туннель не проверяет по умолчанию. Можно включить, чтобы проверял, но не нужно, потому что лучше эту задачу возложить на протокол динамической маршрутизации, например, на OSPF. Если хотим посмотреть, как туннель у нас работает, есть команда show tunnel interface, но это просто про то, можем ли мы инкапсулировать пакеты на другой конец туннеля или нет.

Показывается, что у нас есть tunnel 0, это GRE-туннель, который заворачивает IP-пакеты или что-то ещё внутрь IPv4-заголовка. В этом IPv4-заголовке проставляются source и destination. Вот такие. Дальше указывается, что когда у нас получится новый IP-пакет, он будет отправляться через интерфейс Ethernet 0/1, через next hop 203.0.1.2. Это вычисляется автоматически. Это делает аппаратный ускоритель маршрутизации, который называется CEF, Cisco Express Forwarding. Мы нигде это не задаём в конфиге, но оно само правильно заполняется и само начинает работать, само просчитывает, куда отправлять такой трафик. На самом деле здесь этот адрес 203.0.1.2 будет немножко другой — он показывает connected-адрес. Дальше показывается, что внутри этого GRE-туннеля мы можем обрабатывать

IPv4, IPv6, MPLS. Но по умолчанию обрабатывается только IPv4. Если мы на туннельном интерфейсе включили только IPv4-адреса, не делали IPv6, не делали MPLS, то всё это будет дропаться. Вот и всё. Пакеты, которые будут отправляться в туннельный интерфейс, будут самыми разными. Некоторые из них будут разрешать фрагментацию, некоторые из них не будут разрешать фрагментацию. Разное железо разных вендоров будет по-разному себя вести при построении транспортного пакета. В частности, они будут по-разному себя вести в части флага DF, Don't Fragment. Может быть такое, что если вы берёте пассажирский пакет, у которого стоит «меня нельзя фрагментировать», и делаете из него IP-пакет, который будет предназначен для путешествия по интернету,

вы будете реплицировать состояние флага DF. Если пассажирское вложение не предполагало, что его можно фрагментировать, то и внешний пакет тоже нельзя будет фрагментировать. Но есть нюанс, что если такой пакет где-то по сети будет убиваться, то невозможно будет исходному отправителю такого пакета, который внутри отправлял вложение, сообщить, что пакеты прибились по дороге. Невозможно будет, если у вас есть компьютер, который отправляет пакеты на роутер, который строит туннель с другим каким-то роутером в интернете. У нас здесь действительно настоящий интернет. Если мы берём, отправляем пакет 1480 байт, мы из этих 1480 байт сделали пакет 1508 байт, отправили пакет на роутер, тот сказал: я принял у тебя такой пакет, но я пытаюсь дальше его переложить, и в интернете 1508 байт всё-таки редко пробиваются.

И он говорит: я твой пакет прибил. В ответ идёт сообщение Packet Too Big. И в этом Packet Too Big указывается 1500. Типа отправляй пакеты размером 1500 байт, и они пролезут. У нас получается, что пакет этот packet2big доходит до нашего конца туннеля, но из такого пакета невозможно вычленить информацию, какого размера пакеты должны быть для того, чтобы они влезли внутрь туннеля, во-первых. Во-вторых, невозможно будет понять, кому именно надо отправить сообщение, отправляй пакеты поменьше, а то твои большие пакеты с дополнительными заголовками кому-то в туннеле там не нравятся. Для того, чтобы такого не происходило, Cisco по умолчанию DF bit не проставляют. Даже если вдруг пассажирское вложение говорило, меня фрагментировать ни в коем случае нельзя, Cisco говорит, ничего, можно. И, соответственно, пакеты, которые отправляются, если получилось 1508 байт размером, она будет говорить, окей, не проблема, отправляем 1480 байт одним пакетом

и еще 28 байт другим пакетом. Это что касается point-to-point GRE. Что касается фирменного Cisco-вского механизма, когда у вас есть один интерфейс, который смотрит на всех соседей сразу. Очень удобная штука, если у вас много филиалов. Штука называется DMVPN, Dynamic Multipoint VPN. Она использует точно такой же GRE-туннель, который настраивается очень похожим образом, но вы не указываете IP-адрес получателя. У вас есть один интерфейс, который смотрит на всех соседей сразу. В таком интерфейсе есть несколько соседей, поэтому мы должны будем, отправляя пакет, указывать, кому конкретно мы его отправляем. И у нас не предполагается, что мы указываем IP-адрес получателя, IP-адрес другого конца туннеля. Предполагается, что этот IP-адрес будет автоматически выясняться для каждого конкретного получателя с помощью специального протокола, который называется NHRP, Next Hop Resolution Protocol.

Этот самый NHRP — в принципе, протокол стандартный, но Cisco его немножко модифицировала и сказала, что если мы используем GRE, точнее, Multipoint GRE, как раз тот самый туннель, который смотрит на всех соседей сразу, в связке с NHRP, то это получается фирменный Cisco-вский протокол DMVPN, который ни у кого не поддерживается, кроме самой Cisco. И если вы работаете именно с Cisco-вским железом, то он позволяет очень легко и достаточно надежно реализовывать замечательно легко масштабируемую конфигурацию VPN-а на много-много узлов. В таком туннеле, в таком интерфейсе, который смотрит на всех соседей сразу, очень специфически работает Multicast. В Point-to-Point туннеле Multicast не нужен. Там всего один конец туннеля, поэтому там нет задачи отправить такой один пакет, который дойдет до многих соседей сразу, чтобы кто-то зажмурился, а кто-то не зажмурился. В DMVPN у нас такая задача появляется, и, соответственно, Multicast в нем работает крайне

специфически криво. Я сейчас просто рамочно расскажу, как DMVPN настраивается, для того, чтобы вы просто представляли, как это всё выглядит, но не предполагайте, что вы после этого сможете его настраивать. Там есть много всяких разных подводных камней, которые нужно будет знать перед тем, как DMVPN-решение пускать в production. Выглядит туннель DMVPN точно так же, как и обычный Point-to-Point. Соответственно, мы вешаем IP-адрес на туннельный интерфейс, мы указываем tunnel source, с какого интерфейса, с какого адреса мы отправляем пакеты. Можно указать tunnel source IP-адрес, это tunnel source интерфейс, возьми IP-адрес с интерфейса Gigabit 00. Но есть новая строчка tunnel mode gre multipoint, и она как раз указывает, что IP-адрес получателя, tunnel destination, мы не указываем. За него будет отвечать протокол NHRP. И мы указываем вот такую штуку: туннель у нас будет резолвить IP-адреса получателей

с помощью протокола NHRP, и у роутера может быть несколько разных экземпляров NHRP. NHRP может на роутере быть разным. Может быть такое, что у нас рядом есть другой DMVPN-туннель, и, соответственно, у нас должны быть несколько разных, назовем это баночек, куда мы складываем публичные IP-адреса разных узлов. И мы запускаем локальный процесс с номером 1 для того, чтобы конкретный наш туннель пользовался баночкой с номером 1. Если у нас есть другой туннельный интерфейс, он будет пользоваться другой баночкой NHRP, другой базой с другим номером. Так же, как у OSPF. Мы можем запустить несколько процессов OSPF и их пронумеровать. Сказать, вот это OSPF 1, это OSPF 2. Просто локально значимое число, по сети не передается. Оно нужно для того, чтобы просто не путать разные процессы между собой. На хабе это всё, что нужно сделать. Мы просто указываем, что это туннель, который смотрит на всех соседей сразу.

И говорим, что соседей мы будем резолвить с помощью протокола NHRP. При этом никаких дополнительных настроек на хабе не задается. К этому хабу может подключаться сколько угодно филиалов. Филиальные роутеры, Spoke 1, Spoke 2, Spoke 3. Мы нигде на хабе не прописываем, кто они. Этих Spoke может быть миллион. Настройка от этого хаба не изменится. Всё, что здесь есть, это всё, что нужно для того, чтобы настроить DMVPN на хабе. На Spoke нужно будет сделать всё это и еще кое-что. Нужно будет прописать, кто же всё-таки будет в нашем DMVPN присутствовать. Потому что иначе получится, что если мы вообще нигде ничего не указываем, то все могут взаимодействовать со всеми, что ли? Это не то, что мы хотим. Мы должны будем прописать, кто будет резолвить нам адреса по протоколу NHRP. И на Spoke-овских роутерах добавляются две новые строчки. Та же самая IP NHRP Network ID. Здесь какое-то локально значимое число. И дальше мы указываем, что в эту баночку номер один, в эту базу,

складываются публичные IP-адреса с помощью протокола NHRP, который мы резолвим на хабе. И команда будет иметь вид IP NHRP NHS, Next Hop Server. И мы указываем частный IP-адрес Next Hop Server, который резолвится в этом туннеле. У нас здесь есть, допустим, 10.0.0.1 — частный IP-адрес. Здесь 10.0.0.3. Здесь 10.0.0.2. Это все узлы по /24 маске, которые видят друг друга, которые считают, что они находятся в одном таком большом псевдопроводе. Псевдокоаксиальном проводе. И, соответственно, нам нужно будет как-то сказать, где этот 10.0.0.1 надо будет взять. Потому что частный же IP-адрес, да? Может он у вас, может он у Васи-соседа, может он у Google какого-то. Поэтому мы должны будем указать, что адрес 10.0.0.1 частный соответствует публичному IP-адресу 192.0.2.1. Это единственное место на Spoke,

где прописывается хоть какая-то настройка, относящаяся именно к вам. Вы указываете публичный IP-адрес вашего хаба в команде IP NHRP map — частный IP-адрес к публичному IP-адресу. Это означает, что если мы захотим отправить любые пакеты на частный адрес 10.0.0.1, то мы должны будем их уложить в новый большой IP-пакет, в качестве адреса источника в новом пакете указать адрес tunnel source, а в качестве адреса назначения указать этот публичный IP-адрес 192.0.2.1. А если мы хотим отправить трафик кому-нибудь другому, 10.0.0.3, 10.0.0.4, 10.0.0.100, мы для того, чтобы узнать его публичный IP-адрес, спросим у 10.0.0.1. А как добраться до 10.0.0.1? Мы уже знаем, надо отправить публичный пакет на 192.0.2.1. Мы отправляем ему публичный пакет, содержащий запрос: 10.0.0.1, как добраться до 10.0.0.100? Он нам возвращает ответ: чтобы добраться до 10.0.0.100, ходи на публичный IP-адрес вот такой.

И мы отправляем от одного Spoke на другой Spoke трафик напрямую, минуя хаб. На хаб пользовательский трафик при этом вообще не идет. Это совершенно гениальная штука. Она сокращает время прохождения пакета по сети, потому что если бы мы строили туннели по схеме всё через hub, то трафик должен был бы дойти до хаба, потом вернуться на другой Spoke. И если бы мы подключались из Калининграда к Владивостоку через Нью-Йорк, понятное дело, трафик бы шел очень долго. А так трафик идет напрямую, и, соответственно, на хаб нагрузка никакая дополнительно не создается. То, что хаб периодически отвечает на запросы NHRP — такая его нелегкая хабья доля. Нагрузка там не очень большая, поэтому, в принципе, сеть на основе DMVPN, если у вас в основном взаимодействие идет между Spoke-ами, она очень и очень эффективна. Да, если вдруг у вас используется везде оборудование Cisco, если у вас используется в качестве протокола

динамической маршрутизации протокол EIGRP, то DMVPN с EIGRP дает очень неплохую связку, которая исключительно быстро работает и исключительно хорошо себя проявляет. Но при этом вы подсаживаетесь на иглу привязки к Cisco. Если вы хотите внутри DMVPN запускать протокол динамической маршрутизации, то придется разобраться с мультикастом. Мультикаст в DMVPN крайне кривой, и когда мы, допустим, хотим отправлять hello-пакеты на адрес 224.0.0.5, возникает вопрос, а как это сделать? Кому конкретно уйдут пакеты, на какие публичные IP-адреса, если они содержат частный пакет на адрес 224.0.0.5? Правильный ответ — никуда не уйдут. DMVPN не знает, кому отправлять такие пакеты. До тех пор, пока мы в явном виде не пропишем, куда такие пакеты девать. В этом случае на Spoke мы должны будем сказать, мультикаст идет только на хаб.

Мы в явном виде указываем получателя мультикастового трафика только хабом. Да, это не совсем честный мультикаст, потому что у нас есть интерфейс, через который мы можем, в принципе, обмениваться трафиком со многими разными узлами, но по факту мы говорим, мультикаст в нашем случае не будет работать между всеми. У нас в Unicast-топологии каждый видит каждого, а в мультикасте топология другая. Spoke видит только центральный хаб. И в этом случае мы на Spoke говорим IP NHRP map multicast и дальше указываем публичный IP-адрес 192.0.2.1, IP-адрес хаба. Если мы хотим отправить пакет на частный адрес хаба, на 10.0.0.1, мы отправляем на 192.0.2.1. И если мы хотим отправить мультикаст, мы тоже отправляем это на 192.0.2.1. В то же время на хабе мы просто говорим, что любые узлы, которые к нам приходят, все эти Spoke, они у нас регистрируются в нашей базе NHRP. Поэтому мы можем на хабе сказать IP NHRP map multicast dynamic.

То есть не указывать публичные IP-адреса всех наших Spoke заранее, а сказать, что все, кто к нам приходил с запросами, какой у него публичный IP-адрес, скажи мне его, мы их всех запоминаем, и всех их, поскольку у нас база этих пользователей ведется, будем указывать в качестве мультикастового получателя. При этом нельзя отправить один публичный пакет, который дошел бы до многих разных публичных IP-адресов. Мы должны будем в этом случае фактически эмулировать мультикаст. Мы должны будем отправить кучу юникастовых публичных пакетов, которые будут предназначены для разных пользователей. Соответственно, ненастоящий, конечно, будет мультикаст, но тем не менее другого у нас нет. Заставить между Spoke-ами мультикаст ходить без изощрений не получится вообще никак. Мультикаст между Spoke-ами в принципе не ходит. После того, как мультикаст у нас такой кривой-косой завелся,

нужно будет сказать, кто кого как будет видеть. Соответственно, если мы используем мультикастовое взаимодействие для обнаружения соседей, то нам нужно будет убедиться, что этот самый центральный роутер, который у нас хаб, он видит всех, а все видят его. Как следствие, если у нас происходят какие-то изменения в OSPF, они в первую очередь должны быть отправлены не кому попало, а именно этому самому центральному хабу. Поэтому именно центральный хаб у нас должен стать Designated Router, диспетчером. И, соответственно, если изменения какие-то возникнут, то он их отправит дальше всем остальным участникам в этом самом виртуальном туннеле. Мы прописываем, что у нас есть приоритет при выборах DR и BDR, IP OSPF Priority. Мы указываем, что у нас есть этот туннельный интерфейс, соответственно, который сидит в нулевом регионе, например. И мы указываем тип среды Broadcast. На курсе по маршрутизации разберемся, что это такое.

И со стороны Spoke указываем то же самое. IP OSPF Network Broadcast, IP OSPF 1 и Area 0. И мы указываем IP OSPF Priority 0, что мы отказываемся от роли DR. Эти все узлы не могут быть ни DR, ни BDR. Они могут быть только DR Other. И они фактически очень сильно зависят от хаба. Покуда хаб жив, они с ним работают. Если хаб сдох, DMVPN у нас немножко развалился. DMVPN — это большая толстая штука. Мы сейчас рамочно его посмотрели. Посмотрели на то, что в принципе он включается, на то, что там есть с чем поработать. Есть сложности с мультикастом, есть сложности с динамической маршрутизацией вследствие сложности с мультикастом. Поэтому если у вас есть проблемы с DMVPN, нужно будет сначала посмотреть, работает ли инкапсуляция GRE. Если GRE работает, работает ли NHRP, проходит ли корректная регистрация NHRP, проходит ли резолвинг публичных IP-шников.

Если нужно гонять динамическую маршрутизацию, работает ли мультикаст, корректно ли настроен протокол динамической маршрутизации для работы в такой кривой среде. Поэтому там много чего может пойти не по плану. И это многое будет очень сильно зависеть от того, что конкретно вы там гоняете. Если говорить про то, с чем чаще всего возникают проблемы в DMVPN, это некорректная регистрация спока на хабе. И для того, чтобы посмотреть, кто конкретно из узлов какой публичный IP-шник соседа будет знать, есть команда show IP NHRP. На хабе все споки должны будут регистрироваться, поэтому если мы на хабе делаем show IP NHRP, у нас все споки будут показываться. В нашем случае, например, 10.0.0.2 по /32 маске зарегистрировался. Динамическая регистрация, публичный IP-шник 203.0.113.2. Если мы на споке пытаемся ту же самую команду выполнить, show IP NHRP, то показывается, что у нас есть узел 10.0.0.1, это IP-шник хаба, публичный IP-шник у него вот такой,

и тип у него будет static. Логику, я думаю, вы примерно поняли. Показывается, как давно запись создана и через сколько она протухнет. Срок записи в таблице NHRP будет 2 часа по умолчанию. Если захотите, можно его изменить. Как правило, это не требуется. Основная сложность с DMVPN заключается не в том, что там срок жизни у этих записей слишком маленький, а в том, что, как правило, либо регистрация не проходит вовсе, либо проходит, но неправильно. И здесь можно будет посмотреть, что конкретно там зарегистрировалось, какие публичные IP-шники узлам будут известны и известны ли вообще. На этом с DMVPN предлагаю закрыть тему. Тема большая. Мы обзорно на него посмотрели, лабу делать не будем. И перейдём к следующему материалу.