MPLS LDP IGP Sync

должно быть. Окей. Поехали дальше. То есть это такой маленький-маленький механсовый. Следующее, что вы можете улучшить в LDP. Итак, ребята, мы с вами вчера говорили о том, что у нас, по сути, живут два протокола вместе. Это некий протокол успех, может быть, любой на самом деле IGP-протокол на SAS, либо EGRP. Единственное, сразу хочу оговориться, что EGRP в MPL-сетях почти что не применяется, поскольку с ним невозможен абсолютно трафик-инженерик. Я вам попозже расскажу, почему именно. Но пока можете просто запомнить, что если вам потребуется как-то рулить, то есть, например, если вы захотите какой-то трафик пускать через одни линки, какой-то трафик пускать через другие линки, то вам обязательно в Underlay нужен либо успех, либо SAS. На EGRP это не заведется. Но еще один момент, что EGRP по определению протокол проприетарный, ну, мы понимаем,

что RFC есть, но тем не менее, количество реализации его, помимо цисковских, примерно ноль, если не считать FRR. И провайдеры, которые строят свою сеть на только цисковском железе и решают использовать в IGP, EGRP вместо, например, того же SPF или SAS, это исчезающее редкое явление. Поэтому, да, действительно, EGRP в MPL-се встретить не получится, ну, просто по соображению правого смысла. Да. Итак, итак, так, а как в SPF не анонсит транзитные сети? Иван, ну, на самом деле, это вопрос даже больше не то, чтобы ко мне, наверное, вопрос к тем, у кого вы слушали курс по C7P. В SPF есть команда, я сейчас не скажу, может быть, ее точно префикс, да, но суть в том, что там есть команда, которая называется Suppress Transit Networks, что-то в таком духе она должна называться. Prefix Suppression называется? Prefix Suppression, да. То есть он оставит генерацию LSE,

да, то есть калькуляцию LSE, скажем так, да, только для лупбеков. Есть еще альтернативный вариант для вандалов, это можно заставить ESPF посчитать маршруты до всех сетей, кроме лупбеков, но потом не установить их в таблицу муштизации. Да, можно, конечно, навесить какой-нибудь Distribute List на IN. Ну да ладно. Итак, ребята, смотрите, у нас есть топология. Вот такая, очень-очень простейшая. То есть это просто часть некой там большой топологии. Смотрите, по-хорошему, по-хорошему, да, вы когда внедряете OSPF, и когда вы внедряете LDP, у вас на самом деле чаще всего происходит один к одному байник. То есть, словом говоря, у нас все интерфейсы, на которых включен SPF, на всех же этих интерфейсах должен быть включен LDP. То есть для этого вы можете использовать такую конфигурацию, как автоконфиг, например, либо вручную. Но иногда, когда вы конфигурируете вручную,

вы можете, например, забыть, а включить LDP на каком-то конкретном интерфейсе. Это раз. Либо, помните, когда мы вчера говорили, что у нас линк, например, флапнул, то есть упал, поднялся. Что у нас получается? У нас сначала установился OSPF соседства, после этого только через какое-то время установился LDP. То есть у нас в течение какого-то времени OSPF работает, а, соответственно, маршрутизатор может начать туда направлять трафик, а LDP еще не сошелся, меточек у нас там нет. Зарян. Телефончик уберу подальше. К чему это может привести? Давайте подумаем. Скажем, у меня все линки равнозначные, например, у SPF, скажем, у всех линков стоимость 10. Стоимость 10. Предположим, что я включил LDP, я включил LDP здесь,

я включил LDP здесь, но забыл включить на нижнем линке. Либо, опять же, у меня пошла конвергенция. К чему это приведет? Соответственно, пакет попадает на маршрутизатор R1. Пакет попадает на маршрутизатор R1. Например, пакет бежит на сетку B. Дальше, дальше. Маршрутизатор. Маршрутизатор смотрится, собственно говоря. У него, согласно OSPF, лучший путь уже будет через этот линк. Поэтому трафик будет направляться вот сюда. Поскольку у нас здесь LDP нет, здесь нет никаких меточек, то пакет будет выплевываться, как обычный IPv4 пакет. То есть, если к нам сюда пришел пакет MPLS, то есть в нем были какие-то метки, то все эти метки снимаются, и дальше идет чисто IPv4 пакет. К чему это приводит? А это приводит к тому, что, ребят,

