Работа с канальными средами в Cisco IOS (часть 2)

Закончили вчерашнее занятие на том, что сделали лабу на PPPoE. Мы посмотрели, как настраивается аутентификация в PPPoE, посмотрели, что можно использовать PPPoE в PPPoE-сценарии. Это не единственное место, где вы можете встретить PPPoE. Все VPN, всякие L2TP, PPTP, они тоже будут использовать dialer-интерфейсы в цисках. Они тоже будут использовать те же самые команды по аутентификации. Так что если вы захотите поднять VPN, то так или иначе вы столкнётесь с теми же самыми виртуальными шаблонами, с теми же самыми дайлерами. И конфигурация этих интерфейсов будет очень сильно напоминать то, что мы с вами сделали на предыдущем занятии. Соответственно, следующая наша тема будет посвящена другому протоколу, который точно так же, как и PPPoE, может работать поверх serial-линков. А может работать и поверх других физических сред, где вы можете передавать нолики-единички.

Frame Relay изначально предназначен для среды, в которой вы можете передавать нолики-единички. Например, serial link позволяет вам передавать нолики-единички. Также всякие T1-интерфейсы могут передавать нолики-единички. Или E1. Это уже детали, где конкретно вы можете сформировать битовый поток. Но из этого битового потока надо каким-то образом составить кадры. И PPP-шный кадр — это один из вариантов, как можно составить из битиков какую-то осмысленную последовательность. Но это не единственный вариант. Второй вариант — это, например, Frame Relay. Если вы включаете Frame Relay на интерфейсе, то вы указываете вместо encapsulation PPP — encapsulation frame relay. И тогда формат кадра будет использоваться именно FR-овский, а не PPP-шный. На самом деле у PPP и у Frame Relay есть очень много общего. Связано это с тем, что они оба выросли из старого протокола HDLC. Поэтому и Frame Relay-евские кадры тоже будут устроены как PPP-шные. Тоже между отдельными пакетами будут идти те самые флаги.

Нолик, 6 единиц, снова нолик. Тоже, если между флагами мы передаём какой-то кадр, и внутри кадра мы хотим передать последовательность из 6 единиц подряд, тоже мы её будем разбавлять нулями. После 5 единиц, неважно, что дальше идёт, мы всегда добавляем искусственный нолик. Если получатель принимает 5 единиц и видит после них нолик, он всегда этот нолик выбрасывает. Он понимает, что этот нолик искусственно разбавил единицы. Но у Frame Relay есть свои особенности, и связаны они с тем, что Frame Relay-евские кадры изначально предназначались для коммутации. Поэтому там есть те самые DLCI, которые указывают, куда их надо коммутировать. Есть всякие поля для того, чтобы уведомлять о перегрузке в сети, чего в PPP в принципе не было, потому что в PPP кадры не коммутируются. Вы можете отправить кадр Frame Relay, и он где-то по дороге может испытать перегрузку. У него будет проставлен флаг FECN, Forward Explicit Congestion Notification,

и в обратную сторону, соответственно, пакеты пойдут с BECN. Backward Explicit Congestion Notification. И тогда тот, кто BECN будет получать, он поймёт, что его кадры чудом прошли через какое-то место в сети, где возникла перегрузка, и он снизит нагрузку на сеть, будет отправлять данных поменьше. Плюс в кадрах Frame Relay есть некоторые другие фичи, которые специально предназначены для упрощения коммутации. Например, в Frame Relay-евских кадрах можно указать какие-то свойства Quality of Service. В Ethernet, например, никаких полей штатных для Quality of Service не было. В PPP никаких штатных полей для Quality of Service не было. Что Ethernet, что PPP — изначально некоммутируемые протоколы. Ethernet не создавался для того, чтобы его можно было коммутировать. Коммутация в нём появилась позднее и как дополнительный костыль, как эмуляция толстого жёлтого коаксиала, в котором коммутации быть не должно. Поэтому в кадрах Ethernet никаких следов ни Quality of Service, ни коммутации, естественно, не присутствует. А вот во Frame Relay такая штука есть.

И во Frame Relay может такое случиться, что кадры, которые будут проходить через коммутацию, будут испытывать какую-то перегрузку. Вам нужно одновременно два кадра, которые пришли на ваш свитч с разных сторон, выплюнуть через один и тот же интерфейс. И вам как минимум надо в определённом порядке их выплюнуть. Сначала один кадр, потом второй. И надо каким-то образом определить, кто из кадров достоин пройти через сеть первым, а кто вторым. И если получается, что нам можно положить, допустим, в исходящий буфер только один кадр, а второй туда уже не влезет, потому что перегрузка такая, что tail drop случается, то нам надо выбрать, какой из кадров мы всё-таки положим в очередь, а какой мы tail drop-нем. И во Frame Relay штатно была фича указать, какие кадры вы передаёте важные, которые нельзя терять по дороге, и какие кадры будут неважные, и их можно потерять по дороге. Там был специальный битик, который назывался Discard Eligible, DE. И этот битик указывал, важные кадры вы передаёте или неважные.

Если вы выставляли единичку, значит, этот кадр можно было потерять, и это было не ужасно. А если вы выставляли нолик, значит, кадр не допускает потери, и его надо обязательно любыми средствами передать в сеть. Сразу возникает вопрос, а зачем проставлять, что какие-то кадры важные, какие-то неважные, если мы в принципе хотим, чтобы все наши кадры проходили через сеть одинаково. Но всё-таки надо понимать, что если у нас все кадры абсолютно передаются через сеть одинаково, то математика нам всё равно в какой-то момент некоторые вещи сделать не позволит. Если у нас есть мегабитный интерфейс, и приходит в него 2 мегабита трафика, которые надо отправить, математика нам не позволяет через мегабитный интерфейс 2 мегабита отправить. Она всё равно скажет, что-то надо будет выкинуть. Поэтому если мы не проставляем, что какие-то кадры выкидывать можно, то они будут tail drop-аться. И tail drop-аться они будут по случайному механизму. Какой смог войти в буфер, тот молодец.

Какой не смог войти в буфер, тот не молодец. А если же мы будем проставлять битики Discard Eligible, что некоторые кадры важные, а некоторые кадры не такие важные, то тогда можно будет сказать, что то, что мы проставили, будет конкурировать с другими кадрами такого же типа. Но если вдруг у нас через интерфейс надо пропустить 2 мегабита трафика, а пропустить по факту можно только один, то сбрасывать в первую очередь будут как раз мегабит того трафика, который помечен как неважный. Вы должны будете сами проставить своим кадрам метки, в каких кадрах передаётся что-то важное, в каких нет. Если у вас будет телефония, например, передаваться, вы должны будете ей, конечно, проставить метки, что это важные кадры, что это non-discard eligible. Но если вы передаёте, допустим, просто какой-то трафик, например, TCP, то ему можно смело проставлять флажок, что это можно потерять, и TCP потом передоставит всё недостающее

и постарается ещё и управлять нагрузками на сеть, что если в сети TCP будет видеть, что идёт перегрузка, он притормозит сам передачу и нагрузку снизит. Поэтому во Frame Relay такие вещи были, и в отличие от других протоколов, в которых коммутация изначально не была предусмотрена, во Frame Relay она изначально была. Поэтому Frame Relay изначально позиционировался как специальный провайдерский протокол, который коммутируемый, который хорошо работает во всяких WAN-сетях, и в своё время его очень сильно любили. Альтернатив ему для передачи просто абстрактных данных особо не было. Были всякие телефонистские протоколы, но у них были свои заморочки, они были адаптированы для передачи голоса, они не были адаптированы для передачи совершенно произвольных данных. Чтобы и переподписку можно было сделать, и в то же время гарантировать определённую полосу, и управлять качеством — это всё появилось только в пакетных сетях.

И Frame Relay был одним из первых протоколов, который позволял всё это делать. Есть ли вероятность, что приоритетный трафик займёт 100% полосы? Да, конечно, такая вероятность есть. Если вы не будете разбивать никакой трафик на тот, который подлежит отбросу в первую очередь, и не подлежит отбросу в первую очередь, если вы просто весь трафик промаркируете как важный, он у вас весь будет пытаться занимать 100% полосы, и дальше вам всё равно среди этих кадров надо будет выбрать какие-то, которые потеряются, а какие нет. Поэтому если вы так плохо промаркировали трафик, что по факту начинают теряться важные данные, то значит вы сами себе злобный Буратино. Ваша задача промаркировать трафик так, чтобы важного трафика было заведомо меньше, чем может пройти через интерфейс. Как правило, если вы провайдер, вы позволяете своим клиентам, которые будут к вашей сети подключаться, промаркировать важным трафиком, важным этим битиком, не более чем определённую полосу.

Вы говорите: дорогой клиент, вот у тебя двухмегабитный интерфейс, я эти два мегабита от тебя принимаю и дальше по своей сети пропускаю. Получится у меня пропустить по своей сети два мегабита? Прекрасно, у тебя будет двухмегабитный канал. Не получится — мне придётся твои кадры дропать. Но если ты мне поможешь и скажешь, какие кадры можно дропать в первую очередь, то тем самым получится, что твой трафик, который будет важный, я пропущу в приоритете. Но чтобы ты не хамил и не пометил весь трафик как суперважный, я от тебя буду принимать не более чем, например, 20% трафика, помеченного как важный. И если 20% трафика важного я приму, и где-то у меня в сети будет затык, вот эти 20% я прокоммутирую в приоритете. Остальное — по остаточному принципу. Флаг DE выставляется на уровне пакетов. В каждом пакетике у вас есть битик, и вы этот битик можете либо поставить, либо не поставить. На самом деле аналогичная история есть в 802.1p,

в протоколе, который появился позднее в качестве развития Ethernet, и мы его знаем как 802.1Q. Там есть, если помните, заголовок 802.1Q. Сначала идёт 2 байта, это 0x8100, хорошо известный EtherType для 802.1Q-меток. Потом идёт 3 битика 802.1p приоритета, и один битик, который раньше назывался Canonical Format Identifier, а потом его переименовали в Discard Eligible Identifier. И этот Discard Eligible в актуальных версиях 802.1p — это ровно тот же самый Discard Eligible, который был во Frame Relay. И потом уже 12 бит, собственно, метки VLAN. Так что в современных актуальных версиях Ethernet, если вы помечаете кадры метками 802.1Q, у вас тот самый Discard Eligible битик в каждом пакетике тоже будет бегать, в котором есть метка 802.1Q. Давайте разберёмся, как настраивается Frame Relay

со стороны клиента. Как настраивается провайдерская часть, мы рассматривать не будем, тем более что Frame Relay-свитчей Cisco никогда не делала, и Frame Relay-свитчи — это всегда была отдельная тема. Но вот Frame Relay клиентские железки, DTE-шки, Cisco делала и вполне себе успешно. Давайте разберёмся, как они настраивались. У нас был serial-интерфейс. Мы на нём помечали encapsulation frame relay. Он обозначал, что кадры мы отправляем не PPP-шные, не HDLC-шные, как по умолчанию, а именно FR-овские. Дальше. Мы указывали, что нам известна DLCI к соседу. Мы подключались со стороны роутера R1 к провайдерскому свитчу. Их может быть много. Один свитч или несколько свитчей — для нас неважно. Для нас вся вот эта вот — сеть провайдера. Провайдер говорит: дорогой клиент, ты купил канал от R1 до R2.

Соответственно, я тебе сообщаю, что чтобы добраться до R2, на R1 ты должен кадры отправлять с DLCI сотой. И я тебе прописал PVC, Permanent Virtual Circuit, так, чтобы от R1 кадры до R2 доходили. И всё, что ты отправишь с сотой меткой, я буду коммутировать в сторону R2. И мы должны будем каким-то образом сообщить, что IP-шник роутера R2 будет доступен за сотой DLCI. И мы прописываем статический маппинг. Frame Relay Map IP. Map IP означает, что мы прописываем маппинг IP-адреса к DLCI. Дальше указываем IP-шник 172.16.0.2. Указываем DLCI, в нашем случае сотку. И если хотим, можем добавить слово Broadcast. Эта фича, слово Broadcast, будет означать следующее. Во Frame Relay Broadcast нету. Вы не можете отправить один кадр в Frame Relay, который дойдёт до более чем одного участника. Вы всегда можете отправить только Unicast-кадры. Но если вам известно,

