Настройка IP-MPLS (2)

Хочу заметить, что в предыдущий раз, когда я делал лабу, вот на ASIS я включил роутер XE правильно, то есть с его стороны все настройки были хорошие, а вот, соответственно, в XR роутере у меня не получилось ввести вот одну команду. На уровне интерфейса нужно прописать адрес family IPv6.unicast. Поэтому я сейчас возьму и сделаю все уже правильно. Enable. Ой, какой Enable, господи, что я делаю? Cisco. Cisco. Вы у себя, пожалуйста, проверьте, что у вас на интерфейсе в настройке роутера XR, так же, как я сейчас буду вводить, есть соответствующая настройка. Потому что если вы вчера делали вместе со мной, то у вас ее, видимо, нет. Конфигурию. Kong. Все уже. Сатурну больше не наливать. Роутер ASIS 1. Дальше адрес family IPv4.unicast.

Интерфейс. Так, интерфейс какой у нас там? Егабит 0.0.0.0.0.0. Адрес... ADD.RESS family IPv4.unicast. Мы сейчас на этом роутере имеем метрики широкие пока еще, поэтому сейчас у нас, вот после того, как мы все настройки вот эти вот сделали, прописали, что у нас интерфейсы есть, на которых есть адрес family IPv4 Unicast, на самом роутере есть адресное семейство IPv4 Unicast. Еще дополнительно, на всякий случай покажу, чтобы оно осталось просто в конфиге net. Так, оно не здесь делается. Просто в конфиг роутере net 49.0000.

Прописываю адрес роутера SS, то есть предсказуемый формат 49, дальше код региона, дальше секретный закодированный IPv4 Unicast 10.002, и в конце 0.0 как селектор intermediate system, а не конечная система. И дальше, соответственно, смотрим на то, что у нас получилось. Вот сейчас у нас LDP, не LDP, простите, ISIS должен работать, должен установить соседские отношения. Так, commit. И выходим. Show ISIS neighbors. Neighbors. У нас показывается, что есть некоторое количество роутеров. Один роутер, я прошу прощения, здесь появился лишний, я тестировал и забыл его убрать. Но, тем не менее, да. Вот у нас есть соседства, здесь два соседства, на роутере XR должно быть одно соседство. Enable. Все.

Пайцы заплетаются под конец рабочей недели. Не могу нормально ничего набрать. Ем. Роутер, похоже, повис. Давайте пока show run XR наберу. Show run router SS. То есть у нас прописан тип intermediate system level 2 only. У нас прописан адрес. У нас прописано, что все идет взаимодействие в адресном семействе IPv4 Unicast. И, кстати, там используются широкие метрики. И у нас есть два интерфейса, на которых работает ISIS. Я, кстати, здесь забыл прописать, но вообще на лупбеке тоже надо прописать, чтобы оттуда IP-шник можно было анонсировать про ISIS. Так. Enable. Show SS neighbors. Вот. У нас показывается, что тоже есть два соседства. Вот этот вот сосед — это роутер XR.

Это вот фантомный дополнительный роутер, которого у вас нет. Да. Еще такой нюанс есть. Смотрите. Вы можете на одну железку, в принципе, в некоторых ситуациях повесить несколько Network Entity Title. Делать это надо с осторожностью. Ну, вот, гипотетически, если вы это делаете, то у вас System ID должен быть одинаковый в любом случае. То есть могут различаться коды регионов, могут различаться типы регионов, но сам System ID должен быть одинаковый везде. Так. К слову сказать, да, show SS neighbors показывает соседей, show SS interfaces показывает список интерфейсов. Еще мне надо звездочка. Сейчас.

Что-то мне это как-то подозрение какое-то вызывает. Show SS interface. Вот. Show SS interface здесь работает. Показывается список интерфейсов, на которых у вас есть SS. И показывается, вот, что у нас есть loopback, на нем работает SS. Показывается, что у нас есть гигабитный Ethernet, на нем тоже работает SS. Здесь можно это показать в более компактном виде. Мамамамамамам. Как же это делается? Это brief. Привет. Все. Brief. Вот. То есть show SS interface brief на XR-ном роутере показывает интерфейсы, на которых завелся SIS. И показывает, что у нас действительно есть два интерфейса, loopback 0 и гигабитный Ethernet 0.0.0.0. На гигабитном интерфейсе у нас есть два adjacency второго уровня. Опять же, у вас должно быть одно, потому что у вас всего один сосед.

Давайте я уберу лишнее соседство, которое нам не нужно. Reconnect. Enable.clone.pt. No router. И сейчас лишнее соседство должны будут пройти. Ну, надо некоторое время для того, чтобы прочихаться. И, соответственно, со стороны router.xr show is this interface. Ну, да, он что-то отказывается использовать такую команду. Ну, еще есть show c lns interfaces. Вот, она показывает по большому счету все то же самое. То есть показывается, когда у нас есть... Какие у нас есть интерфейсы, на которых можно взвести isis, показывается, когда у нас следующий hello. Вот оно. Показывается, сколько у нас соседств есть. Вот показывает, что есть одно соседство второго уровня.

Ну, и вот у нас есть loopback, на котором у нас тоже чего-то там вот бегает. Результатом того, что isis завелся, является притаскивание маршрутов. Show ip road is this. Вот у нас маршрут, прибежавший по isis. Маршрут второго уровня, то есть известный из региона второго уровня. Вот она сетка. Isis-овское административное расстояние 115. Каждый интерфейс в Isis по умолчанию имеет метрику 10, поэтому два интерфейса, которые нужны для того, чтобы дойти до удаленной сети, получается всего 20 копеек. И если вдруг мы захотим посмотреть базу данных в ISIS, то это show isis database. Вот. Я так сильно догадываюсь, что вот эта LSA выпущена роутером XR, и мы можем гипотетически попросить рассказать нам именно про нее.

show isis database detail. Вот. Он рассказывает, что у него есть интерфейс, который смотрит на соседа. Это я так сильно подозреваю как раз на наш роутер. И у него есть два интерфейса, которыми он смотрит на пользовательские сети, на те сети, в которых у нас есть айпишники. С точки зрения ISIS разницы между конечной рабочей станцией и айпи-сетью особой нет. Изначально, если вы помните, ISIS создавался для того, чтобы передавать информацию о подключенных конечных станциях, N-system. Ну вот он фактически говорит, что у меня есть какая-то полезная нагрузка, про которую я могу рассказать. Ну и если мы закажем LSA-ку свою, LSP-шку свою собственную, то гипотетически... Где это у нас будет? Это будет у нас вот, скорее всего, вот такая вот штуковина.

Detail. И он нам расскажет, как наша собственная LSP-шка выглядит. Вот, опять же, есть интерфейс, который смотрит на соседа, и есть два интерфейса, на которых у нас висят пользовательские сетки. Давайте сейчас, для того, чтобы продемонстрировать, как выглядит взаимодействие в ISIS в Виршарке, я сейчас взорву соседство. Роутер. This is. Shutdown. Он так не умеет. Собака страшная. Мегабит 1. Shutdown. И я запускаю Виршарк для того, чтобы в этом Виршарке можно было сейчас посмотреть на те пакеты, которые передаются по сети. Так. Вот он запускается. Он сейчас будет ловить вообще все. Ну, да.

No shutdown. Ждем, чтобы ASIS прочихался. Вот мы уже видим, там какие-то сейчас первые пойдут ISIS Hello. Мы видим, что они вкладываются напрямую в кадры Ethernet. То есть вот у них формат очень такой интересный. Они вкладываются в Ethernet с инкапсуляцией... с инкапсуляцией 802.2. То есть в них указывается не, чего внутри лежит, а сколько этого внутри лежит. Дальше идет LSI-шное вложение, в котором указывается, что внутри лежит что-то ISO-шное. Очень редкий случай, когда мы видим протоколы, в которых дальше идет не снап-вложение. То есть такие, например, стандартные... стандартные спанинг-трейшные кадры, ванильные, будут использовать свое собственное вложение 0x42. И вот ASIS тоже используют свое собственное вложение. И дальше внутри контрольное слово всегда 0.3. И дальше внутри уже само содержимое мясо ASIS. Мы видим ASIS hello.

Мы видим здесь кучу всякого разного. И вот это вот всякое разное, оно будет у нас здесь показывать на то, что мы готовы рассказать. Показывается, что у нас есть... Сейчас, где же это? Вот поддерживаем протоколы. То есть ASIS в hello пакете заявил, что он готов дружить по протоколу IP. Если вдруг мы два роутера друг на друга натравливаем, на обоих включаем ASIS, но один с одной стороны готов дружить по протоколу IP, а второй не готов, то он здесь не заявляет поддерживаемого протокола, и как следствие дружба не происходит. так, давайте посмотрим на какое-нибудь мясо. Вот у нас LSP-шки передаются. ASIS рассказывает про то, что он как-то что-то знает. И у нас есть PDU-шка, LSP-DU. В ней рассказывается про то, что некий роутер с вот таким вот ID-шником 01000000002

нечто придумал. Придумал он вот в этом вот регионе 49.00. Придумал он по протоколу IP. И дальше он рассказывает, чего он такое придумал. Где у нас там есть? Extended IP Rageability. Вот, он рассказывает про два маршрута, которые ему известны. И эти маршруты доступны через метрику 10. И здесь у нас не используются дополнительные метрики широкие. То есть отдельно TLV-шки с большими метриками здесь не присутствуют. Если вдруг мы захотим отправить указание, что у нас некая сетка доступна через больше, чем 10 копеек, то нам нужно включить широкие метрики и задействовать сумму на интерфейсе побольше. Так, это у нас был 100002, это XR. Давайте на XR. Мы сейчас сделаем вот такую штуку. Так.