если у вас вот здесь был, например, какой-то сервис, например, VPN-сервис, смотрите, чтобы... Когда мы будем погружаться в детали, вы увидите, что, чтобы построить VPN-сервис, вам необходимо обеспечить условия, когда у вас метки между двумя граничными маршрутизаторами существуют на всем пути следования пакета. соответственно, если хотя бы в одной точке у вас появляется линк, где этих меточек нету, соответственно, ваш сервис просто падает. То есть у вас, по сути, ваш VPN, скажем так, накрывается мебельным тазом. Это первая проблема. Вторая проблема, что такие проблемы очень трудно трублшутить. Если в классических IP-сетях вы запустите трейсраут, например, и вы просто можете понять, на каком хопе у вас дропаются пакеты, то в MPLS-сетях,

если у вас что-то где-то не работает, если у вас не работает VPN-сервис, вы просто на самом деле увидите, условно говоря, первый хоп, и дальше будут одни звездочки. Потому что MPLS-сетях, скажем так, трейсраут в MPLS-сетях работает несколько по-другому, чуть более сложно. Опять же, а почему? Потому что я вам говорил, что основная идея у нас будет сделать так, чтобы транзитные мужетизаторы, которые внутри облака стоят, чтобы они могли не знать о кастомерских сетях. Поэтому на самом деле кастомер, если выкинет трейсраут, то когда пакет будет идти через транзитный мужетизатор, он не сможет кастомеру ответить, потому что он не знает, куда ставить пакет, у него нет его адреса, таблец может седаться. Есть, конечно, некие костыли, как в итоге смогли заставить трейсраут работать. Но если у вас где-то путь меток разрывается, и кастомер запускает трейсраут, он просто увидит ничего.

Это хорошо еще, если трейсраут есть. А, например, если в MPLS запихали какой-нибудь E1 или ATM, там-то этого всего просто нету, и у тебя между R1 и R2 пойдет не IPv4 пакет, а попытка передать E1, ячейку. И, естественно, ничего из этого не выйдет. Соответственно, по сути, задача обеспечения связанности, непрерывной связанности пути меток, hop by hop, это основная задача всего MPLS транспорта. Кстати, вот такая последовательность меток, то есть, если я вернемся к трейсрауту, если сделаем трейсраут, там 150, 2, 2, 2, вот видите, у нас идет последовательность меток, то есть, вот она 30-ая, потом на следующем hopе 28-ая, потом 30-ая, 28-ая, 30-ая, то есть, вот этот, не стек меток, вот эта последовательность меток, она называется LSP, label switch path.

То есть, собственно говоря, мы всегда должны обеспечить его непрерывность. Интересный работник, как раз MPLS. Стас, отвечая на этот вопрос, тут зависит от, можно сделать, иногда можно сделать трейсраут, ну, или pin трейсраут видимым, но действительно, на самом деле, в большинстве случаев, в большинстве случаев реальной имплементации для тебя MPLS облака будет выступать просто в качестве одного hop, в качестве одного виртуального маршрутизатора, и, по сути, ты должен увидеть, условно говоря, свой gate и дальше уже выходную точку МТС, то есть, куда она дальше там перется. То есть, ты будешь просто в трассе видеть один ход. Так, итак, к чему это? По сути, ребята, вот смотрите, в такой ситуации, в такой ситуации нам бы хотелось бы, то есть, даже, даже предположим, что мы совершили ошибку, например, да, там, неправильно настроили, да, либо у нас конвергенция сети пошла,

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

Что мы можем сделать? Что мы можем сделать? Смотрите, нам необходимо, нам необходимо зайти в режим протокол и ситуация, который у нас настроен. Да уж, путь. Так, на мне настроен протокол SPF1. Естественно, внутри этого протокола, внутри этого протокола, да, как мы с вами просто рассматривали, есть некие команды, которые так или иначе касаются NPLS, касаются протокола LDP, и есть команда sync. Я ее настрою на мышцизаторе R1, на мышцизаторе R5, R8. 5.

