Apa yang terjadi ketika cache ARP meluap?

Dalam setidaknya satu implementasi ada batasan keras pada kapasitas tabel ARP. Apa yang terjadi ketika cache ARP penuh dan paket ditawarkan dengan tujuan (atau next-hop) yang tidak di-cache? Apa yang terjadi di bawah tenda, dan apa pengaruhnya terhadap kualitas layanan?

Sebagai contoh, router Brocade NetIron XMR dan Brocade MLX memiliki maksimum sistem yang dapat dikonfigurasiip-arp . Nilai default dalam kasus itu adalah 8192; ukuran subnet / 19. Tidak jelas dari dokumentasi apakah ini per antarmuka atau untuk seluruh router, tetapi untuk tujuan pertanyaan ini, kita dapat berasumsi itu adalah per antarmuka.

Beberapa networkers akan mengkonfigurasi / 19 subnet pada suatu antarmuka dengan sengaja, tetapi bukan itu yang terjadi. Kami memigrasikan router inti dari model Cisco ke Brocade. Salah satu dari banyak perbedaan antara Cisco dan Brocade adalah bahwa Cisco menerima rute statis yang didefinisikan dengan antarmuka outbound dan alamat next-hop, tetapi Brocade bersikeras pada satu atau yang lain. Kami menjatuhkan alamat next-hop dan menjaga antarmuka. Kemudian, kami mempelajari kesalahan dari cara kami, dan berubah dari antarmuka ke alamat next-hop, tetapi semuanya tampaknya bekerja pada awalnya.

+----+ iface0    +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1       .2+----+
      10.0.0.0/30

Sebelum migrasi, R1 adalah Cisco, dan memiliki rute berikut.

ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2

Setelah migrasi, R1 adalah Brocade, dan memiliki rute berikut.

ip route 10.1.0.0 255.255.0.0 iface0

R2 adalah router Cisco, dan router Cisco melakukan proxy ARP secara default. Ini adalah konfigurasi (salah-) dalam produksi yang mengatur tahap untuk apa yang ternyata menjadi overflow cache ARP.

1. R1 menerima paket yang ditujukan untuk jaringan 10.1.0.0/16.
2. Atas dasar rute antarmuka statis, ARP R1 untuk tujuan aktif iface0
3. R2 mengakui bahwa ia dapat mencapai tujuan, dan merespons ARP dengan MAC-nya sendiri.
4. R1 cache hasil ARP yang menggabungkan IP di jaringan jauh dengan MAC R2.

Ini terjadi untuk setiap tujuan berbeda di 10.1.0.0/16. Akibatnya, meskipun / 16 sub-netted benar melampaui R2, dan hanya ada dua node pada tautan yang berdekatan R1 dan R2, R1 menderita kelebihan cache ARP karena menginduksi R2 untuk berperilaku seolah-olah semua alamat 65k terhubung langsung.

Alasan saya mengajukan pertanyaan ini adalah karena saya berharap ini akan membantu saya memahami laporan masalah layanan jaringan (beberapa hari kemudian) yang akhirnya membawa kami ke cache ARP yang meluap. Dalam semangat model StackExchange, saya mencoba menyaring bahwa apa yang saya yakini adalah pertanyaan yang spesifik dan tajam yang dapat dijawab secara objektif.

EDIT 1 Agar lebih jelas, saya bertanya tentang bagian dari lapisan lem antara tautan data (lapisan 2) dan jaringan (lapisan 3), bukan tabel penerusan MAC dalam lapisan tautan data. Host atau router membuat yang pertama untuk memetakan alamat IP ke alamat MAC, sementara sebuah switch membangun yang terakhir untuk memetakan alamat MAC ke port.

EDIT 2 Sementara saya menghargai upaya yang telah dijawab oleh responden untuk menjelaskan mengapa beberapa implementasi tidak terkena ARP cache overflow, saya merasa bahwa penting bagi pertanyaan ini untuk membahas yang ada. Pertanyaannya adalah "apa yang terjadi ketika", bukan "apakah vendor X rentan terhadap". Saya telah melakukan bagian saya sekarang dengan menggambarkan contoh nyata.

EDIT 3 Pertanyaan lain yang bukan ini adalah "bagaimana cara mencegah cache ARP meluap?"

Edit 2 :

Seperti yang Anda sebutkan ...

ip route 10.1.0.0 255.255.0.0 iface0

Memaksa Brocade ke proxy-arp untuk setiap tujuan di 10.1.0.0/16 seolah terhubung langsung ke iface0.

Saya tidak bisa menanggapi tentang implementasi cache ARP Brocade, tetapi saya hanya akan menunjukkan solusi mudah untuk masalah Anda ... konfigurasikan rute Anda secara berbeda:

ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP

Dengan melakukan ini, Anda mencegah Brocade dari ARP untuk semua 10.1.0.0/16 (catatan, Anda mungkin perlu memberi nomor baru tautan antara R1 dan R2 berada di luar 10.1.0.0/16, tergantung pada implementasi hal-hal yang dilakukan Brocade) .

Jawaban asli :

Saya berharap bahwa di sebagian besar, atau bahkan semua, implementasi, ada batas keras pada kapasitas tabel ARP.

Router Cisco IOS CPU hanya dibatasi oleh jumlah DRAM di router, tetapi itu biasanya tidak akan menjadi faktor pembatas. Beberapa sakelar (seperti Catalyst 6500) memiliki batasan keras pada tabel adjacency (yang berkorelasi dengan tabel ARP); Sup2T memiliki 1 Juta adjacencies .