Configuration. Роутер. This is 1. Роутер. This is 1. Адрес family IPv4. Интерфейс gigabit 0, 0, 0, 0. А, нет, loopback 0. Мы хотим loopback 0. И метрики. Так. Где у нас адрес family IPv4? Метрик 100, например. Вот я сейчас сделал изменение метрики для ASAS. Он должен, по идее, сейчас разослать BPD-ушку. LSPD-ушку соответствующую. Так. Вот, я думаю, это она. Так, так, так, так, так. И, и, и, и, и, и.

Где у нас тут мясо, мясо, мясо, мясо. Это не она. Нам нужно LSP. Это CSNP. Это комплект sequence number был. Нам нужно не ее. Так, так, так, так, так. Вот все LSP, которые есть. Что-то как-то маловато их. А, потому что я коммит не сделал. Все просто. Сейчас должна пробежать еще одна LSP. Вот она пробежала. У нас произошли изменения. И здесь должна указываться теперь большая метрика. Вот она, большая метрика. Так. Видно здесь, что метрика эта достаточно жирная.

То есть вот она занимает 24 бита. Здесь не показывается только 32 бита, как будто она занимает. На самом деле на 24 бита. И плюс к тому здесь еще должно быть отдельное указание, на каких интерфейсах мы дружим с соседями. Так. Давайте попробуем изменить метрику теперь на мегабитном интерфейсе. Так. Так. Новая LSP. И вот тут вот сейчас наш роутер. Должны обменяться информацией о том, на кого они как смотрят. Так. Это можно скрыть. Это можно скрыть. Это можно скрыть. Так. У нас есть две пользовательские сети, на которые мы смотрим нашими...

нашими интерфейсами. И у нас есть еще указание, что мы смотрим на соседа. Вот здесь у нас опять же указывается 000064. Это число 100. 24-битное. При этом мы заявили поддержку широких метрик. Сейчас я найду, где это происходит. Так. Может, это в Hello пакетах идет? Я, честно говоря, не могу найти, где это заявлено. Но, тем не менее, вы видите, да, что метрики там при этом толстые идут. Если мы сейчас скажем, что метрики толстые нам не нужны... Так. Это у нас... Где происходит? У нас происходит в глобальном адресном семействе. Brexit.

Brexit. Adress family IPv4. No metric style wide. Commit. Система нас предупреждает, что метрики сократятся до 63. То есть с такими метриками сотками оно просто не влезет в штатные метрики, которые до 63 предусмотрены в интерфейсе. Поэтому для того, чтобы у нас все стало хорошо, мы должны будем использовать метрики 63. Возможно, опять же, нам сейчас дадут посмотреть на новый LSP. Вот она, новый LSP. И... AS reachability. AS neighbor. Метрика 63. То есть была сотка, стало 63. Вот так вот.

Так. Что еще можно сделать? Там было написано extended reachability. Так. Действительно. IP reachability, internal reachability. У нас пропало... А, во-во-во, смотрите. У нас... Вот оно. AS reachability. Это IPшное... В смысле, это соседство с... С другими... Intermediate system. IP internal reachability. Reachability показывает на то, что у нас известны какие-то префиксы. И они показываются с маленькими метками, метриками. То есть вот у нас какие-то вот кривые метки стоят. Default metric 63. И если мы включаем широкие метрики, да, у нас будет другой тип, другая TLVшка. То есть точно оно будет передаваться именно в этих LSPшках, как уже по-другому. Здесь можно хорошо видеть, что вот эта вот IP internal reachability TLVшка имеет тип 128.

И она показывает, кстати, четыре разные метрики, которые передаются в ASIS. Как уже я говорил в теоретическом модуле, действительно, ASIS использует четыре разные метрики. У него есть default метрика, которую все используют. Delay, стоимость линка и процент ошибок на интерфейсе. Но вот эти вот три последние метрики, они опциональные. И как следствие их никто из вендоров не делал. Сначала не делали, потому что было опциональное типо, не обязательно их было делать. А потом, когда руки до них дошли, выяснилось, что тоже никому особо и не надо. Поэтому да, все вендоры сегодня поддерживают только дефолтную метрику. И вот она имеет тип 63. В то же время, если мы посмотрим на... Давайте мы опять же вернемся. ISO тип... Тип, тип, тип, тип, тип, тип. Тип ПДУшки. Посмотрим на более ранние ПДУшки, которые у нас передавались. Здесь у нас используется... Что-то не то используется.

Вот, Extended IP Reach Ability. Не просто IP Reach Ability, Internal IP Reach Ability, как было, 128 тип. А Extended IP Reach Ability тип 135. И здесь уже ни про какие дополнительные метрики речь не идет. Здесь только одна метрика, которую вы здесь видите. Вот, так что действительно все честно. Показывается, что действительно у нас есть 4 метрики. Показывается, что у нас есть метрика 63 на интерфейсе. Здесь нигде не посмотреть то, что максимум в штатном IP... В штатном ISIS с короткими метриками ограничения на длину маршрутов 1023. Но я думаю, что вы просто поверите мне на слово. Но если мы переключаем ISIS в широкие метрики, у нас эти метрики изменяются, становятся трехбайтовые. Два в 24 степени на интерфейс. И суммарная стоимость маршрута у нас получается тоже до 16 миллионов. Что более чем достаточно для реальных случаев. Так, давайте перейдем к BGP.

У нас следующий по плану протокол BGP. ISIS вот прикольно можно включить, поиграться, увидеть, что маршрут он притаскивает. То есть на XR притаскивает маршруты. show route IPv4. ISIS. А, ну, было бы странно, если бы он смог подружиться. Так, router ISIS 1. Address family IPv4. metric style-wide commit. Вот у нас есть ISIS-ский маршрут. Он прибежал, он нормально посчитан. И мы видим, что с ним все хорошо. У него административное расстояние 115, метрик 110. 100 поставил на интерфейс, который смотрит на соседа, плюс за 10 копеечек сосед продал мне этот интерфейс. Давайте переходим к BGP.

Если мы хотим настраивать BGP, мы должны будем сначала определить, какие автономные системы у нас где будут использоваться. И, соответственно, это определяет то, какие соседства у нас будут устанавливаться. BGP по-разному работает на IBGP-шных и EBGP-шных соседствах. И настройки на них требуются разные. То есть если в случае с EBGP мы настраиваем, допустим, EBGP multi-hop при необходимости, или это L-security, точнее не E, или скорее это E-TTL-security нужно настраивать. Но T-TL-security по сравнению с EBGP multi-hop вот в EOS обычно надо либо одно, либо другое настраивать, потому что если вы включаете EBGP multi-hop, вы отправляете пакеты с T-TL-2. Если вы настраиваете T-TL-security, вы должны будете сказать, что вместо EBGP multi-hop вы отправляете пакеты с T-TL-255, но принимаете пакеты с T-TL-254. В любом случае настройки у нас будут делаться следующим образом. Мы указываем роутер, дальше BGP, номер автономной системы своей.

Мы, безусловно, можем запустить BGP, указав автономную систему, но мы не можем запустить два разных, две разные автономные системы на одном роутере. Если BGP, простите, если EGRP, мы можем запустить два разных экземпляра, сказав, что у нас есть автономная система такая, автономная система сякая, то BGP можно запустить только с одним номером автономной системы, но это не является проблемой, потому что в определенных ситуациях, если вам нужно будет, чтобы некоторые разные соседи видели вас в разных автономных системах, вы можете наврать. Вы можете сказать, что с некоторым соседом мы дружим, подменяя свой номер автономки на какой-то еще. Поэтому запускается только один комплект роутера BGP, дальше номер своей автономки, и вы указываете, с какими соседами вы будете дружить. Neighbor чего-то там, прямоут аэс чего-то там. Это базовое прописывание соседства. Для EBGP этого, в принципе, достаточно. Для IBGP мы обычно прописываем update source дополнительно к этому, потому что мы в IBGP дружим поверх лупбеков.

После того, как мы подружились, то есть если необходимо, в EBGP прописываем вот это вот, если необходимо, в IBGP прописываем update source. Чаще всего update source нужен. Соседство у нас устанавливается, и можно будет посмотреть, насколько хорошо оно работает. Для того, чтобы посмотреть список соседей в ИОСе обычном, используется команда show ipbgpsummary. Она показывает много всякой очень полезной информации, но нас сейчас интересует только вот указание соседства. 192.0.2.2. В нашем случае это IP-шник соседа. Он находится в автономке вот такой вот. Мы сразу понимаем, ага, значит, наша автономка вот такая, его автономка вот такая, значит, это EBGP-шная связь. Дальше. Смотрим вот сюда вот. Это последняя цифра. И если мы там видим цифру, значит, все хорошо. Если мы там видим нет цифру, значит, все плохо, у нас соседство не установилось. Соседей мы узнаем не автоматически, как в SPF, поэтому если мы соседа видим в списке, это ничего не означает. То, что вообще сосед присутствует в списке, означает, что он просто в конфиге прописан, не более того.

А вот эта вот строчка state prefix received, она как раз указывает, в каком состоянии сосед. Если вы захотите, вы можете отдельно посмотреть show.ip.bgp-neighbor, дальше указать конкретный адрес соседа и посмотреть, в каком состоянии сосед и прочее, прочее, прочее. Но вот эта вот команда show.ip.bgp-neighbor, она показывает простыню на четыре экрана. Ее просто тупо долго читать. А show.ip.bgp-summary показывает в табличном виде все самое удобное, все компактно, сразу наглядно видно, с какими роутерами удалось подружиться, с какими нет. И вот здесь вот, если вы видите не цифру, это значит, что у вас соседство не перешло в фазу establishment. То есть вы зависли либо в idle, либо в active, либо в каком-то еще состоянии. Если же вы видите цифру, значит, у вас роутер, сосед находится с вами в состоянии establishment, с ним все хорошо, он обменивается апдейтами. И вот эта вот циферка, которую вы здесь видите, будет показывать на то, какое количество маршрутов есть на соседе. Какое количество маршрутов он вам заявил, этот самый сосед.