что есть, допустим, провайдерская сеть, и в этой провайдерской сети есть несколько соседей, R2, рядом здесь будет какой-нибудь R3, здесь R4, и всё это ваши роутеры. У вас ко всем ним куплены PVC. Вы купили канал между R1 и R4, между R1 и R2. И здесь у вас будет, например, 103-я DLCI, здесь будет сотая DLCI, и здесь будет 104-я DLCI. Три DLCI вы купили. И вы хотите отправить какой-то IP-пакет так, чтобы он дошёл до всех трёх узлов одновременно. В Ethernet вы бы сказали: окей, прекрасно, отправим мультикастовый кадр, и он дойдёт до всех, кому нужно. Или Broadcast-кадр. В Frame Relay вы не можете отправить Broadcast-кадр. Вы можете отправить только три разных Unicast-кадра. Но бывают такие протоколы, которые говорят: а нам всё равно хочется отправлять Broadcast. Например, тот же самый RIP.

Если вы включаете RIP на интерфейсе, у вас всего один интерфейс Serial 0/1/0. Вы можете сказать на нём: давайте включать RIP. И этот RIP будет отправлять мультикастовые пакеты на адрес 224.0.0.9. Вы его не можете отучить от этого мультикастового адреса. Он только на него будет отправлять пакеты. И ваша Cisco может симулировать наличие Broadcast / Multicast на интерфейсе. Она может сказать: окей, когда к нам приходит IP-пакет, который надо промультикастить или пробродкастить на физическом уровне, мы скажем: да-да, всё сделаем, дорогой товарищ. И мы берём один IP-пакет и разделяем его на три разных Unicast-кадра. Мы сделаем одну копию Unicast-кадра до роутера R2, другую копию этого же Unicast-кадра на R3 и третью копию для R4. И только у них DLCI будут стоять разные. До R2 будет стоять сотая DLCI, до R3 будет стоять 103-я, до R4 — 104-я.

IP-пакет был один, но на этапе эмуляции Broadcast Cisco вместо одного Broadcast-кадра с этим Broadcast или Multicast пакетом сделала три разных Unicast с одним и тем же содержимым. Это именно эмуляция Broadcast. Cisco такое делать умеет, и среди всех, кому вы пропишете слово Broadcast, им будет отправляться автоматически копия Broadcast или Multicast IP-пакетов в отдельном Unicast-кадре Frame Relay. В большинстве ситуаций вы как раз хотите, чтобы это происходило, чтобы просто включить, например, условный тот же самый протокол RIP, и чтобы он автоматически работал, вы не должны будете ничего специального делать, чтобы он просто работал. Да, он ожидает увидеть Multicast, да, Multicast-а во Frame Relay нету, но Cisco его эмулирует. Никаких проблем нету с тем, что на самом деле это не полноценный Multicast, потому что по факту вы заранее должны всё равно знать, какие PVC у вас есть,

за какие PVC заплатили деньги, какие DLCI для доступа к этим PVC будут использоваться. Если у нас есть IP-шник соседа 172.16.0.2, мы говорим: 172.16.0.2 соответствует DLCI сотой, и копии эмулированных бродкастов ему отправляем. Если рядышком будет другой роутер с IP-шником 172.16.0.3, мы точно такую же запись сделаем: Frame Relay Map IP 172.16.0.3, DLCI уже какая-то другая, и тоже добавим слово Broadcast. Что важно, интерфейс при этом у нас остается всего один. Мы одним интерфейсом смотрим на нескольких соседей, как в случае с Ethernet, например. И сама среда Frame Relay уже определяет, куда конкретно ваши кадры до определенного соседа отправить, так, чтобы они до него дошли. Если вдруг вам хочется IPv6, никаких проблем. В IPv6 всё то же самое делается. Мы указываем link-local адреса,

и мы указываем маршрутизируемые адреса, если нам это будет необходимо. И опять же указываем соответствующие DLCI. Если вдруг нужен мультикаст или бродкаст, то же самое ключевое слово «бродкаст» абсолютно точно так же будет работать. Для маршрутизируемых адресов обычно бродкаст и мультикаст не сильно интересен, а вот как раз для link-local адресов это будет полезно. С другой стороны, как видите, ответные действия: прописывается IP-шник соседа, DLCI, ключевое слово «бродкаст» для того, чтобы эмулировать наличие мультикаста-бродкаста. Для IPv4 у нас отдельная строчка, для IPv6 у нас тоже отдельная строчка с той же самой DLCI, на самом деле должно быть 200, а не 100. И маршрутизируемый IPv6 адрес, тоже указываем, что DLCI всё то же самое. И какой бы мы IP-шник ни использовали для, допустим, пинга соседа, допустим, хотим попингать fe80::2,

никаких проблем. Отправляем пинги, находим канальный адрес соседа с помощью вот этой frame-relay map IPv6, указываем DLCI сотку, и по этой PVC-шке трафик отправляется до R2. Предполагается, естественно, что link-local адрес у него действительно будет fe80::2. Его ручками надо будет как-то назначить. Если хотите, можете совершенно произвольный link-local адрес назначать, команда IPv6 address, и после указания link-local адреса вы указываете ключевое слово link-local. Тогда можно вот такие красивые link-local назначать. Как уже говорилось, Frame Relay — это протокол специфический. И специфичность его заключается в том числе и в том, что у него необязательно будет полносвязная топология между всеми участниками.

Может быть такое, что у вас есть несколько роутеров, которые подключены к Frame Relay сети. Вот как на картинке. Это роутер R1, R2, R3 и R4. И все они подключены к одному и тому же провайдеру. И провайдер этот предоставляет доступ по Frame Relay. Но вам было жалко денег, вы не захотели покупать полную связь между всеми четырьмя роутерами. Потому что иначе пришлось бы купить связь между первым и вторым, между первым и третьим, первым и четвертым, вторым и четвертым, вторым и третьим, третьим и четвертым. Это шесть каналов. Может быть такое, что вы скажете, нам не нужно передавать трафик между любыми двумя узлами. По крайней мере, не нужно делать это часто. Мы хотим организовать передачу данных между первым и вторым, между первым и третьим, между первым и четвертым. Ещё иногда мы хотим между третьим и четвертым тоже гонять трафик напрямую. Вот как в такой ситуации выходить из положения для того, чтобы корректно прописать адреса

и корректно дать роутерам понять, кто с ними находится в одной сети, а кто с ними в одной сети не находится. Потому что если мы повесим на все эти интерфейсы, которые у нас есть на serial-линке, IP-шники, то мы должны будем сказать, что-то у нас там будет типа 172.16.0.1, 172.16.0.2, 172.16.0.3, и 172.16.0.4. И получится, что если мы везде 24-ю маску повесим, то мы тем самым говорим, что все узлы, которые находятся с нами в одной сети, у которых левые 24 бита будут такие же, как у нас, они все должны находиться с нами в одном канале, и мы до них можем достать. Если мы говорим на R1, что 172.16.0.1 по 24-й маске, то 172.16.0.2, 0.3, 0.4 находятся все за вот этим интерфейсом, который смотрит на Frame Relay сеть. И это, конечно, так, потому что действительно

R1 может отправить пакет на адрес 172.16.0.2, 0.3, 0.4, и трафик даже дойдет до получателя, потому что все PVC куплены. Но если, например, у нас будет какой-нибудь условный R3 роутер, который захочет отправить на R2 пакет, у него есть IP-шник 172.16.0.3 по 24-й маске, он говорит, всё, что у меня начинается на 172.16.0, всё находится со мной в одном канале, здесь 172.16.0, здесь 172.16.0. У нас есть прямая связанность между собой. Получатель находится за serial-интерфейсом. И он должен будет сказать, что я хочу отправить пакет на 172.16.0.2, и IP говорит ему, да, всё хорошо, отправляй. И здесь возникает затык. А на какой именно канальный адрес надо отправить этот пакет? А канального адреса нету, потому что DLCI не прописан. И он прописан быть не может, потому что PVC-шки нет. И в этой ситуации R3 говорит, а я не могу отправить пакет на адрес, который находится со мной в одном канале. А что делать, если очень хочется? PVC-шки нету,

а всё-таки хочется отправлять трафик. Здесь нас выручат так называемые логические интерфейсы или субинтерфейсы. Дело в том, что в Frame Relay мы можем соорудить такую же штуку, как в 802.1Q субинтерфейсы у нас были. То же самое и здесь. Можно поверх физического интерфейса нарисовать несколько логических, которые будут видеть некоторое подмножество узлов, находящихся за соседней железкой. Во Frame Relay есть два типа логических интерфейсов. Это point-to-point интерфейсы, которые смотрят всегда на одного и того же соседа, и весь трафик, который отправляется в этот интерфейс, он отправляется всегда на одну и ту же DLCI. Есть второй тип интерфейсов. Это point-to-multipoint интерфейсы. Там вы должны будете точно так же, как и в случае с родительским интерфейсом, прописывать маппинги. Но фишка в том, что если у вас есть физический интерфейс, и вы поверх него поднимаете несколько логических интерфейсов, то вы можете на эти логические интерфейсы назначить разные сетки. И тогда получается,

что у вас есть ваша топология, в которой есть PVC-шки, которые кое-как на кого-то смотрят, и вы эти наборы PVC-шек фактически разбиваете на некое подмножество. Либо point-to-point-овые, либо, по крайней мере, полносвязные подмножества PVC-шек. В нашем случае у нас есть канал между R1 и R2. И это будет point-to-point логический линк. Вот этот вот. В нем всего два участника, а нам больше не надо. И есть одно подмножество между R1, R3 и R4. Есть полносвязная топология. Мы говорим, да, R2 не всех видит, но нам это не надо, он будет видеть только R1. И мы поднимаем логический субинтерфейс, говорим interface, дальше называем физический интерфейс serial 0/0 и дальше точка 102. Эта точка 102 будет означать просто номер логического интерфейса. Вы можете использовать любые номера, которые захотите. Я вам рекомендую использовать такие же номера,

как DLCI. Это просто удобно, вы не запутаетесь, когда будете видеть, что у вас номер логического интерфейса какой-то определенный, вы будете понимать, что это тот самый логический интерфейс, который использует DLCI 102. Дальше. Так же, как в 802.1Q, для того, чтобы логический интерфейс заработал, нам нужно будет указать, какой трафик на этот интерфейс будет отсылаться. В 802.1Q мы должны были указать команду encapsulation dot1Q и дальше номер VLAN. А здесь мы указываем frame-relay interface-dlci и номер DLCI. Эта команда по смыслу абсолютно аналогична команде encapsulation dot1Q в настройке роутерного субинтерфейса 802.1Q. После этого на этот интерфейс мы можем повесить IP-шник. Например, 168.1.1 по 30-й маске. Прекрасно. С другой стороны, на роутер R2 мы тоже создаем логический интерфейс Serial 0.0.102 Point-to-Point.

Опять же, вот это 102 обозначает номер DLCI. Если у вас здесь вдруг трафик между R1 и R2 будет использовать какую-то другую DLCI, можно использовать другую. То есть, здесь вот эта вот DLCI, она не обязательно должна быть такая же, как вот здесь. И вы указываете, соответственно, номер субинтерфейса, номер DLCI. Не обязательно они должны совпадать, но удобно, когда они совпадают. Просто шансов запутаться будет меньше. И ответный IP-шник прописываете IP-адрес 192.168.1.2 по 30-й маске. После этого у нас получается логический субинтерфейс, который смотрит только на одного соседа, на котором используется отдельная сетка по 30-й маске. В этой 30-й сетке есть только один соучастник. И для того, чтобы отправить трафик в этот субинтерфейс, мы используем всегда одну и ту же DLCI-ку 102. Мы здесь не прописываем, что именно 192.168.1.2 будет иметь IP-шник такой-то, а DLCI-ку такую-то, потому что вот эта вот команда