Jadi, apa yang terjadi ketika cache ARP penuh dan paket ditawarkan dengan tujuan (atau next-hop) yang tidak di-cache?

Router Cisco IOS CPU tidak kehabisan ruang dalam tabel ARP, karena ARP tersebut disimpan dalam DRAM. Mari kita asumsikan Anda sedang berbicara tentang Sup2T. Anggap saja seperti ini, misalkan Anda memiliki Cat6500 + Sup2T dan Anda mengkonfigurasi semua Vans mungkin, secara teknis itu adalah

4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans

Asumsikan Anda membuat setiap Vlan a / 24 (jadi itu 252 ARP yang mungkin), dan Anda mengemas setiap Vlan penuh ... itu adalah 1 Juta entri ARP.

4094 * 252 = 1,030,680 ARP Entries

Setiap ARP akan mengkonsumsi sejumlah memori dalam tabel ARP itu sendiri, ditambah tabel kedekatan IOS. Saya tidak tahu apa itu, tapi katakanlah total overhead ARP adalah 10 Bytes ...

Itu berarti Anda sekarang telah mengkonsumsi 10MB untuk overhead ARP; masih tidak terlalu banyak ruang ... jika Anda memiliki memori yang rendah, Anda akan melihat sesuatu seperti %SYS-2-MALLOCFAIL.

Dengan banyak ARP dan waktu ARP empat jam, Anda harus melayani hampir 70 ARP per detik rata-rata; itu lebih mungkin bahwa pemeliharaan pada 1 juta entri ARP akan menguras CPU router (berpotensi pesan CPUHOG).

Pada titik ini, Anda dapat mulai memantul kedekatan protokol routing dan memiliki IP yang tidak dapat dijangkau karena CPU router terlalu sibuk untuk ARP untuk IP.

Hanya pengalaman sebenarnya yang saya alami dengan kejadian ini adalah pada switch C3550 (batas MAC 2-8k, tergantung pada template sdm) dan di sana menjatuhkan entri tertua dari tabel.

Untuk iOS dan JunOS dan tumpukan komersial lainnya yang harus Anda uji, untungnya tidak terlalu sulit.

Tetapi untuk linux , freebsd, netbsd, openbsd, uIP, lwIP dan mungkin banyak implementasi lainnya Anda cukup memeriksa kode sumbernya untuk mengetahui perilaku.

Di Linux Anda perlu memeriksa 'net / core / neighbour.c' (mulai dengan baris 'if (entri> = tbl-> gc_thresh3' || ') dan' net / ipv4 / arp.c '.
Di Linux Anda tampaknya memiliki tiga level penuh

1. gc_thresh1 - tidak ada yang dilakukan sampai ini tercapai
2. gc_thresh2 - ini dapat dipukul sesaat
3. gc_thresh3 - ukuran ini tidak dapat dilampaui

Ketika gc_thresh3 mencoba melebihi, ia mencoba untuk memaksa pengumpulan pengumpulan sampah, kecuali jika sudah dijalankan baru-baru ini. Pengumpulan sampah tampaknya menghapus entri yang tidak dirujuk lagi, jadi tidak berarti terlama atau terbaru, namun gc_staletime yang melebihi tampaknya merupakan salah satu cara entri dereferencing, yang sekali lagi diterjemahkan menjadi entri terlama.
Jika pengumpulan sampah tidak dapat dijalankan, entri baru tidak ditambahkan. Semua interval pengumpulan gc_threshN dan sampah berkala ini dapat disetel.
Kode ini adalah keluarga alamat (ipv4, ipv6) agnostik, sehingga tabel IPv6 ND dan IPv4 ARP ditangani oleh jalur kode yang sama, bukan jalur duplikat.

Itu akan arp untuk menyimpan alamat IP dalam tabel dan tergantung pada implementasi harus menghapus entri tertua. Dampak terhadap kinerja tergantung, jika ini merupakan kejadian yang tidak biasa, tidak banyak dampak, tetapi ini adalah vektor serangan sehingga seseorang dapat mengirim banyak arps yang memengaruhi penggunaan prosesor.

Switch akan ke ARP untuk IP tujuan itu untuk mendapatkan alamat MAC-nya (yang juga akan mengisi tabel CAM dengan respons). Permintaan ARP disiarkan ke semua port. Ini membutuhkan CPU dan melibatkan ARP Inputproses. Jika permintaan ARP adalah untuk IP yang sama, karena tabel ARP sering meluap, saklar harus memberi peringkat-batas pada ARP setiap dua detik. Jika permintaan untuk IP acak cukup sering, CPU dapat melonjak karena CPU terlibat dalam permintaan dan respons ARP.

Dari serangan yang saya pelajari pada switch Cisco 3550, 3560 dll. Anda dapat mengubahnya menjadi hub raksasa setelah Anda membebani batas alamat MAC. Switch memiliki batas yang ditetapkan dari alamat MAC (sekitar 6000) yang dapat disimpan, dan sekali batas itu tercapai akan membanjiri semua data dari interface-nya. Tidak ingat apakah itu berlaku untuk paket 802.1q karena saya tidak harus melakukannya dalam waktu yang lama. Mungkin harus menjalankan lab jaringan saya di rumah untuk mengetahuinya.