То есть префикс received, ну, вполне говорящее название поля, сколько он вам прислал, сколько вы префиксов в него приняли. Если мы хотим настроить IBGP-шное соседство, мы прописываем и номер автономки, и указываем update source. Для IBGP это важно. Чаще всего в IBGP у нас роутеры не все физически связаны друг с другом. То есть у нас есть здесь какой-то IGP протокол, например, OSPF. Он притаскивает маршруты лупбеков. И, соответственно, с этими лупбеками мы строим связи. Для того, чтобы если вдруг у нас между этими роутерами изменится оптимальный маршрут, OSPF или ISAS или что-либо еще перестроило бы кратчайшие маршруты между роутерами, и трафик от одного лупбека до другого по-прежнему продолжил бы ходить. После того, как соседство установлено, мы будем... Мне кажется, что я где-то видел слайд. Да. Мы будем, опять же, в showIPBGP summary его наблюдать.

Для internal BGP у нас в showIPBGP neighbors показывается, что автономка соседа такая же, как у нас, поэтому с этим соседом гайки немножечко расслабляются. В случае с IBGP мы чуть-чуть больше доверяем приходящим апдейтам. Не в том смысле, что у нас прям совсем отключаются все механизмы безопасности, но некоторые механизмы безопасности действительно у IBGP по умолчанию будут отключаться. BGP-шные сессии мы ставим не просто так, а для того, чтобы у нас роутеры по BGP обменивались маршрутами. И эти маршруты должны будут в BGP как-то попасть. Один из вариантов, как это сделать, это сказать, что у нас зарождается в BGP маршрут некий нативный. На роутере мы указываем команду network. Эта команда делает не то же самое, что в EJRP или в RIP или в OSPF. Она не включает BGP на интерфейсах. Нет такого понятия включить BGP на интерфейс. Есть понятие анонсировать в BGP какую-то сетку. Дальше мы указываем IP-шник сети.

Дальше мы указываем ключевое слово mask. И дальше мы указываем десятичную маску. Вот эта маска, и это не условие аксесс-листа. Это прямая маска. И вот этот вот IP-шник плюс вот эта вот маска должны присутствовать в таблице маршрутизации в RIP для того, чтобы вы могли анонсировать эту сеть. BGP — это дистанц-векторный протокол. Дистанц-векторные протоколы не должны анонсировать то, чего у них нет в таблице маршрутизации, иначе это может вызвать петлю. ЦИСК довольно ревностно следит за тем, чтобы дистанц-вектор протокола на ее продукцию следовали базовые плогики, поэтому BGP никогда не анонсирует то, чего у него в таблице нет. Некоторые другие маршрутизаторы, других вендоров могут так себя не вести, но вот ЦИСК себя так ведет. То есть если чего-то в таблице нет, это не анонсируется. Если вы породили какую-то сеть в таблице BGP, в таблице, ну да, вы добавили какую-то сеть в анонс BGP, то этот маршрут должен будет попасть в таблицу BGP.

Ее можно будет посмотреть в команде show ip bgp. И маршруты, которые ваш роутер сам придумал, будут иметь вид в этой таблице следующий. NextHop у них будет прописан 0000. Дальше локальный атрибут вес. Это фирменный ЦИСКовский атрибут, который не передается по сети, но он достаточно важный. Он самый первый проверяется ЦИСКой при алгоритме BestPath Selection. Прописывается 32768. Атрибут ISPath будет пустой. Здесь вот в этой вот колоночке показывается атрибут ISPath. Он состоит из некоторого количества автономных систем плюс буковки. Вот эта вот буковка, либо буковка I, означает, что это нативно взявшийся в BGP маршрут, либо буковка E. Это значит, что маршрут был переложен из протокола EGP, древнего протокола предшественника BGP. Либо вопросик, код происхождения неизвестен. Incomplete. То есть это атрибут origin, и вот этот вот атрибут origin 0,

это атрибут origin 1, это атрибут origin 2. Мы здесь видим, что маршрут вот этот вот, например, взялся нативно из BGP, и он прибежал из автономки 64502. А вот этот вот маршрут взялся нативно в BGP в нашей собственной автономной системе. Поэтому у него атрибут ISPath пустой. Дальше этот маршрут начинает анонсироваться соседям, а соседи анонсируют, возможно, какие-то свои маршруты уже нам. И нам здесь показывают, что вот есть, например, маршрут до сети 0, 0, 0, 0. Я так сильно подозреваю по нулевой маске. Здесь Cisco не показывает маску, но тем не менее она как бы предполагается, что и другой она вряд ли будет. И показывает next hop. То есть до какого IP-шника следует поставить маршрут в таблице маршрутизации. По каждому маршруту показываются всякие страшные буковки. Вот эта вот звездочка, астерийская, показывает, что маршрут валидный. То есть что его, в принципе, гипотетически можно ставить в таблицу маршрутизации.

Вот эта вот птичка показывает, что маршрут лучший. Из всех возможных вариантов, как можно по BGP добраться до дефолтной сетки, до 0, 0, 0, 0, был выбран один маршрут, который самый лучший, который best. Почему у нас два лучших маршрута? Потому что они до двух разных сетей. Вот этот вот маршрут до сети 0, 0, 0, он лучший из всех вариантов, как добраться до сети 0, 0, 0, 0. А вот этот вот маршрут лучший, как добраться до сети 203, 0, 113, 0. То есть это, да, лучший по каждой отдельной сети. Не бывает вообще универсально лучшего маршрута в принципе. То есть нельзя сказать, что из вариантов, куда можно пойти, можно пойти до одной сети, до другой сети, до третьей сети. Лучше всего пойти во вторую сеть. Есть варианты выбрать из двух вариантов, как добраться до одной и той же сети, лучший с точки зрения политик. Вот именно это и делает алгоритм Best Path Selection. В нашем случае у нас всего один вариант, как добраться до такой сети, и всего один вариант, как добраться до вот этой сети.

Поэтому лучший в каждом случае выбирается очень легко. Он единственный вариант, как добраться до каждой сети. Он же становится и лучшим. Эти маршруты валидные, то есть у них никаких препятствий для того, чтобы быть добавленным в таблицу маршрутизации нет. У них валидные next-hop, которые резолюбятся. У них дальше идет критерий сравнения, ну, например, вес. И дальше из одного варианта, как можно выбрать лучший вес. У нас есть один маршрут, у которого вес самый-самый выгодный, самый большой в нашем случае. Из одного варианта был выбран маршрут с весом 0. Ну, вот он и был добавлен в таблицу маршрутизации. Если мы используем IBGP, то есть у нас есть какие-то маршруты, которые к нам прибегают из одной автономной системы, из внешней автономной системы по IBGP-шному соседству. И, соответственно, вот нам какой-то роутер-пограничник соседа рассказывает, что он знает некую сетку 203.0.113.0 по 24 маске

и заявляет, что next-hopом должен быть он сам. То есть при отправке маршрута по IBGP атрибут next-hop у маршрутов меняется на IP-шник, из-под которого ставится сессия. Роутер R2 принимает такой маршрут и дальше отправляет его всем своим соседям по IBGP. В случае с IBGP маршруты не меняют свои атрибуты. И, как следствие, next-hop по умолчанию будет пересылаться тот же самый, который его проставил внешний сосед. Если вы видите, ну, например, вот на роутере R3, вот здесь вот, что к вам прибежал маршрут до сети 203.0.113.0 по 24 маске, и у него next-hop проставлен в 10.0.01, этот маршрут считается валидным, но при этом у него не рабочий next-hop. То есть, как бы, с точки зрения IBGP маршрут как бы корректный, но его не удается добавить в таблицу муштизации. Поэтому вот здесь вот у нас птички не будет. Маршрут не был выбран вообще

ни один в качестве лучшего. Иногда бывает такое, что, да, что мы, если даже имеем всего один маршрут в сторону какой-то сети, мы не можем выбрать из них один, из него один лучший. Просто потому, что не срабатывает базовое правило, чтобы next-hop резолвился в таблице маршрутизации. Самое первое, что происходит при выборе лучшего маршрута, мы отбрасываем те маршруты, у которых next-hop не резолвится. Вот мы из одного маршрута, который был, отбросили все, у которых next-hop не резолвился, и у нас не осталось ничего. Для того, чтобы такой маршрут добавить в таблицу, нам нужно будет либо вот этот вот адрес 10.0.0.1 рассказать по, не знаю, OSPF-у или по ASIS-у или почему-то там еще. То есть, например, R2 скажет, давайте я тебе расскажу, как добраться до 10.0.0.1. Либо альтернативный вариант, вы можете заставить роутер R2 немножко нарушить требование, что IBGP-шные маршруты переходят без изменений, в смысле, EBGP-шные маршруты в IBGP-шных соседей приходят без изменений,

и сказать вот такую вот настройку. Neighbor, дальше IBGP-шный сосед, и указать next-hop self. В этом случае при переправке маршрутов в его сторону вы будете подменять next-hop на свой собственный IP-шник, из-под которого у вас ставится сессия. Как будто бы вы работали по EBGP. И в этом случае тот же самый роутер R3 будет получать точно тот же самый маршрут, но в этом случае у него будет next-hop поставляться уже правильный, уже тот, который он точно знает, потому что с этим IP-шником у него IBGP-шные сессии ставятся. Ну и, как следствие, такой маршрут может быть добавлен в саблицу маршрутизации. Если у вас есть, например, роутер рефлекторы, гипотетически такое может быть, вы в принципе можете добиться поведения, что на роутер рефлектор приходит трафик, дальше вы с этого роутер рефлектора отправляете маршруты уже своим всем остальным роутер рефлектор клиентам.