Может быть, ты расскажешь в двух словах, что это за команда, что она делает? Интересно. Я на самом деле просто хочу показать на примере, что делать от команды, для чего она бывает нужна. Так, я сейчас скину. Скажем так, это дополнительный атрибут, это дополнительный атрибут, то есть, если я дам showmplsldp sync, showmplsldp enable. А NGP может быть? Да. Showmplsldp NGP. Да, я просто, наверное, не увидел этого. Да, вот оно. Там даже мтдс, да. Showmplsldp sync. Собственно говоря, у меня включается синхронизация на всех моих интерфейсах. LDP is configured. Я боюсь, мне нужно для начала сделать клиент PLS LDP neighbors.

То есть, скинуть соседство со всеми. Окей. Окей. По сути, как себя ведет эта команда? Давайте посмотрим на примере, ребят. Просто давайте посмотрим на примере и попытаемся вместе с вами додуматься. Итак, у меня есть show.ip route 150.222. Как вы видите, у меня, собственно, есть две выходные точки. У меня осуществляется equal cost multipassing on the murchтизаторы R8 и через murchтизаторы R5. Давайте сэмулируем LDP fail на интерфейсе, например, на murchтизаторе R5. Это можно сделать различными способами. для начала я создам access list и access list extended LDP,

в котором просто дропну в сеть цепи сессии, например, примите cp any any им, примите any any. Соответственно, если я дропаю TCP, то в итоге моя LDP сессия развалится и применяю на интерфейсе. Подожди, ты что-то неправильно делаешь. Да, согласен. Согласен. Ну, 20, ну, 10, dnxp, any, any, any, some IP, some IP access list. Так, тут огромное количество для... окей. Соответственно, теперь интерфейс G2.15 и говорим IP access group.

Через какое-то время, да, которое равно тайм-ауту TCP-сессии, да, мы увидим, что моя TCP-сессия должна будет развалиться. А если не секрет, какой там тайм-аут, потому что, ну, штатно в TCP никакого тайм-аута нету. Может быть, там какие-то дополнительные киполаевы? Да, шоу-мплс. Там, естественно, есть киполаевы, LDP-шные, шоу-мплс, лдп-нейбр, я, к сожалению, не помню, какой он, какой он по умолчанию. Вероятно, там в районе 30 секунд, наверняка. Шоу-мплс. 155355. Окей. Шоу-мплс. 155355. 155355. Давайте я просто симулирую, чтобы это было быстрее. clear. pls. LDP-нейбр.

Я сброшу соседство прям непосредственно на шоу-мплс. 63R5. И, по идее, оно у меня не должно будет заново установиться. pls. LDP-нейбр is up. шоу-мплс. 215. show.ip access.list LDP. UDP ходит, но UDP не дает нам установить, на самом деле, отношения со сессой. Они просто увидят друг друга. То есть у нас не должно быть, еще у нас не должно быть здесь, на самом деле, насколько я понимаю, TCP-сессии. Да, Discovery, на самом деле, он здесь роли не играет.

Роли не играют. Нет, я не знаю, может быть, это так. А если мы сделаем... Сейчас, как... Добавь туда 646-юдп для красоты. Ну, давай сделаем так. ip access.list standard.cn No.10, No.20, скажем, deny cp any any any any any any any deny udp any any any 646 deny udp any equal 646 И вот, видишь, вот они у меня упали. То есть у меня такое ощущение, что нужно было более специфичный отцесс-лист. Я не могу сказать сейчас сходу, почему. Вполне вероятно, это может быть связано с обработкой control plane трафика.

