L2TPv2, L2TPv3, GRE, dan VPWS: pilih berdasarkan payload

Sebagian besar L2TP versus GRE runtuh karena alasan yang sama: nama-nama itu berada di lapisan masalah yang berbeda. Dua di antaranya menggambarkan enkapsulasi yang Anda konfigurasi di router Anda sendiri. Satu menggambarkan layanan yang dijual orang lain kepada Anda. Mulailah dari payload yang harus dibawa titik akhir, dan perbandingannya menjadi daftar konsekuensi yang singkat, bukan pertarungan fitur.

Payload dulu, protokol kemudian

Dalam praktiknya payload adalah salah satu dari empat hal: sesi PPP, frame Ethernet mentah, paket IP, atau frame MPLS yang diserahkan ke penyedia. Masing-masing menuntut hal berbeda pada pengalamatan, penanganan siaran, dan deteksi kegagalan. Jika daftar ini salah, tidak ada penyetelan enkapsulasi yang bisa menyelamatkan desain.

Apa pun di luar baris ini ditambahkan belakangan, seperti enkripsi, kompresi, atau pembentukan lalu lintas. Pilih barisnya dulu.

L2TPv2 dan L2TPv3 berbagi nama dan hampir tidak ada lagi

L2TPv2 ada untuk membawa sesi PPP melintasi jaringan IP, itulah sebabnya ia terbaca sebagai protokol akses jarak jauh, bukan transport frame umum. L2TPv3 menggeneralisasi gagasan itu: koneksi kontrol menegosiasikan sesi, dan setiap sesi membawa koneksi lapisan 2 tertentu antara dua titik akhir IP. Nama keluarga sama, protokol kontrol berbeda, model sesi berbeda. Persyaratan yang hanya menyebut L2TP tidak lengkap, dan templat yang disalin dari versi yang salah bahkan tidak akan bernegosiasi.

Jika Anda membutuhkan PPP, L2TPv2 adalah satu-satunya anggota keluarga yang realistis; jika Anda membutuhkan frame Ethernet melintasi inti yang dirutekan, Anda berada di wilayah L2TPv3.

Detail transport berbeda dengan cara yang muncul saat tinjauan firewall. L2TPv3 dapat melintas langsung di atas protokol IP 115 atau di dalam UDP, biasanya pada port 1701, sedangkan L2TPv2 tetap di UDP 1701 dengan PPP di dalamnya. Kebijakan yang ditulis untuk satu versi bisa terlihat sepenuhnya benar dan tetap menjatuhkan versi lainnya.

GRE adalah header, bukan layanan

GRE membungkus payload dalam header empat byte dengan bidang kunci dan urutan opsional, lalu menyerahkan hasilnya ke IP untuk pengiriman. Ia tidak mengklaim apa pun tentang makna payload, sehingga implementasi dapat menerowongkan IPv4, IPv6, atau Ethernet jika jenis protokol itu didukung. Umum bukan berarti universal: verifikasi jenis protokol dan perilaku fragmentasi pada perangkat sebenarnya.

Bidang kunci inilah yang membuat GRE berguna ketika beberapa terowongan berbagi satu pasangan alamat titik akhir, karena penerima melakukan demultipleks berdasarkan nilai itu. GRE di atas IPv4 memakan sekitar 24 byte sebelum opsi tambahan apa pun, dan itu mulai berarti pada tautan yang sudah disiapkan untuk frame 1500 byte. Sendirian GRE tidak menawarkan kerahasiaan, jadi pola biasanya memasangkannya dengan IPsec dan membiarkan IPsec memiliki batas kripto. Pemasangan itu berhasil, tetapi anggaran MTU kemudian harus menutupi kedua header.

GRE juga membawa multicast dan siaran melalui terowongan ketika payload-nya Ethernet, yang tidak bisa dilakukan terowongan IP unicast biasa. Sifat itulah, bukan akronimnya, yang biasanya membuat sebuah desain memilihnya.

VPWS dibeli, bukan dikonfigurasi

Layanan kabel privat virtual mengirimkan sirkuit lapisan 2 titik ke titik melintasi jaringan penyedia. Sirkuit sambungan Anda berakhir pada perangkat tepi penyedia, dan pseudowire melintasi inti menjadi milik penyedia. Pertanyaan yang penting bersifat operasional: di mana batas demarkasinya, siapa yang memiliki mil pertama dan terakhir, dan apa yang dilakukan penyedia terhadap frame yang kelebihan ukuran.

Di sinilah perbandingannya berbalik. L2TPv3 dan GRE adalah hal yang Anda jalankan dari ujung ke ujung, jadi Anda men-debug-nya dengan kredensial Anda sendiri dan tangkapan Anda sendiri. VPWS adalah kontrak dengan serah terima, jadi gangguan dimulai dengan tiket, bukan tangkapan paket. Tidak ada model yang menang mutlak; keduanya gagal di tempat berbeda, dan pilihannya bergantung pada apakah Anda ingin memiliki mil terakhir.

Tumpukan label pseudowire tetap berada di dalam jaringan penyedia, jadi tidak mengubah aritmetika MTU Anda seperti header terowongan yang terlihat.

Pilih satu baris dan tuliskan

Catat keputusannya sebagai satu kalimat dengan tiga bagian: payload, enkapsulasi, dan pemilik transport. Lalu lampirkan angka-angka yang membuatnya dapat diperiksa.

Untuk setiap kandidat, tuliskan overhead di kabel, frame terbesar yang diterima jalur, dan hop pertama yang akan melaporkan masalah MTU. Pastikan kedua titik akhir mendukung jenis protokol atau jenis sesi yang Anda pilih, bukan hanya istilah pemasaran di lembar data. Putuskan seperti apa multipleksing jika sirkuit kedua muncul tahun depan, karena kunci GRE dan ID sesi L2TPv3 bukan solusi yang dapat dipertukarkan untuk masalah itu. Lalu kirim satu frame kelebihan ukuran dan satu frame normal; pasangan itu menangkap sebagian besar desain yang tampak baik di atas kertas.

Membandingkan terowongan berdasarkan nama terus menghasilkan perdebatan yang tidak bisa diselesaikan siapa pun. Membandingkannya berdasarkan payload, overhead, dan kepemilikan menghasilkan keputusan dalam satu sore, plus bukti yang dibutuhkan untuk mempertahankannya nanti.