Anda bisa melihat sesi naik, melihat rute muncul, dan tetap membaca layanan yang salah. Pasangan angka di awal setiap pengumuman, pengenal famili alamat dan pengenal famili alamat berikutnya, menentukan pengurai mana yang membaca muatan dan tabel mana yang menyimpan hasilnya. Salah membaca pasangannya, kebijakan impor, kecocokan target rute, dan pencarian hop berikutnya semuanya berjalan terhadap struktur yang tidak diumumkan siapa pun. Penelusuran di bawah dimulai dari pasangan itu dan berakhir pada hasil penerusan.

Dua angka menentukan tabel mana tempat rute itu berada

Pasangan itu muncul dua kali: di dalam kemampuan multiprotokol, tempat pembicara mengumumkan famili, dan di depan setiap NLRI yang dibawa famili tersebut. Itu menjadikannya sifat rute, bukan pengaturan pada kotak asal. Vendor mencetaknya sebagai nama seperti Address family VPNv4 Unicast, dan kata-katanya bergeser antar rilis sementara angkanya tetap.

Where you meet itFamily pairBoundary of what it proves
VPNv4 unicast capability on a neighbour1 / 128the peer will signal labelled VPN-IPv4, nothing about import
VPNv6 unicast capability on a neighbour2 / 128the peer will signal VPN-IPv6, silent about the transport below
VPLS NLRI with a VE ID and a label base25 / 65a pseudowire is signalled, not that a bridge learned a MAC
EVPN MAC/IP advertisement route25 / 70a binding is advertised, not that the host answers

Empat pengodean mencakup hampir semua kasus perusahaan: 1 dengan 128 untuk VPN-IPv4 berlabel MPLS, 2 dengan 128 untuk padanan IPv6, 25 dengan 65 untuk VPLS bersinyal BGP, dan 25 dengan 70 untuk EVPN. Kesalahan pertama adalah menganggap setiap layanan Layer 2 berada di balik 25 dengan 65, yang menyembunyikan EVPN. Yang kedua adalah memperlakukan dua famili IP sebagai satu famili dengan alamat lebih panjang, padahal keduanya dinegosiasikan terpisah dan dapat diterima pada peer berbeda. Yang ketiga muncul ketika templat disalin dari rilis yang hanya mengenal salah satunya. Pencarian di registri menyelesaikan ketiganya lebih cepat daripada dugaan yang dibangun dari nama layanan.

Perlakukan keempat baris sebagai contoh dari registri IANA, bukan registri itu sendiri. Ketika sebuah angka tidak cocok dengan apa pun yang Anda kenali, telusuri dulu sebelum membangun kebijakan di sekitarnya.

AFI 25 membawa dua format NLRI yang tidak berhubungan

Kedua famili Layer 2 berada di bawah AFI 25, dan kemiripannya berhenti di situ. NLRI VPLS dalam RFC 4761 section 3.2.2 membawa panjang, pembeda rute, VE ID, offset blok VE, ukuran blok VE, dan basis label, yang bersama-sama menamai titik akhir pseudowire dan labelnya. EVPN mempertahankan AFI 25 dan pindah ke SAFI 70, tempat muatannya adalah tipe rute: penemuan otomatis Ethernet, pengumuman MAC/IP, multicast inklusif, segmen Ethernet, prefiks IP. Jadi offset byte yang sama berarti hal berbeda di kedua famili. Pengurai yang ditulis untuk satu membaca yang lain tanpa keluhan dan menghasilkan omong kosong. Pasangan itu satu-satunya peringatan bahwa tafsirannya salah.

Bidang yang berarti offset blok VE di satu famili tidak punya padanan di famili lain, dan rute pengumuman MAC/IP hanya ada di EVPN. Mengutip atribut seolah berlaku untuk keduanya adalah cara tinjauan tangkapan menjadi salah.

