Bagaimana cara mencapai routing multi-paket per-paket di Linux?

Kernel Linux sebelum 3.6 menggunakan route caching untuk melakukan routing multath IPv4, yang berarti routing antara dua jalur / ISP terpisah cukup mudah. Dari 3,6 algoritma berubah menjadi per-paket, yang berarti bahwa beberapa trik rute tabel / aturan / iptables diperlukan untuk mencapai dua jalur / ISP.

Namun, jika Anda memiliki dua saluran dengan ISP yang sama yang dapat merutekan IP tunggal ke kedua jalur berdasarkan per-paket secara seimbang / gagal, maka dari 3,6 Anda dapat dengan mudah mencapai ikatan garis (pada tingkat IP) karena per-paket routing di kedua arah.

Dari 4.4, kernel berubah lagi menjadi load balancing berbasis aliran berdasarkan hash atas alamat sumber dan tujuan.

Saat ini saya sedang menjalankan Kernel 4.4.36, dan saya menggunakan routing multipath melalui koneksi PPPoE. Lalu lintas hilir saya dari ISP dirutekan melintasi dua jalur terpisah pada basis per paket (satu IP dialirkan ke kedua saluran). Ini memberi saya kecepatan pengunduhan lebih cepat daripada kecepatan satu saluran individual. Nyaris kecepatan kedua jalur itu disatukan. Ini bekerja dengan sangat baik, video Skype, VoIP (UDP), YouTube dll. Semua berfungsi dengan baik.

Karena memiliki pengalaman hilir yang begitu baik, saya ingin mencobanya di hulu tetapi lalu lintas hulu saya dialihkan sesuai dengan algoritma berbasis aliran yang lebih baru di kedua perangkat ppp (yang memiliki alamat IP yang sama). Ini berarti bahwa saya tidak dapat mencapai kecepatan unggah yang lebih cepat dari kecepatan satu baris.

Apakah ada cara untuk mengkonfigurasi Kernel saat ini untuk menggunakan algoritma per-paket? Atau metode lain untuk mencapai routing multi-paket per-paket? Apakah saya perlu kembali ke Kernel yang lebih lama (yang saya tidak ingin lakukan karena berbagai alasan lain)?

ISP saya tidak mendukung ppp multi-tautan.

Dalam hal ini relevan, saya sedang menjalankan Arch Linux ARMv7 pada Raspberry Pi 3.

— bao7uo
sumber

Ini ide yang sangat buruk. Penyeimbangan per paket di L2 (yaitu MLPPP) mencakup logika yang cukup untuk menyusun kembali paket-paket yang dipesan. Menjalankan ini melalui IP meninggalkan peluang besar (jika bukan hampir pasti) untuk pengiriman out-of-order. Ini akan menyebabkan sejumlah besar masalah dengan sesi TCP lambat, sama sekali UDP rusak, masalah dengan segala jenis streaming real-time, dll. Masalah lainnya adalah bahwa bahkan jika Anda mengirim paket round-robin ke ISP Anda ada sama sekali tidak ada saran bahwa mereka juga akan menyeimbangkan Anda.

— rnxrx

@rnxrx terima kasih atas komentar Anda - telah mengedit pertanyaan untuk memberikan detail tambahan. Dari pertanyaan saya: "lalu lintas hilir dari ISP dialihkan melintasi dua jalur terpisah pada basis per paket". ISP menyediakan panel kontrol - ketika saya memilih satu IP untuk dialihkan melalui kedua jalur maka mereka merutekannya dengan round-robin dengan sempurna berdasarkan per paket. Berfungsi dengan baik, sekitar 90% dari total kecepatan kedua saluran yang ditambahkan bersamaan, dan memberikan failover instan. Video Skype, panggilan VOIP, YouTube, streaming BBC dll. Semua hebat - Pengalaman hilir yang hebat membuat saya ingin mencoba upstream

— bao7uo

Ahh - mengerti ... Jadi saat ini apakah Anda memiliki dua IP unik (satu per koneksi) atau apakah mereka merutekan ke IP tunggal (atau subnet) di sisi Anda melalui dua jalur paralel? Jika Anda menjalankan jenis NAT apa pun, sangat penting bahwa itu terjadi sebelum penyeimbangan ini. Bagaimanapun - apakah Anda sudah melihat support.aa.net.uk/… ? Ia menggunakan ekstensi iptables pada dasarnya untuk mencapai apa yang Anda uraikan dan karenanya harus cukup konsisten di seluruh versi kernel yang cukup modern.