говорит, что если что-то отправляется в интерфейс, оно всегда отправляется на одну и ту же DLCI-ку 102. поэтому даже если вдруг у нас каким-то макаром за этим интерфейсом образуется много разных IP-шников, они все будут маркироваться 102-й DLCI-кой. В то же время, соответственно, если у нас есть что-то более сложное, чем Point-to-Point-Link, то, соответственно, нам понадобятся мультипоинт-интерфейсы. В принципе, вы можете абсолютно любую топологию разбить на кучу Point-to-Point-интерфейсов. Если у вас будет вот такая вот топология, типа как на рисунке, вы можете сказать, вот у нас раз пара Point-to-Point-интерфейсов, вот два пара Point-to-Point-интерфейсов, вот три пара Point-to-Point-интерфейсов, вот четыре. То есть, всю эту топологию можно разбить на отдельные PVC-шки, каждые PVC-шки, просто сделать отдельный Point-to-Point-субинтерфейс. Это абсолютно простой, как барабан, подход. Если у вас IP-шников достаточно, это будет, на самом деле, лучше всего, если вы это сделаете, потому что эти Point-to-Point-интерфейсы, они предсказуемые, они прекрасно работают и вопросов, в общем-то, даже не задают.

Но у CISC есть нюанс. CISC иногда на экзаменах любят спрашивать, а что, если у нас IP-шников мало? Потому что на каждой вот этой вот отдельной Point-to-Point-сетке мы должны выделить отдельную 30-ю сеть. То есть, у нас на каждой два IP-шника, которые мы по факту используем, используется еще два IP-шника служебных. Ну и плюс к тому, да, вот у нас получается четыре роутера, на каждом из них нужно будет прописать, здесь у нас три IP-шника, здесь три IP-шника, нет, здесь два IP-шника, здесь тоже два, здесь один. Получается всего восемь адресов и плюс еще восемь служебных. 16 адресов нам потребуется. А CISC может вполне сказать, а что если у нас столько просто нету? Вот мы должны везде обязательно белые IP-шники вешать, а у нас просто с 16 белых IP-шников в распоряжении нету, у нас адресов меньше. Мы должны экономить адреса. Что в такой ситуации? В такой ситуации нас спасут Point-to-Multi-Point, где мы берем и в неком подмножестве PVC-шек, которые при этом полносвязные,

мы объявляем, что это подмножество PVC-шек будет использовать отдельную IP-сеть. В нашем случае это подмножество вот такое вот. То есть R1, R3, R4 друг друга видят полностью целиком. R1 видит R3, R3 видит R4, R4 видит R1. И мы говорим, окей, значит, мы вот в этом подмножестве делаем на каждом роутере отдельный Point-to-Multi-Point интерфейс. Указываем интерфейс, serial 00. чего-то там. Это опять же номер субинтерфейса, он не обязан ни с чем совпадать. Если вы придумаете какую-то систему нумерации ваших Point-to-Point интерфейсов, чтобы вы не запутались, окей, пожалуйста, используйте их. Я просто выбрал номер 9, потому что он мне просто нравится. И указываете ключевое слово Multipoint. Дальше указываете, какой у вас IP-шник будет висеть. Вот 10.001. Я сделал по 24-й маске, но это просто вот так, чтобы для красоты было. Вы можете использовать любую маску, которая вас устроит. Но вы должны будете понимать, что в этом канале с вами будут жить

еще как минимум два других роутера. То есть в нашем случае 10.003 и 10.004. И вот здесь уже халявые уровни интерфейса DLC-i отделаться не получится. Вы должны будете прописать Frame Relay, Map IP, IP-шник, DLC-i, ну, если захотите использовать слово Broadcast. У вас тогда будет подобие Multicast и там будут работать всякие штуки типа OSPF, обнаружение соседей в кавычках обнаружение, RIP, EJRP и всякое такое. Вот. Мы указываем, что у нас есть 10.003, указываем, что у нас есть 10.004, указываем их DLC-i, и получается, да, что на R1 настроили все, на R3 настроили точно такой же Multipoint-интерфейс. Номера Multipoint-ов не обязаны совпадать на соседних железках, но просто удобно, когда они у вас одинаковые. Тоже вешайте IP-шник, прописывайте соседей. Ну, и на R4 абсолютно аналогично все. Здесь нет смысла переводить конфиг, потому что он абсолютно идентичен. Только вот здесь будет четверка, здесь будет, соответственно,

тройка. Ну, и DLC-i, тройка. Ну, и, возможно, какие-то эти самые DLC-i изменятся. Смысл, я думаю, что вы поняли, что в некотором подмножестве PVC-шек, которые при этом полносвязаны, мы, соответственно, делаем один интерфейс, который смотрит на всех соседей сразу. И в этом интерфейсе указываем, какие конкретно PVC-шки, с какими DLC-i смотрят на каких соседей. Соответственно, есть предположение, что абсолютно любую топологию можно разбить на Point-to-Point интерфейсы. И в подавляющем большинстве случаев, если у вас есть какая-то кривая, косая топология, можно среди этой топологии вычленить какие-то участки, которые будут полносвязаны, и сократить множество Point-to-Point линков до Point-to-Point мультипоинтов в каких-то вот областях. Если вдруг вы считаете это необходимым, вы можете это сделать. Если вдруг зачем-то в какой-то ситуации вам придется работать с Frame.RDM, я призываю вас использовать Point-to-Point интерфейс. Это более разумно,

потому что легче траблшутить, легче управлять, а IPшники, особенно если частные, ну, особых проблем с их экономией, в общем, встречать не приходится. Point-to-Point это просто, это надежно, ну и да, то есть проблем с ними быть не должно. С Point-to-Multipoint будут проблемы, потому что там в таких интерфейсах приходится специальным образом настраивать протокол динамической маршрутизации, тот же SPF, приходится там изощряться, как-то изгаляться, чтобы узнать, кто кого как видит, поэтому Point-to-Multipoint я вам не рекомендую. Но, тем не менее, знать про него, про то, что он бывает, нужно. Так, как проверить, что Frame Relay у вас работает? Во-первых, вы можете посмотреть на маппинги, те, которые вы прописали ручками, или вдруг, если у вас есть какие-то маппинги, которые автоматически образовались с помощью протокола Inverse Arp, я напомню, как он работает, он во все живые DLCI, которые он узнает с помощью сигнализации, отправляет свой

IP-шник. И когда у вас поднимается интерфейс, и вдруг из-под какой-то DLCI прибегает пакет Inverse Arp с криками «Я такой-то», вы запоминаете его в списке маппингов и, как правило, как раз со статусом «Браткаст». Вот пример того, как это будет выглядеть. IP-шник 172.16.02, DLCI-к 100, и вот этот вот дайнемик как раз намекает на Inverse Arp. Вот. «Браткаст» ставится автоматом. У Inverse Arp есть ограничения, он работает только поверх физических интерфейсов, то есть в субинтерфейсах он не будет работать. Если у вас субинтерфейсы, то вы должны будете все ручками прописывать. На субинтерфейсах Point-to-Point-ах вы прописываете, что у вас DLCI-к смотрит на всех соседей сразу, то есть не на какого-то конкретного соседа с IP-шником, а на всех соседей, которые живут за Point-to-Point-субинтерфейсом. Поэтому здесь вот IP-шник не показывается, здесь показывается Point-to-Point-DLCI. И показывается, какая она. 102-ая. Она живет на интерфейсе 0.10.102,

и весь трафик, который отправляется в этот субинтерфейс, промаркируется 102-ой DLCI-кой. На Point-to-Point-мультипойнтовых интерфейсах, на, простите, субинтерфейсах Point-to-Multipoint мы указываем все IP-шники ручками, указываем DLCI-ки, они получают статус static, broadcast, если вы проставили, я думаю, что вы проставили. Ну, да, то есть Show Frame Relay Map на самом деле это некое подобие Show IP ARP в каком-то смысле. Кто за какой DLCI-ка сидит с каким IP-шником. Дальше. Что еще нужно будет на самом деле здесь знать? Не хватает здесь таблички, я ее, кажется, забыл. Show Frame Relay DLCI. Это нам покажет статистику по сигнализации. Если вдруг вам провайдер присылает Show Frame Relay PVC, простите, Show Frame Relay PVC, покажет статистику, которая сигнализация провайдера вам присылает, какие DLCI-ки живы, какие нет.

То есть, если вы видите там статус active, значит, все хорошо, DLCI-ка, она живая, и в нее можно отправлять трафик, и, соответственно, из-под нее тоже трафик может выбегать. Ну, и Show Frame Relay Map вы можете посмотреть, кто за этой DLCI-ка сидит. Вот. Если вы видите, что Frame Relay PVC вам ничего не показывает, там должны бегать пакетики Enquiry, в которых вот как раз сигнализация передается. Если вдруг вы видите, что все счетчики там по нулям, вообще абсолютно все, то, значит, сигнализация не работает, значит, интерфейс не живой. Так. Вы можете, если захотите, включить Frame Relay на интерфейсах в виртуальных железках. Не на нашем стенде, но, однако, на большинстве эмуляторов, которые доступны сегодня на рынке, вот вы можете попробовать включить Frame Relay. Соответственно, что и ОУ, что динамипсовские эмуляторы, они позволяют создать сериаллинки, и в этих сериаллинках

можно будет включить Frame Relay. Если вдруг вы это захотите сделать, вам потребуется несколько команд, которых у нас на слайдах не было. Сейчас я напишу их. Первая команда нужна будет для ситуации, когда вы соединяете между собой два роутера. То есть, вот у вас два роутера, там R1 и R2. Один роутер просто подключается к сети, и он себя считает DTE. Он себя считает DTE с точки зрения сериаллинка, то есть, он адаптируется под тактовую частоту, которую сообщает ему DTE. И он себя считает DTE с точки зрения Frame Relay. То есть, он подстраивается под сигнализацию, которую присылает ему сосед. Вот это вот DTE, соответственно, есть DTE сериаллинка, а есть DTE Frame Relay. Если вы, соответственно, с другой стороны будете подключать тоже вашу же эмулированную железку, то вам нужно будет, во-первых, задать команду ClockRate, чтобы железка стала DTE виртуальной и начала задавать тактовую частоту на Serial Link. А во-вторых, нужно будет Frame Relay переключить в режим DTE и команда будет

Frame Relay IntType DTE. Это как раз позволит отправлять сигнализацию Frame Relay на соседа. Вот. Кроме того, есть команда Connect. Я рекомендую вам, если вдруг вы будете изучать вопрос, как, соответственно, настроить Frame Relay на ваших железках, просто вопросиком посмотрите, она абсолютно понятная. Connect в глобальном конфиге указывает интерфейс, через который приходит трафик, DLCIQ, через который приходит трафик, интерфейс, через который трафик должен уйти, DLCIQ, с которой пакеты должны будет уходить. Ну и она, команда двусторонняя, то есть трафик, который приходит, вы отправляете сюда, трафик, который приходит отсюда, вы отправляете сюда. То есть что-то типа Connect, Serial 1.0, там, DLCIQ и сотка, Serial 1.1, DLCIQ и двухсотка. Это вот как раз пополнение таблицы коммутации Frame Relay, когда вы пытаетесь проэмулировать

Frame Relay Switch с помощью Cisco Router. Вот. Ну, я надеюсь, что вам это никогда не пригодится, потому что Frame Relay все-таки уже технология мертвая. А в MPLS в ручками вы никогда ничего не будете прописывать, поэтому тоже вам это не понадобится. Поэтому этого и на слайдах не было. Что касается GRE, да, мы с вами обсуждали теоретическую часть GRE, что GRE просто берет пакеты и оборачивает их в заголовок. Ну, соответственно, делать это можно по-разному. И Cisco делают это следующим образом. Они порождают виртуальный интерфейс, который будет называться туннель, и дальше у него будет циферка. Ну, то есть, циферку вы можете сами создавать. Туннельных интерфейсов можно наплодить сколько угодно, они виртуальные. Ну, и, соответственно, все, что отправляется в такой виртуальный интерфейс, на самом деле будет оборачиваться как раз добавленным заголовком. Будет формироваться новый пакет, и этот пакет будет отправляться по таблице марштизации как вот, ну, абсолютно другой пакет. То есть, если у нас есть узел 10.0.1.2,

