Для того, чтобы прокинуть L3VPN между разными автономными системами, необходимо использовать опции протокола BGP — A, B или C. Если кто не знает, как работают эти опции, то прошу сюда. У каждой из данных опций есть как плюсы, так и минусы. Остановимся на каждой поподробнее:
Option A.
Смысл данной опции заключается в том, что на ASBR-рах поднимаются отдельные vrf для каждого клиентского vpn и создается сабинтерфейс, через который происходит обмен чистыми ip маршрутами и, через эти же сабинтерфейсы, происходит форвардинг клиентского трафика. Никакого mpls между ASBR нет. Взаимодействие между ASBR происходит, как между PE и CE маршрутизаторами.
Недостатки данной опции более чем очевидны:
— необходимо помимо создания vrf на PE маршрутизаторах, создавать vrf на ASBR-ах;
— для обмена маршрутами между ASBR необходимо в каждой vrf поднимать протокол маршрутизации, естественно большое количество, к примеру, bgp-сессий не благоприятно сказывается на производительности маршрутизатора;
Но, как не удивительно, у данной схемы есть и плюсы:
+ так как между ASBR идет чистый ip трафик, без mpls, то можно реализовать qos и фильтрацию на основе ip заголовка;
+ трафик клиентов четко разделен;
+ данная опция является самой защищенной из всех (к примеру, если вы можете поднять данную опцию между разными провайдерами если не хотите инжектировать чужие маршруты в свою автономную систему).
Но все все таки, минусы в данном случае перевешивают плюсы (представьте, что вам надо прокинуть 50-60 vpn-ов – желание использовать опцию А сразу же отпадает). Поэтому, находясь в своем уме, вряд ли какой то инженер захочет в нынешних условиях поднимать опцию А.
Option B.
Смысл данной опции заключается в том, что ASBR обмениваются vpnv4 маршрутами. Получив vpnv4 маршрут из соседней AS, ASBR генерирует новую метку, ставит next-hop-ом себя (option B-a) или не меняя next-hop (option B-b) передает маршруты на рефлектор (или PE маршрутизаторы сразу, в зависимости от вашей топологии), после чего у всех PE маршрутизаторов есть необходимые vpnv4 маршруты.
Плюсы данного подхода:
+ необходима всего одна BGP vpnv4 сессия для передачи маршрутов между автономными системами, ASBR не нагружен протоколами маршрутизации в vrf;
+ так как все префиксы передается в рамках одной сессии, то данный подход имеет хорошую масштабируемость (в сравнении с опцией А);
+ при включении нового клиента нет необходимости менять конфигурацию на ASBR (кроме фильтров естественно);
Минусы:
— трафик клиентов передается в общем потоке с mpls меткой и применить qos или фильтрацию на основе ip заголовка не представляется возможным;
— ASBR нагружен помимо форвардинга трафика, еще и перевариванием большого количества vpnv4 маршрутов;
Option C.
Смысл данной опции заключается в том, что обмен vpnv4 маршрутами происходит между роутрефлекторами разных автономных систем по ebgp-multihop сессии. ASBR-ры, в свою очередь, передают в соседние автономные системы маршруты с метками (bgp labeled-unicast) до лупбеков роутрефлекторов и PE маршрутизаторов. В итоге с помощью меток, полученных от ASBR, PE маршрутизаторы могут построить end-to-end lsp между собой, а метки vrf между всеми PE маршрутизаторами распределены с помощью роутрефлекторов.
Плюсы данной опции:
+ очень высокую масштабируемость
+ не нагружает ASBR лишней работой (в сравнении с другими опциями)
Но есть и минусы:
— как и в опции В, клиентский трафик между ASBR идет в общем потоке, правда уже с двумя mpls метками, что не дает применить qos и фильтрацию трафика между ASBR на основе ip заголовка.
Как совместить в одном подходе и возможность применения фильтров/qos и в то же время не нагрузить ASBR лишней работой по поддержанию большого количества bgp (ospf, isis, rip)-соседств, а инженеров избавить от сложных конфигураций на ASBR?
Итак, сегодня речь пойдет об inter-AS Option AB (D).
Данная опция, как и опция А, подразумевает создание на ASBR-рах отдельного vrf на каждый vpn, а так же создание отдельного сабинтерфейса в каждом vrf, который будет использоваться для передачи клиентского трафика. Пока что все так же как и в стандартной опции А. Существенное различие в том, что никакой протокол маршрутизации в vrf (на ASBR) не запускается, а созданные сабинтерфейсы используются только для форвардинга трафика. Как же будет производиться обмен маршрутами? Для этой цели, как в опции В, создается единственная vpnv4 сессия между ASBR-ми, по которой и производится передача vpnv4 маршрутов. Собственно, можно сказать, что мы одновременно понимаем и опцию А и опцию В между двумя ASBR. Давайте теперь перейдем к детальному описанию control plane, что бы все встало на свои места:
1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.
2. Роутрефлектор производит валидацию полученного маршрута, и передает его своим клиентам. В нашем случае на ASBR2.
3. ASBR2 получает vpnv4 маршрут и инсталирует его в таблицу маршрутизации соответственного vrf, в нашем случае vrf VPN1-ASBR2, согласно сконфигурированному route-target import.
4. ASBR2 генерирует новый vpnv4 маршрут, навешивает на него excommunity (route-target), которое указано на экспорт в vrf VPN1-ASBR2 и передает маршрут на ASBR1. Next-hop-ом, как и при обычной опции В устанавливается адрес маршрутизатора ASBR2 (адрес интерфейса, который является сорсом для данной vpnv4 сессии).
5. ASBR1, принимает данный маршрут и согласно route-target import, устанавливает данный маршрут в таблицу маршрутизации соответствующего vrf, в нашем случае vrf VPN1-ASBR1, производя замену next-hop, согласно указанному в vrf VPN1-ASBR1 (inter-as hybrid next-hop). Замена производится на адрес ASBR2 (стык ASBR2(vrf VPN1-ASBR2)==> ASBR1 (vrf VPN1-ASBR1)).
6. ASBR1 генерирует новый vpnv4 маршрут, навешивает на него excommunity (route-target), которое указано на экспорт в vrf VPN1-ASBR1 и отправляет маршрут на роутрефлектор RR1 (next-hop — лупбек ASBR1)
7. RR1 анонсирует маршрут на PE1.
8. PE1, получив маршрут от RR1, инсталирует его в таблицу маршрутизации соответствующего vrf.
Основным в данной опции является то, что vpnv4 маршруты на ASBR сначала попадает в vrf и уже из данной vrf анонсируется дальше, причем анонсируется с тем excommunity, которое указанно в vrf на экспорт, и оно может отличаться от того excommunity, c которым данный маршрут изначально анонсировался). Схематично это выглядит вот так:
То есть передача vpnv4 маршрута из одной AS в другую происходит в такой последовательности: PE2==>RR2==>ASBR2==>ASBR2 (vrf VPN1-ASBR2)==>ASBR1==>ASBR1 (vrf VPN1-ASBR1)==>RR1==>PE1.
Итак, рассмотрим все вышесказанное на примере.
На PE2 созданы два vrf:
Мы будем рассматривать сигнализацию маршрута 10.0.1.0/24 из vrf VPN1-CE2.
Ниже представлен vpnv4, маршрут сгенерированный PE2:
Мы видим, что для PE2 маршрут является локальным и для данного префикса сгенерированна метка 22.
Теперь PE2 должен отправить данный маршрут на роутрефлектор. Проверим:
Мы анонсируем два маршрута (10.1.1.2 — это лупбек маршрутизатора VPN1-CE2, который получен через ospf). Дальше маршрут передается на ASBR2:
У нас не включена опция no bgp default route-target filter, но на ASBR2 созданы vrf:
Согласно route-target import 2:100 маршруты попадают в vrf VPN1-ASBR2.
Примечание: в конфигурации vrf появилась новая команда: inter-as-hybrid next-hop. Ее назначение будет рассмотрено далее.
Проверим, установлен ли наш маршрут к сети 10.0.1.0/24 в таблицу маршрутизации vrf VPN1-ASBR2:
Отлично, маршрут есть. Пока что все как в опции А. Но в опции А дальше мы должны анонсировать чистые ip маршруты из одного vrf в другой с использованием специально запущенного в vrf протокола маршрутизации. Но в опции АВ маршруты между ASBR передаются по bgp vpnv4 сессии между ASBR-ми. Посмотрим, что мы анонсируем на ASBR1 по bgp сессии между ASBR-ми:
Мы анонсируем 4 маршрута, но у них уже не оригинальный rd. Анонс с PE1 был с rd 2:1, а теперь мы анонсируем маршруты с rd 2:10001. То есть маршрут был заново сгенерирован на ASBR2. Что бы это работало, необходимо в настройках bgp сессии между ASBR дать команду: inter-as-hybrid. Данная команда указывает на то, что данная сессия предназначена для передачи vpnv4 маршрутов для опции AB ( в терминах Сиско — созданный на ASBR vrf называется option AB vrf).
Продолжим. Проверим маршруты до сети 10.0.1.0/24 на ASBR1:
В выводе у нас два маршрута, один с next-hop 10.2.0.2 — это оригинальный vpnv4 маршрут, полученный от ASBR2; второй с next-hop 10.1.0.2 (via VPN1-ASBR1) — уже измененный маршрут, который будет использоваться для передачи трафика и инсталироваться в таблицу маршрутизации VPN1-ASBR1.
Прошу обратить внимание на то, что ASBR2 как и положено ASBR-ру в опции В сгенерировал метку: в маршруте на ASBR1 есть метка на out: “mpls labels in/out 31/19”. Но данная метка не будет использована для передачи трафика. Это видно из маршрута, который импортируется в таблицу маршрутизации vrf VPN1-ASBR1: в маршруте mpls метки нет: “MPLS label: none” (см вывод ниже):
Замена next-hop была произведена благодаря команде inter-as-hybrid next-hop на ASBR1:
Если данную команду не указать, то в vrf будут импортироваться маршрут с оригинальным next-hop-ом из полученного vpnv4 маршрута от ASBR2 (то есть next-hop-ом будет адрес ASBR2, который используется как сорс для eBGP сессии, как в обычной опции В). В нашем случае на ASBR1 мы имеем вот такие интерфейсы:
Нам надо что бы трафик vpn1 форвардился через интерфейс GigabitEthernet3/0.10 (соответственно vpn2 — через GigabitEthernet3/0.20). Поэтому в настройках vrf next-hop-ом указан адрес 10.1.0.2 — интерфейс GigabitEthernet3/0.10 на ASBR2, который находится в vrf VPN1-ASBR2:
Двигаемся дальше. Из vrf VPN1-ASBR1 данный маршрут должен быть анонсирован на роутрефлектор:
Думаю вы уже заметили, что это новый маршрут, сгенерированный ASBR1, так как вот маршруты, которые ASBR1 получил (обратите внимание на rd):
А вот маршруты, который анонсированы с ASBR1:
Обратите внимание на rd: был 2:10001, теперь 1:10001. Посмотрим, какие vrf настроены на ASBR1:
Думаю теперь понятно, что маршрут был сгенерирован ASBR1.
ASBR1 сгенерировал метку 31 для данного префикса:
Далее все стандартно. Маршрут передается c RR1 на PE1:
А PE1 инсталирует его таблицу маршрутизации соответствующего vrf:
На картинке ниже изображен процесс сигнализирования метки vpn.
Теперь перейдем к data plane. Сделаем трассировку между CE маршрутизаторами:
И тоже самое для vpn2:
PE1 получает IP пакет от клиентского маршрутизатора и согласно своей таблицы маршрутизации производит навешивание двух меток — 31 (метка vrf) и 17 или 16 (транспортная метка до ASBR1 в зависимости от того, как PE1 балансирует трафик):
Судя по трассировке выше, PE1 выбирает маршрут через P1.
P1, получив пакет с меткой 17, производит снятие данной (верхней) метки и отправку пакета в интерфейс Gi1/0 (линк в сторону ASBR1):
ASBR1 обрабатывает пакет как обычный PE маршрутизатор — снимает метку и отправляет в интерфейс Gi3/0.10 чистый IP пакет:
Получив данный пакет, ASBR2, работает как PE маршрутизатор, получивший пакет от клиентского CE маршрутизатора — навешивает метку vrf (22) и транспортную метку (17 или 19 — опять эквивалентные пути и судя по трассировке пакет идет на RR2):
RR2, как и положено транзитному mpls маршрутизатору на предпоследнем хопе, снимает верхнюю метку и отправляет пакет на PE2:
Ну а PE2 знает, что метка 22 указывает на то, что надо сделать ip lookup в vrf VPN1-CE2:
Далее пакет улетает на клиентский CE маршрутизатор. Все метки и операции с ними представлены на рисунке ниже.
В итоге мы получили гибрид опции А и В, в которой мы можем использовать qos и фильтрацию клиентского трафика между ASBR-рами как в опции А, но в тоже время хоть нам и придется сконфигурировать vrf для каждого vpn на ASBR и сделать отдельный стык, но нет необходимости в отдельном процессе протокола маршрутизации в каждом vrf, что естественно снижает нагрузку на ASBR, который, как в опции В, должен поддерживать всего одну vpnv4 сессию с соседним ASBR-ом.
Ну и в конце хотелось бы акцентировать внимание на двух важных командах:
inter-as-hybrid next-hop в иерархии ip vrf — данная команда необходима для подмены next-hop, если ее не указать, то в vrf будет импортироваться маршрут с next-hop в стык, на котором запущена опция В.
neighbor 10.2.0.1 inter-as-hybrid — данная команда указывает на то, что между пирами установлена bgp сессия для обмена vpnv4 маршрутами для Inter-AS Option AB. Данная команда дает возможность сначала импортировать маршруты в vrf, а потом экспортировать маршруты из этого vrf дальше (меняя rd и при необходимости community).
Важно, что обе эти опции должны быть включены, иначе у вас или ничего не заработает или заработает, но не так как должно работать.
В настоящее время есть только драфт RFC, посвященный опции AB. В данной статье мы познакомились с опцией АВ на примере реализации ее компанией Cisco. Пишите в личку если найдете какие либо недостатки или считаете, что что то надо дополнить/описать получше.
Всем спасибо за внимание!
Option A.
Смысл данной опции заключается в том, что на ASBR-рах поднимаются отдельные vrf для каждого клиентского vpn и создается сабинтерфейс, через который происходит обмен чистыми ip маршрутами и, через эти же сабинтерфейсы, происходит форвардинг клиентского трафика. Никакого mpls между ASBR нет. Взаимодействие между ASBR происходит, как между PE и CE маршрутизаторами.
Недостатки данной опции более чем очевидны:
— необходимо помимо создания vrf на PE маршрутизаторах, создавать vrf на ASBR-ах;
— для обмена маршрутами между ASBR необходимо в каждой vrf поднимать протокол маршрутизации, естественно большое количество, к примеру, bgp-сессий не благоприятно сказывается на производительности маршрутизатора;
Но, как не удивительно, у данной схемы есть и плюсы:
+ так как между ASBR идет чистый ip трафик, без mpls, то можно реализовать qos и фильтрацию на основе ip заголовка;
+ трафик клиентов четко разделен;
+ данная опция является самой защищенной из всех (к примеру, если вы можете поднять данную опцию между разными провайдерами если не хотите инжектировать чужие маршруты в свою автономную систему).
Но все все таки, минусы в данном случае перевешивают плюсы (представьте, что вам надо прокинуть 50-60 vpn-ов – желание использовать опцию А сразу же отпадает). Поэтому, находясь в своем уме, вряд ли какой то инженер захочет в нынешних условиях поднимать опцию А.
Option B.
Смысл данной опции заключается в том, что ASBR обмениваются vpnv4 маршрутами. Получив vpnv4 маршрут из соседней AS, ASBR генерирует новую метку, ставит next-hop-ом себя (option B-a) или не меняя next-hop (option B-b) передает маршруты на рефлектор (или PE маршрутизаторы сразу, в зависимости от вашей топологии), после чего у всех PE маршрутизаторов есть необходимые vpnv4 маршруты.
Плюсы данного подхода:
+ необходима всего одна BGP vpnv4 сессия для передачи маршрутов между автономными системами, ASBR не нагружен протоколами маршрутизации в vrf;
+ так как все префиксы передается в рамках одной сессии, то данный подход имеет хорошую масштабируемость (в сравнении с опцией А);
+ при включении нового клиента нет необходимости менять конфигурацию на ASBR (кроме фильтров естественно);
Минусы:
— трафик клиентов передается в общем потоке с mpls меткой и применить qos или фильтрацию на основе ip заголовка не представляется возможным;
— ASBR нагружен помимо форвардинга трафика, еще и перевариванием большого количества vpnv4 маршрутов;
Option C.
Смысл данной опции заключается в том, что обмен vpnv4 маршрутами происходит между роутрефлекторами разных автономных систем по ebgp-multihop сессии. ASBR-ры, в свою очередь, передают в соседние автономные системы маршруты с метками (bgp labeled-unicast) до лупбеков роутрефлекторов и PE маршрутизаторов. В итоге с помощью меток, полученных от ASBR, PE маршрутизаторы могут построить end-to-end lsp между собой, а метки vrf между всеми PE маршрутизаторами распределены с помощью роутрефлекторов.
Плюсы данной опции:
+ очень высокую масштабируемость
+ не нагружает ASBR лишней работой (в сравнении с другими опциями)
Но есть и минусы:
— как и в опции В, клиентский трафик между ASBR идет в общем потоке, правда уже с двумя mpls метками, что не дает применить qos и фильтрацию трафика между ASBR на основе ip заголовка.
Как совместить в одном подходе и возможность применения фильтров/qos и в то же время не нагрузить ASBR лишней работой по поддержанию большого количества bgp (ospf, isis, rip)-соседств, а инженеров избавить от сложных конфигураций на ASBR?
Итак, сегодня речь пойдет об inter-AS Option AB (D).
Данная опция, как и опция А, подразумевает создание на ASBR-рах отдельного vrf на каждый vpn, а так же создание отдельного сабинтерфейса в каждом vrf, который будет использоваться для передачи клиентского трафика. Пока что все так же как и в стандартной опции А. Существенное различие в том, что никакой протокол маршрутизации в vrf (на ASBR) не запускается, а созданные сабинтерфейсы используются только для форвардинга трафика. Как же будет производиться обмен маршрутами? Для этой цели, как в опции В, создается единственная vpnv4 сессия между ASBR-ми, по которой и производится передача vpnv4 маршрутов. Собственно, можно сказать, что мы одновременно понимаем и опцию А и опцию В между двумя ASBR. Давайте теперь перейдем к детальному описанию control plane, что бы все встало на свои места:
1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.
2. Роутрефлектор производит валидацию полученного маршрута, и передает его своим клиентам. В нашем случае на ASBR2.
3. ASBR2 получает vpnv4 маршрут и инсталирует его в таблицу маршрутизации соответственного vrf, в нашем случае vrf VPN1-ASBR2, согласно сконфигурированному route-target import.
4. ASBR2 генерирует новый vpnv4 маршрут, навешивает на него excommunity (route-target), которое указано на экспорт в vrf VPN1-ASBR2 и передает маршрут на ASBR1. Next-hop-ом, как и при обычной опции В устанавливается адрес маршрутизатора ASBR2 (адрес интерфейса, который является сорсом для данной vpnv4 сессии).
5. ASBR1, принимает данный маршрут и согласно route-target import, устанавливает данный маршрут в таблицу маршрутизации соответствующего vrf, в нашем случае vrf VPN1-ASBR1, производя замену next-hop, согласно указанному в vrf VPN1-ASBR1 (inter-as hybrid next-hop). Замена производится на адрес ASBR2 (стык ASBR2(vrf VPN1-ASBR2)==> ASBR1 (vrf VPN1-ASBR1)).
6. ASBR1 генерирует новый vpnv4 маршрут, навешивает на него excommunity (route-target), которое указано на экспорт в vrf VPN1-ASBR1 и отправляет маршрут на роутрефлектор RR1 (next-hop — лупбек ASBR1)
7. RR1 анонсирует маршрут на PE1.
8. PE1, получив маршрут от RR1, инсталирует его в таблицу маршрутизации соответствующего vrf.
Основным в данной опции является то, что vpnv4 маршруты на ASBR сначала попадает в vrf и уже из данной vrf анонсируется дальше, причем анонсируется с тем excommunity, которое указанно в vrf на экспорт, и оно может отличаться от того excommunity, c которым данный маршрут изначально анонсировался). Схематично это выглядит вот так:
То есть передача vpnv4 маршрута из одной AS в другую происходит в такой последовательности: PE2==>RR2==>ASBR2==>ASBR2 (vrf VPN1-ASBR2)==>ASBR1==>ASBR1 (vrf VPN1-ASBR1)==>RR1==>PE1.
Итак, рассмотрим все вышесказанное на примере.
На PE2 созданы два vrf:
ip vrf VPN1-CE2
rd 2:1
route-target export 2:100
route-target import 1:100
route-target import 2:100
!
ip vrf VPN2-CE2
rd 2:2
route-target export 2:200
route-target import 1:200
route-target import 2:200
Мы будем рассматривать сигнализацию маршрута 10.0.1.0/24 из vrf VPN1-CE2.
Ниже представлен vpnv4, маршрут сгенерированный PE2:
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 VPN1-CE2)
Advertised to update-groups:
3
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:2: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 IPv4 VRF Aggr:22/nolabel(VPN1-CE2)
Мы видим, что для PE2 маршрут является локальным и для данного префикса сгенерированна метка 22.
Теперь PE2 должен отправить данный маршрут на роутрефлектор. Проверим:
PE2#show ip bgp vpnv4 rd 2:1 neighbors 10.1.10.10 advertised-routes
BGP table version is 13, 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 VPN1-CE2)
*> 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
Мы анонсируем два маршрута (10.1.1.2 — это лупбек маршрутизатора VPN1-CE2, который получен через ospf). Дальше маршрут передается на ASBR2:
RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.1.10.3 advertised-routes | i 10.
BGP table version is 37, local router ID is 10.1.10.10
*>i10.0.1.0/24 10.1.10.1 0 100 0 ?
*>i10.1.1.2/32 10.1.10.1 2 100 0 ?
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 100
Paths: (1 available, best #1, no table)
Not advertised to any peer
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:2: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 nolabel/22
У нас не включена опция no bgp default route-target filter, но на ASBR2 созданы vrf:
ip vrf VPN1-ASBR2
rd 2:10001
route-target export 2:100
route-target import 1:100
route-target import 2:100
inter-as-hybrid next-hop 10.1.0.1
!
ip vrf VPN2-ASBR2
rd 2:10002
route-target export 2:200
route-target import 1:200
route-target import 2:200
inter-as-hybrid next-hop 20.1.0.1
Согласно route-target import 2:100 маршруты попадают в vrf VPN1-ASBR2.
Примечание: в конфигурации vrf появилась новая команда: inter-as-hybrid next-hop. Ее назначение будет рассмотрено далее.
Проверим, установлен ли наш маршрут к сети 10.0.1.0/24 в таблицу маршрутизации vrf VPN1-ASBR2:
ASBR2#sh ip route vrf VPN1-ASBR2 10.0.1.0
Routing Table: VPN1-ASBR2
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:50:46 ago
Routing Descriptor Blocks:
* 10.1.10.1 (default), from 10.1.10.10, 00:50:46 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 22
MPLS Flags: MPLS Required
Отлично, маршрут есть. Пока что все как в опции А. Но в опции А дальше мы должны анонсировать чистые ip маршруты из одного vrf в другой с использованием специально запущенного в vrf протокола маршрутизации. Но в опции АВ маршруты между ASBR передаются по bgp vpnv4 сессии между ASBR-ми. Посмотрим, что мы анонсируем на ASBR1 по bgp сессии между ASBR-ми:
ASBR2#sh ip bgp vpnv4 all neighbors 10.2.0.1 advertised-routes
BGP table version is 109, 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:10001 (default for vrf VPN1-ASBR2)
*>i10.0.1.0/24 10.1.10.1 0 100 0 ?
*>i10.1.1.2/32 10.1.10.1 2 100 0 ?
Route Distinguisher: 2:10002 (default for vrf VPN2-ASBR2)
*>i20.0.1.0/24 10.1.10.1 0 100 0 ?
*>i20.1.1.2/32 10.1.10.1 2 100 0 ?
Total number of prefixes 4
Мы анонсируем 4 маршрута, но у них уже не оригинальный rd. Анонс с PE1 был с rd 2:1, а теперь мы анонсируем маршруты с rd 2:10001. То есть маршрут был заново сгенерирован на ASBR2. Что бы это работало, необходимо в настройках bgp сессии между ASBR дать команду: inter-as-hybrid. Данная команда указывает на то, что данная сессия предназначена для передачи vpnv4 маршрутов для опции AB ( в терминах Сиско — созданный на ASBR vrf называется option AB vrf).
ASBR2#sh configuration | b address-family vpnv4
address-family vpnv4
neighbor 10.1.10.10 activate
neighbor 10.1.10.10 send-community extended
neighbor 10.2.0.1 activate
neighbor 10.2.0.1 send-community extended
neighbor 10.2.0.1 inter-as-hybrid
exit-address-family
Продолжим. Проверим маршруты до сети 10.0.1.0/24 на ASBR1:
ASBR1#sh ip bgp vpnv4 all 10.0.1.0/24
BGP routing table entry for 1:10001:10.0.1.0/24, version 98
Paths: (1 available, best #1, table VPN1-ASBR1)
Advertised to update-groups:
1
2, imported path from 2:10001:10.0.1.0/24
10.1.0.2 (via VPN1-ASBR1) from 10.2.0.2 (10.1.10.3)
Origin incomplete, localpref 100, valid, external, best
Extended Community: RT:2: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 31/19
BGP routing table entry for 2:10001:10.0.1.0/24, version 94
юPaths: (1 available, best #1, no table)
Not advertised to any peer
2
10.2.0.2 from 10.2.0.2 (10.1.10.3)
Origin incomplete, localpref 100, valid, external, best
Extended Community: RT:2: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 nolabel/19
В выводе у нас два маршрута, один с next-hop 10.2.0.2 — это оригинальный vpnv4 маршрут, полученный от ASBR2; второй с next-hop 10.1.0.2 (via VPN1-ASBR1) — уже измененный маршрут, который будет использоваться для передачи трафика и инсталироваться в таблицу маршрутизации VPN1-ASBR1.
Прошу обратить внимание на то, что ASBR2 как и положено ASBR-ру в опции В сгенерировал метку: в маршруте на ASBR1 есть метка на out: “mpls labels in/out 31/19”. Но данная метка не будет использована для передачи трафика. Это видно из маршрута, который импортируется в таблицу маршрутизации vrf VPN1-ASBR1: в маршруте mpls метки нет: “MPLS label: none” (см вывод ниже):
ASBR1#sh ip rou vrf VPN1-ASBR1 10.0.1.0
Routing Table: VPN1-ASBR1
Routing entry for 10.0.1.0/24
Known via "bgp 1", distance 20, metric 0
Tag 2, type external
Last update from 10.1.0.2 on GigabitEthernet3/0.10, 01:14:18 ago
Routing Descriptor Blocks:
* 10.1.0.2, from 10.2.0.2, 01:14:18 ago, via GigabitEthernet3/0.10
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 2
MPLS label: none
Замена next-hop была произведена благодаря команде inter-as-hybrid next-hop на ASBR1:
ip vrf VPN1-ASBR1
rd 1:10001
route-target export 1:100
route-target import 1:100
route-target import 2:100
inter-as-hybrid next-hop 10.1.0.2
Если данную команду не указать, то в vrf будут импортироваться маршрут с оригинальным next-hop-ом из полученного vpnv4 маршрута от ASBR2 (то есть next-hop-ом будет адрес ASBR2, который используется как сорс для eBGP сессии, как в обычной опции В). В нашем случае на ASBR1 мы имеем вот такие интерфейсы:
ASBR1#sh int description | i Gi3
Gi3/0 up up "to ASBR2 | AS2"
Gi3/0.2 up up "to ASBR2 | vpnv4 routes only"
Gi3/0.10 up up "for VPN1 only"
Gi3/0.20 up up "for VPN2 only"
ASBR1#sh ip int brief | i 3/0
GigabitEthernet3/0 unassigned YES NVRAM up up
GigabitEthernet3/0.2 10.2.0.1 YES NVRAM up up
GigabitEthernet3/0.10 10.1.0.1 YES NVRAM up up
GigabitEthernet3/0.20 20.1.0.1 YES NVRAM up up
Нам надо что бы трафик vpn1 форвардился через интерфейс GigabitEthernet3/0.10 (соответственно vpn2 — через GigabitEthernet3/0.20). Поэтому в настройках vrf next-hop-ом указан адрес 10.1.0.2 — интерфейс GigabitEthernet3/0.10 на ASBR2, который находится в vrf VPN1-ASBR2:
ASBR2#sh run int gigabitEthernet 3/0.10
Building configuration...
Current configuration : 165 bytes
!
interface GigabitEthernet3/0.10
description "for VPN1 forwarding"
encapsulation dot1Q 10
ip vrf forwarding VPN1-ASBR2
ip address 10.1.0.2 255.255.255.252
end
Двигаемся дальше. Из vrf VPN1-ASBR1 данный маршрут должен быть анонсирован на роутрефлектор:
ASBR1#sh ip bgp vpnv4 all neighbors 10.0.10.10 advertised-routes
BGP table version is 101, local router ID is 10.0.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: 1:10001 (default for vrf VPN1-ASBR1)
*> 10.0.1.0/24 10.1.0.2 0 2 ?
*> 10.1.1.2/32 10.1.0.2 0 2 ?
Route Distinguisher: 1:10002 (default for vrf VPN2-ASBR1)
*> 20.0.1.0/24 20.1.0.2 0 2 ?
*> 20.1.1.2/32 20.1.0.2 0 2 ?
Total number of prefixes 4
Думаю вы уже заметили, что это новый маршрут, сгенерированный ASBR1, так как вот маршруты, которые ASBR1 получил (обратите внимание на rd):
Route Distinguisher: 2:10001 (default for vrf VPN1-ASBR2)
*>i10.0.1.0/24 10.1.10.1 0 100 0 ?
*>i10.1.1.2/32 10.1.10.1 2 100 0 ?
А вот маршруты, который анонсированы с ASBR1:
Route Distinguisher: 1:10001 (default for vrf VPN1-ASBR1)
*> 10.0.1.0/24 10.1.0.2 0 2 ?
*> 10.1.1.2/32 10.1.0.2 0 2 ?
Обратите внимание на rd: был 2:10001, теперь 1:10001. Посмотрим, какие vrf настроены на ASBR1:
ip vrf VPN1-ASBR1
rd 1:10001
route-target export 1:100
route-target import 1:100
route-target import 2:100
inter-as-hybrid next-hop 10.1.0.2
!
ip vrf VPN2-ASBR1
rd 1:10002
route-target export 1:200
route-target import 1:200
route-target import 2:200
inter-as-hybrid next-hop 20.1.0.2
Думаю теперь понятно, что маршрут был сгенерирован ASBR1.
ASBR1 сгенерировал метку 31 для данного префикса:
RR1#sh ip bgp vpnv4 all 10.0.1.0/24
BGP routing table entry for 1:10001:10.0.1.0/24, version 38
Paths: (1 available, best #1, no table)
Advertised to update-groups:
1
2, (Received from a RR-client)
10.0.10.3 (metric 20) from 10.0.10.3 (10.0.10.3)
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
mpls labels in/out nolabel/31
Далее все стандартно. Маршрут передается c RR1 на PE1:
RR1#sh ip bgp vpnv4 rd 1:10001 neighbors 10.0.10.1 advertised-routes
BGP table version is 41, local router ID is 10.0.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: 1:10001
*>i10.0.1.0/24 10.0.10.3 0 100 0 2 ?
*>i10.1.1.2/32 10.0.10.3 0 100 0 2 ?
Total number of prefixes 2
А PE1 инсталирует его таблицу маршрутизации соответствующего vrf:
PE1#sh ip route vrf VPN1-CE1 10.0.1.0
Routing Table: VPN1-CE1
Routing entry for 10.0.1.0/24
Known via "bgp 1", distance 200, metric 0
Tag 2, type internal
Redistributing via ospf 1
Advertised by ospf 1 subnets
Last update from 10.0.10.3 01:45:25 ago
Routing Descriptor Blocks:
* 10.0.10.3 (default), from 10.0.10.10, 01:45:25 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 2
MPLS label: 31
MPLS Flags: MPLS Required
На картинке ниже изображен процесс сигнализирования метки vpn.
Теперь перейдем к data plane. Сделаем трассировку между CE маршрутизаторами:
CE1-VPN1#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 = 72/101/144 ms
CE1-VPN1#traceroute 10.0.1.2
Type escape sequence to abort.
Tracing the route to 10.0.1.2
1 10.0.0.1 32 msec 12 msec 8 msec
2 10.0.2.2 [MPLS: Labels 17/31 Exp 0] 48 msec 44 msec 48 msec
3 10.1.0.1 [MPLS: Label 31 Exp 0] 44 msec 40 msec 12 msec
4 10.1.0.2 60 msec 48 msec 44 msec
5 10.1.0.2 [MPLS: Labels 17/22 Exp 0] 72 msec 88 msec 68 msec
6 10.0.1.1 80 msec 40 msec 56 msec
7 10.0.1.2 100 msec 84 msec 80 msec
И тоже самое для vpn2:
VPN2-CE1#ping 20.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/120/144 ms
VPN2-CE1#traceroute 20.0.1.2
Type escape sequence to abort.
Tracing the route to 20.0.1.2
1 20.0.0.1 64 msec 16 msec 16 msec
2 10.0.0.2 [MPLS: Labels 16/32 Exp 0] 44 msec 40 msec 40 msec
3 20.1.0.1 [MPLS: Label 32 Exp 0] 12 msec 28 msec 24 msec
4 20.1.0.2 52 msec 44 msec 40 msec
5 10.1.0.2 [MPLS: Labels 17/23 Exp 0] 40 msec 48 msec 64 msec
6 20.0.1.1 60 msec 48 msec 84 msec
7 20.0.1.2 76 msec 72 msec 76 msec
PE1 получает IP пакет от клиентского маршрутизатора и согласно своей таблицы маршрутизации производит навешивание двух меток — 31 (метка vrf) и 17 или 16 (транспортная метка до ASBR1 в зависимости от того, как PE1 балансирует трафик):
PE1#sh ip route vrf VPN1-CE1 10.0.1.0
Routing Table: VPN1-CE1
Routing entry for 10.0.1.0/24
Known via "bgp 1", distance 200, metric 0
Tag 2, type internal
Redistributing via ospf 1
Advertised by ospf 1 subnets
Last update from 10.0.10.3 01:45:25 ago
Routing Descriptor Blocks:
* 10.0.10.3 (default), from 10.0.10.10, 01:45:25 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 2
MPLS label: 31
MPLS Flags: MPLS Required
PE1#sh mpls forwarding-table 10.0.10.3
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
18 16 10.0.10.3/32 0 Gi1/0 10.0.0.2
17 10.0.10.3/32 0 Gi2/0 10.0.2.2
Судя по трассировке выше, PE1 выбирает маршрут через P1.
P1, получив пакет с меткой 17, производит снятие данной (верхней) метки и отправку пакета в интерфейс Gi1/0 (линк в сторону ASBR1):
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.0.10.3/32 11590 Gi1/0 10.0.3.1
ASBR1 обрабатывает пакет как обычный PE маршрутизатор — снимает метку и отправляет в интерфейс Gi3/0.10 чистый IP пакет:
ASBR1#sh mpls forwarding-table labels 31
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
31 No Label 10.0.1.0/24[V] 1712 Gi3/0.10 10.1.0.2
Получив данный пакет, ASBR2, работает как PE маршрутизатор, получивший пакет от клиентского CE маршрутизатора — навешивает метку vrf (22) и транспортную метку (17 или 19 — опять эквивалентные пути и судя по трассировке пакет идет на RR2):
ASBR2# sh ip route vrf VPN1-ASBR2 10.0.1.0
Routing Table: VPN1-ASBR2
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 01:51:32 ago
Routing Descriptor Blocks:
* 10.1.10.1 (default), from 10.1.10.10, 01:51:32 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
23 17 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, как и положено транзитному mpls маршрутизатору на предпоследнем хопе, снимает верхнюю метку и отправляет пакет на PE2:
RR2#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 7242 Gi2/0 10.1.1.1
Ну а PE2 знает, что метка 22 указывает на то, что надо сделать ip lookup в vrf VPN1-CE2:
PE2#show mpls forwarding-table labels 22
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 Pop Label IPv4 VRF[V] 8150 aggregate/VPN1-CE2
Далее пакет улетает на клиентский CE маршрутизатор. Все метки и операции с ними представлены на рисунке ниже.
В итоге мы получили гибрид опции А и В, в которой мы можем использовать qos и фильтрацию клиентского трафика между ASBR-рами как в опции А, но в тоже время хоть нам и придется сконфигурировать vrf для каждого vpn на ASBR и сделать отдельный стык, но нет необходимости в отдельном процессе протокола маршрутизации в каждом vrf, что естественно снижает нагрузку на ASBR, который, как в опции В, должен поддерживать всего одну vpnv4 сессию с соседним ASBR-ом.
Ну и в конце хотелось бы акцентировать внимание на двух важных командах:
inter-as-hybrid next-hop в иерархии ip vrf — данная команда необходима для подмены next-hop, если ее не указать, то в vrf будет импортироваться маршрут с next-hop в стык, на котором запущена опция В.
neighbor 10.2.0.1 inter-as-hybrid — данная команда указывает на то, что между пирами установлена bgp сессия для обмена vpnv4 маршрутами для Inter-AS Option AB. Данная команда дает возможность сначала импортировать маршруты в vrf, а потом экспортировать маршруты из этого vrf дальше (меняя rd и при необходимости community).
Важно, что обе эти опции должны быть включены, иначе у вас или ничего не заработает или заработает, но не так как должно работать.
В настоящее время есть только драфт RFC, посвященный опции AB. В данной статье мы познакомились с опцией АВ на примере реализации ее компанией Cisco. Пишите в личку если найдете какие либо недостатки или считаете, что что то надо дополнить/описать получше.
Всем спасибо за внимание!
