Mpls L3Vpn Поверх Dmvpn

Кросспостинг, оригинальная публикация DMVPN — широко известное решение для построения топологий типа «звезда».

В некоторых случаях может потребоваться поддержка изолированной передачи трафика от разных клиентов.

Конечно, в каждом VRF можно построить туннель DMVPN; однако в реальной жизни этот подход недостаточно масштабируем.

В такой ситуации на ум приходит MPLS, хорошо зарекомендовавший себя в корпоративных и провайдерских сетях.

GRE поддерживает инкапсуляцию различных PDU, в том числе MPLS, поэтому на уровне передачи трафика, на первый взгляд, проблем быть не должно.

Однако с протоколами управления ситуация несколько сложнее.

LDP и RSVP должны установить смежность перед обменом какими-либо данными.

Масштабируемость этих протоколов обусловлена использованием многоадресной рассылки для обнаружения соседей и обмена с ними необходимыми параметрами протокола.

Ручная настройка смежности LDP/RSVP в DMVPN сведет на нет масштабируемость, поэтому в этой статье этот сценарий не рассматривается.

Использование многоадресной рассылки ограничивает функциональность решения, поскольку лучи могут обмениваться такими сообщениями только с концентратором, что исключает наличие межлучевого соединения с использованием MPLS.



Однако существует третье решение, которое вполне масштабируемо и также может обеспечивать соединение MPLS между лучевыми узлами — это одноадресная рассылка с меткой BGP (BGP LU).

Существует несколько способов превратить лучевой маршрутизатор в PE (например, первый вариант – отправить пакет с тегом VPN непосредственно на другой луч, аналогично второй фазе DMVPN; второй вариант – концентратор непосредственно участвует в передаче пакета внутри VRF, выполняя перенаправление пакетов, как и на третьем этапе DMVPN); однако в некоторых случаях может потребоваться разместить PE за спицами.

Как обычно, мы соберём лабораторию и итеративно создадим работающее решение.

Ниже представлена топология, использованная в обзоре 2547oDMVPN:



Планировка стенда Роли маршрутизатора:

• R1, R5, R7 (и позже R6) – MPLS PE;
• R3 – провайдер DMVPN;
• R2 – концентратор DMVPN;
• R4, R6 – спицы DMVPN.

• R1-R2, R4-R5, R6-R7 – OSPF на сайте организации;
• R3 – поставщик OSPF, обеспечивающий соединение между маршрутизаторами DMVPN;
• R1, R5, R7 (R6) – MP-BGP VPNv4 AF;
• R2, R4, R6 – MP-BGP IPv4 AF;