В этом случае вы должны будете убедиться, что у вас вот этого next-hop self не стоит. Что у вас, если есть там 3-4 роутера и один роутер рефлектор, вот это все в одной автономке происходит. Что если вдруг один роутер А рассказывает про то, что у него есть какая-то сетка, и роутер B, и роутер C, и роутер D, они все рассказывают про то, что у них есть какие-то подключенные сети, не подключенные, а которые они получают из внешних источников. Вот, как правило, в этом случае они с роутер рефлектором дружат через какие-то вот дополнительные линки, через которые по факту трафик ходить не должен. То есть у нас отдельно все это дело ходят по какому-то быстрому ядру сети и отдельно ставятся BGP-шные сессии. Поэтому роутер А, когда скажут, что у него есть какая-то сетка, он ее отправит на роутер рефлектор, роутер рефлектор вернет эту сетку, например, на роутер B, дальше роутер B не должен получать next-hop роутера, роутер рефлектор. Он должен получать либо next-hop роутера А,

либо next-hop, который у него, роутера А есть за спиной, чтобы трафик между B и А ходил уже напрямую. Так что не надо думать, что next-hop-селф нужно прописывать всегда. Это на самом деле довольно такая специфическая штука, и нужно посмотреть в каждом конкретном случае, как лучше всего по дизайну будет организовать вашу сеть. Либо по IGP-протоколу заставить роутеры все изучить выходные точки для трафика, либо next-hop-селф ставить на пограничниках. Если мы настраиваем BGP на Cisco EOS XR, то нужно будет, в принципе, все то же самое сделать, как делаем и на нацистских обычных. То есть синтаксис команд тот же самый, но есть один нюанс. Про него сейчас расскажу. Вы точно так же запускаете роутер BGP, указываете номер автономной системы. Вы прописываете нейборов, но только у вас получается уже более как бы читабельная конструкция. Вы не пишете нейбор чего-то там однако под командой, нейбор чего-то другая под командой, нейбор чего-то третья под командой.

Потому что если у вас нейборов много, на них на всех разные настройки, то Cisco EOS-овский стандартный конфиг читает довольно некомфортно становится, просто неудобно. XR-ный конфиг читается намного лучше, потому что у нас в настройке нейбора есть свой отдельный подконтекст, и мы все настройки, которые мы хотим давать для этого нейбора, относим в его, как это называется, в его субконтекст. То есть если мы хотим прописать, что у нас нейбор 1001 живет в автономке 650001 с нами, окей, заходим в контекст нейбора 1001, пишем remote.is такой-то, если нужно там MD5 аутентификацию сделать, делаем пасворд Cisco, ну или пасворд клеер Cisco, значит, что там дальше идет пароль в открытом виде. В конфиге вот этот вот клеер не будет. Дальше указываем update source, если необходимо, eBGP multihop, но для IBGP-шного соседа eBGP multihop не очень сильно нужен, но тем не менее.

Total security, все то, что мы прописываем на настройке нейбора, вот все это здесь в отдельном контексте есть. И еще одна штука, которую обязательно нужно будет прописать в настройке нейбора. Вы должны будете сказать, что определенный нейбор будет получать определенное адресное семейство. Total security не указывается в EGOS XR, то есть вы указываете просто, что Total security есть, а дальше сказать, сколько его будет, нельзя. Вот. Важный момент. Для EOS XR вы обязаны при eBGP-шном взаимодействии, вот для eBGP это очень важно, если у вас eBGP-шный сосед, что в принципе не наш случай, но тем не менее, если у вас eBGP-шный сосед, вы обязаны на него повесить фильтры. Вы обязаны на него повесить фильтр на вход и фильтр на выход. EOS обычный, по умолчанию ведет себя в расхлябанном режиме. Он принимает и отправляет все, что ему заблагорассудится. То есть EOS в принципе протокол,

который не должен никому ничего не доверять. Если вдруг мы по EOS дружим с некоторым соседом, принимать и отправлять маршруты для этого соседа нужно по-хорошему, только проведя дополнительную инспекцию. EOS классически ведет себя не по актуальному стандарту. Актуальный стандарт говорит, что обязательно должна происходить фильтрация. EOS обычный не выполняет фильтрацию. И поэтому вы должны будете как бы озаботиться этим вопросом, вы должны будете понимать, что в EOS вы прежде чем включать BGP-шное взаимодействие с соседями, ручками пропишите фильтры и включите все в сеть после того, как эти фильтры будут настроены. В противном случае вы рискуете словить крайне неприятную ситуацию. Например, ситуация, у вас есть ESP1, у вас есть ESP2, и у вас есть некий роутер. Ну, в предприятиях это обычно будет актуально. Роутер R. И вот у него две BGP-шные сессии. Один провайдер присылает дефолт. 0, 0, 0, 0, 0, 0.

И, скорее всего, с этим дефолтом выгружает кучу всякой мелочи. То есть дополнительно посылает какие-то кастомные маршруты. И провайдер 2 тоже, соответственно, выгружает дефолт и тоже выгружает кучу всякой мелочи. Если вы на роутере принимаете все, какие попали маршруты, у вас все вот эти вот маршруты складываются в BGP-шную таблицу, а дальше вы по умолчанию раздаете тоже все маршруты всем своим соседям. И у вас все, что в этой табличке есть, оно отсылается всем провайдерским роутерам без какой-либо дополнительной фильтрации по умолчанию. Как следствие, провайдеры, может быть, от вас дефолт-то и не примут, потому что дефолт не сильно интересен. В любом случае, даже если примут гипотетически, проблемы это не создаст. А вот куча всякой мелочи, которая от ESP2 придет в таблицу ESP1, если ESP1 ее не отфильтрует, она будет вызывать проблему, потому что в сторону всей этой мелочевки ESP1 будет ходить теперь через ваш роутер. То есть вы фактически перехватите часть трафика ESP2. Вы клиентам, которые должны были ходить

через оплимки этих провайдеров, будете пускать через себя. Ну и, в принципе, если вы принимаете все подряд маршруты, то вы рискуете тем самым, что на ваш роутер будет совершена атака, при которой провайдер может быть неумышлен, но пришлет вам какие-то маршруты, которые на самом деле присылать вам не должен. Самый простой вариант – это провайдер вам начинает выгружать full view, то есть всю картину интернета в целом. Сегодня в интернете порядка там, ну, чуть меньше 800 тысяч маршрутов IPv4, и там еще порядка 70 тысяч IPv6 маршрутов. Это дофига. Если у вас роутер для этого специально не предназначен, то вы, получив случайно full view от провайдерского роутера, просто сдохните по перегрузке памяти. Так что, да, принимать маршруты, какие попало, не нужно. Вы должны будете прописывать фильтры, но если в EOS обычном это просто здравый смысл, что если вы хотите, чтобы у вас все корректно работало, вам следует прописать фильтры, то в EOS XR вы обязаны прописать фильтры.

Без этого просто не будет работать. Если у вас EBGP-шная сессия, в EOS XR вы обязаны прописать роут-полиси. Мы прописываем роут-полиси, который называется pass. Это, ну, типа permit any any. Прописывается она вот такой вот конфигурацией. Роут-полиси pass. Дальше мы переходим в субконтекст роут-полиси и прописываем просто одно слово pass. Роут-полиси – это очень мощные штуки, которые мы будем с вами разбирать на провайдерском треке более детально, но у них есть очень много возможностей, то есть они намного более мощные, чем роут-мапы в классическом EOS. Если вдруг вы знаете, что это такое, то есть фактически это как язык программирования, там можно делать очень-очень клевые штуки. Настраивать их довольно сложно, поэтому в рамках нашего курса мы это просто не успеем сделать. Но самую простую роут-полиси, которая пропускает через себя вообще все, она вот так вот коротенько и выглядит. Это роут-полиси pass. И вы указываете, что на вход вы ничего не фильтруете и на выход вы ничего не фильтруете. Кроме того, если вы хотите,

вы можете в настройке address-family IPv4 unicast прописать next-hop-self, если вдруг вам это будет актуально. Ну и network команда, она происходит тоже в настройке address-family, но в настройке address-family всего роутера в целом. То есть вот здесь вот. Это в config bgp address-family IPv4. Вот это вот все в настройке нейбора, причем вот это вот в настройке address-family на нейборе, а вот это вот в настройке роутера bgp address-family. Давайте попробуем с вами настроить наши роутеры и посмотреть на то, что у нас в итоге получится. Так, где это у нас будет? Наш роутер. Вот как раз первый попался под руку роутер XR. Прекрасно его и будем настраивать. У нас сейчас... Так, что за userconf? Cisco? User Cisco. У нас сейчас есть связь с loopback'ом нашего соседнего роутера.

PNG 10.1.1.1. ISAS мне притащил маршрут на loopback соседа. Я прекрасно буду этим пользоваться и сейчас подниму IBGP-шную связь с этим самым loopback'ом. Сейчас сначала... Давайте сначала я чуть-чуть поднастрою роутер XE. FT, роутер bgp. Какой-нибудь номер автономной системы выберу. 650001. Neighbor 10.2.2.2. Remote AS такой же 650001. Ну, вот просто нейбор прописал. В XR прописываю conf... Conf... Роутер bgp. 650001. Дальше... Neighbor 10.1.1.1.1. Перехожу в субконтекст нейбора и прописываю remote AS 650001.

Вот если я сейчас нажму commit, у меня ничего не получится. Казалось бы, нейбора прописали и там, и там. Но у нас связи все равно между ними не будет. Не будет связи. Могу продемонстрировать, что действительно ее не будет. Do show ip bgp summary. Вот. Сосед у нас висит в состоянии idle. Давайте я раскрою на весь экран. И еще раз выполню. Show ip bgp summary. Idle означает, что мы даже не пытаемся установить с ним соседские взаимоотношения. Притом do ping 10.2.2.2. Ping пингаются. А сосед в idle висит. Как же так? Проблема здесь в том, что для того, чтобы у нас устанавливалось соседство, надо, чтобы соседство шло на правильный адрес из-под правильного адреса. Сейчас, если я включаю... Допустим, давайте аккуратненько сделаю. Do debug ip packet.