Ketika seseorang memberikan tangkapan atau tabel vendor, tanyakan ke famili mana atribut itu termasuk. Lalu pastikan implementasi penerima mendukung famili itu, bukan nama layanan di lembar data. Dua platform dapat sama-sama mengklaim dukungan VPLS sambil mengimplementasikan famili pensinyalan berbeda. Pasangan itu memisahkan keduanya; label produk tidak.

Famili alamat milik sesi itu sendiri adalah pertanyaan terpisah

VPN-IPv6 rutin diumumkan melalui sesi yang koneksi TCP-nya berjalan di atas IPv4, dan itu desain yang didukung, bukan kesalahan. Karena itu membaca ringkasan sesi saja tidak mengatakan apa pun tentang famili VPN mana yang dipertukarkan para peer.

Famili NLRI, famili transport, dan famili penerusan adalah tiga keputusan independen. Router dapat berbicara IPv4 dengan peer-nya, menerima keterjangkauan VPN-IPv6, dan memasang rute yang hop berikutnya adalah alamat IPv6 yang terjangkau melalui jalur yang tidak Anda maksudkan. Setiap lapisan memerlukan konfirmasinya sendiri. Situs yang melaporkan tujuan IPv6 tak terjangkau sementara pengumumannya tampak benar biasanya kehilangan resolusi hop berikutnya, bukan negosiasi famili.

Uji famili alamat sesi secara terpisah, lalu famili yang dibawanya, lalu apa yang dapat diteruskan inti. Menjaga ketiganya terpisah mencegah salah diagnosis umum saat pengumuman yang benar dibaca sebagai bukti IPv6 bekerja dari ujung ke ujung. Itu hanya membuktikan satu peer memberi tahu peer lain tentang prefiks.

Dinegosiasikan, diterima, diimpor, dipasang

Untuk satu rute yang diharapkan, empat keadaan harus berlaku berurutan, dan tiap keadaan dapat diamati. Famili harus dinegosiasikan dengan peer tersebut, rute harus tiba, target rute harus mengimpornya ke konteks yang dimaksud, dan hop berikutnya harus teresolusi agar rute terpasang. Melewati keadaan pertama membuat tiga lainnya tak terjawab, karena famili yang tidak dinegosiasikan tidak menghasilkan rute untuk diperiksa. Pada platform bergaya Cisco, ringkasan famili dan kemampuan per peer adalah perintah terpisah.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

Negosiasi tampak pada pertukaran kemampuan yang dicetak per peer, dan sesi yang terbentuk tanpa famili tercantum tidak membawa apa pun yang Anda minta. Impor diputuskan oleh target rute yang dibawa sebagai komunitas diperluas, sehingga pasangan benar dengan target salah ketik membuat tabel kosong. Pemasangan lalu bergantung pada hop berikutnya yang teresolusi dalam konteks penerima, yang bisa gagal sementara setiap pengumuman tampak sempurna.

Konfirmasikan bidang data paling akhir, karena rute dalam tabel adalah klaim, bukan pengiriman. Empat keadaan yang sama berlaku untuk setiap famili; hanya perintah dan nama tabelnya yang berubah.

Apa yang tidak pernah dibuktikan pasangan famili

Membaca pasangan dengan benar memberi tahu Anda cara menafsirkan informasi perutean yang menyusul, dan itulah seluruh klaimnya. Itu tidak mengatakan apa pun tentang keterjangkauan, kebijakan, atau kesehatan bidang data. Mencampur keduanya menghasilkan pernyataan percaya diri tentang jaringan yang tidak diverifikasi siapa pun. Ketidakcocokan target rute dan hop berikutnya yang rusak terlihat identik hanya dari pasangannya. Pasangan itu instruksi membaca, bukan putusan.

Saat Anda mengeskalasi, letakkan pasangan, target rute, dan hop berikutnya yang teresolusi dalam satu catatan. Insinyur berikutnya lalu punya tiga hal independen untuk diuji alih-alih nama layanan untuk ditafsirkan ulang. Jika negosiasi tidak ada mereka langsung melihatnya, target yang salah membuat impor tampak absen, dan hop berikutnya yang tak teresolusi membuat rute hadir tetapi tak terpakai.

Artikel terkait