MPLS Inter-AS L3 VPN Option A: часть 3

888, activate. Далее, на муфтизаторе R8, на муфтизаторе R8, show run section BGP. Говорим, no router BGP 100. Router BGP 1.3.5.9. Router 1.3.5.9. Так, у нас здесь не будет уже второго. Мне нужен только первый и... Мне нужен первый и девятый.

И соответственно, remote AS 1.3.5.9. Окей, готово. То есть вроде бы пока ничего сложного. Peer is wrong AS. 1.5.9. Кто у меня? А, первый. Ну, да, потому что на первом у меня еще тоже. Ну, остается у меня только вот это.

Вот. То есть мне остается вот это вот. Раутер BGP 1.3.5.9. Связанность, да, то есть остается связанность с root-рефлектором. То есть с мемортизатором R8. И в рамках VRF и R8 будет 11-й нейбор. Да, но автономная система у него уже будет номер 11. Готово. На мемортизаторе R11. Поднимаем раутер BGP 11. Говорим neighbor. 10.1.11.1. Remote AS 1.3.5.9.

Peer is wrong AS. Тут же run section. Ага. Да, Василий, спасибо. Окей. Интересно, на R11 сессия, по-моему, поднялась. Былшой IP-интерфейс-бриф. Но интерфейс LBAC-2. Раутер BGP-11. И адвертайзим сетку. Network 11111111.

Mask 255. Раутер. Но раутер SPF-1. Но раутер SPF-99. Раутер EGRP-1114. Окей. Проверяем. Show IP BGP summary с точки зрения CE. Раутер EGRP. Да, то есть вы видите, что у меня тут… Опс-опс-опс-опс-опс-опс. Show IP route BGP. У меня нету BGP-шных префиксов. Надо разбираться, почему. На маршрутизаторе R1. На маршрутизаторе R1. Да, кстати. Show run. Убил раутер. No router. EGRP. EGRP.

Что у меня на маршрутизаторе R1? Show IP route. DREF red. Обратите внимание, что на маршрутизаторе R1 у меня нету 12-го префикса. То есть у меня нету 12-го префикса. При этом на маршрутизаторе R9 он есть. На маршрутизаторе R9 он есть. Давайте с вами включим дебаг и посмотрим, в чем дело. Дебаг VPN v4, Unicast, Updates, Debug BGP. Unicast, Updates. Убил ссин. Сделаем clear.

BGP VPN v4, Unicast, In. Terminal Monitor. Show BGP VPN v4, Unicast, All, Summary. У меня нет сессии с амортизатором R8. Show IP-RAL 150.8.8.8. Маршрут известен. А на амортизаторе R8. Unicast approach base removed. Show BGP VPN 4. Unicast all summary. Она застыла в Videl.

Show IP-Route 150.1.1.1. Ping 150.1.1.1. Source loopback 0. Здесь вроде бы все окей. Show run section BGP. Проверяем. OK. Remote.IS. Update source. На первом. Remote.IS не тот у нас стоит. Итак. Обратите внимание, что происходит. Смотрите. У меня поднялась сессия. У меня поднялась сессия с root reflector. Вот она.

На этом шаге все окей. Далее. Далее. Мы видим, что от амортизатора R8 мы получаем префикс 12.12.12.12. С VPN-овской меткой номер 17. Denied. И причина. Extended community not supported. То есть, мы получаем update, да. И deny его, потому что мы не можем обработать, не можем обработать его extended community. Давайте посмотрим, что же у нас такое происходит. Передача community стоит, да.

Передача community включена здесь. Ну, и очевидно, что она включена вот здесь. Так почему же мы дропаем этот трафик? Почему мы его никуда не импортируем? Смотрите. Show.grf.detail. Обратите внимание, что у меня настроена просто старая еще конфигурация. Видите? Импорт раут-таргета со значением 100.1. А мы получаем update с extended community 200.1. Мы просто не знаем, что делать с community 200.1. Что делать с раут-таргетом 201. У нас нету vrf, в которую мы бы данный префикс могли импортировать. Поэтому марштизатор дропает такой апдейт, его не обрабатывает. Поэтому, поэтому добавим раут-таргет босс 201.

окей. Окей. Ну. Да, тут, ты знаешь, я думаю, что некоторые сообщения могут разниться. Но по сути просто нод-саппорт в том плане, что нод-саппорт, он не может его никуда, скажем так, заинсталлировать. Теперь обратите внимание, да, как только мы дали добро на импорт 200.1, у нас что получается? Мы получили, мы получили апдейт, апдейт для префикса. Видите? 12.12.12. И заинсталлировали его внутрь IP-таблицы vrf.red. Вот так.

Тесты. Теперь на амортизаторе R11 проверяем, что это раут-бит. Тест появился. Сделаем пинг. 12.12.12.12. Сурс лукбак 0. Пинг есть. Давайте теперь запустим трассировку. Трейс раут. 12.12.12.12. Сурс лукбак 0. Немерик. Изобрать внимание, то есть на первом этапе, на первом этапе, то есть вот это у нас стык ПЕЦЕ, вот это у нас стык ПЕЦЕ. Далее вот эта меточка 17, видите, она не изменяется. Она не изменяется на первом путь исследования. У нас получается, что 17 это VPN метка. Далее у нас появляется шаг.

