Для того, чтобы прокинуть 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. Пишите в личку если найдете какие либо недостатки или считаете, что что то надо дополнить/описать получше.
Всем спасибо за внимание!
