/ 31 Bitmap point-to-point


13

Kapan tepat menggunakan jaringan / 31 dalam produksi , dan menggunakannya sebagai praktik yang baik? Pada tautan point-to-point, siaran seharusnya tidak diperlukan, jadi apakah ada kasus yang memaksa untuk hanya menggunakan / 31 over / 30 karena tampaknya / 30s masih banyak digunakan dan lazim. Ini telah ditentukan oleh RFC 3021 .

Apakah ada kasus penggunaan untuk menggunakan / 31 selain untuk menghemat ruang alamat? Apakah pengenalan / 31s membawa set baru kekhawatiran yang tidak ditemukan di / 30s?

Apakah / 31 umumnya hanya terlihat di ruang publik, terutama untuk ISP, atau apakah mereka biasa digunakan di ruang pribadi juga untuk ISP dan Perusahaan?


2
Memilih untuk menutup karena ini tampaknya bukan pertanyaan yang sebenarnya, tetapi lebih banyak membuat forum untuk diskusi (sesuatu yang ingin kita hindari). Saya telah melihat mereka menggunakan sedikit dalam produksi - apakah mereka berfungsi sebagaimana mestinya hingga implementasi vendor.
John Jensen

@JohnJensen izinkan saya ulangi ungkapan ini ....
knotseh

Saya pikir pertanyaannya di sini adalah: "kapan pengaturan ini digunakan?"
Bulki

2
@ Mike-Pennington Saya harus tidak setuju dengan Anda mengenai hal ini (dengan hormat ofc). Saya dapat memahami masalah dengan alamat / 31 pada tingkat teoretis. Karena Anda tidak memiliki bagian-alamat yang hanya merupakan alamat dan bukan bagian siaran atau subnet. Namun ini dapat digunakan ketika Anda menggunakan perutean yang tepat ke jaringan ini, dll, atau point-to-point. Pertanyaan "mengapa itu mungkin" atau "kapan itu digunakan" adalah pertanyaan yang bagus.
Bulki

1
Hanya untuk dicatat di sini Mikrotik tidak mendukung / 31 atau / 127. Dan mereka tidak punya niat untuk memperbaikinya.
sdaffa23fdsf

Jawaban:


11

Kami telah menggunakan / 31s dalam inti kami (Brocade, Juniper, Cisco) selama lebih dari tiga tahun tanpa masalah apa pun.

Ini adalah jaringan ISP produksi, dan karenanya tepat untuk menggunakannya dalam lingkungan produksi selama kit Anda mendukungnya, dan Anda telah mengujinya


Tidak benar-benar menjawab pertanyaan, bukan, "kami telah menggunakan ini"
jwbensley

Sangat tepat untuk menggunakannya kapan pun Anda mau, karena tidak menyebabkan masalah apa pun dalam jaringan produksi
mellowd

Jadi masukkan itu dalam jawaban Anda :)
jwbensley

6

Seperti yang telah dikatakan di tempat lain, menggunakan / 31 bit mask dapat bekerja dan merupakan cara yang baik untuk menghemat ruang alamat yang tersedia.

Apa yang mungkin lebih banyak impor adalah dalam keadaan apa Anda tidak bisa menggunakan / 31s? Protokol atau aplikasi apa yang dapat bertingkah atau rusak akibat tidak memiliki alamat penyiaran ?

BootP dan DHCP berada di bagian atas daftar sesuai dengan artikel sebelumnya, tetapi kami tidak khawatir dengan yang ada di tautan point-to-point router. ARP menggunakan alamat MAC broadcast - bukan IP - jadi seharusnya tidak ada masalah di sana ... OSPF & EIGRP keduanya menggunakan alamat multicast, RIP v1 sepertinya bisa menjadi masalah.

Apa lagi yang tergantung pada siaran atau alamat jaringan?


IMHO ini pertanyaan, bukan jawaban.
CVn

1
Sepakat. Pertanyaan aslinya tidak diucapkan dengan baik dan pertanyaan itu sebenarnya ditutup dengan suara. Sudah kata-kata dan dibuka kembali sejak posting ini awalnya dibuat. (Semoga itu berkontribusi pada peningkatan pertanyaan.)
Peter

5

Saya telah menggunakannya secara internal di lab yang menjalankan EIGRP sebentar dan belum menemukan masalah sejauh ini.

Cara saya melihatnya jika / 24 dialokasikan untuk rentang P2P.

  1. / 30 bitmask = 64 tautan P2P
  2. / 31 bitmask = 128 tautan P2P

/ 23 alokasi

  1. / 30 bitmask = 128 tautan P2P
  2. / 31 bitmask = 256 tautan P2P

Baiklah, saya tidak akan membuat orang bosan dengan subnet matematika dan kekuatan dua. Tapi karena kita berada dalam mode kelelahan IPv4, ini memungkinkan kita untuk lebih memanfaatkan tugas subnet yang diberikan.

Juga, dalam P2P saya tidak melihat alasan mengapa kita memerlukan alamat broadcast. Hanya ada dua host di jaringan ini. Oleh karena itu, setiap paket yang ditujukan untuk siaran akan didengar oleh tuan rumah lainnya.

BTW, router Cisco telah mendukung fitur ini sejak IOS 12.2 (2) T


jadi Anda bertanya dan 8 menit kemudian menjawabnya sendiri ... sepertinya agak aneh sekarang bukan? Bagaimanapun, satu-satunya implementasi dari a / 31 menurut saya digunakan pada firewall di mana hanya 2 alamat WAN diperlukan (dan NAT akan melakukan sisanya).
Bulki

@Bulki setuju itu aneh - diposting ini sebelum memodifikasi pertanyaan karena saya sedang mencari lebih banyak struktur forum / debat yang saya tidak menyadari kami menghindari.
knotseh

1
Saya tidak berpikir pertanyaan ini cocok karena sangat subyektif. Adalah umum untuk menggunakan / 31, setidaknya pada ISP. Tidak ada alasan untuk tidak melakukannya karena vendor besar telah mendukungnya sejak lama.
Daniel Dib

Ini cukup terbuka, tetapi dibentuk sebagai pertanyaan harus bermanfaat. Mungkin pertanyaan harus 'adakah alasan untuk tidak selalu menjalankan / 31 dan / 127 pada tautan point-to-point' maka kita bisa mendapatkan data menarik tentang vendor di mana ini tidak bekerja atau motivasi lain untuk tidak menjalankannya (saya bisa memikirkan of one for / 127)
ytti

7
@bulki Tidak ada yang salah dengan memposting pertanyaan dan kemudian menjawab pertanyaannya sendiri. Ini sangat dianjurkan. meta.networkengineering.stackexchange.com/questions/4/…
Craig Constantine

2

Mengingat kehati-hatian dan pentingnya menangani konservasi, pendekatan umum untuk menggunakan / 31 harus "jika berhasil, gunakan" .

Tentu saja, Anda dapat mengambil langkah ini lebih jauh dan mulai menggunakan ruang pribadi untuk tautan point-to-point Anda, tetapi ini jelas bisa menjadi masalah jika Anda akan menjalankan pelacakan dari internet, bukan dari jaringan Anda sendiri, meskipun bahkan itu dapat dikurangi sedikit dengan mengkonfigurasi router Anda untuk mengeluarkan kesalahan ICMP dengan alamat IP sumber tertentu.

Singkatnya, lakukan apa pun yang Anda bisa untuk membuang alamat sesedikit mungkin (dalam batas praktik terbaik dan kelayakan, jangan mulai melemparkan konsentrator NAT ke mana-mana)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.