Loopback2 эмулирует клиентские сети внутри VRF. Начнем с базовой конфигурации PE:

   

 R1(config)# vrf definition A
 R1(config-vrf)# rd 1:1
 R1(config-vrf)# address-family ipv4
 R1(config-vrf-af)# route-target export 1:1
 R1(config-vrf-af)# route-target import 1:1
 R1(config-if)# interface Loopback0
 R1(config-if)# ip address 1.1.1.1 255.255.255.255
 R1(config)# interface Loopback2
 R1(config-if)# vrf forwarding A
 R1(config-if)# ip address 1.1.1.1 255.255.255.255
 R1(config)# interface FastEthernet0/0
 R1(config-if)# ip address 192.168.12.1 255.255.255.0
 R1(config-if)# mpls ldp router-id Loopback0
 R1(config)# router ospf 1
 R1(config-router)# mpls ldp autoconfig
 R1(config-router)# router-id 1.1.1.1
 R1(config-router)# network 0.0.0.0 255.255.255.255 area 0
 R1(config)# router bgp 1
 R1(config-router)# template peer-policy L3VPN
 R1(config-router-ptmp)# send-community both
 R1(config-router-ptmp)# exit-peer-policy
 R1(config-router)# template peer-session SESSION
 R1(config-router-stmp)# remote-as 1
 R1(config-router-stmp)# update-source Loopback0
 R1(config-router-stmp)# exit-peer-session
 R1(config-router)# bgp router-id 1.1.1.1
 R1(config-router)# no bgp default ipv4-unicast
 R1(config-router)# neighbor 5.5.5.5 inherit peer-session SESSION
 R1(config-router)# neighbor 7.7.7.7 inherit peer-session SESSION
 R1(config-router)# address-family vpnv4
 R1(config-router-af)# neighbor 5.5.5.5 activate
 R1(config-router-af)# neighbor 5.5.5.5 send-community extended
 R1(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPN
 R1(config-router-af)# neighbor 7.7.7.7 activate
 R1(config-router-af)# neighbor 7.7.7.7 send-community extended
 R1(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPN
 R1(config-router-af)# exit-address-family
 R1(config-router)# address-family ipv4 vrf A
 R1(config-router-af)# redistribute connected
 R1(config-router-af)# exit-address-family

   

Обязательным условием для L3VPN является наличие работающего LSP между PE. Поскольку ни LDP, ни RSVP внутри DMVPN для этой задачи не подходят, мы используем MP-BGP для передачи следующей информации:

• адреса обратной связи;
• соответствующие им метки MPLS.

А как насчет поддержки MPLS на интерфейсах?

R2# sho mpls interfaces Interface IP Tunnel BGP Static Operational FastEthernet0/0 Yes (ldp) No No No Yes

MPLS пока не работает на Tunnel0. Нам нужно только включить поддержку пакетов MPLS, не включая LDP, поэтому команда «мплс айпи» не подходит. Однако есть еще одна менее известная команда, отвечающая нашей задаче:

R2(config)#interface Tunnel0 R2(config-if)#mpls bgp forwarding R2#sho mpls interfaces Interface IP Tunnel BGP Static Operational FastEthernet0/0 Yes (ldp) No No No Yes Tunnel0 No No Yes No Yes

После запуска этой команды на всех лучах вы можете приступить к настройке BGP. В этой статье мы используем iBGP между концентратором и лучом; концентратор действует как отражатель маршрутов и принимает входящие соединения BGP:

R2(config)# router bgp 1 R2(config-router)# bgp router-id 2.2.2.2 R2(config-router)# bgp listen range 192.168.0.0/24 peer-group DMVPN R2(config-router)# no bgp default ipv4-unicast R2(config-router)# neighbor DMVPN peer-group R2(config-router)# neighbor DMVPN remote-as 1 R2(config-router)# neighbor DMVPN update-source Tunnel0 R2(config-router)# address-family ipv4 R2(config-router-af)# network 1.1.1.1 mask 255.255.255.255 R2(config-router-af)# neighbor DMVPN activate R2(config-router-af)# neighbor DMVPN route-reflector-client R2(config-router-af)# neighbor DMVPN send-label



R4(config)# router bgp 1 R4(config-router)# bgp router-id 4.4.4.4 R4(config-router)# no bgp default ipv4-unicast R4(config-router)# neighbor 192.168.0.2 remote-as 1 R4(config-router)# neighbor 192.168.0.2 update-source Tunnel0 R4(config-router)# address-family ipv4 R4(config-router-af)# network 5.5.5.5 mask 255.255.255.255 R4(config-router-af)# neighbor 192.168.0.2 activate R4(config-router-af)# neighbor 192.168.0.2 send-label



R6(config)# router bgp 1 R6(config-router)# bgp router-id 6.6.6.6 R6(config-router)# no bgp default ipv4-unicast R6(config-router)# neighbor 192.168.0.2 remote-as 1 R6(config-router)# neighbor 192.168.0.2 update-source Tunnel0 R6(config-router)# address-family ipv4 R6(config-router-af)# network 7.7.7.7 mask 255.255.255.255 R6(config-router-af)# neighbor 192.168.0.2 activate R6(config-router-af)# neighbor 192.168.0.2 send-label

Проверим, есть ли IP-связь между PE:

R5#ping 1.1.1.1 so lo 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: Packet sent with a source address of 5.5.5.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/64 ms

Достаточно ли этого для подключения внутри VRF?

R5#ping vrf A 1.1.1.1 so lo 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: Packet sent with a source address of 5.5.5.5 .

Success rate is 0 percent (0/5)

К сожалению, решение несколько сложнее, чем может показаться на первый взгляд. Причина отсутствия связи – неработающий LSP между PE:

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5 Sending 5, 100-byte MPLS Echos to 1.1.1.1/32, timeout is 2 seconds, send interval is 0 msec: Codes: '!' - success, 'Q' - request not sent, '.

' - timeout, 'L' - labeled output interface, 'B' - unlabeled output interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 'P' - no rx intf label prot, 'p' - premature termination of LSP, 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. BBBBB Success rate is 0 percent (0/5)

Если быть точным, то место отказа — R4:

R4#sho mpls forwarding-table 1.1.1.1 32 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 19 No Label 1.1.1.1/32 1125 Tu0 192.168.0.2

Однако именно в R4 возникает проблема? Разве R2 не должен был отправить R4 префикс вместе с меткой?

R4#sho ip bgp labels Network Next Hop In label/Out label 1.1.1.1/32 192.168.12.1 nolabel/nolabel 2.2.2.2/32 192.168.0.2 nolabel/imp-null <output omitted>

Важное замечание: 1.1.1.1/32 не имеет сопутствующей метки MPLS, однако 2.2.2.2/32 ведет себя так, как предполагалось.

Также стоит обратить внимание на next-hop для 1.1.1.1/32 — это адрес R1, а не R2. R2 импортировал маршрут в BGP, сохранив исходный следующий переход из таблицы маршрутизации.

Поскольку сеанс между R2 и R4 представляет собой iBGP, значение следующего перехода для 1.1.1.1/32 не меняется.

Для 2.2.2.2/32 значением следующего перехода является адрес R2. Однако это тонкое различие является ключевым: BGP присваивает метку префиксу MPLS только в том случае, если маршрутизатор BGP является следующим переходом для этого префикса, т. е.

включен в LSP. В нашем случае нам нужно присвоить метку только префиксам, импортированным локально, а не менять информацию со спица:

R2(config)#router bgp 1 R2(config-router)#address-family ipv4 R2(config-router-af)#neighbor PEER next-hop-self ? all Enable next-hop-self for both eBGP and iBGP received paths <cr> R2(config-router-af)#neighbor PEER next-hop-self

Эта команда довольно хитрая.

По умолчанию это заставляет R2 менять следующий переход для маршрутов, импортируемых локально или полученных через eBGP; если вам нужно изменить next-hop для всех префиксов, в том числе полученных по iBGP, вам нужно добавить ключевое слово "все".

Была ли какая-то согласованность?

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5 <output omitted> Type escape sequence to abort. !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/65/72 ms R5# R5#ping vrf A 1.1.1.1 so lo 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: Packet sent with a source address of 5.5.5.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/108 ms R5# R5#ping mpls ipv4 7.7.7.7/32 source 5.5.5.5 <output omitted> Type escape sequence to abort. !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/64 ms R5# R5#ping vrf A 7.7.7.7 so lo 2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds: Packet sent with a source address of 5.5.5.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 48/79/104 ms R5# R5#traceroute 7.7.7.7 so lo 0 Type escape sequence to abort. Tracing the route to 7.7.7.7 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.45.4 [MPLS: Label 22 Exp 0] 88 msec 80 msec 80 msec 2 192.168.0.6 [MPLS: Label 16 Exp 0] 52 msec 64 msec 52 msec 3 192.168.67.7 40 msec 64 msec 64 msec

Мы заставили L3VPN работать поверх DMVPN. Однако внимательный читатель, повторивший описанные действия в собственной лаборатории, мог заметить следующее предупреждение, появляющееся при настройке BGP LU:

R4(config-router-af)#neighbor 192.168.0.2 send-label %BGP: For distributing MPLS labels to IBGP peers, the update source should be set to a loopback interface

Хотя сообщение намекает на потенциальные проблемы, они остались незамеченными в нашей топологии.

Рассмотрим следующую диаграмму:



В этом примере маршрутизатор R1 устанавливает сеанс BGP от своего интерфейса f0/0 к интерфейсу обратной связи на маршрутизаторе R3, повторяя схему DMVPN. Плоскость управления в этом случае будет работать без ошибок, тогда как связность на плоскости данных — LSP — будет нарушена.

Причина в PHP, выскакивании предпоследнего хопа.

Интерфейс f0/0 находится в сети с прямым подключением к R2, которая объявляет его с меткой неявного нуля.

Давайте посмотрим, что происходит с пакетом, который R3 отправляет R1:

1. R3 добавляет в пакет тег VPN (например, 16);
2. R3 добавляет транспортную метку (неявно нулевую) к полученному кадру MPLS;
3. R3 отправляет полученный кадр маршрутизатору R2 с тегом VPN наверху стека.

кадр и транспортную метку в LFIB).

В любом случае шансы R1 получить кадр ничтожно малы.

Стоит отметить, что использование явного значения null не решит проблему, поскольку базовая метка VPN все равно будет использоваться для передачи кадра.

Однако какое отношение это имеет к нашей исходной топологии? Описанная проблема касается неправильно настроенных PE-маршрутизаторов.

Однако эта проблема становится актуальной и в нашей топологии, если луч превращается в PE, поскольку BGP использует Tunnel0 для установления сеанса.

Можно попробовать перенастроить BGP на использование шлейфа, хотя это ни к чему хорошему не приведет: LSP будет рваться, потому что некому рекламировать сами метки для шлейфов — обычно это задача LSP/RSVP. Однако решение довольно простое: вы можете использовать петлю только для сессий VPNv4 AF и рекламировать соответствующие метки с помощью BGP LU:

R6(config)# vrf definition A R6(config-vrf)# rd 2:2 R6(config-vrf)# address-family ipv4 R6(config-vrf-af)# route-target export 1:1 R6(config-vrf-af)# route-target import 1:1 R6(config-vrf-af)# exit-address-family R6(config-vrf)# interface Loopback1 R6(config-if)# ip address 100.0.0.6 255.255.255.255 R6(config-if)# interface Loopback2 R6(config-if)# vrf forwarding A R6(config-if)# ip address 6.6.6.6 255.255.255.255 R6(config-if)# router bgp 1 R6(config-router)# template peer-policy L3VPN R6(config-router-ptmp)# send-community both R6(config-router-ptmp)# exit-peer-policy R6(config-router)# template peer-session SESSION R6(config-router-stmp)# remote-as 1 R6(config-router-stmp)# update-source Loopback1 R6(config-router-stmp)# exit-peer-session R6(config-router)# neighbor 1.1.1.1 inherit peer-session SESSION R6(config-router)# neighbor 5.5.5.5 inherit peer-session SESSION R6(config-router)# neighbor 7.7.7.7 inherit peer-session SESSION R6(config-router)# address-family ipv4 R6(config-router-af)# network 100.0.0.6 mask 255.255.255.255 R6(config-router-af)# exit-address-family R6(config-router)# address-family vpnv4 R6(config-router-af)# neighbor 1.1.1.1 activate R6(config-router-af)# neighbor 1.1.1.1 send-community extended R6(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPN R6(config-router-af)# neighbor 5.5.5.5 activate R6(config-router-af)# neighbor 5.5.5.5 send-community extended R6(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPN R6(config-router-af)# neighbor 7.7.7.7 activate R6(config-router-af)# neighbor 7.7.7.7 send-community extended R6(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPN R6(config-router-af)# exit-address-family R6(config-router)# address-family ipv4 vrf A R6(config-router-af)# redistribute connected R6(config-router-af)# exit-address-family

Теперь R6 участвует в L3VPN, и мы можем проверить подключение внутри VRF:

R6#tclsh R6(tcl)#foreach x {1.1.1.1 5.5.5.5 7.7.7.7} {ping vrf A $x so lo 2} Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: Packet sent with a source address of 6.6.6.6 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/59/84 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: Packet sent with a source address of 6.6.6.6 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/44 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds: Packet sent with a source address of 6.6.6.6 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms

Наконец, L3VPN поверх DMVPN работает так, как мы ожидали.

Мне кажется, что трудности описываемой конструкции заключаются в следующем:

• обладание тайными знаниями о существовании BGP LU;
• назначение метки MPLS только в том случае, если маршрутизатор является следующим переходом для префикса;
• понимание, в каких случаях PHP способен сломать LSP.

Отличием от документированных методов является возможность разместить PE-маршрутизатор за концентратором/лучевыми узлами, не нарушая двунаправленное соединение через DMVPN. Что касается настройки eBGP, я бы хотел оставить это в качестве домашнего задания для любопытных читателей.

Спасибо за ваш обзор: Анастасия Куралева, Максим Климанов Теги: #cisco #cisco #Сетевые технологии #it-инфраструктура #mpls #l3vpn #ibgp #DMVPN #2547odmvpn #bgp lu #front-door #fvrf

• Советы По Выбору Подходящего Программного Обеспечения Для Бухгалтерского Учета Для Школ

  19 Oct, 24

• Потребность Во Внешних Службах Технической Поддержки

  19 Oct, 24

• Советы По Безопасности Пароля И Как Выбрать Хороший Пароль

  19 Oct, 24

• Доверие И Авторитетность Ссылок, Предпочитаемые Поисковыми Системами

  19 Oct, 24

• Мобильные Телефоны Станут Технически Сложным Продуктом

  19 Oct, 24

• Опубликован Список Из 25 Самых Опасных Уязвимостей Программного Обеспечения

  19 Oct, 24

• Альтапоиск Для Веб-Мастеров

  19 Oct, 24

• Безопасность Данных: Сервер Дома Или В Дата-Центре.

  19 Oct, 24

• Прямая Трансляция С Vue.js Moscow Meetup #1

  19 Oct, 24

• «Рткомм» Защитит Корпоративную Почту С Помощью Advascan

  19 Oct, 24