который хочет отправить пакет на 10.0.2.2, он отправляет пакет. Этот пакет доходит до роутера R1. R1 говорит, я беру пакет с 10.0.1.2 на 10.0.2.2, маршрутизирую его по таблице маршрутизации, нахожу выходной интерфейс, и это будет туннельный интерфейс ГРОЕ. Дальше я оборачиваю старый пакет новым заголовком. У меня получается новый пакет, и новый пакет уже будет идти с других IP-шников на другие, ну, то есть, не с IP-шника 10.0.1.2 на 10.0.2.2, а он будет идти со 192.0.2.1 на 203.0.1.3.2. То есть, у этого пакета получается два IP-заголовка, разделенные между собой заголовком ГРОЕ. Когда у нас все узлы посерединке будут пропускать такие пакеты через себя, они не смотрят на содержимое при маршрутизации, они заглядывают только в заголовок IP-пакета

внешнего, и, соответственно, они будут видеть только публичные IP-шники. Ну, соответственно, да, когда такой пакет приходит на R2, он приходит на IP-шник 203.0.1.3.2, узел R2 видит номер вложения 47, он понимает, что это протокол ГРЕ что-то прислал, смотрит на IP-шники отправителя-получателя, заглядывает внутрь ГРЕ-шного заголовка, если видит там ключ, он, соответственно, берет и ключ тоже. Дальше всю совокупную вот эту связку IP-шник отправителя, IP-шник получателя и ключ в поле ГРЕ сравнивает со списком того, что у него зарегистрировано в качестве интерфейсов, и понимает, что конкретный пакет со 192.0.2.1 на 203.0.1.3.2 приходит из интерфейса Туннель 0. То есть заголовок ГРЕ-шный срезается, внешний транспортный заголовок тоже срезается и остается оригинальный IP-пакет. Этот IP-пакет отправляется уже на движок маршрутизации. Ну и, соответственно, там уже мы говорим, что у нас пакет шел

на 10.0.2.2, поэтому выпустить такой пакет надо через в нашем случае Gigabit.01 интерфейс. Фактически по таблице маршрутизации внутренней сети у нас пакет маршрутизируется там, где собственно говоря видно этот самый оригинальный заголовок. То есть вот здесь и вот здесь в тех частях сети, которые будут частные. В этой части узлы транзитные не будут видеть внутренние частные адреса, они будут видеть только внешний транспортный заголовок с публичными IP-шниками и маршрутизация будет идти только по вот этим публичным IP-шником. Здесь сразу надо будет оговориться, что если внутри своей сети вы можете настроить политики quality of service, вы можете допустим влиять на то, что голосовые пакеты отправляются с определенным приоритетом, то есть внутри вот этой части сети и внутри вот этой части сети это ваша сеть, вы можете делать все, что угодно, приоритизацию можете настраивать и так далее. Но в интернете

вы механизмы quality of service никогда не сможете контролировать, потому что это чужая сеть, не находящаяся под вашим контролем, поэтому пакеты, которые вы отправите, они могут теряться, они могут фрагментироваться, они могут реордериться, то есть с ними может произойти все, что угодно. Это обычная IP-сеть. И поэтому, несмотря на то, что с логической точки зрения, вот этот вот интерфейс туннель, это просто псевдопровод, по факту это не провод, это некая виртуальная сущность, которая все равно состоит из одной большой транспортной IP-сети. И в этой IP-сети возможны всякие неполадки. Поэтому рассчитывать на то, что грешный туннель всегда будет хорошо работать так же хорошо, как физический провод, вы не можете. В этом проводе, виртуальном псевдопроводе могут теряться данные. Но, тем не менее, настройка будет происходить следующим образом. Когда у нас есть что-то вот подобное, что мы хотим реализовать, связь между двумя офисами, то есть фактически вот это вот можно сказать, у нас, допустим, может быть офис

московский, а вот это вот у нас офис, например, питерский. И вот мы говорим, что вот мы хотим связать эти два офиса, мы поднимаем типа туннель, типа псевдопровод, и в этот псевдопровод мы хотим маршрутизировать наши данные. Что для этого мы должны будем сделать? Внутренний интерфейс на роутере R1 у нас гигабит 01, гигабит 01, проверяем, что там IP-шник свой, хороший, частный IP-шник. Гигабит 00, это, соответственно, публичный IP-шник, 192.0.2.1. Ну, да, вот он 192.0.2.1. Дальше, поднимаем туннельный интерфейс, и как в случае с настоящим живым интерфейсом, который проводом соединяется с интерфейсом соседской железки, нам на этом интерфейсе надо включить IP. И для того, чтобы включить IP, самый простой способ повесить на этот интерфейс IP-адрес. Ну, вот, 10.0.0.1 по 24-й маске отдельная сеть, 10.0.0.0, нигде больше не пересекающаяся. Здесь у нас 10.0.1 сетка, здесь у нас 10.0.2 сетка, вот здесь у нас 10.0.0.0

по 24-й маске сетка, совершенно отдельная. И вот мы из этой сети адрес .1 вешаем на один конец туннеля, .2 на другой. Дальше. Рекомендация ЦИСКи зажимать МТУ на таком туннельном интерфейсе до 1400. Связано это с тем, что если вдруг вы хотите отправить через такой псевдопровод пакет, который не должен подвергаться фрагментации, то, соответственно, в нем будет проставлен флаг ДФ, и вы, если вдруг не сможете его отправить, то вы сами его пристрелите и скажете, такой пакет по сети не пролезет. Если же вы не проставите МТУ 1400, а поставите, ну, там, либо поставите значение по умолчанию 1500, либо поставите какое-то заведомо большое, там, 1498, к примеру, то вы пакет на части можете не порезать. Дальше он дорисует, роутер дорисует поверх оригинального пакета ГРЭшный заголовок 8 байт, а то и 12. Дорисует еще сверху

заголовок IP новый транспортный, это еще 20 байт, и получится, что у вас пакет вырастет на 28 байт. И когда этот новый пакет будет маршрутизироваться, и он должен будет выйти через гигабитный интерфейс, ну, это просто обычный пакет, адресованный в интернет. Он может получиться слишком большим, и он уже будет порезан на части. Так вот, фишка в том, что если вдруг вы положите в ГРЭшное вложение пакет с флагом DF, то совершенно не факт, что роутер этот флаг DF будет копировать в оригинальный пакет. Может быть такое, что он его, соответственно, проигнорирует. И получится в этой ситуации, что вам надо отправить 1528 байтовый пакет в интернет. Вы, естественно, это сделать не можете, вы его режете на части, и получается, что по факту пакет, который не должен был фрагментироваться, он все равно фрагментируется. То есть, мы не уважаем требования клиента, потому что пакеты фрагментироваться его не должны. Вот чтобы этого не было, мы зажимаем МТУ. ЦИСКО рекомендует ставить 1400.

В реальности, если вы не используете шифрование, в большинстве ситуаций достаточно 1472. То есть, это 8 байт заголовка ГРЕ и 20 байт транспортного заголовка IP. Вот. Но, соответственно, если вы будете использовать шифрование, то пакет может немножко распухнуть. Насколько он точно распухнет, заранее предсказать нельзя. Поэтому 1400 это такой безопасный вариант, при котором заведомо, насколько бы он не распух, он все равно еще в эти 1472 влезет. Дальше. Если вы хотите, вы можете сказать, что TCP при установлении сессии через этот интерфейс автоматически должен получать опцию Adjust MSS, что все сегменты, которые через этот интерфейс будут отправляться, не должны быть больше, чем 1360 байт. Работает вот эта штука IP TCP Adjust MSS следующим образом. TCP, если вы помните, состоит из трехэтапного рукопожатия и дальше передачи боевых данных. Сначала вы отправляете как клиент флаг син, потом сервер отправляет

син плюс ак, и, соответственно, клиент отправляет ак. И вот с этого момента сессия считается установленной. Так вот, когда клиент посылает свой первый син, этот син проходит через R1, дальше он должен уйти в туннель, и вот эта вот опция IP TCP Adjust MSS говорит, если мы видим син пакеты, которые отправляются через этот туннельный интерфейс, добавляем в них опцию Adjust MSS. Указываем, что мы хотим использовать 1360 байт, не больше размера сегмента. Эту опцию проставляет не оригинальный отправитель, ее проставляет сам роутер R1. Он вмешивается в трафик, он видит сим пакеты, которые проходят через интерфейс, и добавляет в них вот эту вот опцию. Соответственно, пакет проходит по всей сети, доходит до роутера получателя, доходит до конечного получателя, получатель в ответ отправляет acknowledge, его acknowledge тоже, скорее всего, продвергнутся Adjust MSS, но уже на роутере R2. И после того, как сессия будет установлена, они согласуют между собой

как раз минимальное значение из тех Adjust MSS, которые были проставлены. То есть, если один поставил 1360, второй поставил, не знаю, 1350, то они по факту будут использовать именно 1350. В трехэтапном рукопожатии как раз в любом случае, кто бы не проставил свою опцию, сосед про это в любом случае узнает. Вот. Рекомендуется как раз эту штуку делать. Если вы зажимаете MTU на 1400, то как раз Adjust MSS на 1360 делать хорошо и полезно. Дальше. Вы можете, если хотите, использовать опцию GROE Keep Life. Вот эта вот опция, она делает следующее. Она будет периодически отправлять пакеты, и если вдруг сосед не увидит этих самых Keep Life, то он поймет, что интерфейс соответственно не работает. По умолчанию Keep Life в GROE нет. То есть, эта штука опциональная, вы должны ее в явном виде включать.

Если вы ее не включаете, то туннель поднимается тогда и только тогда, когда у вас есть прописанные команды TunnelSource, TunnelAtenation. TunnelSource совпадает с вашим собственным IP-шником каком-то на интерфейсе, причем не обязательно том, с которого будут пакеты уходить. И TunnelDestination это просто какой-то адрес, который резолвуется в таблице маршрутизации. То есть, совершенно произвольный адрес здесь писать не стоит, надо писать тот, который действительно будет доступен. Хотя бы через дефолтный маршрут. Ну, то есть, он хоть где-то должен быть доступен. Недоступные адреса будут вызывать падение интерфейса. То есть, если вдруг до этого IP-шника нет маршрута, то интерфейс пойдет в down. Ну, вот если у вас и ваш IP-шник прописан в качестве TunnelSource, и destination резолвится, интерфейс переходит в up-up по умолчанию. Больше никаких проверок нет. Если вы хотите, чтобы другой конец туннеля подтвердил свою корректность настройки, вы можете включить

как раз вот эти вот Keepalive. в качестве Keepalive вы задаете, как часто посылать Hello-пакеты, вот эти самые Keepalive-пакеты, в нашем случае раз 5 секунд, и сколько пакетов должно потеряться перед тем, как мы признаем, что интерфейс сдох. Вот 3 пакета вы можете указать. Почему с этой штукой надо быть осторожным? Дело в том, что может быть такое, что у вас пакеты будут теряться периодически, но не все, а вот как-то выборочно. И может быть такое, что интерфейс у вас в принципе в целом живой, а вот Keepalive в нем, соответственно, как-то вот не прошли 3 штуки. У вас этот интерфейс упадет, а потом через некоторое время сам поднимется. Если вдруг зачем-то вы гоняете через этот интерфейс, например, какой-нибудь USPF, у вас такие штуки будут вызывать пересчет топологии. Лучше будет, если вы вместо Keepalive-ов на этом интерфейсе будете гонять обычные Hello-пакеты USPF. То есть все равно USPF то же самое будет делать. Поэтому нет смысла на самом деле использовать грешные Keepalive-ы. Да, интерфейс у вас в API висит.

