Junos L2VPN: betulkan dahulu kontrak sambungan pelanggan

Sebelum menyentuh pseudowire, ikut satu bingkai pelanggan masuk ke PE dan lihat di mana ia sepatutnya mendarat. Port fizikal mengklasifikasikannya ke unit logik, unit itu membawa enkapsulasi, dan unit itu terikat pada perkhidmatan. Tiga keputusan berasingan, tiga cara berasingan untuk tersilap. Kebanyakan kes yang dieskalasi sebagai kerosakan isyarat sebenarnya ialah bingkai yang diklasifikasikan ke unit yang tiada siapa konfigurasikan untuk perkhidmatan itu. Jadi mulakan dari sambungan dan bergerak ke luar.

Tuliskan kontrak bingkai

Catat kontrak sebelum memilih sebarang konfigurasi: tanpa tag, satu tag perkhidmatan, atau tindanan. Tambah MTU yang akan dihantar pelanggan dan layanan tag yang dijangka dalam setiap arah, kerana itu sifat yang dirundingkan, bukan keutamaan setempat. Nombor unit hanyalah pengecam dan tidak menyatakan apa-apa tentang bingkai yang akan diterima antara muka.

Tuliskan itu dalam nota perkhidmatan, bukan dalam komen tiket. Orang yang akan menyahpepijat ini enam bulan kemudian akan membaca nota. Tiket tidak akan dia baca.

Padankan enkapsulasi dengan kontrak

Perkhidmatan dengan satu tag biasanya menggunakan enkapsulasi litar VLAN seperti vlan-ccc, manakala bingkai tanpa tag memerlukan bentuk litar Ethernet biasa dan tindanan memerlukan varian lanjutan yang memahami dua tag. Pada platform yang menyokong enkapsulasi perkhidmatan setiap unit, satu antara muka fizikal boleh menempatkan beberapa sekali gus, yang praktikal dan juga merupakan cara bingkai berakhir di unit yang salah. Di tempat panduan platform anda meminta family ccc, konfigurasikan itu sebagai sebahagian daripada sambungan lengkap, bukan memasangnya pada antara muka ter-router. Panduan enkapsulasi menyenaraikan jenis sambungan mana yang mengenakan keperluan mana.

Jangan tambah pernyataan family pada setiap antara muka sebagai langkah berjaga-jaga. Konfigurasi yang membuat satu litar berfungsi boleh membuat litar seterusnya menerima bingkai yang pelanggannya tidak pernah hantar.

Ikat sambungan pada perkhidmatan yang betul

VPN lapisan 2 yang diisyaratkan BGP, litar yang diisyaratkan LDP dan perkhidmatan lain yang disokong masing-masing mempunyai konfigurasi ikatan antara muka dan isyarat sendiri, dan semuanya tidak boleh ditukar ganti. Mencampur gaya sambungan yang satu dengan isyarat yang lain menghasilkan litar yang melaporkan rakan sebaya tetapi tidak pernah membawa bingkai.

Bandingkan hujung jauh dengan hujung dekat, bukan menyemak salah satu daripadanya secara berasingan: alamat rakan sebaya, pengecam perkhidmatan, persetujuan enkapsulasi, jangkaan control word dan belanjawan saiz. Lapisan MPLS di bawahnya boleh sepenuhnya sihat sementara sambungannya hilang atau diklasifikasikan di tempat lain, itulah sebabnya ujian yang hanya melihat lapisan bawah tidak membuktikan apa-apa di sini.

Sahkan dengan bingkai, bukan dengan status

Baca pembilang antara muka setempat semasa pelanggan menghantar trafik, kemudian baca status perkhidmatan, kemudian pastikan bingkai yang tiba ialah bingkai yang dipersetujui, termasuk tag-nya. Sambungan yang dibaiki menghantar bingkai itu; perubahan status sahaja tidak membuktikan apa-apa.

Di tempat anda berkuasa menangkap paket, lihat bingkai dalam kedua-dua arah. Asimetri tag mudah terlepas dalam paparan status dan jelas kelihatan dalam tangkapan. Asimetri itu juga menjelaskan aduan yang berjaya dalam satu arah dan gagal dalam arah yang lain.

Kemudian tuliskan

Catat empat nilai dalam nota perkhidmatan: kontrak, enkapsulasi, unit dan ikatan perkhidmatan. Empat itu yang diperlukan jurutera baharu dan yang jarang dinyatakan semakan konfigurasi.

Apabila litar rosak enam bulan kemudian, nota itu ialah perbezaan antara pembaikan seperempat jam dan menerbitkan semula seluruh reka bentuk daripada konfigurasi yang sedang berjalan. Tambah tarikh pengesahan terakhir, supaya nota juga menyatakan berapa usangnya.