Oversigt #
Denne artikel forklarer, hvordan man identificerer og løser problemer med asymmetrisk routing i en RELIANOID implementering, når load balancer har flere netværksgrænseflader forbundet til forskellige undernet.
Denne situation kan opstå, når frontend-klienter har brug for adgang til backend-tjenester, der er placeret i et andet undernet, mens load balancer har grænseflader i begge netværk.
Forkert routingadfærd kan medføre, at svartrafikken afsluttes via en anden grænseflade end den, der bruges til den indgående anmodning, hvilket resulterer i asymmetrisk routing.
Problem Beskrivelse #
I nogle implementeringer, den RELIANOID Load Balancer er konfigureret med flere grænseflader forbundet til forskellige netværk.
Følgende konfiguration er en eksempelmiljø brugt til demonstrationsformål.
| grænseflade | Netværk | Formål |
| eth0 | 192.168.1.0/24 | Management |
| eth1 | 192.168.110.0/24 | frontend |
| eth2 | 192.168.100.0/24 | Applikation / Backend |
Backend-servere er placeret i 192.168.100.0/24 undernet og tilgås via farms, der er konfigureret på load balancer.
Dog er nogle klienter placeret i 192.168.110.0/24 netværket skal også have adgang til tjenester, der hostes i 192.168.100.0/24 netværk.
Da load balancer har en grænseflade i begge netværk, og IP-videresendelse er aktiv som standard, kan systemet muligvis dirigere svartrafik direkte gennem frontend-grænseflade (eth1) i stedet for at sende den gennem den forventede gateway.
Dette resulterer i asymmetrisk routing, hvilket kan forårsage forbindelsesfejl eller mistede pakker.
Eksempel på grænsefladekonfiguration #
Hvad er asymmetrisk routing #
Asymmetrisk routing opstår, når Indgående og udgående trafik fra den samme forbindelse følger forskellige netværksstier.
Eksempel på flow #
Destinationssti: 192.168.110.11 via eth2 (Klient) > 192.168.100.100 (Load Balancer) > 192.168.100.42 (Backend)
Retursti (forkert): 192.168.100.42 (Backend) > 192.168.100.100 (Load Balancer) > 192.168.110.11 via eth1 (Klient)
Fordi returtrafikken går gennem en anden grænseflade, kan mellemliggende enheder som firewalls eller routere droppe pakkerne.
Sådan fungerer routingtabeller #
RELIANOID bruger routingtabeller pr. grænseflade at styre, hvordan trafik videresendes mellem netværk.
Hver grænseflade genererer automatisk sin egen routingtabel.
Eksempel på routingtabeller: table_eth1, table_eth2
Disse routingtabeller definerer:
- Ruter tilknyttet grænsefladen
- Gateways brugt til videresendelse af trafik
- Grænseflader, der har tilladelse til at dirigere trafik
Inden for hver routingtabel kan grænseflader konfigureres som:
Administrerede grænseflader #
Grænseflader, der har tilladelse til at dirigere trafik inden for routingtabellen ved hjælp af IP-videresendelsesfunktionen.
Ikke-administrerede grænseflader #
Grænseflader, der er udelukket fra routingbeslutninger for den pågældende tabel og IP-videresendelsen, gælder ikke for disse grænseflader.
Ved at kontrollere, hvilke grænseflader der administreres eller ikke-administreres, kan administratorer påvirke, hvordan trafikken flyder gennem load balancer og forhindre routingkonflikter.
Eksempel på routingtabel #
Løsning #
For at løse problemet med asymmetrisk routing skal den modstridende grænseflade udelukkes fra den routingtabell, der er knyttet til backend-netværket.
I dette scenario, eth1 bør fjernes fra routingtabellen table_eth2, hvilket sikrer, at trafikken dirigeres gennem den korrekte gateway.
Løsning ved hjælp af webgrænsefladen #
- Naviger til: Netværk > Routing
- Vælg den routingtabel, der er knyttet til backend-grænsefladen:
table_eth2 - Rul til bunden af siden.
- Find den Administrerede grænseflader sektion.
- Flyt grænsefladen eth1 fra Administrerede grænseflader til Ikke-administrerede grænseflader.
Dette forhindrer trafik i at blive dirigeret direkte gennem frontend-grænsefladen, når backend-routingtabellen bruges.
Løsning ved hjælp af CLI #
Den samme konfiguration kan også anvendes ved hjælp af RELIANOID CLI.
Trin 1: Aktivér API-adgang #
Naviger til: System > Brugerindstillinger
Aktivér API-adgang og konfigurer en API-nøgle. Du kan enten definere din egen nøgle eller generere en tilfældig.
Når du har oprettet nøglen, skal du kopiere og gemme den, da den skal bruges første gang du tilgår CLI'en ved hjælp af noid-cli.
Trin 2: Adgang RELIANOID CLI #
Fra systemkonsollen skal du køre:
noid-cli
Indtast API-nøglen, når du bliver bedt om det.
Trin 3: Fjern grænseflade fra routingtabellen #
Udfør følgende kommando:
netværk-routing-tabel-ikke-administreret tilføj tabel_eth2 -grænseflade eth1
Denne kommando forhindrer trafik i at blive dirigeret igennem eth1 når man bruger routingtabel table_eth2.
Trin 4: Gendan konfigurationen (valgfrit) #
Om nødvendigt kan konfigurationen vendes tilbage med følgende kommando:
netværk-routing-tabel-ikke-administreret fjern tabel_eth2 eth1
Best Practices #
- Udfør ruteændringer under timer med lav trafik eller vedligeholdelsesvinduer.
- Valider forbindelsen efter anvendelse af konfigurationen.
- Sørg for, at andre tjenester ikke påvirkes af ruteændringer.
Konklusion #
Asymmetriske routingproblemer kan opstå, når en load balancer er forbundet til flere netværk, og trafikken returnerer via en anden grænseflade end den, der bruges til den indgående forbindelse.
In RELIANOID, kan dette problem løses ved at justere routingtabelkonfigurationer og udelukke modstridende grænseflader fra specifikke routingtabeller.
Dette sikrer, at trafikken følger den korrekte netværkssti og forhindrer forbindelsesproblemer.