Никогда так не делайте в продакшене. У нас тут есть всякие ip-пакеты, которые бегают. Но я хочу дождаться попытки bgp отправить чего-нибудь. Так. Вот оно. Вот оно, оно, оно. Обратите внимание, откуда идет взаимодействие с адреса 10.0.0.1 на адрес 10.2.2.2. К нам идет взаимодействие. Мы его... Мы такой пакет отбрасываем, потому что оно идет из-под адреса 10.0.0.1. Для того, чтобы у нас сессия поставилась, надо, чтобы она шла из-под айпишника разрешенного. А из-под айпишника 10.0... 10.2.2.2 у нас никакие пакеты при этом не приходят. Поэтому для того, чтобы стало хорошо, мы прописываем на row 3xr в настройке нейбора update source 10.2.2.2.

А, он интерфейс хочет. Commit. И у нас сейчас сессия поставится. Обратите внимание на то, что я прописал update source только с одной стороны. С другой стороны... Так, а что сессия не ставится? Адрес family надо прописать, да? Адрес family IPv4 Unicast. Commit. Что-то ему не нравится. Что ему не нравится? А, ему не нравится то, что в глобальном конфиге тоже надо адресное семейство упомянуть. Ну, окей, укажем. Адрес family IPv4 Unicast. Так. И у нас BGP-шная сессия сейчас должна поставиться.

Вот, чую, должна поставиться сессия showIP BGP summary. Поставилась. Neighbor поднялся. И, кстати, я успел выполнить showIP BGP summary до того, как она поднялась. Здесь показывается ноль. Значит, сосед перешел в фазу established и немедленно пробежало сообщение, что, собственно говоря, сессия поднялась. Что в итоге у нас настроено? Я настроил на iOS XR, включил роутер BGP, прописал IP-шник нейбора и больше я на XE-шке ничего не делал. В то же время на XR, do showIP run router BGP, я прописал нейбора. Я прописал, что он у меня будет жить в другой автономной системе, в смысле, в такой же автономной системе, как у меня. И поскольку я дружу с loopback и на loopback, я прописал update source loopback. На XE-шке я сейчас еще пока не прописал update source loopback. И этого все равно достаточно, потому что XR с SOS по его loopback подключился на loopback соседа.

Сессия поставилась, она разрешена с такими параметрами. По-хорошему, конечно же, стоит прописать с обеих сторон update source loopback 0. Это будет более красиво, более качественно. Вот эта вот строчка address family IPv4 unicast разрешает роутеру BGP в принципе иметь в себе базу IPv4 маршрутов. И вот эта вот строчка address family IPv4 unicast разрешает конкретному нейбору обмениваться базой IPv4 маршрутов. Нужно обе эти штуки указать, так же, как на самом деле в роутере SIS у нас. Если посмотреть. Так. Есть SIS. Та же самая история. Есть адресное семейство глобально включено на самом роутере. И есть отдельно интерфейс, который будет пытаться дружить по этому адресному семейству. Та же самая история в BGP. Так. Давайте пропишем для красоты. Уберем source и сессию передернем. Давайте, если хотите, можем взять и показать, что действительно, если убрать update source, сессия не установится заново.

Так. Интерфейс. Нейбор такой-то. Ну, update source такой-то. Так. Clear BGP. 10. 1.1.1. Дернули сессию. Сессия развалилась и больше не ставится. idle. То есть, если у нас попытка взаимодействия идет из-под неправильного IP-шника, она отбрасывается. XE ожидает получать пакеты только от 10.2.2.2.

Если мы не прописываем update source 10.2.2.2, соседство идет из-под другого IP-шника, и оно не принимается XE. Возвращаем все, как было. Commit. Ждем, что сосед установится. Вот он опять. Только успел показать, что IPBGP summary, оно сразу установилось. Для красоты прописываем с стороны XE ответную часть. Neighbor 10.2.2.2. Update source. Loopback 0. Это не является необходимостью в нашем конкретном случае, потому что у нас сессия ставится с L10.2.2.2 на наш loopback. Но если вдруг наш роутер захочет инициировать сессию из-под своего loopback на адрес соседа loopback, то, соответственно, ему эта команда будет нужна. Дальше. Поставили IBGP-шную связь из-под одного loopback на другой loopback.

И теперь надо будет что-нибудь поделать. Давайте поанонсируем какие-нибудь сеточки. Например, у нас есть вот эти вот самые наши loopback. Давайте эти loopback запихнем в BGP. У нас сейчас они известны через ASIS с административным расстоянием 115. Если я сейчас анонсирую эти же сетки через BGP, то административное расстояние IBGP-шных маршрутов будет 200. Поэтому по BGP они прибегут к таблицу соседа, но не смогут поставиться туда. Показываю. Network. 10.222. Mask. 255.255.255.0. 255. 32-ая там маска. Это на XE-шке. И адрес family.ipv4.unicast. Так, это настройки нейбора.

Так, network. 10.222.255.255.0. 255.255.0. Так, я здесь ошибся. Здесь вот у нас не вот эта сетка, а совершенно даже другая. Так, commit. В BGP у нас сейчас попало две сетки. 10.1.1.1.1.10.2.2.2. И эти сетки в таблицу маршрутов сейчас попасть не смогут, потому что там уже занято. Проверяем. doShowBGP.ipv4.summary. Unicast.summary. Вот. У нас есть сосед. Он прислал нам один префикс. И doShowBGP.ipv4.

Вот эти префиксы. Вот они. 10.1.1.1.10.2.2.2. Маршруты валидные. Маршрут IBGP-шный. Вот он, IBGP-шный маршрут. Единственное, что я не понимаю, почему показывается, что он лучший. Он, по идее, не должен был добавиться в таблицу маршрутизации, но против него должна стоять буковка R. Подозрительно это. doShowBGP.ipv4. Да, вот. Видимо, косяк отображения. Такого быть не должно. Не должно показываться вот этой вот птичке. Напротив него должна стоять буковка R, что ribfailor. Ну и здесь у нас doShowBGP.summary. Маршрут приходит.

Один префикс получен. DoShowIPBGP. Вот они у нас есть. Вот он. Показывается буковка R. Что с ним не все хорошо. Его не удалось поставить в таблицу маршрутизации. R — это ribfailor. Кон 17. Можно заказать детальный вывод. doShowIPBGP 10.222. Slash 32. И он покажет, что именно с этим маршрутом не так. Ribfailor 17. Вот свойства этого маршрута. 10.222. У него MED 110. Код происхождения. Атрибут origin. IGP. Нативно взявшийся в BGP маршрут. Дальше. Local preference 100. Его никто не менял. Он по умолчанию такой. И что с ним еще есть? В принципе, ничего нет. То есть маршрут есть, но в таблицу маршрутизации не добавляется. doShowIPRoute. BGP. Тут пусто. Давайте вбросим какой-нибудь маршрут, который будет присутствовать.

Для этого нам нужно что-нибудь. Ну, например, я предлагаю взять маршруты статические. Давайте породим статические маршруты. И укажем, что мы эти маршруты будем выбрасывать в BGP нативно. IPRoute. IPRoute. Какой-нибудь бы маршрут мне сделать бы. Это у меня роутер там, допустим, 1.1.1.1. 255, 255, 255, 255. 0, 0. Маршрут смотрит никуда. Это маршрут вполне нормальный. doShowIPRoute. Вот он есть. Работает. 5 есть, не просит. Да, он никуда не смотрит, но как бы от BGP-шных маршрутов не требуется, чтобы они куда-то смотрели. Указываем, что роутер BGP 65.0.0.1. Указываем, что мы хотим взять такую сетку из таблицы маршрутизации и анонсировать ее своим соседям. Network. 1.1.1.1.1.

Mask. 255, 255, 255, 255. Проверяется строгое соответствие IP-шника и маски. В нашем случае строгое соответствие есть. 1.1.1.1.1. Slash 32. В BGP мы анонсировали маршрут. Со стороны соседа проверяем, что действительно что-то приходит. ShowBGP IPv4 Unicast Summary. У нас теперь приходят два префикса. ShowBGP IPv4 Unicast. Просто, без ничего. Показывает, что в таблице BGP-шной у нас есть. Вот маршрут 1.1.1.1.1. Slash 32. Он приходит от соседа 10.1.1.1. И мы сейчас проверяем. ShowBroad IPv4 BGP. Маршруты в таблице маршрутизации, оказавшиеся по BGP-шной воле. Действительно маршрут. Действительно с сеткой 1.1.1.1.1. Действительно с Slash 32. Административное расстояние 200.

Доступен через 10.1.1.1. Если я сейчас попытаюсь попингать этот IP-шник, он будет пингаться с предсказуемым негативным результатом. Потому что он будет нульроутиться. Вот. Просто в никуда трафик уходит и все. Так. Далее. Если я хочу работать по EBGP. То есть нам сейчас потребуется тогда третий роутер. Третий роутер. Давайте возьмем на основе VEUS. То есть на основе операционной системы Cisco EUS. Просто обычный наш маленький роутер, который мы использовали с самого начала для замены XE. Сейчас нам нужно будет сделать так, чтобы у нас было три роутера в цепочке. Первый будет смотреть на второй, второй будет смотреть на третий. И сейчас мы указываем, что у нас есть EBGP-шная связь. Enable. Conf.t. Я, честно говоря, не помню, есть тут IP-шник или нет. Поэтому на всякий случай переделываю все с нуля.

Интерфейс Gigabit 0.0. Указываю, что no shutdown. IP-адрес 10.0.0.3. 255, 255, 255.0. Затем роутер BGP. 65.0.0. Неважно, какой. Другую какую-нибудь автономную систему. 65.0.0.3. Neighbor. 10.0.0.2. Remote. AS. 65.0.0.1. Я сейчас буду дружить с XR. То есть мой третий роутер смотрит на XR. Точно тот же самый интерфейс, через который у нас идет дружба. Ничего страшного, в этом нет. Прописали нейборы на роутере EOS. Теперь ответная часть на XR прописываем. Conf.t. Роутер BGP 65.0.0.1.

