Jak osiągnąć routing wielościeżkowy dla pakietu w systemie Linux?

9

Jądro Linux w wersji wcześniejszej niż 3.6 używało buforowania tras do rutowania IPv4 wielościeżkowego, co oznaczało, że routing między dwiema oddzielnymi liniami / dostawcami usług internetowych był dość łatwy. Od wersji 3.6 algorytm zmienił się na pakiet na pakiet, co oznacza, że ​​niektóre triki znaczników tabeli / reguły / iptables były wymagane do uzyskania dwóch linii / dostawców usług internetowych.

Jeśli jednak masz dwie linie z tym samym usługodawcą internetowym, który może przekierować pojedynczy adres IP w dół obu linii na zasadzie na pakiet w sposób zrównoważony / awaryjny, to od wersji 3.6 można łatwo osiągnąć łączenie linii (na poziomie adresu IP) z powodu routing na pakiet w obu kierunkach.

Z 4.4 jądro ponownie zmieniło się na równoważenie obciążenia oparte na przepływie oparte na haszowaniu adresów źródłowych i docelowych.

Obecnie korzystam z jądra 4.4.36 i używam routingu wielościeżkowego przez połączenia PPPoE. Mój dalszy ruch z ISP jest kierowany przez dwie oddzielne linie na podstawie pakietu (jeden adres IP kierowany w obie linie). Daje mi to prędkość pobierania większą niż prędkość jednej linii. Prawie prędkość obu linii zsumowanych. Działa naprawdę dobrze, wideo Skype, VoIP (UDP), YouTube itp. Wszystko działa świetnie.

Ze względu na tak dobre doświadczenie pobierania danych, chcę wypróbować go wcześniej, ale mój ruch pobierania danych jest kierowany zgodnie z nowszym algorytmem opartym na przepływie na obu urządzeniach ppp (które mają ten sam adres IP). Oznacza to, że nie mogę osiągnąć prędkości wysyłania większej niż prędkość pojedynczej linii.

Czy istnieje sposób skonfigurowania bieżącego jądra do korzystania z algorytmu dla pakietu? A może jakaś inna metoda osiągnięcia routingu wielościeżkowego na pakiet? Czy musiałbym powrócić do starszego jądra (czego nie chcę robić z różnych innych powodów)?

Mój ISP nie obsługuje wielu łączy ppp.

W razie potrzeby korzystam obecnie z Arch Linux ARMv7 na Raspberry Pi 3.

bao7uo
źródło
3
To bardzo zły pomysł. Równoważenie pakietów na poziomie L2 (tj. MLPPP) obejmuje logikę wystarczającą do ponownego złożenia pakietów w kolejności. Uruchomienie tego adresu IP pozostawia ogromną szansę (jeśli nie jest prawie pewną) na dostawę poza kolejnością. Spowoduje to powstanie ogromnej liczby problemów z wolnymi sesjami TCP, całkowicie zepsutym UDP, problemami z wszelkiego rodzaju strumieniowaniem w czasie rzeczywistym itp. Innym problemem jest to, że nawet jeśli wysyłasz pakiety okrężne do ISP, absolutnie nie ma sugestii, że będą się do ciebie balansować podobnie.
rnxrx
@rnxrx dzięki za komentarz - zredagowałem pytanie, aby podać dodatkowe szczegóły. Z mojego pytania: „dalszy ruch z ISP jest kierowany przez dwie osobne linie na podstawie pakietu”. ISP zapewnia panel sterowania - kiedy wybieram jeden adres IP, który ma być kierowany przez obie linie, to kierują go idealnie zbalansowanym round-robinem na zasadzie na pakiet. Działa dobrze, przy około 90% sumy prędkości obu linii dodanych razem i zapewnia natychmiastowe przełączanie awaryjne. Wideo na Skype, połączenia VOIP, YouTube, streaming BBC itp. Świetnie - tak wspaniałe doświadczenie downstream sprawia, że ​​chcę spróbować upstream
bao7uo 12.12.2016
1
Ahh - rozumiem ... Czy w tej chwili masz dwa unikalne adresy IP (jeden na połączenie), czy są one routowane do jednego adresu IP (lub podsieci) po twojej stronie przez dwie równoległe ścieżki? Jeśli korzystasz z NAT, to oczywiście ważne jest, aby wystąpiło to przed tym równoważeniem. W każdym razie - czy rzuciłeś okiem na support.aa.net.uk/… ? Korzysta z rozszerzeń iptables, aby osiągnąć zasadniczo to, co opisujesz, i jako takie powinno być dość spójne we względnie nowoczesnych wersjach jądra.
rnxrx
Dzięki @rnxrx - tak, mogę wykonać dowolną opcję (dwa unikalne adresy IP lub jeden adres IP za pośrednictwem równoległych ścieżek). Wolałem opcję pojedynczego adresu IP, ponieważ wydawało się to mieć większy sens.
bao7uo

