Jak zapewne wszyscy wiecie, pamięć podręczna tras ipv4 została usunięta z serii jądra Linuxa 3.6, co miało poważny wpływ na routing wielościeżkowy. Kod routingu IPv4 (w przeciwieństwie do IPv6) wybiera następny przeskok w sposób okrągły, więc pakiety od danego źródłowego adresu IP do docelowego adresu IP nie zawsze przechodzą przez ten sam następny skok. Przed wersją 3.6 pamięć podręczna routingu korygowała tę sytuację, ponieważ następny skok, po wybraniu, pozostawał w pamięci podręcznej, a wszystkie kolejne pakiety z tego samego źródła do tego samego miejsca docelowego przechodziły przez ten następny skok. Teraz kolejny przeskok jest ponownie wybierany dla każdego pakietu, co prowadzi do dziwnych rzeczy: przy 2 domyślnych trasach o równych kosztach w tabeli routingu, z których każda wskazuje na jednego dostawcę Internetu, nie mogę nawet nawiązać połączenia TCP, ponieważ początkowa SYN i końcowe ACK iść różnymi drogami,
Czy jest jakiś stosunkowo łatwy sposób przywrócić normalne zachowanie routingu wielościeżkowego, aby następny skok był wybierany dla przepływu, a nie dla pakietu? Czy są jakieś łatki, które sprawiają, że IPv4 opiera się na haszu opartym na hash, tak jak w przypadku IPv6? A jak sobie z tym wszystkim radzicie?
ip ro add 8.8.8.8/32 nexthop via 1.2.3.4 nexthop via 1.2.3.5
czy to prawidłowe założenie?Odpowiedzi:
Jeśli to możliwe, zaktualizuj do jądra Linux> = 4.4 ....
Wprowadzono wielościeżkowe routing oparty na skrócie , który pod wieloma względami jest lepszy niż zachowanie wcześniejsze niż 3.6. Jest oparty na przepływie, biorąc hash źródłowych i docelowych adresów IP (porty są ignorowane), aby utrzymać stałą ścieżkę dla poszczególnych połączeń. Jednym minusem jest to, że uważam, że były różne tryby algorytmów / konfiguracji dostępne przed wersją 3.6, ale teraz dostajesz to, co otrzymałeś! Możesz jednak wpłynąć na wybór ścieżki
weight
.Jeśli jesteś w mojej sytuacji, to tak naprawdę chcesz,
3.6 >= behaviour < 4.4
ale to nie jest już obsługiwane.Jeśli wykonasz aktualizację do> = 4.4, to powinno załatwić sprawę, bez wszystkich innych poleceń:
Alternatywnie według urządzenia:
źródło
„Stosunkowo łatwy” to trudny termin, ale możesz
Nastąpiło dyskusji na liście dyskusyjnej netfilter na ten temat, gdzie jestem kradzież ofert od:
1. Reguły routingu (RPDB i FIB)
2. Reguły zapory (użycie ipset do wymuszenia „przepływu” trybu LB)
Możesz śledzić dyskusję o liście mailingowej netfilter dla niektórych wariantów powyższego.
źródło
u32
uzyskaćip rule
ipset
- po prostu tworzy zestawy, które są wypełniane za pomocą--add-set
i dopasowywane do za pomocą--match-set
- ale dotyczy to głównie połączeń w stanie NOWY. W przypadku połączeń stanu USTANOWIONEGO znak jest wybijany na pakietach za pomocą--restore-mark
parametruCONNMARK
celu - ta dyrektywa kopiuje znak połączenia do pakietu. Znak połączenia jest ustawiony wcześniej używając--save-mark
wPOSTROUTING
łańcuchu (gdzie pakiety należące do nowych połączeń będzie przechodzić przez). Scenariusz wydaje mi się zbyt skomplikowany, ale przekazuje ten pomysł.