— rnxrx

Terima kasih @ rnxrx - ya saya bisa melakukan salah satu opsi (dua IP unik atau satu IP melalui jalur paralel). Saya lebih suka opsi IP tunggal karena tampaknya lebih masuk akal.

— bao7uo

Ok, jadi setelah memiliki lebih banyak waktu untuk menyelidiki ini, saya menemukan cara untuk melakukannya menggunakan Linux TEQL (True Link Equalizer). Berikut ini tautan yang saya ikuti dengan longgar, tetapi dengan beberapa penyesuaian.

http://lartc.org/howto/lartc.loadshare.html

Ini adalah bagaimana saya membuatnya bekerja di Arch Linux ARMv7 (Raspberry Pi 3)

Saat boot:

Perintah berikut harus dijalankan saat boot untuk memuat modul Kernel yang sesuai.

modprobe sch_teql

Perintah-perintah berikut juga untuk dijalankan pada boot dengan asumsi Anda ingin NAT dari jaringan lokal di eth0.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

Lalu lintas pengembalian FORWARD adalah pada ppp +, dan MASTERER POSTROUTING pada teql + karena lalu lintas keluar padu pada teql dan lalu lintas kembali kembali pada ppp.

Saat tautan ppp muncul:

Dengan asumsi tautan yang akan di-load-load adalah ppp, perintah berikut untuk dijalankan dalam sebuah skrip dalam sebuah /etc/ppp/ip-up.d/skrip.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

Di mana 1.1.1.1alamat IP publik ISP Anda menghadap. IP publik tambahan dapat ditugaskan ke perangkat teql0, tetapi tidak perlu ditugaskan ke perangkat ppp. Dalam pengaturan saya, dua tautan ppp berbagi IP yang sama (dinegosiasikan oleh pppoe, dll.) Tautan teql yang ditetapkan secara manual seperti ditunjukkan di atas. ISP perlu mengirim lalu lintas untuk IP secara merata di kedua tautan.

Jalur balik ( rp_filter) diatur ke 2(longgar) baik dalam skrip di atas sehingga paket kembali tidak jatuh karena mereka kembali pada antarmuka ppp daripada teql0.

Saya telah mengaturnya seperti itu, dan berfungsi dengan baik. Sangat mudah! Saat tautan gagal, ada failover mulus. Ketika mereka datang, mereka baru saja mulai bekerja lagi. Sepertinya tidak ada paket yang hilang atau tertunda saat gagal, dan tidak ada yang muncul kembali.

Juga, salah satu komentator menyarankan tautan di bawah ini yang menggunakan perutean kebijakan, dengan iptables untuk menandai setiap paket lainnya, dll. Tetapi saya akan mencoba dalam beberapa hari untuk melihat apakah itu berfungsi lebih baik daripada yang di atas dan memberikan umpan balik di sini sesuai.

http://support.aa.net.uk/Router_-_Linux_upload_bonding_using_policy_routing

— bao7uo
sumber

Saya tidak pernah mencoba perutean kebijakan karena TEQL bekerja dengan sangat baik. Jika tidak rusak ....

— bao7uo

Saya mencoba untuk membuatnya bekerja. Saya memiliki ikatan yang berfungsi, saya dapat menggunakan antarmuka terikat dari router. Saya tidak bisa mendapatkan NAT bekerja, lalu lintas dari LAN saya tidak turun tautan terikat :(

— andynormancx

jika Anda memposting pertanyaan baru tentang kesalahan server, dan menautkannya dari komentar saya akan mencoba mencari jawabannya. sertakan sebanyak mungkin info seperti konfigurasi antarmuka / ip, tabel perutean, aturan iptables, dll. kecuali Anda dapat memasukkan semua info di komentar?

— bao7uo

PS. hanya melihat kesalahan dalam konfigurasi saya. katanya sysctl -w net.ipv4.ip_forwardtetapi harus mengatakan sysctl -w net.ipv4.ip_forward=1demikian saya telah diperbaiki di atas. Itu pasti akan mencegah lalu lintas dari LAN turun tautan berikat.

— bao7uo

Saya tidak berpikir itu yang menghentikannya bekerja untuk saya, saya telah mengaktifkan forwarding di sysctl. Saya sekarang mencoba mencari tahu apakah jumlah besar paket tidak sesuai yang saya lihat diharapkan.

— andynormancx