Odpowiedzi:

3

Ok, więc po tym, jak miałem więcej czasu, aby to zbadać, znalazłem sposób na zrobienie tego przy użyciu Linux TEQL (True Link Equalizer). Oto link, który swobodnie śledziłem, ale z pewnymi poprawkami.

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

Tak to działa na Arch Linux ARMv7 (Raspberry Pi 3)

Podczas uruchamiania:

Następujące polecenie powinno zostać uruchomione podczas rozruchu, aby załadować odpowiedni moduł jądra.

modprobe sch_teql

Następujące polecenia również działają przy rozruchu, zakładając, że chcesz NAT z sieci lokalnej na 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

Ruch powrotny FORWARD odbywa się na ppp +, a POSTROUTING MASQUERADE na teql +, ponieważ ruch wychodzący jest wyłączany na teql, a ruch powrotny wraca na ppp.

Gdy pojawią się linki ppp:

Zakładając, że łączami, które mają być równoważone obciążeniem, są ppp, następujące polecenia należy uruchamiać w skrypcie w /etc/ppp/ip-up.d/skrypcie.

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

Gdzie 1.1.1.1jest twój publiczny adres IP skierowany do dostawcy usług internetowych? Dodatkowe publiczne adresy IP można przypisać do urządzenia teql0, ale nie trzeba ich przypisywać do urządzeń ppp. W moim ustawieniu dwa łącza ppp dzielą ten sam adres IP (negocjowany przez pppoe itp.) Łącze teql przypisane ręcznie, jak pokazano powyżej. Dostawca usług internetowych musi przesyłać ruch IP w równym stopniu w dół obu łączy.

Odwrotna ścieżka ( rp_filter) jest ustawiona na 2(luźną) zarówno w powyższym skrypcie, aby pakiety zwrotne nie były odrzucane, ponieważ wracają na interfejsach ppp, a nie na teql0.

Ustawiłem to w ten sposób i działa idealnie. Bardzo łatwe! Gdy łącza zawodzą, następuje płynne przełączanie awaryjne. Kiedy się pojawią, znów zaczynają działać. Wygląda na to, że nie ma utraty lub opóźnienia pakietu, gdy nastąpi przełączenie awaryjne, ani żadnego, gdy nastąpi powrót.

Ponadto jeden z komentujących zasugerował poniższy link, który używa routingu zasad, z iptables do oznaczania każdego innego pakietu itp., Ale postaram się za kilka dni sprawdzić, czy działa on lepiej niż powyższy i odpowiednio przekazać tutaj opinię.

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

bao7uo
źródło
Nigdy nie próbowałem routingu zasad, ponieważ TEQL działał tak dobrze. Jeśli to się nie zepsuło ...
bao7uo,
Staram się, żeby to zadziałało. Mam działające wiązanie, mogę użyć powiązanego interfejsu z routera. Nie mogę jednak uruchomić NAT, ruch z mojej sieci LAN nie spada w połączonym łączu :(
andynormancx
jeśli opublikujesz nowe pytanie na temat błędu serwera i link do niego z komentarza, postaram się go znaleźć. zawierać jak najwięcej informacji, takich jak konfiguracja interfejsu / adresu IP, tabela routingu, reguły iptables itp., chyba że zmieścisz wszystkie informacje tutaj w komentarzach?
bao7uo
1
PS. właśnie zauważyłem błąd w mojej konfiguracji. powiedział, sysctl -w net.ipv4.ip_forwardale powinienem powiedzieć sysctl -w net.ipv4.ip_forward=1, że poprawiłem powyżej. To z pewnością zapobiegłoby ruchowi z sieci LAN w dół połączonego łącza.
bao7uo
Nie sądzę, że to właśnie przestało działać, miałem włączone przekazywanie w sysctl. Próbuję teraz ustalić, czy spodziewana jest olbrzymia liczba pakietów poza kolejnością.
andynormancx