Сегодня речь пойдет о «межоператорском» взаимодействии — 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 маршруты, если у него нет 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).
Итак, начнем с 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 ( на маршрутизаторе дана команда keep all).
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. Статья получилась очень большая и писалась не один день, если кто то хочет что то добавить или заметил какой то недостаток (все таки я человек), прошу писать в личку — поправим и добавим. Если есть вопросы — пишите в комментарии, по возможности отвечу. Спасибо за внимание!
В статье рассмотрим следующие темы:
— 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 маршруты, если у него нет 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).
Итак, начнем с 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 ( на маршрутизаторе дана команда keep all).
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. Статья получилась очень большая и писалась не один день, если кто то хочет что то добавить или заметил какой то недостаток (все таки я человек), прошу писать в личку — поправим и добавим. Если есть вопросы — пишите в комментарии, по возможности отвечу. Спасибо за внимание!
Поделиться с друзьями
Комментарии (14)
Bormoglotx
05.06.2016 14:13Что имеете в ввиду под синтаксом??
satandyh
05.06.2016 16:34+1Извините, ввел в заблуждение. Не синтаксис, но грамматика. Меня во время чтения не покидал призрак граммар-наци. Вот и вылилось в комментарий.
mickvav
05.06.2016 15:10А можно попросить уважаемого автора хотя бы в один абзац описать задачу, для решения которой необходимо всё это?
Bormoglotx
05.06.2016 17:44Это нужно что суметь провести диагностику проблем на l3vpn. Я думаю это и так ясно.
vvpoloskin
05.06.2016 19:59он имел в виду введенее какое-нибудь внятное сделать, аудитория хабра довольно широка, не все знают даже, что такое l3vpn.
Сегодня речь пойдет о межоператорском взаимодействии
В отечественных операторах эти опции скорее используются при взаимодействии различных филиалов или дочерних, купленных позже, компаний. С совершенно разными операторами про создание стыков по optb и optc я не слышал.
Bormoglotx
05.06.2016 20:52Вы правы, именно для этого это и используется (именно потому что аудитория хабра слишком широкая я не стал этого указывать). Давайте добавим.
evg_krsk
06.06.2016 03:54+1Спасибо, очень хорошо расписано, прятно читать.
Но, на мой взгляд, не хватает краткого сравнения опций (единственное «Option A не мастштабируется» — это мало), плюсы/минусы, когда имеет смысл использовать каждый вариант.
amarao
06.06.2016 11:47Очень хардкорно. Если бы вы сделали пару абзацев с объяснением используемых аббревиатур, порог вхождения был бы существенно меньше. Я, например, отвалился на фразе «CE-PE маршрутизаторы». До этого момента было терпимо-понятно (я даже догадался, что ASBR, это AS border router), но дальше — совсем нет.
evg_krsk
06.06.2016 12:17Если вы не знаете основ mpls, разницы между bgp labeled-unicast и vpnv4 unicast, то читать данную статью вам нет смысла
Всё как заявлено :-)
Chelioz
14.06.2016 16:26+1Автор, молодец. Зажги про Iner-AS VPLS. На cisco в этом теме умереть можно, а вот на джуне очень даже просто.
feo_sobolev
Спасибо за статью! Хоть, на практике, к сожалению, еще не представлялось возможным поработать с MPLS.
Т.к. в нашем небольшом ISP и городе он попросту не используется.
Все равно читать интересно.
Особая благодарность за, назову это «Dual-Stack» — симбиоз настроек Cisco и Juniper.