В прошлых выпусках мы с Вами познакомились с понятиями Default MDT, типами корневых деревьев и разобрали два варианта реализации mVPN на основе mGRE и mLDP:
На сегодняшний день адресное семейство BGP MDT (которое уже рассматривали) является устаревшим. Ему на замену пришло новое — SAFI = multicast VPN (mVPN). Что нового приносит данное адресное семейство? Какие случаи использования могут быть? Попробуем разобраться.
Заинтересованным — добро пожаловать под кат.
Авторы идеи предложили разделить сообщение BGP update на две составляющие:
- Непосредственно mvpn NLRI. Внутри передаётся следующая информация:
- Типа маршрута (значение от 1 до 7). У каждого маршрута — своя функция.
- Аттрибуты туннеля PMSI (PMSI Tunnel Attribute, PTA). Отвечают за передачу информации о типе корневого дерева.
Типы BGP mVPN маршрутов
Тип маршрута | Имя | Предназначение |
1 | Intra-AS I-PMSI A-D | объявление РЕ в качестве mVPN участника для конкретного VPN. Это BGP Auto-Discovery. |
2 | Inter-AS I-PMSI A-D | объявление ASBR в качестве mVPN участника для конкретного VPN. Используется для построения Inter-AS mVPN. |
3 | S-PMSI A-D | объявление РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группыПереключение на Data MDT (подробнее разберёмся позднее) |
4 | Leaf A-D | ответ на Inter-AS PMSI A-D или S-PMSI A-D в случае выставленного бита Leaf Information (LI) |
5 | Source Active A-D | сообщение Source Active |
6 | Shared Tree Join | эквивалент сообщения PIM (*, G) Join (или Prune) |
7 | Source Tree Join | эквивалент сообщения PIM (S, G) Join (или Prune) |
PTA
Тип туннеля определяет используемое корневое дерево и может принимать одно из следующих значений:
0 — информация не представлена
1 — RSVP-TE P2MP LSP
2 — mLDP P2MP LSP
3 — PIM-SSM
4 — PIM-SM
5 — BIDIR-PIM
6 — Ingress Replication
7 — mLDP MP2MP LSP
Дополнительные community
В зависимости от того, используется ли BGP для сигнализации многоадресного трафика в рамках VRF, у маршрутов могут появляться дополнительные коммьюнити.
VRF Route Import (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение: импортирование многоадресных маршрутов (подобную функцию в vpnv4 выполняет аттрибут Route-Target)
Route Target Constraint (RTC)
Предназначение: в случае наличия RTC, Route-Reflector (или любой другой РЕ) отправляет только «желаемый» vpnv4/vpnv6 префикс к РЕ. «Желаемый» обозначает, что на принимаемом РЕ есть один или более VRF, в который указанный префикс может быть импортирован.
Прим. Более подробно про RTC написано в RFC4684
Source-AS Extended Community (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение: передача AS информации для организации Inter-AS mVPN сценариев
PE Distinguisher Label
Предназначение: построение PPMP дерева для участия в Partitioned MDT (на текущий момент я не планирую рассматривать данное дерево в рамках цикла статей).
Поскольку с появлением SAFI mVPN функционал BGP очень расширился, то и применять данное SAFI можно для разных сценариев, в частности:
- проведение Auto-Discovery
- замена PIM сигнализации на BGP
Стоит отметить, что два вышеуказанных сценария могут быть задействованы как одновременно, так и по-отдельности.
Сначала рассмотрим случай когда в наложенной сети сохраняется PIM, но поиск заинтересованных РЕ происходит посредством BGP. Передача данных между РЕ осуществляется посредством GRE. Данная реализация известна под кодовым именем «Profile 3».
Как и раньше, будем использовать следующую лабораторную топологию:
Начальные условия:
- В рамках опорной сети:
- настроен OSPF
- настроен P-PIM в режиме SSM
access-list 99 permit 239.1.1.0 0.0.0.255 ip pim ssm range 99
- В рамках VRF:
- настроен C-PIM
- нет активных источников или получателей трафика
- VRF приведена к виду
ip vrf C-ONE rd 1.1.1.1:1 route-target export 65001:1 route-target import 65001:1
В первую очередь рассмотрим ситуацию, когда в рамках vrf C-ONE работает C-PIM SSM.
Настройка СЕ | Настройка РЕ |
access-list 99 permit 230.1.1.0 0.0.0.255 ip pim ssm range 99 |
access-list 98 permit 230.1.1.0 0.0.0.255 ip pim vrf C-ONE ssm range 98 |
На всех РЕ:
ip vrf C-ONE
mdt auto-discovery pim
mdt default 239.1.1.1
На РЕ устройствах поднимается новый PMSTI:
*Nov 24 20:44:40.941: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2
PE1#show int tu2
Tunnel2 is up, line protocol is up
Interface is unnumbered. Using address of Loopback0 (1.1.1.1)
Tunnel source 1.1.1.1 (Loopback0)
Tunnel protocol/transport multi-GRE/IP
Пока что нет PIM соседства (т.к. РЕ не знают друг о друге):
*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2
Активируем адресное семейство ipv4 mvpn:
router bgp 65001
!
address-family ipv4 mvpn
neighbor MPLS_PE send-community extended
neighbor MPLS_PE route-reflector-client
neighbor 1.1.1.1 activate
neighbor 2.2.2.2 activate
neighbor 3.3.3.3 activate
neighbor 4.4.4.4 activate
exit-address-family
На РЕ моментально появляются соседи в рамках C-VRF:
PE1#show ip pim vrf C-ONE neighbor
172.1.11.11 GigabitEthernet2.111 2w3d/00:01:19 v2 1 / DR S P G
172.1.15.15 GigabitEthernet2.115 2w3d/00:01:35 v2 1 / DR S P G
4.4.4.4 Tunnel2 00:00:17/00:01:27 v2 1 / DR S P G
3.3.3.3 Tunnel2 00:00:17/00:01:27 v2 1 / S P G
2.2.2.2 Tunnel2 00:00:47/00:01:27 v2 1 / S P G
И соответствующие (S, G) деревья:
PE1#show ip mroute 239.1.1.1
(1.1.1.1, 239.1.1.1), 00:00:45/00:02:44, flags: sT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.15, Forward/Sparse, 00:00:45/00:02:44
(4.4.4.4, 239.1.1.1), 00:00:49/00:02:10, flags: sTIZ
Incoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5
Outgoing interface list:
MVRF C-ONE, Forward/Sparse, 00:00:49/00:02:10
(3.3.3.3, 239.1.1.1), 00:00:53/00:02:06, flags: sTIZ
Incoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5
Outgoing interface list:
MVRF C-ONE, Forward/Sparse, 00:00:53/00:02:06
(2.2.2.2, 239.1.1.1), 00:01:19/00:01:40, flags: sTIZ
Incoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5
Outgoing interface list:
MVRF C-ONE, Forward/Sparse, 00:01:19/00:01:40
Как РЕ смогли «увидеть» друг друга? Ответ на этот вопрос нам даст анализ BGP таблицы:
PE1#show bgp ipv4 mvpn all
BGP table version is 258, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i — internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i — IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)
*> [1][1.1.1.1:1][1.1.1.1]/12
0.0.0.0 32768 ?
*>i [1][1.1.1.1:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
*>i [1][1.1.1.1:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
*>i [1][1.1.1.1:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Route Distinguisher: 2.2.2.2:1
*>i [1][2.2.2.2:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
Network Next Hop Metric LocPrf Weight Path
*>i [1][3.3.3.3:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
Route Distinguisher: 4.4.4.4:1
*>i [1][4.4.4.4:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Как видим, каждый РЕ маршрутизатор создал BGP IPv4 mvpn маршрут первого типа, в котором описал себя
PE1#show bgp ipv4 mvpn all route-type 1 4.4.4.4
BGP routing table entry for [1][1.1.1.1:1][4.4.4.4]/12, version 262
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Not advertised to any peer
Refresh Epoch 1
Local, imported path from [1][4.4.4.4:1][4.4.4.4]/12 (global)
4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Community: no-export
Extended Community: RT:65001:1
Originator: 4.4.4.4, Cluster list: 8.8.8.8
PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for [1][4.4.4.4:1][4.4.4.4]/12, version 265
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Not advertised to any peer
Refresh Epoch 1
Local
4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Community: no-export
Extended Community: RT:65001:1
Originator: 4.4.4.4, Cluster list: 8.8.8.8
PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101
rx pathid: 0, tx pathid: 0x0
Обратите внимание на PTA:
- Tunnel type: 3 говорит нам о том, что в рамках vrf использует SSM PIM
- tunnel parameters сообщает нам об адресе РЕ и группе многоадресной рассылки (EF01 0101 = 239.1.1.1)
Подключим клиента:
CE4(config-if)#ip igmp join-group 230.1.1.1 source 11.11.11.11
На РЕ этого сайта появляется многоадресный маршрут:
PE4#show ip mroute vrf C-ONE
(11.11.11.11, 230.1.1.1), 00:00:11/00:03:18, flags: sT
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:00:11/00:03:18
В качестве RPF nbr указан адрес 1.1.1.1 — как PE4 вычисляет его? На самом деле очень просто. Это адрес BGP next-hop для источника = 11.11.11.11
PE4#show ip route vrf C-ONE 11.11.11.11
Routing Table: C-ONE
Routing entry for 11.11.11.11/32
Known via "bgp 65001", distance 200, metric 0
Tag 65011, type internal
Last update from 1.1.1.1 01:02:10 ago
Routing Descriptor Blocks:
* 1.1.1.1 (default), from 8.8.8.8, 01:02:10 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65011
MPLS label: 10018
MPLS Flags: MPLS Required
Соответственно, РЕ4 генерирует PIM Join и отправляет его в рамках Default MDT:
Данный PIM Join будет получен всеми РЕ, но обработан только на РЕ1 (т.к. только на нём Join пройдет RPF проверку)
PE1#show ip mroute vrf C-ONE | b \(
(11.11.11.11, 230.1.1.1), 00:01:16/00:03:11, flags: sT
Incoming interface: GigabitEthernet2.111, RPF nbr 172.1.11.11
Outgoing interface list:
Tunnel2, Forward/Sparse, 00:01:16/00:03:11
PE2#show ip mroute vrf C-ONE | b \(
PE2#
Проверим работоспособность сервиса:
CE1#ping
Target IP address: 230.1.1.1
Repeat count [1]: 5
Extended commands [n]: y
Interface [All]: GigabitEthernet2.111
Source address or interface: 11.11.11.11
Sending 5, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
Reply to request 0 from 14.14.14.14, 7 ms
Reply to request 1 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 8 ms
Reply to request 3 from 14.14.14.14, 8 ms
Reply to request 4 from 14.14.14.14, 7 ms
Как видно, многоадресные пакеты корректно передаются через опорную сеть. При этом стоит отметить, что способ передачи пакетов ничем не отличается от того, что мы с Вами наблюдали в рамках Profile0. Т.е. пакеты долетают до всех РЕ в рамках Default MDT и уже там отбрасываются в случае отсутствия активных подписчиков.
В этом можно убедиться, сняв дамп трафика на сети как это показано на рисунке ниже (vlan id = 37 характеризует интерфейс между R3 и R7):
Выше мы рассмотрели случай использования PIM SSM внутри C-VRF. Изменится ли что-либо, если будет работать PIM ASM?
CE4(config-if)#interface Lo0
CE4(config-if)#ip igmp version 2
CE4(config-if)#no ip igmp join-group 230.1.1.1 source 11.11.11.11
CE4(config-if)#ip igmp join-group 231.1.1.1
!
CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0
!
CE15(config)#access-list 1 permit 231.1.1.0 0.0.0.255
CE15(config)#ip pim bsr-candidate Lo0
CE15(config)#ip pim rp-candidate Lo0 group-list 1
На РЕ сайта появляется дополнительный туннельный интерфейс для PIM encap:
PE1#
*Nov 24 21:39:32.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
Все маршрутизаторы внутри C-VRF корректно узнают о появившихся RP и BSR устройствах в сети:
CE1#show ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 15.15.15.15 (?)
Uptime: 00:01:54, BSR Priority: 0, Hash mask length: 0
Expires: 00:01:16
До тех пор, пока нет активного источника трафика, внутри C-VRF будут наблюдаться только (*, G) маршруты согласно обычной логике работы PIM ASM:
PE4#show ip mroute vrf C-ONE
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 231.1.1.2), 00:00:46/00:02:43, RP 15.15.15.15, flags: S
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:00:46/00:02:43
При этом внутри BGP домена не появляется никаких дополнительных mvpn префиксов:
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*>i [1][1.1.1.1:1][1.1.1.1]/12
1.1.1.1 0 100 0 ?
Route Distinguisher: 2.2.2.2:1
*>i [1][2.2.2.2:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
*>i [1][3.3.3.3:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
Route Distinguisher: 4.4.4.4:1 (default for vrf C-ONE)
*>i [1][4.4.4.4:1][1.1.1.1]/12
1.1.1.1 0 100 0 ?
*>i [1][4.4.4.4:1][2.2.2.2]/12
Network Next Hop Metric LocPrf Weight Path
2.2.2.2 0 100 0 ?
*>i [1][4.4.4.4:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
*> [1][4.4.4.4:1][4.4.4.4]/12
«Почему?» — спросите Вы? Потому что для сигнализации многоадресного трафика C-VRF используется протокол PIM.
О возможной замене сигнализации на BGP поговорим в следующий раз.