Да, по факту это ничего не означает, но у вас есть Hello-пакеты USPF, которые проверяют живость соседа. Не надо дополнительно проверять живость самого интерфейса с помощью Keepalive-ов. Вы просто тем самым забиваете канал и те пакеты, которые могли бы принести какую-то дополнительную пользу, по факту вы тратите на излишнюю проверку ненужную, потому что все равно USPF в первую очередь будет проверять работоспособность соседа. Хотите, чтобы быстрее проверялся, включите какой-нибудь BFD или таймеры USPF-овские, подкрутите. Но вот получается, что Keepalive-ы на агреет по факту не нужны. Именно поэтому они по умолчанию выключены. Еще раз укажу на то, что когда вы прописываете туннельный интерфейс, не важно, что со стороны соседа, настроено или не настроено, достаточно, чтобы у вас прописан был правильный source и правильный destination. после этого интерфейс автоматически включается и переходит в аппарат. Если вы хотите обойтись малой крови, вы можете включить статическую маршрутизацию, просто указываете IP-road,

дальше какие сетки доступны через этот туннельный интерфейс и указываете, что все надо отправлять в туннель 0. Если хотите прям по-красивому, по-честному сделать, можно вместо туннель 0 прописать там IP-шник 10.0.0.2, который опять же резолвится как на коннект интерфейсе туннель 0. Поскольку GRE это point-to-point интерфейс по природе своей, что все, что отправляется, отправляется ровно на одного соседа, в point-to-point интерфейсах допустимо указывать только название интерфейса, но не IP-шник соседа. Этого нельзя никогда делать на Ethernet, потому что Ethernet это мультиаксесс интерфейс, в котором множественный доступ. А вот на point-to-point интерфейсах, на сериаллинках с PPP это делать можно. Ну, то есть именно на ситуации, которые на слайде показано, использовать такую запись IP-Row допустимо. Ну и с другой стороны все ответные действия тоже самое делать. Если с одной стороны включили KPL-Live, а с другой стороны тоже надо включить. Ну и IP-шники, соответственно. Ну и после того, как вы все это сделали, да, у вас узлы вот

10.0.1.2, 10.0.2.2 начнут пингать друг друга. Пакеты, которые будут отправляться, например, слева на 10.0.2.2 доходят до R1. R1 говорит, я вижу, что у меня есть маршрут до этой сетки, который смотрит в TUNNEL.0. Отправляет пакет в виртуальный псевдоинтерфейс TUNNEL.0. Дальше. Все, что отправляется в этот интерфейс, оборачивается новым заголовком. В этом заголовке прописываются новые IP-шники Source и Destination. И полученный новый пакет отправляется по таблице маршрутизации в гигабитный интерфейс, ну не в гигабитный, а во внешний интерфейс в гигабит.0.0 в нашем случае. Когда R2 принимает такой пакет, он видит, что пакет пришел со вложением ГРЕшным, код вложения 47, видит, что у нас прописаны Source и Destination в пакете, совпадающие с Source и Destination на туннельном интерфейсе TUNNEL.0. Говорит, у меня только что через TUNNEL.0 пришел пакет. Он расковыривает вложение, то, что прибежало по ГРЕ, и отправляет это вложение на таблицу маршрутизации.

И дальше по таблице маршрутизации обнаруживает, что адрес получателя находится за connected-натрофейсом Gigabit.0.1. Ну и обратные пакеты проходят точно такой же маршрут. Что делать, если ГРЕ у нас какие-то проблемы испытывает? Вот вы должны будете в первую очередь понимать, что ГРЕ не проверяет корректность настройки соседа. То есть он проверяет только то, что с вашей стороны все хорошо, и если там в крайнем случае вы включили Keepalive, то, соответственно, вот он проверяет, что хотя бы Keepalive проходит. Keepalive могут вызывать проблемы, не просто проблемы, скажем, характера, вида мы излишне много отправляем пакетов, которые несут в себе одну и ту же полезную нагрузку, типа как вот OSPF-овские Hello пакеты и ГРЕ-шной Keepalive. На самом деле ГРЕ-шной Keepalive еще дополнительно к тому, что у них есть проблемы

с логичностью, они еще плохо будут работать со всякими штуками типа шифрования с помощью IP-сека, и они будут плохо работать с URPF. Связано это с тем, что вот эти вот самые Keepalive физически представляют собой IP-пакеты, которые адресованы персонально нам. То есть смотрите, эти Keepalive это не просто пустой ГРЕ-шной пакет. Когда вы отправляете Keepalive, это будет IP-пакет, в котором лежит ГРЕ-шное вложение, ГРЕ-шное вложение, в котором лежит еще один IP-пакет, который адресован персонально нам. То есть мы сами себе отправляем пакет и отправляем его на адрес нашего соседа. Смысл заключается в том, что когда мы отправим пакет на адрес соседа, сосед его откроет, скажет, внутри лежит пакет, который идет на адрес наш, именно отправителя изначального, он этот пакет обратно сам же нам и отправит.

То есть это не то, что мы как пинги отправляем и мы отправляем запрос, а в ответ нам идет именно ответ на наш запрос. Мы отправляем запрос, который обратно в петлю Возвращается в наш собственный интерфейс через соседа. И получается, что мы сами себе отправляем пакет, который проходит два раза трассу этого самого GRE-шного пакета. Немножко дурная штука, но тем не менее она не требует корректности настройки маршрутизации. Мы не должны знать ни IP-шник нашего соседа, ничего. Мы отправляем сами себе этот пакет. Для того, чтобы это работало, должны знать только публичный IP-шник той стороны. И этот механизм не будет корректно работать, если вы будете включать Unicast Reverse Path Forwarding. Что это

собой будет представлять? Когда вы отправляете какие-то пакеты через интерфейс, вы их просто отправляете. Но когда вы принимаете какие-то пакеты через интерфейс, вы можете проверять, с какого IP-шника они пришли. И если по таблице маршрутизации выясняется, что пакет пришел из-под интерфейса и из-под адреса, который не резолвится в этот интерфейс в таблице маршрутизации, то такой пакет вы можете дополнительно пристрелить. И эта штука, URPF, она во многих сетях реально используется для защиты от спуфинга пакетов. Если кто-то подставит какой-то IP-источник в своих пакетах, который должен находиться в совсем другой части сети, URPF такие пакеты будет пристреливать. Соответственно, механизмы типа BFD, типа Keepalive в GRE-шных, они все будут эти штуки нарушать, потому что они будут сами себе отправлять пакеты, которые должны пройти через другой конец петли GRE-шной.

Если вы будете их использовать, то сразу будут возникать вопросы с тем, что вы сами свои пакеты будете расстреливать, потому что они не будут проходить вашу собственную проверку. Та же история с IPsec. Пакеты, которые вы будете отправлять, непонятно, как надо будет шифровать, чтобы вы их сами могли расшифровать. Когда у нас будет Multipoint GRE, DMVPN на следующих слайдах, тоже непонятно, как мы сами себе отправим пакет, кому мы его отправим. В случае со статическим туннелем там всё понятно, отправляем на другой конец туннеля. А когда у нас есть Multipoint GRE, когда у нас есть NextHop сервер, которому мы должны задавать вопросы, а куда, на какой публичный IP-шник отправить пакет соседу с таким частным адресом, то если мы ему скажем, что надо отправить пакет на наш собственный IP-шник, NextHop сервер скажет, отправь на свой собственный адрес, и получится, что пакет по сети никуда не прошёл. Поэтому Keepalive — штука красивая, но имеет очень много ограничений.

Show Tunnel Interface нам может показать какую-то базовую статистику, покажет, что за тип туннеля у нас есть. GRE IP — это поведение по умолчанию. IP-шники Destination и Source, которые у нас прописаны, показано, соответственно, когда мы будем отправлять пакеты на этот Destination, через какой интерфейс они будут выходить, и кто будет NextHop. В нашем случае два роутера просто с одним между собой прямым интерфейсом, поэтому NextHop у них такой показан. Но в реальности редко такое будет случаться. Интерфейс Tunnel 0 упаковывает данные с протоколом номер 47, когда мы IP-пакет пассажирский заворачиваем в новый GRE-шный заголовок и в новый транспортный IP-пакет, то, соответственно, код вложения мы ставим как раз 47. Всё остальное нас не сильно интересует. IPv4 будет обрабатываться, IPv6 в нашем случае не будет обрабатываться,

MPLS и OTV и всё остальное, то, что можно было бы упаковать в GRE, тоже обрабатываться не будет. Прямо сейчас интерфейс в UP. Надо понимать, что он в UP просто потому, что у нас IP-шники прописаны, не потому, что мы проверили соседа. Всё. Transport IPv4 header, DF bit cleared. Как раз и означает, что мы игнорируем содержимое DF пассажирских пакетов и мы обязательно выставляем DF по нулям. Наши пакеты, которые будут GRE-шные отправляться в интернет, они могут маршрутизироваться с фрагментацией. Если мы хотим настроить DMVPN, то у нас настраивается точно такой же туннельный интерфейс. У нас настраиваются точно так же IP-адреса. Мы должны будем на своём конце туннеля проставить IP-шники. Мы должны будем проставить IP-шники на частных интерфейсах, на публичных интерфейсах, на туннельных интерфейсах,

и туннельные IP-шники все должны быть в одной IP-сети. У нас это получается такой как бы свитч. И мы говорим, здесь у нас 10.0.0.1, здесь 10.0.0.2, 10.0.0.3, 10.0.0.4. Получается, что все узлы понимают, что все соседи находятся за одним и тем же интерфейсом. Дальше мы указываем Tunnel Source. Можно указать IP-шник, можно указать название интерфейса, если вы IP-шник почему-то не знаете. Что достаточно типичная ситуация, например, если вы получаете IP-шник по DHCP. И в принципе, если бы мы ничего больше не сделали, у нас бы интерфейс не поднялся, потому что Destination IP-шник мы не прописываем. В Multipoint GRE разные пакеты будут идти в сторону разных соседей, на разные публичные адреса. Поэтому Tunnel Destination на Multipoint GRE-шных интерфейсах писать не надо. Но если мы ничего дополнительно не сделаем То получится, что трафик, который должен уйти через интерфейс

Никуда не уйдет Потому что интерфейс будет в дауне До тех пор, пока мы не скажем волшебное слово Tunnel Mode GRE Multipoint Эта штука как раз и скажет Туннель должен перейти в App-App Несмотря на то, что у него нету IP-шника получателя Достаточно прописать IP-шник источника Для наших исходящих пакетов А куда эти пакеты пойдут, решит высший суд И этот высший суд будет называться NHRP Next Hop Resolution Protocol Если вы посмотрите, у нас есть некий хаб и есть некие споуки Например, это может быть headquarters А это может быть какие-то филиалы Филиал 1, филиал 2, филиал 3 И настройка headquarters, этого хаба Вот досюда И со споков досюда Она была идентична Создаем туннельный интерфейс Прописываем IP-шники Прописываем Tunnel Source Прописываем Tunnel Mode GRE Multipoint Дальше начинаются небольшие различия

Что касается tunnel key Это как раз тот самый ключ, который есть в заголовке GRE Если вдруг у нас будет несколько разных DMVPN-овских сетей Которые часть смотрят на одних клиентов, часть смотрят на других клиентов То мы можем при создании туннельного интерфейса Наши пакеты маркировать неким ключом Если мы не хотим маркировать наши пакеты ключом Ничего страшного не будет Эту строчку можно не писать Но если у вас будет, например, какая-то схема с двумя хабами И вы что-то такого плана сделаете То вам потребуется сделать отдельные туннельные интерфейсы И надо будет не перепутать трафик Какой туннельный интерфейс какой GRE пакет на себя будет принимать Дальше Хаб от не хаба будет отличаться тем Что хаб будет являться NHS сервером Next Hop сервер А споки будут подключаться к Next Hop серверу

