Profil 0
Profil 1
Profil 3
Pada bagian artikel ini, kita akan melihat opsi untuk mengganti sinyal dalam jaringan overlay dari PIM ke BGP.
Seperti yang telah dibahas sebelumnya (lihat artikel tentang BGP Auto-Discovery), untuk mengirimkan analog pesan PIM, beberapa jenis rute ditemukan di BGP, yang masing-masing membawa fungsionalitas tertentu. Selain itu, ada lebih banyak tipe rute daripada tipe pesan di PIM.
"Mengapa menaruh burung hantu di globe?" - Anda mungkin bertanya, karena semuanya berjalan baik dengan PIM juga. Dan, secara umum, Anda benar. Alasan utama gerakan ksatria semacam itu adalah skalabilitas. PIM, yang pada dasarnya adalah protokol Soft Driven, memerlukan pengiriman pesan layanan yang konstan untuk operasinya, yang, pada ukuran implementasi tertentu (jika jumlah node mulai melebihi beberapa ratus atau ribuan), memperkenalkan batasan karena beban CPU yang tak terhindarkan. BGP adalah protokol Hard Driven - mis. jika sesuatu dikatakan sekali, itu tidak akan diulangi; setiap pembaruan BGP hanya karena perubahan jaringan.
Hari ini kita akan mempertimbangkan dua skenario: menggunakan PIM SSM dan PIM ASM dalam C-VRF.
C-PIM SSM
Untuk pemahaman yang lebih sederhana tentang pensinyalan BGP untuk membangun pohon multicast, mari kita mulai percakapan kita dengan PIM SSM yang lebih sederhana.
Pertama-tama, mari hapus pengaturan saat ini untuk titik pertemuan dan nonaktifkan penerima lalu lintas:
CE4(config)#interface Loopback0
CE4(config-if)#no ip igmp join-group 231.1.1.2
CE4(config-if)#
CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0 group-list 1
Di semua PE, kami akan menunjukkan bahwa BGP akan berfungsi untuk pensinyalan, bukan PIM. Ini dilakukan dengan perintah berikut:
ip vrf C-ONE
mdt overlay use-bgp
Titik awal pengamatan adalah situasi tanpa kehadiran sumber dan penerima lalu lintas multicast. Hanya rute tipe-1 yang harus ada dalam tabel BGP:
PE1#show bgp ipv4 mvpn all
BGP table version is 406, 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 ?
Mari hubungkan penerima:
CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11
Di PE terdekat, rute BGP dari tipe ke-7 dibuat - ini setara dengan pesan Gabung PIM (S, G):
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
0.0.0.0 32768 ?
Logikanya, rute ini harus ada hanya di PE4 dan PE1 (karena melalui mereka lalu lintas harus lewat) dan bukan di PE2 dan PE3. Mari kita periksa:
PE1#show bgp ipv4 mvpn all | b \[7\]
*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
4.4.4.4 0 100 0 ?
PE2#show bgp ipv4 mvpn all | b \[7\]
PE2#
PE3#show bgp ipv4 mvpn all | b \[7\]
PE3#
Bagaimana bisa rute yang semula muncul di PE4 hanya diimpor di PE1?
Mari kita lihat entri di tabel BGP lebih detail:
PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1
BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
7
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
Entri awalan berisi komunitas yang diperluas Route-target = 1.1.1.1:1, yang ditambahkan ke prefiks vpnv4 oleh router, yang merupakan tetangga RPF dari titik PE4:
PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32
BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1 17
Refresh Epoch 4
65011
172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
mpls labels in/out 10018/nolabel
rx pathid: 0, tx pathid: 0x0
PE1#
PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32
BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 152
65011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)
1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10018
rx pathid: 0, tx pathid: 0x0
Mari kita periksa konektivitasnya:
CE1#ping 230.1.1.1 so 11.11.11.11 rep 3
Type escape sequence to abort.
Sending 3, 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 0 from 14.14.14.14, 8 ms
Reply to request 1 from 14.14.14.14, 7 ms
Reply to request 1 from 14.14.14.14, 9 ms
Reply to request 2 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 7 ms
C-PIM ASM
Dalam kasus C-PIM dalam mode SSM, semuanya cukup sederhana. Agar mVPN berfungsi dengan benar, cukup dengan membuat dua (jenis) rute BGP tambahan.
Tetapi bagaimana jika ASM PIM yang lebih kompleks digunakan di dalam C-VRF?
Pertama-tama, kita melihat bahwa semua CE mengetahui informasi tentang titik pertemuan:
CE2#show ip pim rp mapp
CE2#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 231.1.1.0/24
RP 15.15.15.15 (?), v2
Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
Uptime: 1d04h, expires: 00:02:09
CE2#
Bagaimana? Jika kita melihat tabel BGP, kita tidak akan menemukan petunjuk apapun tentang hal ini di sana:
PE1#show bgp ipv4 mvpn all
BGP table version is 682, 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 ?
Jangan lupa bahwa kami memiliki PMSTI dengan PIM yang diaktifkan:
PE1#show ip pim vrf C-ONE interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11
172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.15
1.1.1.1 Tunnel2 v2/S 0 30 1 1.1.1.1
Dari sini, kesimpulan penting dapat ditarik - beberapa pesan PIM (bahkan dengan pensinyalan BGP) ditransmisikan melalui jaringan inti dalam MDT Default .
Bayangkan sebuah sumber muncul di jaringan (di belakang router CE2). Karena saat ini tidak ada entri mRIB pada CE2, Router yang Ditunjuk PIM (dalam kasus kami, ini adalah CE2 itu sendiri) mengirim pesan Register ke titik pertemuan, dengan demikian menandakan adanya sumber aktif dalam jaringan.
Sebuah pohon dibuat di titik pertemuan (12.12.12.12, 231.1.1.1):
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: P
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
Dan, karena tidak ada penerima lalu lintas aktif di jaringan (tidak ada pohon (*, 231.1.1.1)), maka pesan Register-Stop dihasilkan dari sisi CE5.
Menanggapi penerimaan Register-Stop, CE2 menangguhkan transmisi data (tidak ada antarmuka di OIL):
CE2#show ip mroute 231.1.1.1
(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Sekarang, bayangkan ada penerima di jaringan yang tertarik dengan lalu lintas untuk grup 231.1.1.1. Di PE4, rute muncul di dalam C-VRF:
PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \(
(*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45
Dan rute BGP dari tipe ke-6 dibuat, yang setara dengan PIM Join (*, 231.1.1.1):
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
Pada keluaran di atas, Anda perlu memperhatikan perluasan komunitas Route-target = 1.1.1.1:1. Apa itu dan dari mana asalnya?
Mari kita periksa keberadaan awalan ini di PP lain:
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
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
Extended Community: RT:1.1.1.1:1
Originator: 4.4.4.4, Cluster list: 8.8.8.8
rx pathid: 0, tx pathid: 0x0
Itu. awalan hanya ada di PE1. Yang menarik adalah fakta bahwa titik pertemuan (15.15.15.15) terletak persis di situs di belakang PE1.
Mengetahui tujuan Route-target (impor rute ke VRF tertentu), kesimpulannya menunjukkan dengan sendirinya - RT = 1.1.1.1:1 diketahui PE1 dan tidak diketahui PE2 / PE3. Artinya, fakta jelas bahwa PE4 menghasilkan rute BGP yang menggambarkan PIM Shared Tree Join sedemikian rupa sehingga diproses hanya pada PE di belakang tempat titik pertemuan sebenarnya berada (sebenarnya, ini adalah analog dari transmisi PIM Join melalui antarmuka RPF). Tapi bagaimana PE1 dan PE4 mendamaikan nilai Route-target?
PE4 melakukan RPF untuk alamat titik pertemuan:
PE4#show ip rpf vrf C-ONE 15.15.15.15
RPF information for ? (15.15.15.15)
RPF interface: Tunnel0
RPF neighbor: ? (1.1.1.1)
RPF route/mask: 15.15.15.15/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 1.1.1.1
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE1 dipandang sebagai tetangga RPF. Ini berarti bahwa PE4 harus menempatkan Target-Rute di dalam rute Tipe 6 yang hanya akan diimpor oleh PE1. Untuk menjawab pertanyaan "bagaimana PE4 mengetahuinya?" - mari kita lihat, sebagai permulaan, rute vpn:
PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32
BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 1
65015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)
1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10013
rx pathid: 0, tx pathid: 0x0
Perhatikan komunitas MVPN VRF tambahan: 1.1.1.1: 1. Ini tidak lebih dari komunitas Route Import yang dibuat oleh PE1. Nilai inilah yang disalin sebagai Route-target di dalam rute multicast, yang memungkinkan PE1 untuk mengimpor pembaruan yang diterima dari PE4.
Hasil dari pemrosesan rute BGP tipe 6 pada PE4 adalah terciptanya sebuah entri pada tabel routing multicast:
PE4#show ip mroute vrf C-ONE
(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33
Catatan - Perhatikan bahwa Tunnel0 (PMSTI) ditentukan sebagai antarmuka input.
Pada titik pertemuan, pembuatan pohon bersama selesai:
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22
Sekarang, jika sumber lalu lintas aktif muncul lagi di jaringan, titik pertemuan akan mengetahui cara "menggabungkan" (*, 231.1.1.1) dan (12.12.12.12, 231.1.1.1) pohon.
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31
(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PT
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
Titik pertemuan menciptakan PIM Join (12.12.12.12, 231.1.1.1), mengirimkannya menuju CE2. PE1 menerima Gabungan PIM yang ditentukan dan membuat rute BGP dari tipe ke-7:
PE1#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1
*> [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1
BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:2.2.2.2:1
rx pathid: 1, tx pathid: 0x0
Harap dicatat bahwa nilai RD VPN Jarak Jauh disetel ke 2.2.2.2:1, sejak Melalui PE2 pemeriksaan RPF rute diselesaikan:
PE1#show ip rpf vrf C-ONE 12.12.12.12
RPF information for ? (12.12.12.12)
RPF interface: Tunnel2
RPF neighbor: ? (2.2.2.2)
RPF route/mask: 12.12.12.12/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 2.2.2.2
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Dan RT 2.2.2.2:1 telah ditambahkan ke VPNv4 awalan dari sisi PE2:
PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12
BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 2
65012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)
2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1
Originator: 2.2.2.2, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 2.2.2.2:1:2.2.2.2
mpls labels in/out nolabel/31
rx pathid: 0, tx pathid: 0x0
Langkah ini, sebenarnya, menyelesaikan konstruksi pohon (12.12.12.12, 231.1.1.1) di bagian antara sumber dan titik pertemuan:
Setelah menerima rute jenis ke-7, PE2 menghasilkan rute jenis ke-5, yang menandakan adanya sumber lalu lintas aktif di jaringan. Rute diimpor oleh semua perangkat PE.
PE2#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)
*> [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18
0.0.0.0 32768 ?
PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1
BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (2.2.2.2)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Community: no-export
Extended Community: RT:65001:1
rx pathid: 0, tx pathid: 0x0
Ketika tipe rute 5 diterima, pada PE4 (di mana penerima berada), pembuatan pohon multicast selesai:
PE4#show ip mroute vrf C-ONE
(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQ
Incoming interface: Tunnel0, RPF nbr 2.2.2.2
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19
Catatan - perhatikan tanda Q, yang menunjukkan bahwa entri tersebut dibuat berkat pesan BGP Source-Active
Varian yang dipertimbangkan dari organisasi mVPN diberi nama kode "Profil 11". Karakteristik utamanya:
- untuk mengirimkan lalu lintas multicast ke jaringan overlay, MDT default digunakan
- protokol mGRE digunakan sebagai metode organisasi transportasi
- Protokol BGP digunakan untuk memberi sinyal pohon multicast dalam jaringan yang ditentukan