Neighbor 10.0.0.3. Remote. AS у него будет 65.0.0.3, если мне память не изменяет. Сейчас у нас должно установиться соседство. Если я нажму commit. Где у нас соседство? Соседство, соседство. Show IP BGP summary. Пока что idle. Так. И видите у нас, какая гадкая штука проходит. BGP не хочет устанавливать соседство. BGP сбрасывает сессию. Равным образом, и с XR, если сейчас посмотреть. Do show BGP IPv4 unicast summary. Он нам скажет гадкую вещь, что у нас сосед не очень хорошо работает. То есть у нас соседа просто вот как бы нету. Связано это с тем, что у нас на соседа не прописано road policy.

То есть, вообще говоря, нет. У нас сейчас на соседа не прописан даже адресное семейство. Adress family IPv4 unicast. Вот это больше похоже на правду. Ко мне. Так. Проверяем, что у нас получилось. Вот. У нас есть 10.0.0.3 роутер соседа. Но он, видите, в таком вот кривом состоянии. Ноль префиксов получено. И какой-то подозрительный восклицательный знак. Вот этот вот восклицательный знак, он не случайный. Он как раз и означает, что мы не будем понимать, от этого соседа префиксы никакие. И мы не будем ничего ему отправлять. И здесь показывается страшное сообщение, которого раньше не было. Что у нас есть eBGP-шные соседи, у которых нету ни входящих, ни сходящих политик, настроенных в семействе IPv4 unicast. Как следствие, никакой нормальной взаимодействия с ними не будет возможно.

Даже если сессия сама поставится, вот как здесь вот. Мы видим, что сессия поставилась. Если вдруг этот роутер захочет чего-нибудь отправить. Conf.t. IPv4. Не знаю, сейчас придумаю какой-нибудь маршрут. 255, 255, 255, 255. 0.0. И роутер BGP 65.003. Network 10.3333. 255, 255, 255, 255, 255. Я вроде бы вбросил в таблицу BGP какой-то маршрут. Вроде бы show.ip.bgp он уже должен появиться. Он есть. Я про него рассказываю своему соседу. Show.ip.bgp.neighbor.10.002.

Advertised routes. Показывает, что я ему анонсировал этот маршрут. Вот тут команда показывает, чего вы анонсировали соседу. А при этом на XR он по-прежнему показывает, что нифига нету, что у нас ноль маршрутов получено. Это не потому, что мы их не получили. Это потому, что мы их получили, но отбросили. У нас не прописаны правила приема и отправки маршрутов. То есть политики, по которым мы принимаем или отправляем эти маршруты. Поэтому для того, чтобы нам можно было принять или отправить какие-то маршруты по XR на eBGP-шном соседстве, мы должны будем прописать road policy. road policy pass in, road policy pass out. Но самого road policy еще нету, надо ее прописать. Политики обязательно нужны на eBGP-шном соседстве. На eBGP, вот мы только что проверили, они не нужны. На eBGP они обязательны. Выходим из контекста router bgp neighbor address family. Выходим из контекста neighbor. Выходим из контекста bgp.

Прописываем road policy pass. Пасс. Вот такую вот коротенькую road policy, которая принимает все маршруты, пермитит их и ничего с ними не делает. Если вдруг вы захотите делать что-то с road policy, я говорю еще раз, они очень мощные. То есть это как road map, только раз в 10 мощнее. То есть это действительно как полноценный язык программирования. Вы можете принимать маршруты и дальше их колбасить как угодно. Можете делать сложные проверки. Можете видоизменять маршруты. В принципе, road map — это не самый маломощный инструмент в EOS обычном. Но road map по сравнению с road policy просто сосут в сторонке. Ну вот мы делаем commit. У нас сейчас создается road policy. У нас сейчас прописывается это road policy на eBGP-шное взаимодействие. И сейчас уже show ipbgp, чего у нас там есть, unicast summary, показывает, что от соседа был принят префикс. Сосед прислал нам свою сеточку, и она добавилась в таблицу маршрутизации.

Summary убрать. Покажется, что за седка. Вот она. 3, 3, 3, 3. Она доступна через соседа 10.003, принята из автономки 65000.003, и добавлена в таблицу маршрутизации, и анонсирована своим соседям дальше. Роутер xe-шный получил такой анонс, и show ipbgp. Вот он получил его. Попытался добавить в таблицу маршрутизации, и у него это получилось, потому что 10.003 есть его таблица маршрутизации. Он в эту сетку смотрит напрямую. Не всегда это будет так. Чаще всего, когда у вас есть роутеры, которые принимают маршруты eBGP-шные, отправляют дальше их по iBGP, они при этом отправляют next-hop неизмененный, и этого next-hopа в таблице маршрутизации у iBGP-шных соседей нет. Вот в нашем случае это есть, но вообще это не всегда так. Поэтому в случае, если вдруг вы хотите вбросить этот самый 10.003 в таблицу маршрутизации,

чтобы он резолвился, чтобы можно было iBGP-шные маршруты на iBGP-шным соседям принять, вот вы можете, да, либо включить вот этот вот iBGP-шник в OSPF, либо прописать next-hop-self. Давайте пропишем next-hop-self и посмотрим, как это изменит ситуацию. Роутер bGP-65001. Так, neighbor 10.0.10.222. Нет, 10.111. Адрес family IPv4 Unicast. Next-hop-self. Я на neighbor 10.1.1.1.1.1. Передаю маршруты и перебиваю next-hop на свой собственный. Смотрим, что в итоге получилось. Только что next-hop был 10.003 в том виде, в котором он прибежал от оригинального iBGP-шного соседа. Сейчас то же самое делаю.

Next-hop перебился на iBGP-шник, с которого ставится сессия 10.222. Если вы настраиваете iBGP-шное соседство, то вы, скорее всего, захотите next-hop-self прописывать. Ну, в простых сценариях вы это чаще всего будете прописывать, потому что это самый простой вариант, как сделать без какого-то дополнительного геморроя связанность на всех роутерах со всеми префиксами. В реальности, конечно же, таблица bGP на роутерах выглядит куда более серьезно. То есть вот у нас на наших тестовых роутерах сейчас тут 4 несчастных маршрута. А так-то, если посмотреть на какие-нибудь роутеры в интернете, здесь все будет намного серьезнее. Show, IP, BGP, summary. Это сейчас я показываю сервер Looking Glass. И этот сервер, который в интернете действительно существует, где-то в Швейцарии стоит. Вы можете видеть, какое количество маршрутов bGP-шных у него есть в IPv4. В моем случае, да, здесь показывается 760 тысяч маршрутов.

Это сервер Looking Glass. Он специально создан для того, чтобы на него можно было зайти и что-то там позырить. Так что через него боевой трафик не проходит. У него только один сосед, который принимает маршруты от какого-то известного IP-шника. Но, тем не менее, картина интернета у него полноценная. Так, Show, IP, BGP просто. Вот он показывает все-все-все маршруты. Видите, да, что их много. Я буду их очень долго мотать. 760 тысяч – это не шутки. И показываются здесь лучшие маршруты до каждой сети. Вот у нас, например, маршрут некий. Я не знаю, что это за сетка. Просто какая-то абстрактная сетка. И показывается маршрут оригинальный, BGP-шный зародился в BGP или был перебит атрибут оригин у него в ноль. Зародился в автономке 9583, потом пришел в автономку 4755, оттуда пришел в 6453, оттуда пришел к нам. Вот этот вот маршрут, авторы его почему-то решили не перебивать оригин в ноль.

Мы видим здесь инкомплит. Показывается, что зародился он в автономке 132215, потом пришел в 9498 и оттуда пришел уже к нам. Вот это вот в скобочках, вы видите, 65 тысяч. Это 65 тысяч – это в нашей автономной системе маршрут прошел некоторое количество наших автономок, только таких не совсем наших. Эта штука называется конфедерация, и если у вас есть несколько ваших подконтрольных вам автономных систем, которые вы хотите объединить в одну единую, и, соответственно, вот внутри этой конфедерации у вас такие расслабленные правила безопасности будут, то в этом случае там такие EBGP-шные связи, но не совсем. Мы на провайдерском треке обязательно будем это все дело трогать на CENPC и RAS провайдер. Ну вот здесь мы видим, что маршрут прошел через автономку 65 тысяч, оттуда уже пришел к нам. Эта автономка не совсем вражеская, она такая почти своя, поэтому в скобочках.

Ну и бывают случаи, когда мы можем наблюдать что-то вот такое вот. Я вам рассказывал про IS-prepending, технику, когда роутер искусственно добавляет в IS-path несколько раз подряд одну и ту же свою автономку, для того чтобы IS-path стал длиннее и маршрут бы проигрывал. Но даже если вы вдруг выполняете технику IS-prepending для того, чтобы испортить маршрут, отправляемый через uplink, совершенно не факт, что кто-то не посчитает его лучшим. Вот здесь как раз мы видим, что какой-то роутер посчитал таки лучшим маршрут даже тот, в котором IS-prepending был выполнен. Ну, идею я думаю, что вы поняли, что вот оно вот таким вот образом выглядит. Здесь кто-то тоже пытался выполнить prepending, четыре раза подряд указал свою автономку. Это не помогло, все равно маршрут был выбран лучшим. Так, что здесь еще можно рассказать? В принципе, ничего. Базовое взаимодействие в BGP выглядит именно так. Реально на BGP-шных роутерах мы будем делать намного больше, чем будем включать соседство и проверять, что там оттуда прибегают какие-то префиксы.

Реальная работа с BGP состоит в том, что вы будете делать много-много-много настроек с ним. И BGP — это огромный протокол, у которого настроек действительно много. Самое главное, что нужно будет сделать в BGP, это настроить те самые политики. BGP — это протокол, который основан на политиках, поэтому если вы что-то делаете с BGP, то вы прописываете роутмапы, роутполиси, IS-пасс, аксесс-листы и прочие-прочие-прочие, которые будут указывать, что вы согласны принимать, что вы не согласны принимать, что вы модифицируете по дороге, что вы не модифицируете по дороге. Мы с вами это все аккуратно оставили за скобками для того, чтобы было чем позаниматься на провайдерском треке CCNP. Если мы хотим настраивать MPLS, нам нужно будет, во-первых, договориться о том, что на некоторых интерфейсах работает трафик, сагированный метками. А во-вторых, что эти метки каким-то образом распространяются. Делается это, на самом деле, одной командой в iOS обычным.

