Сегодня речь пойдет о «межоператорском» взаимодействии — BGP Inter-AS. Эти опции используют при необходимости прокинуть L3vpn между PE маршрутизаторами, находящимися в разных автономных системах. Стоит уточнить, что данные опции используются по большей части внутри компаний при поглощении/слиянии сетей, для взаимодействия между филиалами одной компании если они имеют свои автономные системы и свои mpls домены.
В статье рассмотрим следующие темы:
— BGP Inter-AS Option A
— BGP Inter-AS Option B
— BGP Inter-AS Option C
— Особенности настройки данных опций на JunOS
В данной статье будет много выводов из CLI Cisco и Juniper. Если вы не знаете основ mpls, разницы между bgp labeled-unicast и vpnv4 unicast, то читать данную статью вам нет смысла. Если же эти понятия вам знакомы, то прошу под кат.
Примечание: в приведенных схемах левая часть состоит из маршрутизаторов под управлением JunOS (кроме CE), в правой части Cisco IOS15.
Ну и начнем с самого банального — Option A.
Смысл данной опции заключается в том, что на ASBR-рах создаются VRF на каждый VPN и поднимаются отдельные сабинтерфейсы с соседней AS. Таким образом ASBR-ры взаимодействуют как CE-PE маршрутизаторы, обмениваясь чистыми IP маршрутами. В данной опции между ASBR-ми нет MPLS — только чистый IP трафик:
Разберем поподробнее как работает control plane:
1. PE1 генерирует vpnv4 маршрут и отдает его по MP-BGP на роутрефлектор (RR1).
2. Роутрефлектор имеет vpnv4 сессию с ASBR1, в рамках которой отдает ему полученный от PE1 vpnv4 маршрут.
3. Так как на ASBR1 тоже создан VRF (в нашей топологии на ASBR1 CE1 и CE3, а на ASBR2 — CE2 и CE4), то он принимает маршрут и инсталирует его в таблицу маршрутизации соответствующей vrf.
4. ASBR1 передает на ASBR2 уже чистый IP марушрут (протокол маршрутизации может быть любым, от RIP до BGP). Тут работает взаимодействие по типу от CE к PE, где ASBR1 будет выполнять роль CE маршрутизатора, отдавая IP префикс, а ASBR2 — PE маршрутизатора, получая префикс и генерируя vpnv4 префикс для своей AS. (маршруты передаются с обоих сторон, поэтому оба ASBR выполняют роль и CE и PE маршрутизатора).
5. ASBR2, получив IP префикс, генерирует vpnv4 префикс и отдает его на свой роутрефлектор (RR2).
6. PE2 получает от роутрефлектора по vpnv4 сессии данный префикс и инсталирует его в таблицу маршрутизации соответствующего vrf, предварительно проверив достижимость next-hop и соответствие rt в маршруте сконфигурированному на маршрутизаторе vrf-import.
Теперь перейдем к data plane:
1. PE1 получает пакет от CE1, навешивает на него метку (метку vrf), полученную от ASBR1, транспортную метку до ASBR1 (полученную по ldp) и отправляет в соответствующий интерфейс.
2. P1 получив пакет от PE1 со стеком из 2-x меток производит снятие верхней транспортной метки (php) и отправку пакета на ASBR1.
3. ASBR1 получает пакет с одной меткой (меткой vrf), и действует как обычный PE маршрутизатор, терминирующий клиентский CE маршрутизатор — снимает метку и отправляет пакет в соответствующий интерфейс, но так как роль CE маршрутизатора в данном сценарии выполняет ASBR2, то чистый IP пакет отправляется в стык c ASBR2.
4. ASBR2 получает данный пакет и работает как обычный PE маршрутизатор – добавляет метку vrf (полученную от PE2), транспортную метку до PE2 (полученную по ldp) и отправляет в соответствующий интерфейс.
5. P2 производит снятие транспортной метки (php).
6. PE2 получает пакет с одной меткой (меткой vrf, которую сам и сгенерировал), снимает ее, делает ip lookup и отправляет пакет согласно таблицы маршрутизации соответствующего vrf.
Теперь посмотрим на практике, какие операции с метками будут производиться.
Ниже представлены конфигурации BGP на ASBR-рах:
Все, как видите, как у обычного PE маршрутизатора, ничего криминального.
Примечание: есть несколько нюансов касаемо протоколов маршрутизации. Если вы используете BGP, то, возможно, вам придется воспользоваться командой loops 2, если вы будете связывать два сайта клиента с одинаковыми номерами автономных систем, а если у вас везде будет, к примеру, OSPF, то не стоит забывать про DN-бит. Каждый отдельный случай необходимо рассматривать отдельно.
Итак, мы создали vrf CE1 на PE1 и ASBR1, и vrf CE2 на PE2 и ASBR2, как показано на схеме. Экспорт и импорт vpnv4 маршрутов возможен только между данными vrf-ми внутри автономной системы. Между автономными системами маршрутами обмениваются только ASBR-ры (и то ipv4 unicast). Проверим связность между клиентскими маршрутизаторами CE1 и CE2:
Все отлично, связность есть. Теперь рассмотрим, какие будут происходить операции с метками по ходу продвижения пакета.
Итак, сморим маршрут на PE1:
PE1 навешивает две метки:
16 — метка vrf, полученную через RR1 от ASBR1
299824 — транспортная метка, полученная по протоколу ldp
и отправляет пакет в интерфейс ge-0/0/0.0 в сторону P1.
P1 согласно таблице mpls.0 (так как он транзитный маршрутизатор) производит снятие верхней метки (отрабатывает механизм php) и отправляет данный пакет на ASBR1:
ASBR1 снимает метку vrf и делает ip lookup в таблице CE1.inet.0 (не забываем давать команду vrf-table-label на JunOS):
Пакет от ASBR1 передается через интерфейс ge-0/0/3 на ASBR2 без mpls заголовка — только чистый ip трафик (обычно тегированный, в нашем случае всего одни vrf, поэтому я не стал делать сабинтерфейсы, когда у вас будет несколько vrf, вам придется делать отдельный сабинтерфейс на каждый vpn и указывать его в настройках vrf).
ASBR2, получив IP пакет, ищет маршрут в таблице маршрутизации vrf CE2:
Согласно маршрута, ASBR2 навешивает метку vrf (22), полученную по bgp vpnv4 от PE2 и отправляет в lsp на PE2 (10.1.10.1). Next-hop-ом в маршруте указан P2 или RR2 (в нашем случае рефлектор работает как P-маршрутизатор). Мы предположим, что трафик пойдет через P2 и будем смотреть операции с метками на нем. P2 получает пакет с двумя метками 22 и 17, смотрит в mpls forwarding-table:
Согласно mpls forwarding-table, P2 снимает верхнюю метку (опять php) и отправляет пакет на PE2.
PE2 видит, что эта метка указывает на vrf CE2, производит ip lookup в таблице vrf CE2 и отправляет чистый ip пакет клиенту:
Понятно, что данное решение масштабируется довольно-таки сложно. Если вы подключаете нового клиента, то вам надо будет создать vrf не только на PE маршрутизаторе, на котором данный клиент будет терминироваться, а еще и на ASBR (причем с ответной стороны должны будут сделать то же самое). Естественно, это решение не удовлетворяет сегодняшние запросы операторов связи, поэтому мы перейдем к рассмотрению более интересных решений — опции В и С.
Option B.
Между ASBR поднимается vpnv4 сессия, в рамках которой производится обмен vpnv4 маршрутами (естественно необходимо настраивать фильтрацию на ASBR отдаваемых и получаемых префиксов, что бы не отдать или не получить что-то лишнее). Но мы знаем, что маршрутизатор отбрасывает vpnv4 маршруты (исключение маршрутизаторы Juniper), если у него нет VRF, которому (-ым) эти маршруты предназначены (если указанного в NLRI route-target нет ни в одном из vrf на import). Чтобы изменить это дефолтное поведение на ASBR необходимо разрешить прием всех vpnv4 маршрутов ( keep all — Juniper, no bgp default route-target filter — IOS, retain route-target all — IOS XR, undo policy vpn-target — Huawei).
Примечание: на маршрутизаторах Juniper нет необходимости в команде keep all, так как при конфигурировании eBGP vpnv4 сессии, маршрутизатор автоматически считает себя ASBR-ром для опции В, поэтому принимает и инсталирует все полученные от пиров vpnv4 маршруты в таблицу bgp.l3vpn.0 и передает данные маршруты своим пирам.
Итак, начнем с control plane:
1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.
2. Роутрефлектор RR2 пересылает данный маршрут всем своим клиентам.
3. ASBR2, являясь клиентом роутрефлектора, получает сгенерированный PE2 vpnv4 маршрут. Так как на нем включена опция no bgp default route-target filter, ASBR2 инсталирует полученный маршрут в таблицу маршрутизации.
4. ASBR2 меняет в полученном от роутрефлектора маршруте next-hop на себя, генерирует новую метку (причем значение метки может и не поменяться) и отправляет этот маршрут на ASBR1 по ebgp vpnv4 сессии.
5. ASBR1 принимает vpnv4 маршрут от ASBR2 и инсталирует его в табилицу маршрутизации bgp.l3vpn.0.
6. ASBR1 меняет в полученном от ASBR2 маршруте next-hop на себя, генерирует новую mpls метку и отправляет данный маршрут на RR1.
7. RR1, получив данный маршрут проверяет доступность next-hop, as-path (стандартный механизм выбора лучшего маршрута bgp) и инсталирует данный маршрут в свою таблицу маршрутизации.
8. RR1 передает полученный от ASBR1 маршрут на PE1.
9. PE1, получив от роутрефлектора vpnv4 маршрут, проверяет доступность next-hop, проверяет соответствует ли extcommunity (rt) в полученном маршруте сконфигрурированному на маршрутизаторе vrf-import и инсталирует его в таблицу маршрутизации соответствующего vrf.
Транспортные метки до ASBR внутри AS распределеяются стандартным способом — LDP или RSVP-TE.
Теперь рассмотрим все вышесказанное на примере:
Рассмотрим как будет происходить сигнализация метки для клиентского префикса 10.0.1.0/24, который терминируется на PE2 vrf CE2:
PE2 генерирует vpnv4 маршрут и отдает его по iBGP на роутрефлектор RR2:
Согласно выводу выше, для данного префикса сгенерирована метка 17: mpls labels in/out 17/nolabel(CE2)
Далее PE2 отдает vpnv4 маршруты на роутрефлектор. Маршрутов два, так как один это сеть между PE2 и CE2, а второй – лупбек клиентского маршрутизатора CE2.
Роутрефлектор RR2 передает полученный от PE2 vpnv4 маршрут своим клиентам, включая ASBR2:
ASBR2 принимает данный маршрут и инсталирует его в таблицу маршрутизации:
Обращаем внимание на строку «mpls labels in/out 26/17». ASBR2 генерирует новую метку на in – 26 и отправляет все имеющиеся у него vpnv4 маршруты (или не все если настроена фильтрация на out) в соседнюю AS на ASBR1:
ASBR1 принимает эти маршруты и инсталирует в таблицу маршрутизации:
Помимо того, что ASBR2 сгенерировал новую метку, он так же и изменил next-hop на себя (Nexthop: 10.2.0.2).
ASBR1 генерирует новую метку (VPN Label: 299888) до префикса 10.0.1.0/24, меняет next-hop на себя (Nexthop: Self) и отдает маршрут на роутрефлектор RR1
Роутрефлектор RR1 отдает маршрут своим клиентам, вк��ючая и PE1:
Маршрут мы видим в двух таблицах: в таблице vrf CE1.inet.0 и в таблице bgp vpnv4 маршрутов bgp.l3vpn.0.
Получая vpnv4 маршруты, JunOS проверяет их на пригодность (AS-PATH, доступность next-hop), есть ли указанные в vpnv4 маршруте excommunity в конфиграциях routing instance на import, и если маршрут проходит данные проверки и выбирается лучшим согласно штатному алгоритму выбора bgp best path, он инсталируется на таблицу bgp.l3vpn.0. И уже из этой таблицы ip префикс переносится в таблицу vrf (CE1.inet.0 в нашем случае).
Data-plane:
С сигнализацией меток мы разобрались. Теперь рассмотрим data plane, то есть как будет пересылаться пакет от CE1 (с 10.0.0.2) к CE2 (10.0.1.2) через “mpls облако”.
Для начала запустим пинг между CE маршрутизаторами и убедимся, что связность между хостами есть:
Теперь сделаем трассировку:
Видно, что максимальное количество меток — 2.
Примечание: их может быть и больше, если вы используете traffic-engineereng. В нашем случае метки распределяет только ldp.
Теперь разберемся с операциями над метками при движении пакета по сети.
На PE1 с клиентского маршрутизатора CE1 прилетает чистый IP пакет (в нашем случае с vlan тегом 10, но это не имеет значения, так как это l3vpn и тег снимается). Маршрут на PE1 говорит о том, что пакет необходимо отправить в mpls тоннель. PE1 навешивает две метки: метку vrf — 299888 (которую мы получили от ASBR1) и транспортную метку до ASBR1 – 299792 (полученную по протоколу ldp):
PE1 отправляет данный пакет в интерфейс ge-0/0/1 в сторону RR1 (в нашем случае роутрефлектор выполняет функцию и P-маршрутизатора).
RR1 получает пакет со стеком меток и анализирует верхнюю метку 299792:
Согласно таблице mpls.0, RR1 производит снятие метки (php) и отправку пакета в интерфейс ge-0/0/0.0 в сторону ASBR2.
ASBR2 получает паект только с одной меткой 299888. Смотрим, что он должен сделать:
ASBR1 делает своп метки 299888 на метку 26 и отправляет пакет через стык с AS2 на ASBR2.
Далее ASBR2 тоже производит своп метки 26 на метку 17 (он ее получил от PE2)
Итак как в маршруте next-hop-ом является 10.1.10.1, то ASBR2 должен добавить еще и транспортную метку (19) до PE2:
Пакет отправляется на RR2 или P2, так как пути равнозначны… Посмотрим, что будет делать с данным пакетом P2:
P2 производит снятие метки и отправляет пакет с одной меткой на PE2.
PE2 получает пакет с единственной меткой 17, которая и является меткой vrf. В данном случае используется распределение меток на префикс (одна метка – одни префикс клиента), что в реальной жизни естественно слишком расточительно, поэтому режим распределения меток необходимо переключить – per-vrf (одна метка на vrf). В отличии же от Cisco, в JunOS дефолтный механизм распределения меток – per-next-hop. Если у клиента Ethernet линк, что естественно будет в подавляющем большинстве случаев, то необходимо включить генерацию меток per-vrf командой vrf-table-label. Принцип обработки пакета в данном случае меняется, и достоин отдельной статьи.
Согласно представленной выше информации, PE2 снимает метку 17, делает ip lookup в таблице vrf CE1 и отправляет пакет клиенту.
Конфигурации ASBR:
Хотелось бы добавить, что бывает два вида Option B. Мы рассмотрели первый способ — самый распространенный — ASBR производит подмену next-hop при передаче маршрута внутрь автономной системы (при передаче маршрута на рефлектор). Второй способ заключается в том, что ASBR, как положено для ibgp сессии, при анонсировании маршрута на рефлектор не производил подмену next-hop на свой адрес. Но тогда сеть между ASBR должна быть анонсирована в IGP (можно линк между ASBR сделать passive интерфейсом или прописать на ASBR статику и сделать ее редистрибуцию в IGP). Это необходимо для того, что бы PE маршрутизаторы могли установить BGP маршрут в свои таблицы (проверка доступности next-hop) а ldp сгенерировал метку до данного префикса.
С Option B думаю разобрались. Перейдем к Option С.
Option C
Обмен vpnv4 маршрутами производится между роутрефлекторами разных AS напрямую по ebgp-multihop сессии, а на ASBR-ры ложится задача по распределению маршрутов с mpls метками до лупбеков роутрефлекторов и PE маршрутизаторов соседней автономной системы.
Рассмотрим как работает control plane:
Распределение транспортных меток:
1. ASBR2 по протоколу ldp получает от своих соседей метку до PE2.
2. ASBR2 согласно настроенной политике генерирует маршруты с метками до лубеков своей автономной системы и по bgp labeled-unicast передает данные маршруты на ASBR1, указывая в маршруте next-hop-ом себя.
3. ASBR1 принимает labeled-unicast маршрут от ASBR2 и инсталирует их в mpls forwarding table.
4. ASBR1 генерирует метки для полученных от ASBR2 маршрутов, указывает next-hop-ом себя и отдает маршруты на RR1.
5. RR1, получив данные маршруты проверяет маршрут на валидность, инсталирует в свою таблицу маршрутизации и отправляет всем остальным своим клиентам.
6. PE1 получив от роутрефлектора labeled-unicast маршрут, производит его валидацию и инсталирует маршрут в таблицу маршрутизации.
Распределение меток vrf:
1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.
2. Роутрефлектор RR2 пересылает данный маршрут всем своим клиентам и RR1 по eBGP multihop сессии, не меняя next-hop и значения меток.
3. RR1 передает полученный от RR2 маршрут всем своим клиентам, включая и PE1.
4. PE1 проверят маршрут на пригодность и устанавливает в таблицу маршрутизации соответствующего vrf.
Метки vrf и транспортные метки распределены.
Теперь посмотрим как это все работает на практике. Сначала нам необходимо распределить маршруты лупбеков между автономными системами, так как наша vpnv4 сессия между роутрефлекторами не поднимется ввиду отсутствия маршрута до удаленного роутрефлектора. Мы будем распределять между автономными системами сразу маршруты с метками, поэтому между ASBR-ми будет только labeled-unicast сессия (ipv4 префиксы без меток нам не нуж��ы). Но если вам нужны оба семейства адресов, то необходимо будет указать, что маршруты labeled-unicast необходимо инсталировать в inet.3(иначе на JunOS вы два семейства адресов ipv4 и ipv4 labeled-unicast в одной сессии не поднимите).
Конфигурация bgp на ASBR1 (сессия с ASBR2):
Посмотрим как отработает сигнализация метки до лупбека PE2.
Итак, внутри автономной системы у нас запущен ldp и метки до лупбеков автоматически разлетаются по всей AS. Естественно у ASBR2 есть метки до лупбеков всех маршрутизаторов AS2. Теперь ASBR2 должен сгенерировать маршруты с метками до лупбеков своей AS и передать их на ASBR1. Посмотрим:
Как видно из вывода, ASBR2 сгенерировал метку до префикса 10.1.10.1 на in, равную 22.
Посмотрим данный маршрут на ASBR1:
Нас интересует в выводе метка: 22 и next-hop: 10.2.0.2 (адрес интерфейса ASBR2). Теперь ASBR1 знает как добраться до PE2.
Далее этот маршрут по labeled -unicast сессии передается на рефлектор и с него распределяется внутри автономной системы между PE маршрутизаторами. Но тут есть одно но: если ASBR1 передаст маршрут в том же виде, что и получил от ASBR2, то ничего не заработает, так как маршрута до сети 10.2.0.0/30 (сеть между ASBR-ми) внутри автономной системы нет. Поэтому ASBR1 меняет next-hop на себя и генерирует новую метку:
Посмотрим теперь данный маршрут на PE1:
Все верно, метка 299920 используется чтобы добраться до PE2. В выводе мы также видим еще одну метку 299776, то есть у нас получился стек меток. О назначении второй (299776) будет написано чуть ниже).
Отлично, теперь у нас есть end-to-end lsp между PE1 и PE2. Собственно говоря между рефлекторами тоже теперь есть lsp, так как маршруты до RR1 и RR2 тоже отдаются с метками. После того, как мы распределили маршруты лупбеков между автономными системами, между роутрефлекторами поднимается соседство:
Между рефлекторами распределяются vpnv4 маршруты: NLRI for this session: inet-vpn-unicast.
Мы принимаем 2 префикса от соседа: Accepted prefixes: 2
И столько же отдаем: Advertised prefixes: 2
Думаю, это понятно.
Настройки рефлекторов:
Примечание: в конфигурации RR2 (Cisco IOS15) часть строк, не относящихся к 10.0.10.10 удалена, что бы сократить размер вывода.
Теперь мы можем посмотреть, как работает распределение меток vrf:
PE2 генерирует маршрут до сети 10.0.1.0/24, которая терминируется в vrf CE1
Как видим, была сгенерирована метка 22.
Далее маршрут отдается на RR2:
Роутрефлектор отдает этот маршрут всем своим клиентам, а так же на RR1:
Посмотрим полученный маршрут на RR1:
Маршрут попал в hidden и никуда больше не распространяется. Возникает вопрос — почему? (Причем у Cisco нет такой беды)
Посмотрим причину:
В выводе напротив Next hop type стоит Unusable. Роутрефлектор проверил маршрут на доступность next-hop, но не нашел в таблице маршрутизации маршрут до указанного next-hop.
Посмотрим в таблицу маршрутизации:
Маршрут есть и даже с меткой (логично, мы же его распространили с ASBR1 по labeled-unicast). Дело в том, что в JunOS (в отличии от других вендоров) есть несколько таблиц маршрутизации. Сейчас нас интересует таблицы inet.0 и inet.3.
inet.0 — таблица маршрутизации, в которой хранятся ipv4 unicast маршруты.
inet.3 — таблица маршрутизации, в которой хранятся ipv4 mpls маршруты. Этой таблицей пользуется маршрутизатор, если он является ingress LSR.
BGP, получая vpnv4 маршруты, пытается разрезольвить next-hop именно в таблице inet.3. По умолчанию, bgp labeled unicast маршруты инсталируются в таблицу inet.0 и они не попадают в inet.3. То есть — роутрефлектор получил vpnv4 маршрут и пытается разрезольвить next-hop, но не находит маршрут до него в таблице inet.3 и помечает vpnv4 маршрут как hidden в связи с unusable next-hop.
Необходимо изменить это поведение. Для его есть несколько рычагов:
resolve-vpn — эта команда меняет стандартное поведение JunOS касательно установки labeled-unicast маршрутов в таблицу маршрутизации. Теперь JunOS будет устанавливать полученные по bgp labeled-unicast маршруты и в таблицу inet.0 и в таблицу inet.3.
rib-groups — очень гибкий механизм, можно с помощью политики перетащить определенные маршруты (в плоть до префикса /32) из одной таблицы маршрутизации в другую (в нашем случае из inet.0 в inet.3) Но с rib-groups нужно быть внимательным, так как можно наломать дров, не четко понимая, что делаешь (возможности rib-groups очень велики).
resolution rib bgp.l3vpn.0 resolution-ribs inet.0 — эта команда позволяет никуда ничего не переносить, а лишь заставляет маршрутизатор резольвить vpnv4 маршруты в таблице inet.0.
На роутрефлеторе дадим команду resolution rib, а на PE маршрутизаторе resolve-vpn:
Теперь маршруты на рефлекторе появились и могу быть распространены внутри автономной системы:
Посмотрим сам маршрут с деталями:
В выводе видно, что next-hop остался неизменным при переходе через границу автономной системы, что не характерно для ebgp. Дело в том, что в конфигурации (показана выше) есть команда no-nexthop-change — JunOS, next-hop-unchanged — Cisco, которая меняет стандартное поведение ebgp и не дает менять next-hop при переходе границы автономной системы. Для чего это нужно. Если не дать данную команду, то во всех vpnv4 маршрутах роутрефлектор будет ставить себя next-hop-ом, то есть весь vpn трафик полезет через роутрефлектор, которому и так не сладко в жизни. Теперь, помимо переваривания кучи маршрутов (особенно если на нем FV), ему придется и обрабатывать огромное количество трафика. Собственно конец всегда будет один — данная схема потерпит фиаско, а если быть точнее — падение роутрефлектора со всеми вытекающими. Причем даже наличие двух резервирующих рефлекторов вам не поможет. Но вернемся к нашей топологии и посмотрим vpnv4 маршрут на PE1 (не забываем, что мы уже дали команду resolve-vpn, иначе маршруты попадут в hidden):
Нам интересны строки:
Protocol next hop: 10.1.10.1
Push 22
VPN Label: 22
Сигнализация отработала, теперь у нас есть lsp между PE маршрутизаторами и метки vrf.
Data-plane:
Теперь посмотрим как будет передаваться трафик по просигнализированному пути.
Для начала проверим связность между CE:
Отлично. Теперь можно сделать трассировку:
Виден стек из трех меток.
И так, сморим маршрут на PE1 до клиентского префикса 10.0.1.0/24:
PE1 навешивает три метки:
22- метка vrf, полученна через рефлекторы от PE2
299920 — метка до лупбека PE2, полученная через роутрефлектор от ASBR1
299776 — метка до ASBR1, полученная по протоколу LDP
и отправляет данный пакет в сторону P1: Next hop: 10.0.2.2 via ge-0/0/0.0
Примечание: так как мы распределили метку до PE2 по labeled-unicast, то у P1 нет метки до лубека PE2. Если мы пошлем пакет с двумя метками, то P1 не будет знать что делать с данной меткой. Поэтому нам нужно добавить еще одну метку до ASBR1, тогда P1 будет обрабатывать данный трафик не подозревая что это трафик в соседнюю AS (работает то она только с верхней меткой). Другими словами мы в lsp до ASBR1 туннелируем lsp о PE2.
Посмотрим, что сделает P1 с полученным пакетом:
Все логично, P1 снимает верхнюю метку (механизм php) и отправляет пакет уже со стеком их двух меток на ASBR1.
ASBR1 производит своп верхней метки (метки до PE2), на метку, которую ему сообщил ASBR2:
Примечание: получился очень наглядно — метка 22 была сгенерирована ASBR2 для достижения PE2, в то же время как метка 22 была сгенерирована и PE2 как vrf метка. Поэтому у нас пакет между ASBR1 и ASBR2 будет идти со стеком из двух одинаковых меток 22/22. Реально же это две разные метки (по назначению) и то, что они в данном случае одинаковые — случайность.
Далее пакет попадает на ASBR2.
ASBR2 производит своп верхней метки в стеке на метку 18 или 17 (у нас эквивалентные пути). Эти метки он получил из протокола ldp:
Предположим что пакет уходит на P2, значит ASBR2 производит своп верхней метки на метку 17.
Смотрим что будет делать P2:
P2 снимает метку и отправляет пакет уже с одной меткой (меткой vrf) на PE2.
Осталось только проверить, что будет делать PE2 с пакетом с меткой 22.
PE1 смотрит в mpls forwarding-table, снимает метку, делает ip lookup в таблице CE1 и отправляет пакет в интерфейс GigabitEthernet3/0.10, который смотрит в SW2, к которому подключен клиентский маршрутизатор CE2:
В данном примере я использовал схему со стеком из трех меток. Есть вариант с использованием стека из 2-х меток. Отличие в том, что маршруты, получаемые ASBR-ми, должны быть перераспределены в протокол IGP. Тогда ldp начнет распределять метки и до лупбеков соседней автономной системы, но лично мне данный вариант не нравится, как минимум потому что мы засовываем bgp маршруты в igp, что не очень хорошо. В остальном все аналогично описанному выше.
Надеюсь, я донес до читателя принцип работы данных опций и вам пригодится эта статья при диагностике неисправностей на l3vpn. Статья получилась очень большая и писалась не один день, если кто то хочет что то добавить или заметил какой то недостаток (все таки я человек), прошу писать в личку — поправим и добавим. Если есть вопросы — пишите в комментарии, по возможности отвечу. Спасибо за внимание!
Спасибо за помощь в написании статьи пользователю AllTheThingsUndone.
В статье рассмотрим следующие темы:
— BGP Inter-AS Option A
— BGP Inter-AS Option B
— BGP Inter-AS Option C
— Особенности настройки данных опций на JunOS
В данной статье будет много выводов из CLI Cisco и Juniper. Если вы не знаете основ mpls, разницы между bgp labeled-unicast и vpnv4 unicast, то читать данную статью вам нет смысла. Если же эти понятия вам знакомы, то прошу под кат.
Примечание: в приведенных схемах левая часть состоит из маршрутизаторов под управлением JunOS (кроме CE), в правой части Cisco IOS15.
Ну и начнем с самого банального — Option A.
Смысл данной опции заключается в том, что на ASBR-рах создаются VRF на каждый VPN и поднимаются отдельные сабинтерфейсы с соседней AS. Таким образом ASBR-ры взаимодействуют как CE-PE маршрутизаторы, обмениваясь чистыми IP маршрутами. В данной опции между ASBR-ми нет MPLS — только чистый IP трафик:
Разберем поподробнее как работает control plane:
1. PE1 генерирует vpnv4 маршрут и отдает его по MP-BGP на роутрефлектор (RR1).
2. Роутрефлектор имеет vpnv4 сессию с ASBR1, в рамках которой отдает ему полученный от PE1 vpnv4 маршрут.
3. Так как на ASBR1 тоже создан VRF (в нашей топологии на ASBR1 CE1 и CE3, а на ASBR2 — CE2 и CE4), то он принимает маршрут и инсталирует его в таблицу маршрутизации соответствующей vrf.
4. ASBR1 передает на ASBR2 уже чистый IP марушрут (протокол маршрутизации может быть любым, от RIP до BGP). Тут работает взаимодействие по типу от CE к PE, где ASBR1 будет выполнять роль CE маршрутизатора, отдавая IP префикс, а ASBR2 — PE маршрутизатора, получая префикс и генерируя vpnv4 префикс для своей AS. (маршруты передаются с обоих сторон, поэтому оба ASBR выполняют роль и CE и PE маршрутизатора).
5. ASBR2, получив IP префикс, генерирует vpnv4 префикс и отдает его на свой роутрефлектор (RR2).
6. PE2 получает от роутрефлектора по vpnv4 сессии данный префикс и инсталирует его в таблицу маршрутизации соответствующего vrf, предварительно проверив достижимость next-hop и соответствие rt в маршруте сконфигурированному на маршрутизаторе vrf-import.
Теперь перейдем к data plane:
1. PE1 получает пакет от CE1, навешивает на него метку (метку vrf), полученную от ASBR1, транспортную метку до ASBR1 (полученную по ldp) и отправляет в соответствующий интерфейс.
2. P1 получив пакет от PE1 со стеком из 2-x меток производит снятие верхней транспортной метки (php) и отправку пакета на ASBR1.
3. ASBR1 получает пакет с одной меткой (меткой vrf), и действует как обычный PE маршрутизатор, терминирующий клиентский CE маршрутизатор — снимает метку и отправляет пакет в соответствующий интерфейс, но так как роль CE маршрутизатора в данном сценарии выполняет ASBR2, то чистый IP пакет отправляется в стык c ASBR2.
4. ASBR2 получает данный пакет и работает как обычный PE маршрутизатор – добавляет метку vrf (полученную от PE2), транспортную метку до PE2 (полученную по ldp) и отправляет в соответствующий интерфейс.
5. P2 производит снятие транспортной метки (php).
6. PE2 получает пакет с одной меткой (меткой vrf, которую сам и сгенерировал), снимает ее, делает ip lookup и отправляет пакет согласно таблицы маршрутизации соответствующего vrf.
Теперь посмотрим на практике, какие операции с метками будут производиться.
Ниже представлены конфигурации BGP на ASBR-рах:
bormoglotx@ASBR1> show configuration routing-instances CE1 instance-type vrf; interface ge-0/0/3.0; route-distinguisher 1:2; vrf-target { import target:1:100; export target:1:100; } vrf-table-label; protocols { bgp { group AS64999 { type external; local-address 10.2.0.1; peer-as 64999; local-as 65000; neighbor 10.2.0.2; } } }
ASBR2#sh configuration | b ip vrf ip vrf CE2 rd 2:2 route-target export 2:100 route-target import 2:100 ASBR2#sh configuration | b address-family ipv4 address-family ipv4 vrf CE2 no synchronization neighbor 10.2.0.1 remote-as 65000 neighbor 10.2.0.1 local-as 64999 neighbor 10.2.0.1 activate exit-address-family
Все, как видите, как у обычного PE маршрутизатора, ничего криминального.
Примечание: есть несколько нюансов касаемо протоколов маршрутизации. Если вы используете BGP, то, возможно, вам придется воспользоваться командой loops 2, если вы будете связывать два сайта клиента с одинаковыми номерами автономных систем, а если у вас везде будет, к примеру, OSPF, то не стоит забывать про DN-бит. Каждый отдельный случай необходимо рассматривать отдельно.
Итак, мы создали vrf CE1 на PE1 и ASBR1, и vrf CE2 на PE2 и ASBR2, как показано на схеме. Экспорт и импорт vpnv4 маршрутов возможен только между данными vrf-ми внутри автономной системы. Между автономными системами маршрутами обмениваются только ASBR-ры (и то ipv4 unicast). Проверим связность между клиентскими маршрутизаторами CE1 и CE2:
R5#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/70/84 ms
Все отлично, связность есть. Теперь рассмотрим, какие будут происходить операции с метками по ходу продвижения пакета.
Итак, сморим маршрут на PE1:
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:03:29, localpref 100, from 10.0.10.10 AS path: 65000 64999 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 16, Push 299824(top)
PE1 навешивает две метки:
16 — метка vrf, полученную через RR1 от ASBR1
299824 — транспортная метка, полученная по протоколу ldp
и отправляет пакет в интерфейс ge-0/0/0.0 в сторону P1.
P1 согласно таблице mpls.0 (так как он транзитный маршрутизатор) производит снятие верхней метки (отрабатывает механизм php) и отправляет данный пакет на ASBR1:
bormoglotx@P1> show route table mpls.0 label 299824 mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299824 *[LDP/9] 00:41:16, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop 299824(S=0) *[LDP/9] 00:41:16, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop
ASBR1 снимает метку vrf и делает ip lookup в таблице CE1.inet.0 (не забываем давать команду vrf-table-label на JunOS):
bormoglotx@ASBR1> show route table mpls.0 label 16 mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 16 *[VPN/0] 00:35:23 to table CE1.inet.0, Pop bormoglotx@ASBR1> show route table CE1.inet.0 10.0.1.0/24 CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:05:41, localpref 100 AS path: 64999 2 ? > to 10.2.0.2 via ge-0/0/3.0
Пакет от ASBR1 передается через интерфейс ge-0/0/3 на ASBR2 без mpls заголовка — только чистый ip трафик (обычно тегированный, в нашем случае всего одни vrf, поэтому я не стал делать сабинтерфейсы, когда у вас будет несколько vrf, вам придется делать отдельный сабинтерфейс на каждый vpn и указывать его в настройках vrf).
ASBR2, получив IP пакет, ищет маршрут в таблице маршрутизации vrf CE2:
ASBR2#show ip route vrf CE2 10.0.1.0 Routing Table: CE2 Routing entry for 10.0.1.0/24 Known via "bgp 2", distance 200, metric 0, type internal Last update from 10.1.10.1 00:20:49 ago Routing Descriptor Blocks: * 10.1.10.1 (default), from 10.1.10.10, 00:20:49 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 22 MPLS Flags: MPLS Required
ASBR2#sh mpls forwarding-table 10.1.10.1 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 21 18 10.1.10.1/32 0 Gi1/0 10.1.0.2 17 10.1.10.1/32 0 Gi2/0 10.1.2.2
Согласно маршрута, ASBR2 навешивает метку vrf (22), полученную по bgp vpnv4 от PE2 и отправляет в lsp на PE2 (10.1.10.1). Next-hop-ом в маршруте указан P2 или RR2 (в нашем случае рефлектор работает как P-маршрутизатор). Мы предположим, что трафик пойдет через P2 и будем смотреть операции с метками на нем. P2 получает пакет с двумя метками 22 и 17, смотрит в mpls forwarding-table:
P1#sh mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 Pop Label 10.1.10.1/32 18542 Gi1/0 10.1.3.1
Согласно mpls forwarding-table, P2 снимает верхнюю метку (опять php) и отправляет пакет на PE2.
PE2 видит, что эта метка указывает на vrf CE2, производит ip lookup в таблице vrf CE2 и отправляет чистый ip пакет клиенту:
PE2#sh mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 No Label 10.0.1.0/24[V] 14450 aggregate/CE2 PE2#sh ip rou vrf CE2 10.0.1.0 Routing Table: CE2 Routing entry for 10.0.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 2 Advertised by bgp 2 Routing Descriptor Blocks: * directly connected, via GigabitEthernet3/0.10 Route metric is 0, traffic share count is 1
Понятно, что данное решение масштабируется довольно-таки сложно. Если вы подключаете нового клиента, то вам надо будет создать vrf не только на PE маршрутизаторе, на котором данный клиент будет терминироваться, а еще и на ASBR (причем с ответной стороны должны будут сделать то же самое). Естественно, это решение не удовлетворяет сегодняшние запросы операторов связи, поэтому мы перейдем к рассмотрению более интересных решений — опции В и С.
Option B.
Между ASBR поднимается vpnv4 сессия, в рамках которой производится обмен vpnv4 маршрутами (естественно необходимо настраивать фильтрацию на ASBR отдаваемых и получаемых префиксов, что бы не отдать или не получить что-то лишнее). Но мы знаем, что маршрутизатор отбрасывает vpnv4 маршруты (исключение маршрутизаторы Juniper), если у него нет VRF, которому (-ым) эти маршруты предназначены (если указанного в NLRI route-target нет ни в одном из vrf на import). Чтобы изменить это дефолтное поведение на ASBR необходимо разрешить прием всех vpnv4 маршрутов ( keep all — Juniper, no bgp default route-target filter — IOS, retain route-target all — IOS XR, undo policy vpn-target — Huawei).
Примечание: на маршрутизаторах Juniper нет необходимости в команде keep all, так как при конфигурировании eBGP vpnv4 сессии, маршрутизатор автоматически считает себя ASBR-ром для опции В, поэтому принимает и инсталирует все полученные от пиров vpnv4 маршруты в таблицу bgp.l3vpn.0 и передает данные маршруты своим пирам.
Итак, начнем с control plane:
1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.
2. Роутрефлектор RR2 пересылает данный маршрут всем своим клиентам.
3. ASBR2, являясь клиентом роутрефлектора, получает сгенерированный PE2 vpnv4 маршрут. Так как на нем включена опция no bgp default route-target filter, ASBR2 инсталирует полученный маршрут в таблицу маршрутизации.
4. ASBR2 меняет в полученном от роутрефлектора маршруте next-hop на себя, генерирует новую метку (причем значение метки может и не поменяться) и отправляет этот маршрут на ASBR1 по ebgp vpnv4 сессии.
5. ASBR1 принимает vpnv4 маршрут от ASBR2 и инсталирует его в табилицу маршрутизации bgp.l3vpn.0.
6. ASBR1 меняет в полученном от ASBR2 маршруте next-hop на себя, генерирует новую mpls метку и отправляет данный маршрут на RR1.
7. RR1, получив данный маршрут проверяет доступность next-hop, as-path (стандартный механизм выбора лучшего маршрута bgp) и инсталирует данный маршрут в свою таблицу маршрутизации.
8. RR1 передает полученный от ASBR1 маршрут на PE1.
9. PE1, получив от роутрефлектора vpnv4 маршрут, проверяет доступность next-hop, проверяет соответствует ли extcommunity (rt) в полученном маршруте сконфигрурированному на маршрутизаторе vrf-import и инсталирует его в таблицу маршрутизации соответствующего vrf.
Транспортные метки до ASBR внутри AS распределеяются стандартным способом — LDP или RSVP-TE.
Теперь рассмотрим все вышесказанное на примере:
Рассмотрим как будет происходить сигнализация метки для клиентского префикса 10.0.1.0/24, который терминируется на PE2 vrf CE2:
PE2#sh ip route vrf CE2 10.0.1.0 Routing Table: CE2 Routing entry for 10.0.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 2 Advertised by bgp 2 Routing Descriptor Blocks: * directly connected, via GigabitEthernet3/0.10 Route metric is 0, traffic share count is 1
PE2 генерирует vpnv4 маршрут и отдает его по iBGP на роутрефлектор RR2:
PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 2 Paths: (1 available, best #1, table CE2) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (10.1.10.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 mpls labels in/out 17/nolabel(CE2)
Согласно выводу выше, для данного префикса сгенерирована метка 17: mpls labels in/out 17/nolabel(CE2)
Далее PE2 отдает vpnv4 маршруты на роутрефлектор. Маршрутов два, так как один это сеть между PE2 и CE2, а второй – лупбек клиентского маршрутизатора CE2.
PE2#sh ip bgp vpnv4 all neighbors 10.1.10.10 advertised-routes BGP table version is 39, local router ID is 10.1.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 (default for vrf CE1) *> 10.0.1.0/24 0.0.0.0 0 32768 ? *> 10.1.1.2/32 10.0.1.2 2 32768 ? Total number of prefixes 2
Роутрефлектор RR2 передает полученный от PE2 vpnv4 маршрут своим клиентам, включая ASBR2:
RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.1.10.3 advertised-routes BGP table version is 21, local router ID is 10.1.10.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 *>i10.0.1.0/24 10.1.10.1 0 100 0 ? *>i10.1.1.2/32 10.1.10.1 2 100 0 ? Total number of prefixes 2
ASBR2 принимает данный маршрут и инсталирует его в таблицу маршрутизации:
ASBR2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 4 Paths: (1 available, best #1, no table) Advertised to update-groups: 1 Local 10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 Originator: 10.1.10.1, Cluster list: 10.1.10.10 mpls labels in/out 26/17
Обращаем внимание на строку «mpls labels in/out 26/17». ASBR2 генерирует новую метку на in – 26 и отправляет все имеющиеся у него vpnv4 маршруты (или не все если настроена фильтрация на out) в соседнюю AS на ASBR1:
ASBR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.2.0.1 advertised-routes BGP table version is 13, local router ID is 10.1.10.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 *>i10.0.1.0/24 10.1.10.1 0 100 0 ? *>i10.1.1.2/32 10.1.10.1 2 100 0 ? Total number of prefixes 2
ASBR1 принимает эти маршруты и инсталирует в таблицу маршрутизации:
bormoglotx@ASBR1> show route receive-protocol bgp 10.2.0.2 10.0.1.0/24 10.0.1.0/24 detail inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 2:1:10.0.1.0/24 (1 entry, 1 announced) Accepted Route Distinguisher: 2:1 VPN Label: 26 Nexthop: 10.2.0.2 AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
Помимо того, что ASBR2 сгенерировал новую метку, он так же и изменил next-hop на себя (Nexthop: 10.2.0.2).
ASBR1 генерирует новую метку (VPN Label: 299888) до префикса 10.0.1.0/24, меняет next-hop на себя (Nexthop: Self) и отдает маршрут на роутрефлектор RR1
bormoglotx@ASBR1> show route advertising-protocol bgp 10.0.10.10 10.0.1.0/24 detail bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 2:1:10.0.1.0/24 (1 entry, 1 announced) BGP group RR type Internal Route Distinguisher: 2:1 VPN Label: 299888 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [1] 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
Роутрефлектор RR1 отдает маршрут своим клиентам, вк��ючая и PE1:
bormoglotx@PE1> show route receive-protocol bgp 10.0.10.10 10.0.1.0/24 detail inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) * 10.0.1.0/24 (1 entry, 1 announced) Import Accepted Route Distinguisher: 2:1 VPN Label: 299888 Nexthop: 10.0.10.3 Localpref: 100 AS path: 2 ? (Originator) Cluster list: 10.0.10.10 AS path: Originator ID: 10.0.10.3 Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) * 2:1:10.0.1.0/24 (1 entry, 0 announced) Import Accepted Route Distinguisher: 2:1 VPN Label: 299888 Nexthop: 10.0.10.3 Localpref: 100 AS path: 2 ? (Originator) Cluster list: 10.0.10.10 AS path: Originator ID: 10.0.10.3 Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
Маршрут мы видим в двух таблицах: в таблице vrf CE1.inet.0 и в таблице bgp vpnv4 маршрутов bgp.l3vpn.0.
Получая vpnv4 маршруты, JunOS проверяет их на пригодность (AS-PATH, доступность next-hop), есть ли указанные в vpnv4 маршруте excommunity в конфиграциях routing instance на import, и если маршрут проходит данные проверки и выбирается лучшим согласно штатному алгоритму выбора bgp best path, он инсталируется на таблицу bgp.l3vpn.0. И уже из этой таблицы ip префикс переносится в таблицу vrf (CE1.inet.0 в нашем случае).
Data-plane:
С сигнализацией меток мы разобрались. Теперь рассмотрим data plane, то есть как будет пересылаться пакет от CE1 (с 10.0.0.2) к CE2 (10.0.1.2) через “mpls облако”.
Для начала запустим пинг между CE маршрутизаторами и убедимся, что связность между хостами есть:
CE1#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/91/132 ms
Теперь сделаем трассировку:
R5#traceroute 10.0.1.2 numeric timeout 1 Type escape sequence to abort. Tracing the route to 10.0.1.2 1 10.0.0.1 32 msec 4 msec 12 msec 2 10.0.2.2 [MPLS: Labels 299792/299888 Exp 0] 48 msec 68 msec 52 msec 3 10.0.3.1 [MPLS: Label 299888 Exp 0] 48 msec 60 msec 52 msec 4 10.2.0.2 [MPLS: Label 26 Exp 0] 64 msec 52 msec 52 msec 5 10.1.0.2 [MPLS: Labels 19/17 Exp 0] 48 msec 60 msec 52 msec 6 10.0.1.1 52 msec 52 msec 56 msec 7 10.0.1.2 48 msec 64 msec 108 msec
Видно, что максимальное количество меток — 2.
Примечание: их может быть и больше, если вы используете traffic-engineereng. В нашем случае метки распределяет только ldp.
Теперь разберемся с операциями над метками при движении пакета по сети.
На PE1 с клиентского маршрутизатора CE1 прилетает чистый IP пакет (в нашем случае с vlan тегом 10, но это не имеет значения, так как это l3vpn и тег снимается). Маршрут на PE1 говорит о том, что пакет необходимо отправить в mpls тоннель. PE1 навешивает две метки: метку vrf — 299888 (которую мы получили от ASBR1) и транспортную метку до ASBR1 – 299792 (полученную по протоколу ldp):
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.2 CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:15:32, localpref 100, from 10.0.10.10 AS path: 2 ? to 10.0.2.2 via ge-0/0/0.0, Push 299888, Push 299792(top) > to 10.0.0.2 via ge-0/0/1.0, Push 299888, Push 299792(top)
bormoglotx@PE1> show interfaces descriptions Interface Admin Link Description ge-0/0/0 up up to P1 ge-0/0/1 up up to RR1 ge-0/0/3 up up to SW1 lo0 up up router-id
PE1 отправляет данный пакет в интерфейс ge-0/0/1 в сторону RR1 (в нашем случае роутрефлектор выполняет функцию и P-маршрутизатора).
RR1 получает пакет со стеком меток и анализирует верхнюю метку 299792:
bormoglotx@RR1> show route table mpls.0 label 299792 mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299792 *[LDP/9] 01:19:34, metric 1 > to 10.0.1.1 via ge-0/0/0.0, Pop 299792(S=0) *[LDP/9] 01:19:34, metric 1 > to 10.0.1.1 via ge-0/0/0.0, Pop
Согласно таблице mpls.0, RR1 производит снятие метки (php) и отправку пакета в интерфейс ge-0/0/0.0 в сторону ASBR2.
ASBR2 получает паект только с одной меткой 299888. Смотрим, что он должен сделать:
bormoglotx@ASBR1> show route table mpls.0 label 299888 mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299888 *[VPN/170] 00:17:02 > to 10.2.0.2 via ge-0/0/3.0, Swap 26
ASBR1 делает своп метки 299888 на метку 26 и отправляет пакет через стык с AS2 на ASBR2.
Далее ASBR2 тоже производит своп метки 26 на метку 17 (он ее получил от PE2)
ASBR2#show ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 4 Paths: (1 available, best #1, no table) Advertised to update-groups: 1 Local 10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 Originator: 10.1.10.1, Cluster list: 10.1.10.10 mpls labels in/out 26/17
Итак как в маршруте next-hop-ом является 10.1.10.1, то ASBR2 должен добавить еще и транспортную метку (19) до PE2:
ASBR2#sh mpls forwarding-table 10.1.10.1 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 23 19 10.1.10.1/32 0 Gi1/0 10.1.0.2 19 10.1.10.1/32 0 Gi2/0 10.1.2.2
Пакет отправляется на RR2 или P2, так как пути равнозначны… Посмотрим, что будет делать с данным пакетом P2:
P1#sh mpls forwarding-table labels 19 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 19 Pop Label 10.1.10.1/32 1180 Gi1/0 10.1.3.1
P2 производит снятие метки и отправляет пакет с одной меткой на PE2.
PE2 получает пакет с единственной меткой 17, которая и является меткой vrf. В данном случае используется распределение меток на префикс (одна метка – одни префикс клиента), что в реальной жизни естественно слишком расточительно, поэтому режим распределения меток необходимо переключить – per-vrf (одна метка на vrf). В отличии же от Cisco, в JunOS дефолтный механизм распределения меток – per-next-hop. Если у клиента Ethernet линк, что естественно будет в подавляющем большинстве случаев, то необходимо включить генерацию меток per-vrf командой vrf-table-label. Принцип обработки пакета в данном случае меняется, и достоин отдельной статьи.
PE2#show mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 No Label 10.0.1.0/24[V] 0 aggregate/CE1 PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 2 Paths: (1 available, best #1, table CE1) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (10.1.10.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 mpls labels in/out 17/nolabel(CE1)
Согласно представленной выше информации, PE2 снимает метку 17, делает ip lookup в таблице vrf CE1 и отправляет пакет клиенту.
Конфигурации ASBR:
bormoglotx@ASBR1# show keep all; group RR { type internal; local-address 10.0.10.3; family inet-vpn { unicast; } export NHS; neighbor 10.0.10.10; } group ASBR-AS2 { type external; local-address 10.2.0.1; family inet-vpn { unicast; } peer-as 2; neighbor 10.2.0.2; }
ASBR2#sh configuration | b router bgp router bgp 2 no synchronization no bgp default route-target filter bgp log-neighbor-changes neighbor 10.1.10.10 remote-as 2 neighbor 10.1.10.10 description RR2 neighbor 10.1.10.10 update-source Loopback0 neighbor 10.2.0.1 remote-as 1 neighbor 10.2.0.1 description ASBR1 | AS2 neighbor 10.2.0.1 update-source GigabitEthernet3/0 no auto-summary ! address-family vpnv4 neighbor 10.1.10.10 activate neighbor 10.1.10.10 send-community extended neighbor 10.1.10.10 next-hop-self neighbor 10.2.0.1 activate neighbor 10.2.0.1 send-community extended exit-address-family ASBR2#sh run int gi3/0 Building configuration... Current configuration : 143 bytes ! interface GigabitEthernet3/0 description to ASBR1 | AS1 ip address 10.2.0.2 255.255.255.252 negotiation auto mpls bgp forwarding ! end
Хотелось бы добавить, что бывает два вида Option B. Мы рассмотрели первый способ — самый распространенный — ASBR производит подмену next-hop при передаче маршрута внутрь автономной системы (при передаче маршрута на рефлектор). Второй способ заключается в том, что ASBR, как положено для ibgp сессии, при анонсировании маршрута на рефлектор не производил подмену next-hop на свой адрес. Но тогда сеть между ASBR должна быть анонсирована в IGP (можно линк между ASBR сделать passive интерфейсом или прописать на ASBR статику и сделать ее редистрибуцию в IGP). Это необходимо для того, что бы PE маршрутизаторы могли установить BGP маршрут в свои таблицы (проверка доступности next-hop) а ldp сгенерировал метку до данного префикса.
С Option B думаю разобрались. Перейдем к Option С.
Option C
Обмен vpnv4 маршрутами производится между роутрефлекторами разных AS напрямую по ebgp-multihop сессии, а на ASBR-ры ложится задача по распределению маршрутов с mpls метками до лупбеков роутрефлекторов и PE маршрутизаторов соседней автономной системы.
Рассмотрим как работает control plane:
Распределение транспортных меток:
1. ASBR2 по протоколу ldp получает от своих соседей метку до PE2.
2. ASBR2 согласно настроенной политике генерирует маршруты с метками до лубеков своей автономной системы и по bgp labeled-unicast передает данные маршруты на ASBR1, указывая в маршруте next-hop-ом себя.
3. ASBR1 принимает labeled-unicast маршрут от ASBR2 и инсталирует их в mpls forwarding table.
4. ASBR1 генерирует метки для полученных от ASBR2 маршрутов, указывает next-hop-ом себя и отдает маршруты на RR1.
5. RR1, получив данные маршруты проверяет маршрут на валидность, инсталирует в свою таблицу маршрутизации и отправляет всем остальным своим клиентам.
6. PE1 получив от роутрефлектора labeled-unicast маршрут, производит его валидацию и инсталирует маршрут в таблицу маршрутизации.
Распределение меток vrf:
1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.
2. Роутрефлектор RR2 пересылает данный маршрут всем своим клиентам и RR1 по eBGP multihop сессии, не меняя next-hop и значения меток.
3. RR1 передает полученный от RR2 маршрут всем своим клиентам, включая и PE1.
4. PE1 проверят маршрут на пригодность и устанавливает в таблицу маршрутизации соответствующего vrf.
Метки vrf и транспортные метки распределены.
Теперь посмотрим как это все работает на практике. Сначала нам необходимо распределить маршруты лупбеков между автономными системами, так как наша vpnv4 сессия между роутрефлекторами не поднимется ввиду отсутствия маршрута до удаленного роутрефлектора. Мы будем распределять между автономными системами сразу маршруты с метками, поэтому между ASBR-ми будет только labeled-unicast сессия (ipv4 префиксы без меток нам не нуж��ы). Но если вам нужны оба семейства адресов, то необходимо будет указать, что маршруты labeled-unicast необходимо инсталировать в inet.3(иначе на JunOS вы два семейства адресов ipv4 и ipv4 labeled-unicast в одной сессии не поднимите).
Конфигурация bgp на ASBR1 (сессия с ASBR2):
bormoglotx@ASBR1> show configuration protocols bgp group ASBR-AS2 type external; local-address 10.2.0.1; family inet { labeled-unicast; } export Lo-export; peer-as 2; neighbor 10.2.0.2;
bormoglotx@ASBR1> show configuration policy-options policy-statement Lo-export term 1 { from { protocol isis; route-filter 10.0.10.0/24 prefix-length-range /32-/32; } then accept; } term 2 { then reject;
Посмотрим как отработает сигнализация метки до лупбека PE2.
Итак, внутри автономной системы у нас запущен ldp и метки до лупбеков автоматически разлетаются по всей AS. Естественно у ASBR2 есть метки до лупбеков всех маршрутизаторов AS2. Теперь ASBR2 должен сгенерировать маршруты с метками до лупбеков своей AS и передать их на ASBR1. Посмотрим:
ASBR2#sh ip bgp 10.1.10.1/32 BGP routing table entry for 10.1.10.1/32, version 2 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 2 Local 10.1.0.2 from 0.0.0.0 (10.1.10.3) Origin incomplete, metric 3, localpref 100, weight 32768, valid, sourced, best mpls labels in/out 22/nolabel
Как видно из вывода, ASBR2 сгенерировал метку до префикса 10.1.10.1 на in, равную 22.
Посмотрим данный маршрут на ASBR1:
bormoglotx@ASBR1> show route receive-protocol bgp 10.2.0.2 10.1.10.1/32 detail inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden) * 10.1.10.1/32 (1 entry, 1 announced) Accepted Route Label: 22 Nexthop: 10.2.0.2 MED: 3 AS path: 2 ?
Нас интересует в выводе метка: 22 и next-hop: 10.2.0.2 (адрес интерфейса ASBR2). Теперь ASBR1 знает как добраться до PE2.
Далее этот маршрут по labeled -unicast сессии передается на рефлектор и с него распределяется внутри автономной системы между PE маршрутизаторами. Но тут есть одно но: если ASBR1 передаст маршрут в том же виде, что и получил от ASBR2, то ничего не заработает, так как маршрута до сети 10.2.0.0/30 (сеть между ASBR-ми) внутри автономной системы нет. Поэтому ASBR1 меняет next-hop на себя и генерирует новую метку:
bormoglotx@ASBR1> show route advertising-protocol bgp 10.0.10.10 10.1.10.1/32 detail inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden) * 10.1.10.1/32 (1 entry, 1 announced) BGP group RR type Internal Route Label: 299920 Nexthop: Self Flags: Nexthop Change MED: 3 Localpref: 100 AS path: [1] 2 ?
Посмотрим теперь данный маршрут на PE1:
bormoglotx@PE1> show route protocol bgp 10.1.10.1/32 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.10.1/32 *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10 AS path: 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top) to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top) inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.10.1/32 *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10 AS path: 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top) to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top)
Все верно, метка 299920 используется чтобы добраться до PE2. В выводе мы также видим еще одну метку 299776, то есть у нас получился стек меток. О назначении второй (299776) будет написано чуть ниже).
Отлично, теперь у нас есть end-to-end lsp между PE1 и PE2. Собственно говоря между рефлекторами тоже теперь есть lsp, так как маршруты до RR1 и RR2 тоже отдаются с метками. После того, как мы распределили маршруты лупбеков между автономными системами, между роутрефлекторами поднимается соседство:
bormoglotx@RR1> show bgp neighbor 10.1.10.10 Peer: 10.1.10.10+34875 AS 2 Local: 10.0.10.10+179 AS 1 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Options: <Multihop NoNextHopChange Preference LocalAddress Ttl AddressFamily PeerAS Rib-group Refresh> Address families configured: inet-vpn-unicast Local Address: 10.0.10.10 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 10.1.10.10 Local ID: 10.0.10.10 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-vpn-unicast NLRI advertised by peer: inet-unicast inet-vpn-unicast NLRI for this session: inet-vpn-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality Peer does not support Receiver functionality Peer supports 4 byte AS extension (peer-as 2) Peer does not support Addpath Table bgp.l3vpn.0 Bit: 20001 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Accepted prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 20 Sent 13 Checked 68 Input messages: Total 210 Updates 3 Refreshes 0 Octets 4222 Output messages: Total 212 Updates 2 Refreshes 0 Octets 4205 Output Queue[1]: 0
Между рефлекторами распределяются vpnv4 маршруты: NLRI for this session: inet-vpn-unicast.
Мы принимаем 2 префикса от соседа: Accepted prefixes: 2
И столько же отдаем: Advertised prefixes: 2
Думаю, это понятно.
Настройки рефлекторов:
bormoglotx@RR1# show protocols bgp group RR-AS2 type external; multihop { ttl 5; no-nexthop-change; } local-address 10.0.10.10; family inet-vpn { unicast; } peer-as 2; neighbor 10.1.10.10;
RR2#sh configuration | b router bgp router bgp 2 bgp log-neighbor-changes neighbor 10.0.10.10 remote-as 1 neighbor 10.0.10.10 ebgp-multihop 5 neighbor 10.0.10.10 update-source Loopback0 ! address-family vpnv4 neighbor 10.0.10.10 activate neighbor 10.0.10.10 send-community extended neighbor 10.0.10.10 next-hop-unchanged exit-address-family
Примечание: в конфигурации RR2 (Cisco IOS15) часть строк, не относящихся к 10.0.10.10 удалена, что бы сократить размер вывода.
Теперь мы можем посмотреть, как работает распределение меток vrf:
PE2 генерирует маршрут до сети 10.0.1.0/24, которая терминируется в vrf CE1
PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24 BGP routing table entry for 2:1:10.0.1.0/24, version 2 Paths: (1 available, best #1, table CE1) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (10.1.10.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0 mpls labels in/out 22/nolabel(CE1)
Как видим, была сгенерирована метка 22.
Далее маршрут отдается на RR2:
PE2#sh ip bgp vpnv4 all neighbors 10.1.10.10 advertised-routes BGP table version is 7, local router ID is 10.1.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 (default for vrf CE1) *> 10.0.1.0/24 0.0.0.0 0 32768 ? *> 10.1.1.2/32 10.0.1.2 2 32768 ? Total number of prefixes 2
Роутрефлектор отдает этот маршрут всем своим клиентам, а так же на RR1:
RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.0.10.10 advertised-routes BGP table version is 5, local router ID is 10.1.10.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 2:1 *>i10.0.1.0/24 10.1.10.1 0 100 0 ? *>i10.1.1.2/32 10.1.10.1 2 100 0 ? Total number of prefixes 2
Посмотрим полученный маршрут на RR1:
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
Маршрут попал в hidden и никуда больше не распространяется. Возникает вопрос — почему? (Причем у Cisco нет такой беды)
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 2:1:10.0.1.0/24 [BGP/170] 00:29:12, localpref 100, from 10.1.10.10 AS path: 2 ? Unusable
Посмотрим причину:
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden detail bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) 2:1:10.0.1.0/24 (1 entry, 0 announced) BGP Preference: 170/-101 Route Distinguisher: 2:1 Next hop type: Unusable Address: 0x8f3c5a4 Next-hop reference count: 2 State: <Hidden Ext> Local AS: 1 Peer AS: 2 Age: 31:00 Task: BGP_2.10.1.10.10+34875 AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 Accepted VPN Label: 22 Localpref: 100 Router ID: 10.1.10.10
В выводе напротив Next hop type стоит Unusable. Роутрефлектор проверил маршрут на доступность next-hop, но не нашел в таблице маршрутизации маршрут до указанного next-hop.
Посмотрим в таблицу маршрутизации:
bormoglotx@RR1> show route 10.1.10.1/32 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.10.1/32 *[BGP/170] 00:33:04, MED 3, localpref 100, from 10.0.10.3 AS path: 2 ? > to 10.0.1.1 via ge-0/0/0.0, Push 299920
Маршрут есть и даже с меткой (логично, мы же его распространили с ASBR1 по labeled-unicast). Дело в том, что в JunOS (в отличии от других вендоров) есть несколько таблиц маршрутизации. Сейчас нас интересует таблицы inet.0 и inet.3.
inet.0 — таблица маршрутизации, в которой хранятся ipv4 unicast маршруты.
inet.3 — таблица маршрутизации, в которой хранятся ipv4 mpls маршруты. Этой таблицей пользуется маршрутизатор, если он является ingress LSR.
BGP, получая vpnv4 маршруты, пытается разрезольвить next-hop именно в таблице inet.3. По умолчанию, bgp labeled unicast маршруты инсталируются в таблицу inet.0 и они не попадают в inet.3. То есть — роутрефлектор получил vpnv4 маршрут и пытается разрезольвить next-hop, но не находит маршрут до него в таблице inet.3 и помечает vpnv4 маршрут как hidden в связи с unusable next-hop.
Необходимо изменить это поведение. Для его есть несколько рычагов:
resolve-vpn — эта команда меняет стандартное поведение JunOS касательно установки labeled-unicast маршрутов в таблицу маршрутизации. Теперь JunOS будет устанавливать полученные по bgp labeled-unicast маршруты и в таблицу inet.0 и в таблицу inet.3.
rib-groups — очень гибкий механизм, можно с помощью политики перетащить определенные маршруты (в плоть до префикса /32) из одной таблицы маршрутизации в другую (в нашем случае из inet.0 в inet.3) Но с rib-groups нужно быть внимательным, так как можно наломать дров, не четко понимая, что делаешь (возможности rib-groups очень велики).
resolution rib bgp.l3vpn.0 resolution-ribs inet.0 — эта команда позволяет никуда ничего не переносить, а лишь заставляет маршрутизатор резольвить vpnv4 маршруты в таблице inet.0.
На роутрефлеторе дадим команду resolution rib, а на PE маршрутизаторе resolve-vpn:
bormoglotx@RR1# show routing-options router-id 10.0.10.10; autonomous-system 1; resolution { rib bgp.l3vpn.0 { resolution-ribs inet.0; } }
Теперь маршруты на рефлекторе появились и могу быть распространены внутри автономной системы:
bormoglotx@RR1> show route receive-protocol bgp 10.1.10.10 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 2:1:10.0.1.0/24 * 10.1.10.1 2 ? 2:1:10.1.1.2/32 * 10.1.10.1 2 ?
Посмотрим сам маршрут с деталями:
bormoglotx@RR1> show route protocol bgp rd-prefix 2:1:10.0.1.0/24 detail bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 2:1:10.0.1.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 2:1 Next hop type: Indirect Address: 0x934d6d8 Next-hop reference count: 1 Source: 10.1.10.10 Protocol next hop: 10.1.10.1 Push 22 Indirect next hop: 2 no-forward State: <Active Ext> Local AS: 1 Peer AS: 2 Age: 11:55 Metric2: 1 Task: BGP_2.10.1.10.10+34875 Announcement bits (1): 0-BGP_RT_Background AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 Accepted VPN Label: 22 Localpref: 100 Router ID: 10.1.10.10
В выводе видно, что next-hop остался неизменным при переходе через границу автономной системы, что не характерно для ebgp. Дело в том, что в конфигурации (показана выше) есть команда no-nexthop-change — JunOS, next-hop-unchanged — Cisco, которая меняет стандартное поведение ebgp и не дает менять next-hop при переходе границы автономной системы. Для чего это нужно. Если не дать данную команду, то во всех vpnv4 маршрутах роутрефлектор будет ставить себя next-hop-ом, то есть весь vpn трафик полезет через роутрефлектор, которому и так не сладко в жизни. Теперь, помимо переваривания кучи маршрутов (особенно если на нем FV), ему придется и обрабатывать огромное количество трафика. Собственно конец всегда будет один — данная схема потерпит фиаско, а если быть точнее — падение роутрефлектора со всеми вытекающими. Причем даже наличие двух резервирующих рефлекторов вам не поможет. Но вернемся к нашей топологии и посмотрим vpnv4 маршрут на PE1 (не забываем, что мы уже дали команду resolve-vpn, иначе маршруты попадут в hidden):
bormoglotx@PE1> show configuration protocols bgp group RR type internal; local-address 10.0.10.1; family inet { labeled-unicast { resolve-vpn; } } family inet-vpn { unicast; } neighbor 10.0.10.10;
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 detail CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 10.0.1.0/24 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 2:1 Next hop type: Indirect Address: 0x934d2e8 Next-hop reference count: 3 Source: 10.0.10.10 Next hop type: Router, Next hop index: 608 Next hop: 10.0.2.2 via ge-0/0/0.0, selected Label operation: Push 22, Push 299920, Push 299776(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Protocol next hop: 10.1.10.1 Push 22 Indirect next hop: 94a0658 262151 State: <Secondary Active Int Ext> Local AS: 1 Peer AS: 1 Age: 39:28 Metric2: 1 Task: BGP_1.10.0.10.10+179 Announcement bits (2): 0-CE1-OSPF 1-KRT AS path: 2 ? Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0 Import Accepted VPN Label: 22 Localpref: 100 Router ID: 10.0.10.10 Primary Routing Table bgp.l3vpn.0
Нам интересны строки:
Protocol next hop: 10.1.10.1
Push 22
VPN Label: 22
Сигнализация отработала, теперь у нас есть lsp между PE маршрутизаторами и метки vrf.
Data-plane:
Теперь посмотрим как будет передаваться трафик по просигнализированному пути.
Для начала проверим связность между CE:
CE1#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/68 ms
Отлично. Теперь можно сделать трассировку:
R5#traceroute 10.0.1.2 Type escape sequence to abort. Tracing the route to 10.0.1.2 1 10.0.0.1 4 msec 4 msec 8 msec 2 10.0.2.2 [MPLS: Labels 299776/299920/22 Exp 0] 48 msec 48 msec 12 msec 3 10.0.3.1 [MPLS: Labels 299920/22 Exp 0] 76 msec 56 msec 36 msec 4 10.2.0.2 [MPLS: Labels 22/22 Exp 0] 48 msec 12 msec 76 msec 5 10.1.2.2 [MPLS: Labels 17/22 Exp 0] 40 msec 52 msec 44 msec 6 10.0.1.1 44 msec 60 msec 48 msec 7 10.0.1.2 44 msec 56 msec 56 msec
Виден стек из трех меток.
И так, сморим маршрут на PE1 до клиентского префикса 10.0.1.0/24:
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.0/24 *[BGP/170] 00:39:25, localpref 100, from 10.0.10.10 AS path: 2 ? > to 10.0.2.2 via ge-0/0/0.0, Push 22, Push 299920, Push 299776(top)
PE1 навешивает три метки:
22- метка vrf, полученна через рефлекторы от PE2
299920 — метка до лупбека PE2, полученная через роутрефлектор от ASBR1
299776 — метка до ASBR1, полученная по протоколу LDP
и отправляет данный пакет в сторону P1: Next hop: 10.0.2.2 via ge-0/0/0.0
bormoglotx@PE1> show interfaces descriptions Interface Admin Link Description ge-0/0/0 up up to P1 ge-0/0/1 up up to RR1 ge-0/0/3 up up to SW1 lo0 up up router-id
Примечание: так как мы распределили метку до PE2 по labeled-unicast, то у P1 нет метки до лубека PE2. Если мы пошлем пакет с двумя метками, то P1 не будет знать что делать с данной меткой. Поэтому нам нужно добавить еще одну метку до ASBR1, тогда P1 будет обрабатывать данный трафик не подозревая что это трафик в соседнюю AS (работает то она только с верхней меткой). Другими словами мы в lsp до ASBR1 туннелируем lsp о PE2.
Посмотрим, что сделает P1 с полученным пакетом:
bormoglotx@P1> show route table mpls.0 label 299776 mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299776 *[LDP/9] 01:13:09, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop 299776(S=0) *[LDP/9] 01:13:09, metric 1 > to 10.0.3.1 via ge-0/0/1.0, Pop
Все логично, P1 снимает верхнюю метку (механизм php) и отправляет пакет уже со стеком их двух меток на ASBR1.
ASBR1 производит своп верхней метки (метки до PE2), на метку, которую ему сообщил ASBR2:
bormoglotx@ASBR1> show route table mpls.0 label 299920 mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 299920 *[VPN/170] 01:13:51 > to 10.2.0.2 via ge-0/0/3.0, Swap 22
Примечание: получился очень наглядно — метка 22 была сгенерирована ASBR2 для достижения PE2, в то же время как метка 22 была сгенерирована и PE2 как vrf метка. Поэтому у нас пакет между ASBR1 и ASBR2 будет идти со стеком из двух одинаковых меток 22/22. Реально же это две разные метки (по назначению) и то, что они в данном случае одинаковые — случайность.
Далее пакет попадает на ASBR2.
ASBR2#sh mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 18 10.1.10.1/32 0 Gi1/0 10.1.0.2 17 10.1.10.1/32 13378 Gi2/0 10.1.2.2
ASBR2 производит своп верхней метки в стеке на метку 18 или 17 (у нас эквивалентные пути). Эти метки он получил из протокола ldp:
ASBR2#show mpls ldp bindings 10.1.10.1 32 lib entry: 10.1.10.1/32, rev 18 local binding: label: 22 remote binding: lsr: 10.1.10.2:0, label: 17 remote binding: lsr: 10.1.10.10:0, label: 18
Предположим что пакет уходит на P2, значит ASBR2 производит своп верхней метки на метку 17.
Смотрим что будет делать P2:
P1#sh mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 Pop Label 10.1.10.1/32 12936 Gi1/0 10.1.3.1
P2 снимает метку и отправляет пакет уже с одной меткой (меткой vrf) на PE2.
Осталось только проверить, что будет делать PE2 с пакетом с меткой 22.
PE1 смотрит в mpls forwarding-table, снимает метку, делает ip lookup в таблице CE1 и отправляет пакет в интерфейс GigabitEthernet3/0.10, который смотрит в SW2, к которому подключен клиентский маршрутизатор CE2:
PE2#sh mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 No Label 10.0.1.0/24[V] 3296 aggregate/CE1
PE2#sh ip route vrf CE1 10.0.1.0 Routing Table: CE1 Routing entry for 10.0.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 2 Advertised by bgp 2 Routing Descriptor Blocks: * directly connected, via GigabitEthernet3/0.10 Route metric is 0, traffic share count is 1
В данном примере я использовал схему со стеком из трех меток. Есть вариант с использованием стека из 2-х меток. Отличие в том, что маршруты, получаемые ASBR-ми, должны быть перераспределены в протокол IGP. Тогда ldp начнет распределять метки и до лупбеков соседней автономной системы, но лично мне данный вариант не нравится, как минимум потому что мы засовываем bgp маршруты в igp, что не очень хорошо. В остальном все аналогично описанному выше.
Надеюсь, я донес до читателя принцип работы данных опций и вам пригодится эта статья при диагностике неисправностей на l3vpn. Статья получилась очень большая и писалась не один день, если кто то хочет что то добавить или заметил какой то недостаток (все таки я человек), прошу писать в личку — поправим и добавим. Если есть вопросы — пишите в комментарии, по возможности отвечу. Спасибо за внимание!
Спасибо за помощь в написании статьи пользователю AllTheThingsUndone.