Вот этот вот. Это у нас, где пирятся наши ASBR. То есть ASBR, ASBR. То есть видите, здесь летит обычный IPv4 пакет без меток. Вот он, на пятом шаге. И после этого у нас появляется другая VPN метка номер 28. Номер 28. Так, это где вопрос? Я не могу тебе сказать, что конкретно обозначают прям все сообщения. Нужно просто загуглить, что оно конкретно значит.

Вот сходу я… А, вот вижу. Linecast Base, Receipt Refresh, EndoPrip. Дело в том, что… У меня есть на самом деле предположение, что это значит. Дело в том, что когда идет… То есть когда BGP update… То есть, скажем так, когда BGP обмен кончается, BGP посылает об этом нотификацию. То, что обмен префиксами завершен. Типа, я тебе поставил все, что хотел. Вероятно, что это значит именно вот это. Но не дам гарантии. Не дам гарантии. Давайте проверим на всякий случай наши выводы. Смотрите, мустизатор R1. Мустизатор R1. Узнал этот префикс от root-рефлектора. А root-рефлектор в свою очередь об этом сообщил… О префикс сообщил мустизатор R9. Соответственно, говорим.

ShowBGP VPN V4 Unicast. All для префикса 12.12.12.12. Здесь, как вы видите, мы получили этот апдейт от мустизатора R9. От мустизатора R9. RouteTarget 200.1. И выходная MPLS-метка – это метка номер 17. Вот она у нас. Красненький. Она на слайде сейчас и нарисована. 17 меток VPN. Соответственно, мы смотрим NextHop. Смотрим NextHop 150.999. И говорим ShowMPLSForwardingTable. Видим, что, чтобы добраться до префикса R9, мы должны использовать выходную метку номер 39.

Но если мы вернемся на нашу трассировку, мы увидим, что первая транспортная метка – это метка 39. Пакет достигает мустизатора R9. Достигает мустизатора R9. Далее он смотрит ShowIPRoute.RF.RED и видит, что 12-й префикс нам доступен через 10.9.10.10. А эта сетка является Directly Connected. То есть ShowIPRoute.RF.RED 10.9.10.10. Соответственно, просто выплевывает туда обычный IPv4 пакет. Этот пакет добегает до мустизатора R10. Далее он проверяет ShowBGP VPN V4 Unicast All 12.12.12.12. И видит, что он получил этот префикс от мустизатора R2.

И чтобы достичь этого префикса, с этим префиксом ассоциирована VPN-овская метка номер 28. Соответственно, вот она. У нас во второй части трассировки появляется это число 28. После этого мустизатор R10 смотрит. Ага, NextCop 150.22.2.2. Поэтому ShowMPLS Forwarding Table 150.22.2.2. Соответственно, с этим префиксом ассоциирована Outgoing Label 28. Это уже LDP-шная метка. Поэтому в трассировке мы видим, вот она. 28, это LDP-шная метка. В обратную сторону все будет, в общем-то, то же самое. TraceRoute 11.11.11.11. SourceLubbuck 0.memory. Но только, как вы видите, VPN-овские метки, они немножко поменялись. То есть стали номера 16 и 33.

Что еще раз нам указывает о том, что генерация меток – это исключительно генерация меток для пути только в одну сторону. То есть говорит нам о том, что наш label switch path, то есть вот этот набор меток end-to-end, он как бы односторонний. То есть трафик в одну сторону и в другую ходит по разным меткам. Виктор, смотри. Между R9 и R10 устанавливаются соседства в двух адресных смесах VPN4 и IPv4? Нет. Давай посмотрим конфигурацию муртизатора, например, муртизатора R9. Show run section BGP. У нас здесь, конечно, настроены два адресных семейства – VPNv4 и… Но между R9 и R10 у нас только обычная BGP-сессия внутри VRF.

То есть адресное семейство IPv4 – внутри нужной нам таблицы муртизации. Соответственно, передача трафика осуществляется как обычная IP. То есть это обычный PE тут… Обычный раутинг между PE и CE устройством. То есть это то же самое… То есть это абсолютно, абсолютно то же самое, как между R1 и R11. Show run section BGP. Вот. Видите? То есть абсолютно одинаково. Виктор, какой конкретно момент непонятен? Окей.

Ребят, у кого-то еще вопросы есть по разобранной опции? Остальные? Ну, то есть смотрите, на самом деле опция A – это ничем не отличается от настройки обычного L3 VPN. Просто эту настройку нужно провести с двух сторон. Соответственно, когда вы настраиваете на первом PE-муртизаторе, вы считаете второго провайдера клиентом. Соответственно, когда вы настраиваете на втором провайдере, вы считаете первого провайдера клиента.