То есть почему-то красненьким не выделено вот это вот, вот это вот, это должно быть красненьким, вот это вот красненьким, и вот это тоже должно быть красненьким. Но, тем не менее. Включается все в циске обычной одной команды. Мы заходим на интерфейс и указываем команду MPLS IP. Это и включает LDP на интерфейсе, и включает обработчик MPLS. То есть одна команда делает сразу два действия. Когда вы включаете MPLS на интерфейсе, вы начинаете отправлять мультикастовый UDP пакета на 646-й порт. После того, как вы отправляете эти пакеты и обнаруживаете пакеты ответные, вы ставите директ от TCP-сессию на 646-й, но уже TCP-шный порт, и у вас TCP уже начинает работать как транспорт для отправки LDP-шных пакетов. LDP работает следующим образом. Он назначает метки локально, после чего рассказывает, что если вдруг, дорогие соседи, вы хотите отправлять трафик мне,

пожалуйста, помечайте его мне вот такой вот меткой. В нашем случае мы видим, что у нас действительно два роутера, обнаружили друг друга, по LDP установлена сессия, что MPLS LDP Neighbor показывает, что сосед действительно есть, и работает он, в нашем случае, на Gigabit 0-0 интерфейсе. Дальше, после того, как сосед обнаружен, с ним установлена LDP-шная связь, нужно посмотреть, чего там LDP такое понаделал, какие метки он назначил, и для этого используется команда showmpls-forwarding-table. Эта команда будет показывать все маршруты, для которых LDP придумал какие-то метки, или она также показывает все пути коммутации по меткам, которые у нас появились в результате работы не только LDP, но и каких-то других механизмов. Здесь показывается очень-очень коротенький вывод, showmpls-forwarding-table, но на самом деле в обычной ситуации будет, конечно, существенно больше. По каждой строчке, по каждому,

если хотите, LSP, который проходит через наш роутер, либо начинается, либо заканчивается на нашем роутере, либо проходит транзитом, показывается строчка, и показывается, что если вдруг на наш роутер приходит какой-то трафик, маркированный меткой 16, это значит, что это трафик, предназначенный для вот такого вот маршрута. Local label — это то, что на нас приходит. Через любой интерфейс будет приходить трафик именно с 16-й меткой. Но что мы с этим трафиком будем делать? Мы не будем смотреть, что там внутри IP-пакет, он идет на адрес 10.222, пытается там маски, значит, надо куда-то там его промаршутизировать. Нет, мы будем говорить, что у нас есть трафик, приходящий на нас с 16-й меткой, и мы трафик, приходящий на нас с 16-й меткой, будем обрабатывать следующим образом. Мы будем его направлять в выходной интерфейс YGABIT.00 без метки. По label, значит, снимаем ту 16-ю метку, которая к нам приходит, отправляем содержимое

в сторону соседа. Этот механизм будет удобен как раз в ситуации, когда у нас есть несколько роутеров, роутер R1, роутер R2, R2 я сказал, роутер R3, и у R3 есть какая-то сеть, сеть A. Вот R3 сначала рассказывает по SPF, ребята, у меня есть сетка A, эта сетка разбегается по всем роутерам, все роутеры знают, что есть сетка A, и рассказывают по SPF, что она дальше есть, но LSA-ки пересылают, или по ASAS-у пересылают, или любым другим образом пересылают указание, что такая сеть вообще существует. Может быть, они используют BGP, может быть, они используют SPF, может, они используют ASAS, может, они RIP используют, может, статикой вообще это прописано. Не суть важна. Главное, что у всех этих роутеров есть таблица маршрутизации, указания, что сетка A доступна в том вот направлении. Все эти роутеры знают про существование сети A в таблице маршрутизации в обычной SHAPI-роут. Дальше. Они включают LDP на интерфейсах, которыми они друг на друга смотрят, и говорят, что если мы хотим

трафик в сторону сети A дальше пересылать, пусть нам его присылают с некоторыми метками. Один говорит, я хочу назначить метку 100, другой говорит, я хочу назначить метку 200, третий говорит, я хочу назначить метку 300, гипотетически. И дальше они говорят, если вы мне хотите рассылать трафик до сети A, присылайте мне, пожалуйста, 300 метку. Во все стороны начинают это дело рассылать. Это по протоколу LDP уходят указания. Я придумал такую-то метку, присылайте мне трафик на нее. На всех интерфейсах, где у нас LDP работает, рассылаются вот такие вот уведомления. Почему 300 я здесь показываю? 200. 200 здесь, и 100 вот здесь. То есть, какую метку придумали, такую мы и рассылаем. Дальше показывается, что у нас роутер, например, вот этот вот, разослал указание, присылайте мне трафик до сети A с 200 меткой, отправил по LDP, это в сторону роутера R1, R1 посмотрел, что в таблице маршрутизации у него есть сетка A,

посмотрел, что NextHop будет роутер R2, посмотрел, что R2 прислал по LDP 200 метку для сети и говорит, окей, если я вижу, что у меня в таблице маршрутизации есть запись 10.222, вот трафик, который до сети 222 пойдет, это будет, соответственно, начало длительного пути прохождения трафика по MPLS, я ингресс роутер для MPLS, и, соответственно, я буду заворачивать трафик в ту метку, которую мне сказал соседний роутер. Трафик будет отправляться в сторону роутера R2 с указанием 200 метки. Роутер R2 принимает трафик с 200 меткой, говорит, если здесь пришло с 200 меткой, то мы перекладываем это в выходной интерфейс какой-то там и указываем ту метку, которую нам указал роутер R3, это сотая метка. Вот такие вот правила здесь как раз будут указывать, какой трафик мы получаем, с какой стороны и куда его деваем. То есть очень простая концепция. Если мы видим, что какой-то соседний заявил нам метку,

так называемую метку implicit null, то есть вот здесь вот показывается implicit null или pop label, это значит, что прислали метку номер 3. Это хорошо известный номер метки, который означает, что у меня дальше за мной идет обработка чистого IP, пожалуйста, присылайте мне содержимое без метки. В этом случае мы видим, что вот некий роутер получил от соседа указание, что мне дальше надо обрабатывать этот маршрут по-честному. Присылаем мне его без метки. Тогда трафик мы получаем с меткой, снимаем метку, делаем операцию pop label, содержимое пересылаем дальше в сторону соседа, не заглядывая внутрь, что важно. То есть это у нас действительно идет обработка через MPLS. Если мы хотим работать с цисками обычными, то метки они по умолчанию назначают, начиная с 16. То есть это стартовый номер, начиная с которого выделяются метки. В iOS XR метки выделяются с, по-моему, 16 тысяч.

То есть у них другой диапазон, из которого они назначают метки в LDP. Если мы хотим в iOS XR включить LDP, то на интерфейс это делается в контексте MPLS LDP. Просто указываем интерфейс такой. Все. Больше ничего не надо делать. Show MPLS LDP Neighbor та же самая команда, показывает соседей. Show MPLS Forwarding без Table показывает табличку MPLS-ных маршрутов. Мы видим 24 тысячи. Ну, окей, 24, значит. Можно детально посмотреть Show MPLS LDP Forwarding и чего-то там. Это то, что LDP назначил. Здесь из интересного будет указание, какой префикс у нас есть. Какая метка входящая, то есть для нас предназначенная для этого маршрута, если вдруг мы разослали указание, что мы придумали метку 24 тысячи, то мы всем сказали соседям присылайте трафик нам с меткой 24 тысячи для сети 10.1.1.1 по 32 маске. Исходящая метка

Implicit Null. Та самая троечка или PopLabel в терминологии iOS обычного. Это означает, что сосед, который прислал нам указание по LDP, и что он знает эту сетку с пустой меткой, хочет, чтобы мы прислали ему трафик до этой сети неразмеченный. Ну и, в общем-то, все то же самое здесь по большому счету. Точно так же, как и в iOS обычном, в iOS XR, если вы хотите отправить пакет через IP до этой сети, то у вас здесь есть указание, что у нас есть в цехе вот эта вот сетка. Трафик доступен через adjacency 1001, и если мы хотим через adjacency 1001 отправлять трафик ему, то мы должны будем дополнительно навесить стэк меток. Наша локальная метка будет 24000, но она не используется, а те метки, которые мы будем вешать в случае этого adjacency, будут Implicit Null. То есть, вот эти вот команды show, impil, s, forwarding, show, cf, они могут быть использованы для диагностики LDP.

Давайте попробуем это дело, опять же, настроить. У нас наши роутеры есть, EOS XE настроим первым, enable, conft, mpls, IP, простите. Мы тем самым включаем обработку IP-шного трафика с помощью mpls. Дальше заходим на интерфейсы, interface, gigabit, 1, mpls, IP. То есть, в общем-то, все, больше ничего не надо делать. На интерфейсе зашли, включили IP, и оно работает. Давайте для красоты сделаем еще какой-нибудь интерфейс, сделаем субинтерфейс до третьего роутера, например. Скажем, что у нас есть интерфейс gigabit 1.100. На нем мы повесим IP-шник, IP-адрес, сначала надо encapsulation сделать, encapsulation dot1q100. IP-адрес 10100, 101,

255, 255, 255, 255.0. И тоже mpls. IP. Я хочу сделать отдельный субинтерфейс, который бы смотрел на третий роутер, чтобы у нас была связь между первым и вторым, между первым и третьим, чтобы у нас этот роутер был в серединке между ними. И на mpls.ip везде прописал. На iOS-е обычном делаю соответствующий субинтерфейс. Интерфейс gigabit 0.0.100. encapsulation dot1q100. IP-адрес 10100, 103, 255, 255, 255.0. И mpls.ip. Так. Transparent bridging. Как интересно. No bridge ARB.

