Linux TC kelas / penomoran filter

Saat ini saya sedang mengerjakan solusi pembentukan lalu lintas untuk perusahaan tingkat ISP, dan sampai pada masalah (jenis filosofis) yang menarik.

Melihat jumlah titik akhir yang harus ditangani oleh sistem (yaitu sekitar ~ 20k), saya sedikit khawatir apa yang akan terjadi ketika saya perlu membuat kebijakan / membentuk lalu lintas lebih banyak pengguna. Karena saya saat ini menggunakan HFSC shaping tree (lihat tc-hfsc, kebanyakan hal yang sama tapi lebih keren dari HTB yang lebih dikenal) untuk seluruh jaringan, saya harus menggunakan lebih banyak ClassIDs (jelas setidaknya satu untuk setiap pengguna pada jaringan). Masalah yang saya temukan adalah bahwa TC ClassID's agak terbatas - mereka adalah angka 16-bit, yang memberi saya kemungkinan maksimum 64k pengguna dibentuk oleh solusi ini.

Demikian pula, jika saya ingin mengelola filter TC secara efisien (mis. Tidak menggunakan 'teknik flush all'), saya harus dapat menghapus atau memodifikasi entri filter individual. (Saya menggunakan sesuatu yang mirip dengan tabel hash dari LARTC [1]). Sekali lagi, satu-satunya metode yang tampaknya berhasil adalah menghitung semua filter menggunakan prioritas individual (tc filter add dev ... prio 1). Tidak ada parameter lain yang dapat digunakan untuk tujuan ini, dan, sayangnya, prio hanya 16-bit-saja.

Pertanyaan saya adalah sebagai berikut: Apakah ada beberapa metode yang baik untuk memperbesar "ruang pengenal" yang tersedia, seperti perintah clsid 32-bit untuk 'kelas tc', dan prioritas 32-bit (atau pegangan modifikasi lainnya) untuk 'filter tc' perintah?

Terima kasih banyak,

-mk

(btw saya harap ini tidak akan masuk ke skenario "64k pengguna harus cukup untuk semua orang" ...)

— exa
sumber

Semua nilai tersebut disimpan dalam ruang kernel, untuk membuatnya lebih besar, Anda harus mengkompilasi ulang utilitas kernel dan userspace Anda. Sudahkah Anda mencoba menggunakan kernel 64bit? Mereka dapat didefinisikan sebagai 32bit di sana.

— Hubert Kario

Kernel 64bit menggunakan ukuran yang sama. Sebagai contoh, nomor filter adalah integer u32 yang terdiri atas (protokol) dan bagian bawah (prio) keduanya jelas 16bit. ID kelas hardcoded sebagai u16. Mungkin akan mencoba bertanya pada seseorang di LKML.

— exa

bahkan menggunakan hash untuk filter Anda, Anda akan memiliki banyak masalah IO jika Anda menggunakan banyak filter (saya kira untuk hulu dan untuk hilir). Saya telah menghabiskan banyak waktu dan harus menambal implementasi antrian di dalam kernel agar semuanya berjalan dengan baik dengan Anda ksoftirqd. Saya menggunakan patch dari seorang pria bernama Simon Lodal yang saya temui di LARTC 4 tahun yang lalu. Lihatlah tambalannya mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Anda dapat mencoba mengiriminya email karena ia selalu memiliki versi yang sangat diperbarui (terhadap kernel terakhir) dengannya.

— Pabluez

@ Pabluez Terima kasih banyak, saya akan mencoba untuk mendapatkan yang terbaik dari itu.

— mis.

Saya pikir persyaratan Anda valid tetapi seperti yang ditulis Pabluez ini tentu saja melibatkan banyak perubahan kernel. Saya tidak ingin mengatakan "Anda salah melakukannya", tetapi saya akan mendorong Anda untuk memeriksa openflow, di mana bagian bawah dari penanganan paket dilakukan pada level switch dan pemolisian dilakukan dalam perangkat lunak khusus, mungkin berjalan di ruang pengguna. Saya tidak tahu apakah itu sesuai dengan kebutuhan Anda, tetapi tentu perlu diselidiki.

— AndreasM

Jawaban:

saya pikir Anda tidak boleh menempatkan pengguna 64k dengan kelas hulu dan hilir dan filter untuk masing-masing dari mereka pada antarmuka yang sama. Anda dapat mengulangi penangan untuk setiap antarmuka yang Anda miliki, jadi tambahkan lebih banyak antarmuka. Anda akan membutuhkan pekerjaan / server / NIC yang luar biasa untuk memiliki hal-hal ini. Jika server macet, Anda akan memiliki 64 ribu pengguna offline (dan itu akan macet dengan mudah dengan jumlah lalu lintas itu). Jangan lupa bahwa paket SETIAP yang melewati kartu jaringan Anda akan diperiksa dan diklasifikasikan oleh filter dan dikirim ke kelas yang akan diantrekan. Ini banyak pekerjaan untuk NIC gateway ISP dengan pelanggan 64k. Terutama dengan semua aliran video yang kita miliki saat ini (yang sulit untuk antri dengan benar).

— Pabluez
sumber

Saya memastikan ketersediaan layanan di tingkat lain, tapi terima kasih atas perhatiannya. Sebenarnya, dengan NIC yang bagus, tidak sulit untuk memiliki router linux yang dapat meneruskan 10Gbits.

— exa

Untuk pertanyaan asli, saya lebih tertarik pada hal-hal seperti menambahkan 5 kelas yang berbeda untuk setiap pengguna, yang akan memungkinkan saya untuk melakukan pekerjaan QOS yang sangat baik (seperti menangani streaming dan lalu lintas waktu nyata secara terpisah), tetapi sebagian besar tidak terpikirkan dalam kondisi saat ini (dengan saya kasus penggunaan saat ini ~ 20k titik akhir saya akan sudah di belakang batas).

— mis.

oke, untuk meneruskan 10Gbits tidak ada masalah, masalahnya adalah memiliki banyak 64k * 2 filter dan kelas. Semoga beruntung: D

— Pabluez

Anda dapat membagi penanganan lalu lintas menjadi dua mesin (menggunakan yang ketiga) alih-alih menangani semua lalu lintas pada satu mesin. Lalu lintas dapat dialihkan hanya berdasarkan alamat IP sumber. Jadi, Anda akan memiliki pengguna 10k secara optimal jika Anda dapat membagi rentang IP secara merata.

Tentu saja, Anda dapat menggunakan lebih dari dua mesin jika diperlukan. Saya pikir ini mungkin lebih baik daripada menambal kernel Linux dan melakukan beberapa peretasan lainnya. Singkatnya, traffic shaping akan didistribusikan pada beberapa mesin. Node pusat hanya akan meneruskan lalu lintas ke node pemrosesan yang tepat.

— Khaled
sumber