Stává se, že narazím na zákazníky, kteří mají ve svých sítích to, co definuji jako „asymetrické směrování“. Jednoduše řečeno, mají dvě brány ve stejné podsíti IP. Klienti jsou nakonfigurováni tak, aby směřovali na jednu bránu (tj. 172.16.1.1), ale existuje další zařízení (tj. 172.16.1.2), které se připojuje a směruje kamkoli. Většinou jsem tento druh nastavení viděl, když existují 2 různé typy připojení WAN: 1 připojení k internetu a 1 firemní připojení MPLS.
Osobně mě výše uvedený druh síťového designu nepřitahuje. podsíť musí mít jednu a pouze jednu bránu. Z mého pohledu může výše uvedený scénář vytvořit pro klienty určité problémy, protože posílají paket na jejich výchozí bránu (172.16.1.1) a tyto pakety jsou poté přeposílány na druhý směrovač (172.16.1.2) a když dostanou odpověď k, dostanou se ke klientovi jednoduše procházející 172.16.1.2. Klienti by nebo měli očekávat, že pakety odpovědí pocházejí z verze 172.16.1.1, nebo se zde mýlím?
Byl bych rád, kdybych měl vaše názory a technické pohledy na tento problém.
Komentáře
- Pomohla vám nějaká odpověď? Pokud ano, měli byste odpověď přijmout, aby otázka ‚ nezachovala vyskakovat navždy a hledat odpověď. Případně můžete zveřejnit a přijmout vlastní odpověď.
Odpovědět
Doporučil bych, abyste se podívali do protokolů First Hop Redundancy, jako jsou HSRP nebo VRRP.
Vlastnost dvou bran může být ve skutečnosti velmi dobrým síťovým designem, protože pokud by router selhal, druhý router může poněkud hladce. Jak však „víte, není snadné tento přechod provést, pokud musíte provést ruční rekonfiguraci každého klienta v podsíti.
Protokoly jako HSRP (nebo VRRP, pokud máte jiné zařízení než Cisco) vám umožní mít dva (nebo více) směrovače (nebo přepínač L3) s) v podsíti sdílet jednu IP adresu. Budete mít svůj první směrovač s adresou .2, druhý s adresou .3 a „virtuální IP adresu“ .1, které si oba směrovače uvědomují prostřednictvím konfigurace. Když selže primární směrovač, sekundární je schopen to zjistit a převzít virtuální IP adresu, což znamená, že vaši klienti musí mít jako svoji bránu nakonfigurován .1 a vy jste v pořádku.
Pokud jde o návrh směrování, do značné míry závisí na aktuálním nastavení. Je možné, že obě brány vedou ke stejné internetové hranici, v takovém případě možná nebudete mít problém. Asymetrické směrování může být špatné, hlavně proto, že riskujete doručení paketů ve špatném pořadí, ale opět to značně závisí na topologii mluvíš o tom.
Spousta designových principů vyplývajících z toho, co jsem právě řekl. Navrhuji, abyste prozkoumali oba protokoly a zjistili, co je pro vaše prostředí nejlepší. Pokud používáte zařízení Cisco, je HSRP široce používanou a dobře srozumitelnou metodou řešení tohoto problému.
Komentáře
- a ‚ nezapomeňte, že existuje také GLBP, který dělá stejnou věc HSRP / VRRP (dobře), ale umožňuje obojí brány ke skutečnému vyvážení provozu. Ladění se občas stává obtížnějším, protože někteří klienti mohou být na R1 a jiní na R2
- @mierdin, asymetrické směrování nemá nic společného s přeskupováním paketů … přeskupování obvykle přichází jako výsledek vícecestných tras pro stejnou předponu …
odpověď
Celý internet je postaven na asymetrickém směrování , takže je to velmi běžné. Klienti se zajímají o rozhraní, na kterém obdrží paket, a o zdroj paketu, nikoli o to, který router jim jej na tomto rozhraní předal.
Asymetrické směrování však může být problematické když se jedná o zařízení sledující stav (zejména brány firewall) a NAT, ale pokud vím, ve vašem příkladu tomu tak není.
Komentáře
- Může to být také problém, když používáte nějaký druh předávání obrácené cesty. Jinak to není tak velký problém.
- Proč by to měl být problém? Trasa existuje a odpovídá rozhraním, takže ani přísné RPF by se zde ‚ nespustilo.
- pokud má router dvě externí rozhraní s pakety vycházejícími jedním směrem ( po IGP) a při návratu do jiného by to paket odhodilo. Příchozí paket by prošel přísnou kontrolou RPF, pokud by samozřejmě nebyly stejné náklady
Odpověď
Síťoví klienti identifikujte toky provozu na základě kombinace 4 hodnot:
- Zdrojová adresa
- Zdrojový port
- Cílová adresa
- Cílový port
U každého jiného připojení tvoří 4 výše uvedené hodnoty jinou kombinaci, která se používá k přiřazení paketů odpovědí ke správnému toku.Jak můžete vidět, brána nebo adresa dalšího skoku nejsou zahrnuty v seznamu, a proto bude klientovi jedno, jestli se paket vrátí skrz stejnou bránu, kterou použil k odeslání svých paketů. Síťovým klientům tedy nezáleží na asymetrickém směrování, jakmile budou moci přijímat provoz ze vzdáleného konce. Protokol TCP / IP byl původně navržen tak, aby podporoval asymetrické směrování.
Pokud se však zaměříme na síťová zprostředkující zařízení, asymetrické směrování není tolerováno, jakmile používáte jakékoli zařízení / technologii, která potřebuje k zobrazení dané funkce všechny pakety v připojení. Například: NAT, stavové brány firewall nebo optimalizátory WAN. Asymetrické směrování v takovém scénáři by způsobilo, že by nebyla poskytnuta zamýšlená funkčnost, nebo, co je nejhorší, pakety, které by znemožnily komunikaci.
Odpovědět
Souhlasím s odpověďmi, které mám před sebou, ale musím něco dodat: pokud existuje filtrování na kterékoli z bran nebo na jakémkoli hopu, který je předán pouze 1 ze 2 bran, pravděpodobně nastanou problémy! (chmele, které procházejí oběma branami, jako je zdrojový stroj, cílový stroj a jakýkoli chmel „společné oběma cestám brány“, se netýkají následujících scénářů)
Například pokud A posílat pakety do B přes gateway1 a pakety se vracejí přes gateway2, pak je vysoce pravděpodobné, že paket odpovědí bude zahozen, pokud gateway2 provádí filtrování (protože tato brána neviděla počáteční paket připojení, takže neočekává odpověď , tedy pokud je cílový / port paketu odpovědí obvykle filtrován, bude filtrován.)
(Existuje samozřejmě mnoho podobných scénářů)
Odpověď
Další dvě oblasti, kde asymetrické trasy způsobí potíže, jsou tyto: 1. Zjištění MTU – pokud se liší nejmenší MTU ze dvou cest, mohlo by být zjištění cesty MTU v koncovém bodě výsledkem bude největší ze dvou MTU, což zase povede k zahození paketů maximální velikosti. Například pokud jedna cesta prochází tunelem VPN a druhá nikoli, tunel VPN bude mít menší MTU. ping bude fungovat dobře, ale přenos velkých souborů bude trvale selhat. 2. Odstraňování problémů s připojením bude obtížnější, pokud je jedna ze dvou cest přerušena, ale druhá není. Stará dobrá „traceroute“ vůbec nepomůže, protože nebude schopna detekovat mezilehlé body zpětné cesty, pokud se neprovádí z obou stran připojení, což vyžaduje kanál pro správu mimo pásmo …