Так. Интересно. какие-то, видимо, следы предыдущей лабы. No bridge ARB. Это несколько дней назад я вам показывал про то, как можно bridging сделать на интерфейсах. Как заставить роутер фактически заниматься свитчингом. И я вижу, что у него какие-то следы здесь остались. Вот, bridge group осталась. No bridge group 100. Так. У нас сейчас есть наши роутеры. На этих роутерах сейчас у нас есть связь по IP. Мы можем попингать наших соседей. Do ping 10100 101. Оно должно пингаться. Должно, но не пингается. Подозрительно. Я сильно подозреваю,

что у нас это как-то вот в первый день, когда мы лабо делали, что-то очень похоже было. Как только я включил субинтерфейсы, нашему роутеру резко поплохело. Так, ну хотя бы связь через родительский интерфейс при этом есть. NG 10. 0. 0. 1. Через родительский есть, через субинтерфейс он что-то не хочет работать. Ну, не хочет, не хочет. Не больно-то и хотелось. Shutdown. Мст. Интерфейс гигабит 0. 0. 0. 0. 0. 0.100. encapsulation dot1q 100 IPv4 адрес 10 100 102 24. Так, проверяем, что у нас есть связь с ним.

Да, с ним есть связь. И, значит, сделаем связь между iOS обычным и iOS XR через субинтерфейсы. И на этих субинтерфейсах подключаем MPLS IP. Так, MPLS IP. Что тебе надо, лошадь? Так, Gigabit 0100. Вроде везде убрал. Ну ладно, давайте везде вообще вырубим все следы bridging, которые тут есть. Так, так, так, так, так, так, так, так. Что-то задумался. Bridging, bridging, bridging. Так, no bridge group.

И возвращаемся в наш субинтерфейс. И очередная попытка MPLS IP. Вот, сожрал. Так, это мы сейчас включили MPLS IP просто на роутере. Сказали, что мы хотим дружить по LDP с центральным iOS XR. На iOS XR делаем ответные действия. Экзит. MPLS LDP. Интерфейс Gigabit 0.000. И заодно интерфейс 0.0.100. Вот два интерфейса сделали. Коммит. Занесли в конфигурацию, что у нас LDP должен работать на интерфейсах физическом 0.000 и логическом субинтерфейсе 100. И сейчас у нас, по идее, должно что-то пробежать.

Show LDP Neighbors. Show, простите, MPLS LDP Neighbors. Так. Так, интерфейс есть. Соседств LDP Neighbors нету. Что нам по этому поводу скажет XR? Commit вроде сделал. Show MPLS LDP Interfaces.

Так, интерфейсы вроде есть. Enabled, enabled, LDP интерфейс. Так. Ну, на самом деле, вот я вижу, что между XR и XE построилось MPLS на соседство, а на EOS обычном оно не построилось. Const T. MPLS IP. Я не забыл в глобальном конфиге дать. Интерфейс gigabit 0.0.100. MPLS IP. Ну, вот, очень сложная конфигурация, как бы сложно было ошибиться. И EOS XR Show Run MPLS LDP. Ну, вот, конфигурация-то простая. То есть, вот, с точки зрения XR все настройки идентичны. С точки зрения CSR, в смысле, XR-шного роутера.

Show Run интерфейс gigabit 0.0. GABIT 0.0. GABIT 1. PLS IP. Больше ничего не нужно. Дебаг. Ну, вот, чувствую, дело идет к дебагу. Дебагом PLS LDP Advertisements. messages. Deceived. Send. Так, и периодически keep alive. Так. Так. Включил все, все, все MPLS-ные сообщения LDP-шные.

И вижу, что у меня что-то как-то ничего не бегает. Где-то что-то забыл. Show Run. Show Run. Где-то чего-то забыл. Так. IP-CF есть. Для работы MPLS обязательно нужен CF. Gigabit 0.0. MPLS IP. IP. Так. Это что такое? Conf T. MPLS IP.

Так. Он что-то не хочет его показывать. Возможно, это по умолчанию так. Так. Так. Вот здесь это похоже на правду, что у нас два MPLS IP. А, ну здесь два интерфейса есть. Так. MPLS IP, видимо, он скрывает по умолчанию. Но это не объясняет, почему у нас не отправляются, не принимаются никакие LDP-шные пакеты. Show LDP. MPLS LDP. MPLS LDP. Neighbor. Neighbor. Ну да, Neighbor нет.

Так. Не может ли такого быть, что у нас LDP не зажегся из-за отсутствия, например, роутера ID? Может такое быть, наверное. Давайте попробуем conf T. MPLS LDP. Роутер ID. У него же есть loopback? У него нет loopback. Loopback 0. Do, show, run, интерфейс loopback 0. У него нет loopback 0. Интерфейс loopback 0. IP-адрес 10.333. 255, 255, 255, 255. 0. Так. У меня что-то как-то идея все выходит уже из головы.

Что с ним может быть? То есть, по идее, как минимум он должен начать рассылать flow-сообщение. Мы ему роутер ID прописали. Мы ему все сделали. Единственное, что showMPLS LDP. Capabilities какой-нибудь. Дебаг запущен ли на XR? Не знаю. В общем, да. Весь мой трэблшитинг, который я сейчас пытался производить, он заключается в том, что... Ну, я просто поднял параллельно LDP на всех четырех железках, которые у нас есть. И они разделились на две части. То есть, XE и XR между собой дружат. Иус обычный и Иус обычный дружат. А XE с Иусом обычным и XR с Иусом обычным не дружат. Я не понимаю, что это такое, почему оно так может быть.

То есть, настройки все идентичные, одинаковые. Никакого морального права так себя вести у него нет. Но, тем не менее, он себя так ведет. Робот класса Буратино нырять не может. Поэтому давайте сейчас, чтобы время не тянуть, мы... Вы мне поверите, что действительно там можно сделать MPLS на более чем два узла. Show MPLS LDP Neighbors. Покажет нам список соседей. Здесь должно быть два соседа. Ну, именно здесь, может быть, и да. Их должно быть вообще-то три, но видно только одного. Вот. Это сосед с ID-шником routerID 10.2.2.2. Мы с ним дружим из-под адреса 10.1.1.1. RouterID выбирается стандартным образом. То есть, берется самая большая пишник слопбэков. Дальше. Этот LDP сосед нам прислал некоторые метки, которые он хочет использовать. Show MPLS LDP Bindings.

Покажет нам, что конкретно по LDP нам было прислано. И сосед сказал, что если мы хотим отправлять трафик на 1.1.1.1, это наша собственная метка, мы ее сами придумали. Local Binding пустая, потому что это наша метка, мы ее сами придумали. И мы подсказываем про то, что трафик до этой сети надо направлять нам без метки. Implicit null, метка номер три. Мы говорим, что вот до этой сети мы знаем, как доставить трафик, но мы требуем трафик без метки. Вот до этой сети мы знаем, как доставить трафик по MPLS, мы требуем без метки. А вот до сети 10.2.2.2 по 32 маске, она у нас есть в таблице маршрутизации, мы знаем, как доставить трафик в эту сеть, и мы требуем указывать 17-ю метку для того, чтобы трафик дошел до нас по MPLS. Мы бы приняли трафик с меткой 17-й и дальше каким-то образом его бы обслужили. Show MPLS forwarding table нам покажет,

что если трафик придет к нам с 17-й меткой, мы с него метку снимем и отправим дальше сеть назначений 10.2.2.2 на интерфейс гигабит 1. По факту трафик туда никогда не ходит через этот маршрут, потому что никто нам не хочет присылать трафик с 17-й меткой. Я хотел соединить в одну сеть несколько устройств, для того, чтобы они по MPLS, по LDP подружились, разослали друг к другу содержимое таблицы маршрутизации и пересылали бы друг к другу трафик с разными метками, для того, чтобы это отснифать. Но когда железки всего две, то увидеть это вживую в фршарке довольно сложно. В XR все то же самое, те же самые команды. То есть если мы идем на XR, show MPLS LDP neighbor покажет нам список соседей. У нас есть сосед 10.1.1.1. Мы с ним дружим из под адреса 10.2.2.2. Он нам прислал какие-то метки, и мы их в show MPLS forwarding будем видеть. Трафик, который мы можем сами обработать до сети 10.1.1.1,

вот если вдруг кто-то пришлет нам с 24-тысячной меткой, мы эту метку снимем и отправим дальше в интерфейс gigabit 0.0.0.0 на nexthop 10.0.0.1. Если вдруг мы сами будем пользоваться этим маршрутом ping 10, 1.1.1.1. Вот он как бы пингается. Сейчас мы увидим, что здесь вот количество пакетов будет расти. Вот. Bytes switch it. Это вот как раз те самые пинги, которые мы запустили. Если мы скажем repeat, не знаю, 1000, size 1500, пакеты будут много-много-много отправляться. Я думаю, 1000 я как-то переборщил. Ну, здесь будет хорошо видно, что счетчик тикает. То есть на самом деле мы пользуемся этим маршрутом, и трафик ходит по этому маршруту. Но show.mp.s.forwarding предполагает, что мы сами генерируем трафик до этой сети. Мы отправляем его дальше по сети назначения без метки. Show.cev.ipv4.10.1.1.1.

Вот он покажет как раз, что мы трафик отправляем по цефу, и мы никакую метку не навешиваем. Implicit.noll предполагает, что метку не вешается. Очень жаль, что не получилось мне показать, как это выглядит в случае, если устройств у нас больше двух, потому что там трафик бы действительно передавался с метками, и было бы видно, как эти метки свапаются. Но что-то вот пошло не по плану. Давайте добьем последнее, что у нас осталось. Это у нас в нашем случае будет модуль про сервисы в провайдерской сети.