Profil 0
Profil 1
Profil 3
Profil 11
Seperti yang kita pelajari dari entri sebelumnya, di backbone, saat mengimplementasikan mVPN, selalu ada konstruksi MDT default yang menghubungkan semua router PE. Pesan layanan PIM (misalnya Bootstrap, Auto-RP) serta lalu lintas multicast kustom dibawa dalam MDT ini. Akibatnya, ternyata beberapa perangkat PE bahkan menerima lalu lintas yang tidak mereka langgani.
Jika Anda ingin tahu cara menangani ini - selamat datang di bawah kucing!
Untuk meningkatkan efisiensi transfer data, konstruksi tambahan digunakan, yang disebut sebagai "MDT Data". Ide di baliknya adalah sebagai berikut:
- Di dalam pohon, hanya lalu lintas C- (S, G) yang didistribusikan
- Hanya PP Keluar yang memiliki penerima yang berminat menjadi anggota pohon
- Perangkat MDT Data root adalah Ingress PE (router tempat sumber berada)
Secara visual terlihat seperti ini:
Jika kita membayangkan situasi di mana sumber mulai menyiarkan ke grup multicast kedua (230.1.1.2), di mana penerima hanya berada di belakang PE2 dan PE3, maka MDT Data tambahan dibuat dan keseluruhan gambar mengambil bentuk (MDT default dihilangkan):
Pemberian sinyal untuk mengalihkan lalu lintas dari MDT Default ke MDT Data dilakukan secara eksklusif sesuai permintaan ketika ambang batas yang telah ditentukan sebelumnya dilampaui oleh Ingress PE baik melalui PIM atau melalui BGP.
Data MDT menggunakan PIM
Jika PIM digunakan untuk pensinyalan, ingress PE menghasilkan pesan TLV Data-MDT PIM khusus dan mengirimkannya sebagai bagian dari MDT Default untuk memastikan bahwa semua PE dapat menerima pesan tersebut. Bersamaan dengan pengiriman Data MDT TLV, Ingress PE memulai pengatur waktu yang sama dengan tiga detik. Setelah penghitung waktu berakhir, semua paket akan dikirim dalam MDT Data.
Perlu juga dicatat bahwa informasi yang terkandung dalam Data-MDT TLV di-cache di semua PE. Alasannya cukup dangkal - bahkan jika tidak ada penerima lalu lintas yang tertarik pada PE tertentu saat ini, mereka mungkin muncul di sana setelah beberapa saat. Karenanya, setelah menerima PIM Join (dalam C-VRF), PE dapat langsung terhubung ke MDT Data yang sudah ada di jaringan.
Approx. TLV Data-MDT ditransmisikan satu kali per menit.
Setiap MDT Data diatur untuk rute (S, G) terpisah dalam VPN / VRF. Administrator harus secara eksplisit menentukan jumlah maksimum MDT Data yang dapat dibuat di perangkat. Jika pada titik tertentu jumlah pohon yang baru dipasang mencapai batas yang ditentukan, maka pohon berikut akan menggunakan kembali pohon yang sudah terpasang.
Approx. Pada tulisan ini, Cisco IOS tidak mendukung pensinyalan PIM melalui Data MDT. Semua profil dengan alarm ini hanya tersedia di sistem operasi IOS XR.
Data MDT dengan BGP
Saat menggunakan BGP dalam jaringan overlay untuk pensinyalan MDT Data, prinsip dasarnya tetap sama (dibandingkan dengan PIM):
- masuknya sinyal PE ke semua PE bahwa lalu lintas untuk C- (S, G) akan ditransmisikan dalam MDT Data
- egress PE, setelah menerima update BGP, bergabung dengan pohon yang ditentukan
- keluarga pengalamatan mVPN (sAFI 129) digunakan untuk pensinyalan.
Ternyata Ingress PE harus membentuk pesan Update BGP khusus dan mengirimkannya ke semua PE di dalam mVPN. Untuk ini, rute tipe ketiga digunakan.
Profil 14
Mari pertimbangkan transisi yang dijelaskan menggunakan contoh laboratorium kita. Secara khusus, konfigurasi yang dikenal sebagai "Profil 14" dapat diterapkan. Profil ini ditandai dengan penggunaan BGP mVPN AD untuk membangun LSP MLDP P2MP.
Di PE kami akan menggunakan template konfigurasi berikut:
ip vrf C-ONE mdt auto-discovery mldp mdt partitioned mldp p2mp mdt overlay use-bgp mdt strict-rpf interface ! router bgp 1 address-family ipv4 mvpn neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family
Approx. kita
mdt strict-rpf
akan berbicara tentang tujuan dari perintah antarmuka di edisi berikutnya.
Penemuan Otomatis
Mari kita lihat apa yang terjadi pada PE1:
Pada setiap PE, antarmuka Lspvif0 dibuat, di mana C-PIM diaktifkan.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
Tidak ada tetangga saat ini:
PE1#show ip pim vrf C-ONE int 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 Lspvif0 v2/S 0 30 1 1.1.1.1
Mari kita lihat tabel BGP:
PE1#show bgp ipv4 mvpn all BGP table version is 39, 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 ? Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [3][1.1.1.1:1][*][*][1.1.1.1]/14 0.0.0.0 32768 ? *>i [3][1.1.1.1:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? *>i [3][1.1.1.1:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? *>i [3][1.1.1.1:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? *> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18 0.0.0.0 32768 ? Route Distinguisher: 2.2.2.2:1 *>i [3][2.2.2.2:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 *>i [3][3.3.3.3:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 4.4.4.4:1 *>i [3][4.4.4.4:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ?
Seperti yang Anda lihat, selain rute tipe pertama yang telah dipertimbangkan sebelumnya, rute tipe ketiga S-PMSI AD ditambahkan, yang digunakan untuk mengiklankan PE sebagai router Ingress untuk grup C- (S, G) tertentu. Saat ini, grup tersebut adalah (*, *). Ini menunjukkan keinginan PE untuk berpartisipasi dalam pembangunan Partitioned MDT.
Jelas, agar transfer data berfungsi, informasi titik pertemuan harus diketahui di dalam VRF. Dalam kasus kami, CE15 bertindak sebagai RP dan BSR.
C-RP#sh run | i pim ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0
Karena C-RP telah membangun lingkungan PIM dengan PE1, maka informasi tentang RP juga diketahui pada PE1 ini:
PE1#show ip pim vrf C-ONE rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:25:50, expires: 00:01:26
Informasi ini perlu disampaikan ke semua PE / CE lainnya. Bagaimana cara melakukannya? Untuk lebih memahami prinsipnya, saya mengusulkan untuk pergi dari sebaliknya dan mulai melihat informasi yang sudah diketahui tentang CE2:
CE2#show ip pim rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:27:54, expires: 00:02:26
Seperti yang Anda lihat, pesan PIM BSR telah tersebar di infrastruktur mVPN. Mari kita lihat dump lalu lintas di PE1:
Seperti yang Anda lihat, PE1 merangkum pesan PIM BSR di dalam MPLS dan menandainya dengan 28. Dari mana asalnya? Kita dapat berasumsi bahwa karena paket ini telah mencapai CE2 (dan karena itu PE2), yaitu beberapa LSP sebelum PE2.
PE2#show mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 1 Type: P2MP Uptime : 04:17:40 FEC Root : 2.2.2.2 (we are the root) Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): > MDT (VRF C-ONE) Uptime : 04:17:40 Path Set ID : None Interface : Lspvif0 RPF-ID : * LSM ID : 3 Type: P2MP Uptime : 01:30:06 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 3 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 34 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 01:30:06 Path Set ID : None Interface : Lspvif0 RPF-ID : *
Dari analisis database mLDP terlihat bahwa pada PE2 terdapat pohon tertentu (LSM ID: 3), root diantaranya adalah PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF dan untuk pohon ini dihasilkan label lokal 34, yang dikirimkan ke tetangga R6 ( P2).
Bagaimana PE2 tahu tentang pohon yang akarnya adalah PE1, dan bahkan mendapat Buram untuk itu? Jawabannya sederhana - menggunakan tipe rute BGP 3.
Ketika PE1 menerima PIM BSR, itu menghasilkan rute BGP tambahan yang menjelaskan grup (*, 224.0.0.13) (ingat bahwa ini adalah alamat yang dicadangkan untuk mengirim semua pesan layanan PIM). Rute ini berfungsi untuk mengiklankan pohon multicast mLDP baru. Di dalam PTA adalah nilai Opaque yang akan digunakan untuk pensinyalan melalui mLDP.
PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1 BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116 Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) Advertised to update-groups: 1 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 Community: no-export Extended Community: RT:65001:1 PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF rx pathid: 0, tx pathid: 0x0
Jadi, dengan mengimpor rute ini, PE2 dapat memulai pensinyalan mLDP menuju PE1 untuk pohon (*, 224.0.0.13). Untuk label yang diterima dari PE2, P2 (R6) membuat label lokalnya sendiri (29) dan mengirimkannya ke P1 (R5):
P2#show mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 01:40:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 5.5.5.5:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.56* Local Label (D): 29 Next Hop : 10.5.6.5 Replication client(s): 2.2.2.2:0 Uptime : 01:40:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.26* Local label (U): None Next Hop : 10.2.6.2
P1 (R5) melakukan hal yang sama, menghasilkan label lokalnya untuk pohon dan mengirimkannya ke PE1:
P1#show mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 01:41:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.15* Local Label (D): 28 Next Hop : 10.1.5.1 Replication client(s): 4.4.4.4:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.45* Local label (U): None Next Hop : 10.4.5.4 7.7.7.7:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 30 Interface : GigabitEthernet2.57* Local label (U): None Next Hop : 10.5.7.7 6.6.6.6:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 29 Interface : GigabitEthernet2.56* Local label (U): None Next Hop : 10.5.6.6
Secara visual, keseluruhan proses ditunjukkan pada gambar di bawah ini:
Bergabung dengan Pohon Bersama dan membangun pohon akar P2MP (ROOT = RP-PE)
Langkah 2. Penerima lalu lintas muncul di jaringan. Setelah Egress PE (PE2) menerima PIM Join dari CE untuk C - (*, G), PE2 melakukan pemeriksaan RPF untuk menemukan BGP Next-Hop menuju C-RP. Found Next-Hop (1.1.1.1) akan digunakan sebagai Partitioned MDT ROOT untuk mLDP.
Selain itu, PE2 membuat antarmuka Lspvif di dalam C-VRF:
PE2# *Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up PE2# *Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1
Langkah 3. Egress PE (PE2) menghasilkan pesan pemetaan mLDP menuju RP-PE (ROOT P2MP MDT) menggunakan nilai Opaque dari update BGP.
PE2#show mpls mldp database summary LSM ID Type Root Decoded Opaque Value Client Cnt. 4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1 1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1 3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1 PE2# PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI * - Indicates Wildcard source or group address [S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][3.3.3.3:1][*][*][3.3.3.3], Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][4.4.4.4:1][*][*][4.4.4.4], Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined Orig: Local Uptime: 04:44:24 Type: MLDP P2MP Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000) PE2#show mpls mldp database opaque_type gid 65536 LSM ID : 4 Type: P2MP Uptime : 00:03:43 FEC Root : 1.1.1.1 Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 4 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 35 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 00:03:43 Path Set ID : None Interface : Lspvif1 RPF-ID : 0x1
Langkah 4. Egress PE menghasilkan rute BGP dari tipe keenam (bergabung dengan Pohon Bersama menuju RP-PE). Rute ini hanya diimpor ke RP-PE.
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1 BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130 Paths: (1 available, best #1, table MVPNv4-BGP-Table) Advertised to update-groups: 1 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 Extended Community: RT:1.1.1.1:1 rx pathid: 1, tx pathid: 0x0
Langkah 5. RP-PE menerjemahkan rute BGP yang diterima dari tipe keenam di Gabung PIM menuju RP. Pada titik ini, RP siap mengirimkan lalu lintas multicast menuju PE Keluar. Anda perlu mengirimkan lalu lintas dari sumber ke RP.
PE1#show ip mroute vrf C-ONE | b \( (*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15 Outgoing interface list: Lspvif0, Forward/Sparse, 00:07:08/stopped
Langkah 6. Ketika S-PE (PE4) menerima paket multicast pertama dari sumber (CE4), lalu lintas dienkapsulasi di dalam pesan PIM Register dan dikirim sebagai paket unicast menuju C-RP (menggunakan aturan VPN MPLS L3 normal).
Langkah 7. Setelah menerima Register PIM, C-RP memulai proses pembuatan C- tree (14.14.14.14, 230.1.1.1). RP-PE menerima PIM Join untuk C- (14.14.14.14, 230.1.1.1) dari C-RP. Pesan ini diterjemahkan ke dalam tipe rute BGP 7. Namun, sebelum mengirim ke sisi sumber, Anda perlu membuat pohon MDT yang dipartisi dengan PE sebagai ROOT.
Langkah 8. RP-PE melakukan pemeriksaan RPF untuk menemukan BGP Next-Hop menuju sumbernya. Alamat ini akan digunakan sebagai ROOT MDT yang Dipartisi untuk mLDP.
Langkah 9. Menggunakan rute BGP Next-Hop dan BGP yang diterima dari tipe ketiga dari Ingress PE, RP-PR menghasilkan pesan pemetaan mLDP menuju alamat IP Ingress PE, sehingga membangun pohon akar P2MP ke Ingress PE.
Langkah 10. RP-PE mengirimkan rute BGP tipe 7 (Join dari RP) menuju Ingress PE.
Langkah 11. Ingress PE mengubah rute BGP yang diterima dari tipe ketujuh menjadi PIM Join dan mengirimkannya ke sumber lalu lintas.
Lampirkan ke Source Tree dan bangun P2MP (ROOT = S-PE)
Langkah 12. PE Ingress juga mengirimkan rute BGP Tipe 5 ke semua PE mVPN, dengan demikian memberi tahu mereka bahwa ada sumber aktif di jaringan. Rute ini merupakan pemicu untuk beralih ke pohon SPT.
Langkah 13. Egress PE menggunakan rute BGP tipe 5 yang diterima untuk menghasilkan pesan pemetaan mLDP menuju Ingress PE (informasi MDT diambil dari rute BGP tipe 3).
Jadi, lalu lintas sekarang dapat dialihkan secara optimal dari sumber ke tujuan menggunakan tag mpls (mLDP).