И для того, чтобы это сделать, нам нужно включить протокол NHRP И надо запустить сам процесс NHRP Что в случае с клиентом, что в случае с сервером Мы указываем команду IP NHRP Network ID и дальше некое число Это число не обязано совпадать на соседних железках Оно нужно как в OSPF Мы должны запустить процесс OSPF И должны сказать какое-то локальное число, которое будет означать номер процесса В OSPF я всегда рекомендовал использовать номер 1 И здесь тоже рекомендую использовать номер 1, чтобы не запутаться Смысл в том, что если у вас будет какая-то схема с двумя хабами Вам надо будет не запутаться, где какие IP-шники, в каком интерфейсе, что будут означать И вы можете сказать, что здесь у нас сетка номер 1 Здесь у нас сетка номер 2 Здесь у нас сетка номер 3 И в этом случае публичные IP-шники у вас будут, возможно, разные В нашем случае у нас всего одна сеть Поэтому мы запускаем один экземпляр NHRP Указываем IP NHRP Network ID 1 И все Мы не прописываем, что эта железка будет NHS клиентом

NHRP клиентом Она будет как следствие сама сервером Если здесь ничего больше нету Значит, это Next Hop сервер Если здесь что-то появляется Вот оно Вот эти две команды Они как раз будут означать, что эта железка не Next Hop сервер Это будет клиент И соответственно мы прописываем команду IP NHRP Тот же самый Network ID Он не обязан совпадать Если здесь двоечку поставить Оно все равно заведется Это локально значимое значение Ни на что особо не влияет Указываем IP NHRP Дальше NHS И частный IP-шник Next Hop сервера Давайте я повторно напишу, какие у нас здесь частные IP-шники 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 Еще раз подчеркну, это частные адреса Мы их повесили на сам интерфейс туннеля Вот он 10.0.0.1 10.0.0.2 И когда мы прописываем Next Hop сервер 10.0.0.1

Предполагается, что каждый из споков будет ходить на 10.0.0.1 И спрашивать Как добраться до Васи? Как добраться до Пети? Но 10.0.0.1, как вы сами понимаете, их много Такой IP-шник может быть у вас Может быть у меня Может быть у Google Может быть у Facebook Может быть у Яндекса У кого угодно IP-шник 10.0.0.1 может быть Поэтому нам нужно будет указать Где именно искать частный IP-шник 10.0.0.1 И мы делаем маппинг IP NHRP Ключевое слово map Во Frame Relay мы уже встречали его И частный IP-шник связываем с публичным IP-шником Если бы мы Frame Relay прописывали Здесь бы мы написали Frame Relay Map IP-шник И DLCI В принципе Очень похож действительно DMVPN на Frame Relay Именно тем, что у него Нужно сделать маппинг Перед тем, как мы начнем отправлять трафик И мы в маппинг прописываем IP-шник и канальный адрес Здесь то же самое

IP-шник И когда мы IP-шник в IP пакете Заворачиваем во что-то транспортное В случае с Frame Relay Мы заворачиваем пассажирский IP пакет В транспортный Frame Relay кадр Здесь мы заворачиваем пассажирский IP пакет В транспортный тоже IP пакет Поэтому этот IP-шник 192.0.2.1 Фактически играет роль Того самого DLCI во Frame Relay У нас получается новый IP пакет Который будет отправляться Именно на этот IP адрес 192.0.2.1 А он уже будет отправляться По обычному интернету Разница между клиентом и сервером Заключается вот в этих двух строчках Кто будет частным Next Hop сервером И где брать этот частный Next Hop сервер За каким публичным IP-шником Вы можете задать вопрос А почему Next Hop сервер прописывается частный? Зачем такая наркомания? Почему нельзя публичный прописать? И ответ будет очень простой Когда у вас работает GRE Вы не хотите передавать его по сети нешифрованным Вы хотите, чтобы весь трафик шифровался А когда вы будете шифровать трафик

Фактически вы говорите 10.0.0.1 Next Hop сервер Трафик будет идти не по интернету А по этому псевдопроводу А дальше вы просто скажете, что все, что отправляется по псевдопроводу Все шифруется И вы IPsec накроете трафик всего интерфейса в целом Если бы вы Next Hop сервер прописали публичный IP-шник То эти пакеты отправлялись бы в интернет И их надо было бы шифровать как-то отдельно А так мы говорим У нас и управляющий трафик Next Hop Resolution протокола И пользовательский трафик Будут идти по одному и тому же интерфейсу А все, что в этом виртуальном интерфейсе идет, мы шифруем Поэтому указывается именно частный IP-шник Next Hop сервера И для того, чтобы частный IP-шник где-то найти Указывается, что частный IP-шник доступен за таким публичным IP-шником Именно такая странная цепочка Именно такая странная логика Если у нас есть IPv6, все то же самое, кстати Точно так же прописываются IP-шники Единственное, что на туннельных интерфейсах нам живые маршрутизируемые IP-шники Устанавливать не нужны

Мы должны будем сделать туннельный интерфейс только с link-local И команда по назначению link-local будет вот такая IPv6 address, дальше указываем fe80::2:1, это link-local адрес И просто так вы такой IP-шник повесить не можете Поэтому вы указываете слово link-local Для того, чтобы указать, что это тот самый единственный link-local, который на интерфейсе будет Здесь мы сделали красивый link-local fe80 Здесь мы сделали тоже красивый link-local Мы его сделали? Нет, мы его не сделали Здесь мы оставили некрасивый интерфейс с некрасивым link-local Здесь просто IPv6 enable, оно генерит link-local адрес, но он будет случайный Для нас важно, чтобы link-local был красивый на хабе Дело в том, что мы Next Hop сервер будем прописывать И Next Hop сервер мы должны будем прописать именно какой-нибудь И чаще всего как раз используется link-local адрес В нашем случае мы сделали fe80::2:1 Дальше прописали Tunnel Source, прописали Tunnel Mode GRE, прописали Network ID 1, но уже с ключом IPv6

IPv6 NHRP Network ID и NHRP Network ID это разные вещи В нашем случае мы используем базу Next Hop сервера для IPv6 Со стороны клиента указываем, что у нас есть IPv6 Next Hop server и дальше тот самый красивый link-local, который мы сделали И указываем IPv6 NHRP map Раньше мы указывали четко один единственный IP-шник, за каким публичным IP-шником будет сидеть Здесь мы указываем IPv6 NHRP map Дальше fe80::2:1/128 Это префикс Вы можете сразу целыми пачками префиксы указывать, что они будут сидеть за одним и тем же публичным адресом И соответственно вы указываете публичный IP-шник В нашем случае интерфейс будет поверх IPv6 работать Если у вас будет интерфейс поверх IPv4 работать, здесь будет публичный IPv4 IP-шник И смотрите какая штука В нашем случае мы действительно предполагаем, что этот самый интернет, поверх которого все работает, это IPv6

Мы на публичном интерфейсе вешаем маршрутизируемый IP-шник 2001:DB8:1::1:1, имеем право И соответственно мы указываем, что мы IPv6 пакеты заворачиваем в IPv6 публичный Поэтому мы указываем Tunnel Mode GRE Multipoint, что у нас работает режим GRE, что у нас действительно не указывается публичный IP-шник destination И мы указываем IPv6, что пакеты, которые мы будем заворачивать В которые мы будем заворачивать GRE, они будут заворачиваться в IPv6 В принципе Tunnel Mode GRE Multipoint IPv6 можно использовать и для IPv4 пакетов У вас будут IPv4 пакеты, которые вы заворачиваете в IPv6 Но все равно эта команда будет та же самая Если вы хотите IPv6 заворачивать в IPv4, тогда просто Tunnel Mode GRE Multipoint В принципе все те же самые концепции здесь будут работать Единственная разница между IPv4 и IPv6 NHRP будет заключаться в том, что IPv6 NHRP работает на уровне префиксов

IPv4 работает с отдельными IP-шниками Хотя на самом деле, если посмотреть, расковырять сам протокол, там видно, что тоже префиксы используются И как раз фаза 3, та самая DMVPN фаза 3, где у нас таблица маршрутизации пустая, там только дефолт А все остальное падает в движок аппаратного ускорителя Там как раз будет видно, что именно на уровне префиксов приходят NHRP сообщения редиректа Даже для IPv4 Но настраивается все равно в конфиге для отдельных адресов DMVPN штука сложная в том смысле, что если что-то пошло не по плану, то приходится отдельно разбирать все возможные проблемы, которые могут вызвать неработоспособность DMVPN Надо, во-первых, смотреть, проходит ли у вас GRE, не блокируется ли он где-нибудь вообще, могут ли GRE пакеты проходить между узлами Если сами GRE пакеты пройти могут, например, вы взяли статический туннель, подняли, видите, что статический туннель между хабом и конкретным споком работает

Дальше может быть предположение, может быть GRE пакеты не проходят между споками Опять же, проверяем споки Если везде GRE пакеты проходят нормально и корректно, значит, проблема не в GRE, значит, проблема в NHRP Надо смотреть, что у нас там резолвится Смогли ли споки зарегистрироваться на хабе? Если смогли, то правильно ли определил хаб IP-шники споков? Для этого используется команда show IP NHRP Она и на споках, и на хабах полезная для того, чтобы посмотреть, что там такое Если мы посмотрели NHRP, там вроде все хорошо, посмотрели GRE, они вроде бы бегают Дальше, после того, как вы убедились, что все базово работает, можно сверху накрывать IPsec и соответственно шифровать все Мы в рамках нашего курса ничего не шифруем Тема достаточно большая, обширная, и у нас не так много времени, всего 60 часов Поэтому мы ее не трогаем Но если вам интересно, есть курс по безопасности INS Там немножко про шифрование у нас будет

И IPsec будет закрываться трафик как раз в туннеле DMVPN хорош тем, что можно одной командой накрыть трафик одного интерфейса целиком И соответственно трафик до всех споков у вас будет попадать под шифрование одной и той же командой Там будут некоторые сложности с тем, чтобы одновременно пересогласовывать ключи Чтобы у вас все это дело действительно корректно синхронизировалось между собой Что если вдруг там где-то у кого-то что-то закончилось И SA кончилась Чтобы все одновременно получили правильную новую SA У DMVPN есть с этим определенные особенности работы Накрыть IPsec обычный GRE-туннель и накрыть IPsec DMVPN-туннель Это немножко разные по сложности вещи Но тем не менее ничего невозможного нет И по инструкции сайта Cisco в принципе все это делается Но если вы чувствуете, что у вас где-то что-то не работает И вы знаете, что у вас DMVPN накрыто IPsec

В первую очередь есть смысл отключить IPsec, посмотреть А без IPsec оно будет работать? Может быть, просто сам IPsec начинает причинять какие-то неудобства И траблшутить надо именно его Если проблема не в GRE, если проблема не в NHRP, не в IPsec Например, пинги внутри туннеля ходят нормально Мы взяли пинганули соседа и он пингается Но трафик пользовательский все равно не ходит Возможно, проблема в динамической маршрутизации Как правило, протоколы динамической маршрутизации будут использовать мультикаст И мультикаст внутри DMVPN это своя отдельная песня Для того, чтобы это все правильно работало Вам, как правило, потребуется мультикаст отдельно настраивать Штатно в DMVPN мультикаста нету Вообще никакого Там, где в Ethernet мы можем нащупать одним пакетом всех соседей сразу Здесь чисто логически невозможно отправить один мультикастовый пакет на адрес 224.0.0.5 Все OSPF роутеры Потому что этот пакет надо отправить на какой-то публичный IP-шник

А у нас публичных IP-шников много у соседей И мы не все из них заранее знаем Если мы хаб, мы знаем все публичные IP-шники соседей Потому что они на нас регистрируются А если мы со Spoke, то мы не можем сказать Дорогой хаб, расскажи нам про все-все-все публичные адреса всех-всех-всех соседей Поэтому мультикаст в DMVPN специфический И настраивать надо работу мультикаста И после того, как мы её кое-как настроим Надо под это кое-как костылями и такой-то матерью Подоткнуть ещё сам протокол динамической маршрутизации Чтобы он с этим костыльным мультикастом хоть как-то мог работать Но в нашем базовом случае у нас ничего этого пока нету У нас пока используется просто show IP NHRP Эта команда покажет список всех маппингов, которые у вас есть Статических и динамических Если вы клиент, у вас есть один статический маппинг Как минимум это Next Hop сервер В нашем случае клиент Spoke показывает show IP NHRP, что у него есть 10.0.0.1 по /32 маске