Да, потому что трафик идет непосредственно на нас. Но все в том, что вы видите, что hold down timer is expired. Теперь, теперь смотрим show ip route 150.222. Обратите внимание, ребят, у меня упала LDP-сессия. У меня изменилось, у меня изменилось, у меня изменились успев маршруты. Чтобы было более наглядно, чтобы было более наглядно. Вот он старый вывод. Вот он старый вывод. Вот новый вывод. обратите внимание, что у меня были маршруты через интерфейсы 2.15 и 2.18. Остались маршруты только через 2.18. А за счет чего это произошло? За счет того, что сам OSPF присчитал,

что не надо ходить через тот интерфейс, на котором не сросся LDP, или это какая-то более поздняя обработка? Очевидно, что это решение самого OSPF. Почему? Потому что все, что мы видим, связано только с OSPF. Давайте посмотрим чуть более детально. Скажем, showMPLS LDP Neighbor. Обратите внимание, что Neighbor у меня один. теперь showMPLS LDP IGP Sync. На интерфейсе G2.15 LDP Synchronization is Enabled. Sync Status Sync Not Achieved. То есть, смотрите, у нас на интерфейсе G2.15, да, то есть мы просто сейчас глобально в OSPF включили синхронизацию между LDP и IGP. Соответственно, на интерфейсе G2.15 у нас LDP упал. Соответственно, у нас теряется синхронизация на этом интерфейсе.

Что после этого происходит? LDP подает сигнализацию OSPF, чтобы он по возможности не использовал вот этот линк, где у нас пропала LDP-сессия. Как OSPF этого может достичь? На самом деле, если вы посмотрите showIPOSPF Database, showIPOSPF Database, showIPOSPF Database, я здесь выяснил, showIPOSPF route, showIPOSPF route, смотри, нет, showIPOSPF route, showIPROAD OSPF, ты не увидишь этого, потому что у тебя остается только один маршрут, то есть у тебя пропадает маршрут через испорченный интерфейс. Я имел в виду, что есть команда showIPOSPF route, которая в EOS есть, видимо,

EOS XEI переименовали, showIPOSPF, что ты хочешь посмотреть, Симон? Сейчас, как же она называется? Я уверен, что это можно посмотреть в дейтабейсе, а в дейтабейсе единственное, я сейчас пытаюсь посмотреть, докуда мне это нужно посмотреть на самом деле. Я просто сейчас сходу не соображу, какую LSA мне нужно смотреть, но суть в том, что адвертайзица Max LSA на самом деле, то есть она на линке, на испорченном линке задирается стоимость под максимум. Я рисую, предположить, что мне нужно смотреть showIPOSPF датабейс раутер для моего соседа.

И вот она. Видите, у нас появляется транзитная сетка, транзит нетворк, и ее метрика ставится в значении 65000. Таким образом, соответственно, все апдейты, которые получает наш маркетизатор через линк 10.1.5, то есть как раз наш интерфейс 2.15, к ним плюсуются, то есть там используется максимальный успех на метрике. таким образом, вы должны понимать, что механизм защиты IGP-Sync вам поможет в том случае, если у вас есть резервный путь. В моем случае я просто семулировал ситуацию, когда у вас пропало ОСПФ соседство, потом поднялось, то есть у вас поднялось ОСПФ соседство, но еще не поднялось ЛДП соседство. Соответственно, как только ЛДП соседство восстанавливается, как только ЛДП соседство восстанавливается,

10.1.5, 10.1.5, C1.5, 14.1.5, как только у нас ЛДП соседство восстановится, мы увидим, что статус статус sync is achieved, peer is reachable, и showip.ospef database у нас возвращается к нашим исходным значениям, и, соответственно, showip.ru 150.222 покажет нам обратно наш equal-cost multipass. Так, соответственно, на этом, ребят, что такое IGP-синхронизация? Соответственно, как best practice, рекомендуется использовать IGP-синхронизацию всегда, когда, ну, на любых мультизаторах, ну, как минимум на тех мультизаторах,

в которых есть, скажем так, несколько линков, несколько плинков там куда-то. Это может привести к забавным последствиям, когда трафик будет идти по очень сильно неоптимальному маршруту, если, например, у вас кольцо, и в этом кольце у вас MPLS. Зато он будет идти, и сервис останется жив. Именно так.