Прописанный ручками префикс Он доступен через публичный IP-шник 192.0.2.1 Тип у него статический И здесь есть флаги: used, там что-то ещё Эти флаги на самом деле очень интересные Для случая со Spoke это не очень актуально Потому что, как правило, Spoke цепляется на хорошо известный IP-шник хаба И у хаба эти IP-шники меняются, как правило, не часто А в случае с хабом У хаба тоже эта команда show IP NHRP есть И у хаба, как правило, статических записей никаких нету Смысл заключается в том, что когда у вас просыпается новый узел Филиальный Spoke Он берёт и регистрируется на хабе Он приходит и говорит: привет, я новенький У меня вот такой частный IP-шник, у меня вот такой публичный IP-шник Он оба адреса сообщает, и хаб себе их в базу заносит И дальше эти флаги Они начинают уже играть большую роль Самый интересный флаг — это unique Заключается интерес этого флага в том, что

Если вдруг у вас кто-то зарегистрировался с определённым публичным IP-шником То эта запись в течение некоторого времени будет жить в списке адресов хаба И время, в течение которого она будет там жить — Таймер по умолчанию 2 часа Вы зарегались, и 2 часа у вас эта запись живёт Не позже, чем через 2 часа надо перерегистрироваться на хабе И обычно это клиент делает через час Но смысл этой записи заключается в том, что этот NBMA-шный, публичный IP-шник будет зафиксирован за этим клиентом Если клиент захочет перерегистрироваться, он должен перерегистрироваться с этим же адресом Если вы хотите подключаться из-под каких-то подключений Где у вас IP-шник заранее неизвестен Или это какой-то ADSL, где вы устанавливаете сессию И каждый раз вам разный IP-шник даётся Или это какой-нибудь Wi-Fi

Или 3G, 4G, где вы не контролируете ваши IP-шники Вы не знаете, какие это адреса заранее И главное, они каждый раз будут разные Вам нужно будет в настройках Spoke сказать Что тот адрес, который вы будете регистрировать, это не уникальный адрес Что вы знаете, что этот адрес может меняться И тогда в этой ситуации у вас Если вы пропишете соответствующую команду, флага unique не будет И тогда вы можете перерегистрироваться через некоторое время Указать, что у вас публичный IP-шник уже будет другой И тогда трафик всё равно будет нормально ходить В противном случае вы просто не сможете зарегаться Вам хаб даст отмашку, скажет Извините, у меня эта запись уже есть И публичный IP-шник там уже указан другой Эта система чем-то напоминает в Active Directory В 2008 сервере, если вы помните, сделали галочку Что объекты будут защищены от редактирования и от удаления Вы пытаетесь что-то удалить А вам система говорит: я тебе не дам это сделать

Потому что ты при создании поставил галочку «защитить объект от удаления» Если вы эту галочку снимете, то всё хорошо Можно удалять, можно делать что угодно А пока эта галочка стоит, ничего нельзя делать И эту галочку вы сами по умолчанию ставите До тех пор, пока не даётся дополнительная настройка Что вы не уникальный IP-шник будете иметь Вам не дают этот IP-шник изменить Зарегались один раз с тем IP-шником, который у вас больше нет — Это ваши половые трудности Так, что здесь ещё надо смотреть? Если вы на хабе пытаетесь посмотреть show IP NHRP Вам показывают все записи, про которые вы знаете По-русски говоря, все записи, которые зарегистрированы на этом хабе Если вы видите, что какой-то Spoke не может подключиться к хабу Смотрите, зарегался он или нет Если не зарегался — значит что-то не так с самим GRE, скорее всего Если он зарегистрировался, то смотрите, что он о себе сообщил Может быть, у него публичный IP-шник стоит неправильный И как раз этот самый флаг unique

По факту клиент уже получил другой IP-шник Но не мог перерегистрироваться, потому что адрес у него помечен как уникальный Давайте попробуем это всё сделать Настроить в нашей лабе и убедиться, что DMVPN — таки действительно живая технология С помощью которой можно делать всякие клёвые вещи Так, давайте приступать к настройке наших железок У нас сейчас на наших роутерах, на первых роутерах Есть интерфейс PPPoE, который смотрит на центральный Пожалуйста, убедитесь, что он действительно есть Show IP Route У нас есть адрес 172.16.0 чего-то И есть адрес 172.16.0.1, который принадлежит центральному роутеру Наверное, даже он пингается Действительно пингается Для того, чтобы всё стало совсем хорошо, нам не помешает Абсолютно не помешает дополнительно сделать ещё одну штуку

Нам нужен интерфейс, который будет восприниматься как публичный Прямо чтобы глазками было видно, что он публичный-публичный А если мы сделаем ещё один адрес с явно публичным IP-шником То нам нужно будет, чтобы на него был маршрут Поэтому у меня есть предложение Давайте пропишем маршруты по умолчанию ручками на PPPoE-шный интерфейс Он, по идее, должен был автоматически раздаваться Но я на центральном роутере забыл просто одну команду сделать А пересогласовывать все PPPoE-шные сейчас соединения очень не хочется Поэтому давайте просто руками пропишем Скажем, что весь интернет будет доступен через Dialer 1 интерфейс Конфигурация, которая у нас сейчас есть Show run interface Ethernet 0.0 И соответственно Dialer 1

Так, проверим IP-шник этот запингался Ping 101.101.101.101 Он действительно пингается У нас сейчас ситуация будет следующая Мы знаем хорошо известный статический IP-шник, с которым мы будем строить связь И мы знаем, что у нас на интерфейсе Dialer 1 есть IP-шник, который достаточно хороший, чтобы отправлять пакеты на 101.101.101.101 Но мы не знаем, какой он заранее будет Он каждый раз разный Поэтому мы как раз будем строить туннель, не зная свой собственный IP-шник Но зная IP-шник получателя 101.101.101.101 Обычный статический GRE, наверное, сейчас смысла уже нет делать Потому что конфигурация его будет очень похожа на то, что на слайде, только будет ещё tunnel destination прописан и никакого NHRP

Это скучно, это предсказуемо, я предлагаю сделать уже сразу DMVPN Поэтому мы создаём туннельный интерфейс Interface Tunnel 0 Это интерфейс воображаемый Он поднимается во включённом состоянии Но видно, что пробегает сообщение Line Protocol Up/Down Что состояние канального уровня на этом интерфейсе Down Это означает, что на этом интерфейсе не прописаны какие-то необходимые свойства, которые нужны, чтобы этот интерфейс перешёл в Up Обычный GRE-интерфейс переходит в Up тогда, когда мы задаём tunnel source и tunnel destination Но у нас, поскольку это DMVPN, tunnel destination не задаётся На слайде его тут как раз не видно Поэтому мы зададим только tunnel source И скажем tunnel mode GRE multipoint Для того, чтобы указать, что наш интерфейс не будет иметь заранее запрограммированный адрес получателя для своих пакетов

Мы каждый раз адрес получателя будем определять автоматически Так Ещё один момент, который нас здесь будет интересовать Я на всякий случай проверю Do ping 172.16.0.1 Ping 0.3 Так, 0.2 — это мой собственный IP-шник Unreachable идут Да, поскольку мы делаем DMVPN, нам нужна будет связь между этими адресами А, 101, простите, да 101, 102, 103 101 работает, 102 работает, 103 Unreachable 104 работает В общем, всё хорошо У нас есть связь между нашими узлами напрямую После того, как мы прописали дефолт Связь между нашими адресами PPPoE Сейчас у нас работает

Нужен ли для NHS ещё один loopback? Нет, не нужен Дело в том, что у нас NHS, который будет прописываться — частный адрес Это будет IP-шник на самом интерфейсе туннеля А публичный адрес — Это самый 101.101.101.101 и будет Поэтому loopback 102 нам здесь не понадобится Так, туннельный интерфейс мы создали Он у нас упал в Down И для того, чтобы его из Down поднять Нам нужно прописать Tunnel source Dialer 1 Что пакеты, которые мы будем отправлять Содержащие GRE-шные вложения Содержащие какие-то пассажирские пакеты Через этот туннельный интерфейс Они будут отправляться с IP-шника интерфейса Dialer 1 И указываем tunnel Mode GRE Multipoint У нас IPv4, поэтому слово IPv6 мы не добавляем IPv4 я имею в виду как транспортная сеть

Наш PPPoE Там используется только IPv4 сейчас IPv6 там нету И мы указываем, что когда мы отправляем GRE-шные пакеты Мы их заворачиваем в обычные IPv4 пакеты На слайде показано здесь Показано слово IPv6 Потому что на слайде у нас использовалась как раз IPv6 транспортная сеть Здесь её нету, поэтому IPv6 мы не указываем Интерфейс поднялся И этого недостаточно для того, чтобы у нас всё хорошо работало Несмотря на то, что интерфейс перешёл в Up По факту трафик сейчас ходить не будет Нам, во-первых, нужно прописать IP-шники Что на нашем интерфейсе туннеля висит такой-то IP-шник А на той стороне туннеля IP-шник будет такой-то Я предлагаю использовать адреса 192.168.0 И дальше на конце номер вашего комплекта У вас 192.168.0.1, 192.168.0.2, 0.3, 0.4, 0.5, 0.12 У меня 15-й комплект

Я сделал 192.168.0.15 IP address 192.168.0.15 По /24 маске 255.255.255.0 Естественно, аналогичную настройку надо будет сделать и на центральном роутере Там тоже надо будет туннельный интерфейс поднять, потому что центральный роутер тоже будет участвовать в NHRP И в DMVPN Поэтому я сейчас туда иду На центральном роутере Прописываю Interface Tunnel 0 Tunnel source И пакеты, которые я буду отправлять Я хочу, чтобы уходили с адреса 101.101.101.101 Поэтому tunnel source я указываю loopback 0 Это заранее созданный интерфейс, на котором висит как раз IP-шник 101.101.101.101 И tunnel mode GRE multipoint Указываю, что на этом интерфейсе мне не нужен адрес получателя

Я его буду автоматически каким-то образом получать Указал tunnel source, указал tunnel mode GRE multipoint Указываю IP-шник, IP address 192.168.0.101 255.255.255.0 Так, кстати, вы мне правильно подсказали Я создал-то интерфейс loopback 101 А здесь в качестве tunnel source указал loopback 0 Это ошибка На экзамене за такое бьют палками Tunnel source loopback 101, конечно Да, спасибо, что подсказали Так, IP-шники прописали Настройки туннеля прописали Дело за малым — настроить тот самый NHRP Если бы мы прописывали обычные статические туннели Мы бы здесь добавили слово tunnel destination Указали бы публичный IP-шник соседа И у нас всё бы заработало Но у нас DMVPN, поэтому мы не прописываем tunnel destination

И нам потребуется для определения IP-шника соседа Тот самый NHRP Запускаем IP NHRP Network ID И дальше совершенно какое захотим число Например, единичка, красивое число Мы тем самым запустили на этом интерфейсе Экземпляр NHRP номер 1 То же самое надо сделать и на ваших роутерах IP NHRP Network ID Неважно, какой мы сделали Можно сделать 1, можно сделать 2, 3, 5, 10, 15 Это число не передаётся по сети Оно локально значимое И ни на что не влияет Главное, чтобы сама строчка IP NHRP Network ID была Network ID задали И дальше мы указываем, что мы не сервер Потому что сейчас настройки на сервере и на клиенте Вообще идентичны Разница только в IP-шниках И мы на клиенте нигде не указывали IP-шник

101.101.101.101 Который у нас использовался Нам надо его где-то указать И мы указываем, что у нас есть Next Hop сервер У которого есть частный адрес 192.168.0.101, кажется, да? Я там сделал 192.168.0.101 И этому адресу будет соответствовать публичный IP-шник 101.101.101.101 IP Вы за мной, пожалуйста, повторяйте NHRP NHS 192.168.0.101 И рядом маппинг для этого IP-шника Map 192.168.0.101 Этот частный IP-шник доступен через публичный IP-шник 101.101.101.101 Всё. Этого достаточно для того, чтобы у нас всё хорошо работало. Единственная беда. Прямо сейчас работать ничего не будет. Если я сейчас попробую попингать его Do ping 192.168.0.101

У меня ничего не должно работать Однако работает Да, он зарегистрировался автоматически. Я хотел рассказать, что Когда вы меняете настройки NHRP Надо перерегистрироваться в NHRP Надо погасить интерфейс и переподнять его снова И тогда он проходит регистрацию И тогда он начинает работать в том режиме, в котором мы его задали Но сейчас, видимо, потому что у нас IP-шник прописан не был И мы его только прописали Он узрел, что можно подключиться к Next Hop серверу И сразу на него побежал И сразу на нём зарегистрировался Далеко не всегда это будет происходить Поэтому для того, чтобы у вас перерегистрация прошла Есть простой механизм Shutdown No shutdown Интерфейс падает, поднимается Приходит перерегистрация И с этого момента всё начинает ходить, как должно быть Правильно Что получается? Сейчас, если мы всё хорошо сделали

Если у нас все конфигурации прописаны так, как и должны Show IP interface brief У нас появляется интерфейс Tunnel 0 На этом интерфейсе висит IP-шник 192.168.0 Номер комплекта По 24-й маске Show IP route Показывает, что появилась Connected сетка Connected сетка Вот она 192.168.0 По 24-й маске Из них 192.168.0 Номер комплекта Это сам наш IP-шник В этой сети И сейчас мы можем пингать всех, кто в этой сети находится вместе с нами Понятное дело, что можно попингать 192.168.0.1 Это 0.101, простите Это тайной не будет Но также можно попингать и всех остальных Если Всё хорошо сделано на той стороне То оно должно Нормально и корректно работать Здесь я вижу, что У нас что-то не работает

Не работает Потому что NHRP не может Упаковать пакеты Видите сообщение Packet error Не может упаковать ICMP-шный пакет Который мы хотим отправить на адрес 192.168.0.1 У него нету канального адреса получателя NHRP не успел зарезолвить это В публичный IP-шник И соответственно у нас происходит ошибка упаковки Вот такие штуки Они бывают Но нам надо каким-то образом узнать Кто у нас зарегистрировался Я сейчас воспользуюсь служебным положением Пойду на центральный роутер И посмотрю, кто там зарегался Show IP NHRP Так Вот 192.168.0.2, например, есть Его я могу попингать И он пингается 192.168.0.3 У него тоже нет Кто там ещё есть?

Второй, шестой, седьмой, девятый, десятый Девятый, одиннадцатый, пятнадцатый Шесть регистраций я вижу Возможно, кто-то ещё прибежал Если вы себя в списке не видите Пожалуйста Shutdown, No Shutdown На интерфейсе И перерегистрация пройдёт Для того, чтобы всё хорошо получилось Нужно прописать Tunnel Mode, GRE Multipoint, Tunnel Source С вашего интерфейса Dialer 1 IP NHRP Network ID IP NHRP Next Hop Server 192.168.0.101 IP NHRP Map 192.168.0.101 На публичный IP-шник 101.101.101 И у вас должен пингаться этот адрес 101.101.101 Вы регистрацию их не видите Регистрацию видит только тот, на кого эта регистрация прошла Только на Next Hop Server На маленьком сервере, типа как мой 15 Show IP NHRP

Будет показывать следующее Во-первых, есть запись 192.168.0.1 Это статическая запись Мы её ручками сделали Мы сказали, что адрес 192.168.0.101 Живёт вот здесь И это не обсуждается Нам эта статическая запись Нужна для работы Next Hop Server Все эти записи Которые вы здесь видите Это записи, которые Ваш роутер автоматически выполнил Выполнил resolving на Next Hop Server Он пошёл туда И спросил Как зовут вот такой комплект Если у вас так получилось, например Что комплект используется первый или второй Тот, который я показал на слайде Весьма вероятно, что вас просто уже кто-то пингал И получается, что Первый, второй, третий, седьмой и пятнадцатый Это записи, которые у меня действительно есть И я могу их использовать для того, чтобы По ним отправлять трафик Здесь стоит заметить вот какую вещь 192.168.0.1

Показывается, что резолвится в публичный IP-шник 101.101.101.101 Это адрес центрального роутера Центральный роутер сказал Я тебе пока ничего не могу сказать Присылай трафик мне, там разберёмся Этот IP-шник на самом деле Он ни о чём мне не говорит Это временная запись И на самом деле это такая запись-заглушка Вот эта запись 192.168.0.2 Это нормальная полноценная запись Я пришёл на центральный роутер Сказал, где мне взять 192.168.0.2 И мне вернулся ответ На тебе публичный IP-шник этого узла И я на него попытаюсь уже направлять трафик напрямую Третья — заглушка Четвёртая — полноценный адрес 172.16.0.1.12 Пятый — полноценный адрес 172.16.0.1.2 Кстати, это я сам И статическая запись На самом деле полноценных записей Которые у меня в таблице есть Только две Это 192.168.0.2 И 192.168.0.7

Так, давайте посмотрим, кто приехал Show IP NHRP Вижу первый, второй, четвёртый, шестой, седьмой, девятый Одиннадцатый и пятнадцатый Вот Давайте попробую я сделать У меня есть одиннадцатая запись Которая резолвится в 105-й IP-шник А на маленьком моём Роутере Одиннадцатый тоже есть Второй, седьмой, одиннадцатый, пятнадцатый Девятого нету Сейчас возьму и попингую девятый комплект Он будет пингаться И после того, как он попингался Show IP NHRP Покажет, что он есть Вот он Он на лету зарезолвился Только что Две секунды назад И через два часа минус две секунды Я признаю его трупом Так, можно ли ещё раз коротко про команды NHS и MAP?

Легко NHS — это Next Hop Server Это тот, кого вы спрашиваете Кому вы задаёте вопросы У какого публичного IP-шника частный адрес И дальше вы задаёте ему вопрос Например, я в табличке не имел записи для девятого — 192.168.0.9 Я пошёл на Next Hop Server и задал вопрос Где мне взять 192.168.0.9? И Next Hop Server согласно своей базе мне ответил У меня есть указание, что 192.168.0.9 соответствует публичному IP-шнику 172.16.0.101 Это то, чем занимается Next Hop Server Для того, чтобы к Next Hop Server обратиться Нам нужно знать его частный адрес Для того, чтобы это всё работало Мы прописываем командой IP NHRP NHS частный IP-шник Next Hop Server В нашем случае мы задали его как 192.168.0.101 Но для того, чтобы зарезолвить 192.168.0.101 в публичный IP-шник

У нас используется команда NHRP Map Interface Tunnel 0 У нас есть Next Hop Server 192.168.0.101 И мы говорим Дорогой 192.168.0.101, где мне взять 192.168.0.9? Он говорит Ходи на 172.16.0.101 А после того, как у нас сформировался запрос для этого IP-шника Нам нужно каким-то образом его упаковать тоже в GRE И тоже завернуть в публичный пакет, который в интернете будет действителен И мы его заворачиваем Source IP-шник мы проставляем свой собственный Destination IP-шник мы проставляем тот, который в маппинге прописан 101.101.101.101 Так Ещё одна полезная команда есть

Show DMVPN Она покажет, с кем вы по факту обмениваетесь трафиком Здесь мы видим, что у нас есть соответствующие записи Мы знаем, как доставить трафик до 192.168.0.101 Вот его публичный IP-шник 192.168.0.11 Вот его публичный IP-шник 0.9, 0.7, 0.2 IP-шники эти случайные Заранее непредсказуемые И соответственно мы их автоматически узнаём Для того, чтобы всё было совсем хорошо Нам с этими самыми динамическими IP-шниками Нужно проставить ещё указание, что они у нас могут теоретически меняться Потому что у нас есть пул адресов, которые мы получаем по PPPoE Если сейчас PPPoE-шная сессия наша разорвётся То в следующий раз мы можем получить уже другой адрес И для того, чтобы с этим можно было как-то смириться Нам нужно сейчас ConfT Interface Tunnel 0

Interface Tunnel 0 0.9 Пальцы заплетаются IP NHRP Здесь вы можете указать всякие разные штучки И среди прочих вы можете указать Если мне память не изменяет Registration no unique No unique Вот No unique Эта строчка Она как раз будет проставлять на Next Hop сервере При регистрации флаг Что этот IP-шник может меняться И соответственно, если мы через некоторое время, меньше чем два часа Придём и попытаемся перерегистрироваться, но уже из-под другого адреса Например, как раз потому, что у нас PPPoE-шная сессия пристрелилась То нам это сделать дадут Сейчас сделать это не получится Я специально для вас сейчас покажу фокус Я отменяю действие этой команды Я её не применяю

Показываю, что в настройке туннеля её нету Этой команды IP NHRP Registration no unique Здесь отсутствует И я ConfT Interface Ethernet 0, drop 0 Shutdown Выключаю целиком интерфейс Ethernet 0, 0 Через который у меня PPP-шная сессия строится Интерфейс падает Все падает PPPOE падает DMVPN падает Сейчас все разом отвалилось И я переподключаюсь No shutdown У меня сначала должна установиться PPP-шная сессия А потом поверх нее будет строиться туннель Поднялся Ethernet Сейчас должен подняться дайлер И через некоторое время поднимется DMVPN Предполагаю, что у меня сейчас будет уже другой IP-шник Не такой, который был Раньше был адрес Какой у меня адрес был?

15-й 102-й у меня был адрес Да, сейчас IP interface brief Тоже 102-й А, я не успел его погасить А оно уже все упало Так, shut No shut Дайлер 1 поднялся Do show IP interface brief Так IP-шника пока нету А, вот-вот-вот Сообщение Мы попытались зарегистрироваться на NHRP-сервере И получили от него Receive registration Reply packet with error Unique address Registered already

У нас в прошлый раз регистрация на NHRP-сервере прошла с флагом Это адрес постоянный и одинаковый Всегда один и тот же И сейчас IP-шник, видите, поменялся Стал вместо 102-го 115-й Мы попытались перерегистрироваться И Core сказал нам Извините, у меня уже есть запись У нее есть флаг unique И IP-шник у нее публичный Заканчивается на 102 Соответственно 192.168.0.15 IP-шник Он по-прежнему думает, что у меня старый адрес И этот самый unique охраняет Чтобы, не дай бог, мне его никто не перезаписал Чтобы у меня получилось перерегистрироваться Мне надо clear IP NHRP 192.168.0 Какой там он? 15 Сделать Понятно, что это удалит эту запись После чего я смогу перерегистрироваться Но я сейчас хочу перерегистрироваться уже без этого флага unique Поэтому сейчас я в настройке туннеля иду

Интерфейс 100-й IP NHRP Если я буду регистрироваться, я буду регистрироваться уже без флага Это уникальный адрес Стираю запись Shut, no shut Прохожу перерегистрацию Может быть, можно было и не гасить Может быть, он сам догадался бы, что надо перерегистрироваться Но с shutdown просто быстрее Интерфейс перерегистрировался Скорее всего, регистрация уже прошла Видите, здесь уже нет слова unique Раньше было Вот оно, unique registered А здесь уже нету И я теперь получаю этот IP-шник Если я сейчас снова выключу дайлер 1 интерфейс

И запущу его снова Снова получу публичный IP-шник уже другой Оно автоматически обновится на DMVPN-сервере Так Интерфейс дайлер 1 Shut Shut Так Дайлер перезапустился Сейчас туннель перезапустится Он падал как раз Так PPP-шная сессия поднялась Туннель поднялся И идем смотреть, что у нас есть Видите, другой IP-шник Он уже не ругался, что не удалось перерегистрироваться Этот флажок unique Мы убрали И смогли перерегистрироваться уже с новым адресом Так Это практически все, что вам надо знать про DMVPN

Здесь есть всякие разные клевые штуки Которые еще можно будет посмотреть Но мы на них посмотрим, когда будем разговаривать Про динамическую маршрутизацию В частности про EIGRP и OSPF Там можно будет с мультикастом поиграть Можно будет всякие еще другие вещи сделать Поэтому этот интерфейс оставим пока живым Давайте на всякий случай сохраним конфигурацию Чтобы потом можно было с этим DMVPN поиграться И пока перейдем уже к следующей теме Продолжение следует...