GRE tunel jako zaklad provozu vlastni (verejne) infrastruktury... no poteskoste. Kdyby si aspon pronajali treba okruh... ale nejake OTT nad jinou IP sluzbou zabalene do GRE? Takze v praxi logicky "nekdy" snizuji MTU... tu potrebu vetsi fragmentace zvlast na vyssich rychlostech vsichni jiste oceni :-) No hlavne ze to udelali "levne"... ale nazval bych to obycejnym bastlem.
V clanku je jasne napsano, ze GRE je zaloha k vyhrazenemu optickemu propoji.
Co se týče globálního provozu, s poskytovatelem tranzitní sítě jsme bohužel nesdíleli žádné datové centrum, a museli jsme tedy pořídit soukromý optický propoj, který znatelně navýšil náklady projektu. Jako záložní řešení jsme v této části architektury zvolili sestavení tunelu GRE.
Ano, ale zaloha by mela byt schopna prevezmout provoz tak, ze to uroven sluzby zasadne nezhorsi. Coz v tomhle pripade proste neni splneno. Vyhrazeny opticky propoj je samozrejme celkem drahe reseni - existuji i levnejsi zpusoby ve forme pronajmu okruhu (kde soucasne narozdil od toho GRE/IP tunelu nemusite prasit MTU, zbytecne fragmentovat provoz atd). Pronajmout si okruh i mezi datacentry neni v CR vubec zadny problem - ostatne cela rada veci kolem vas tak bezne funguje a ani o tom nevite. Pro bastly s GRE neni zadny objektivni duvod.
Dobrý den, klidně to napište do CloudFlaru, implementují to takto všude: https://www.cloudflare.com/magic-transit/ , primár přes CNI, backup přes GRE. Failover do backupu jsme samozřejmě testovali a pravidelně testujeme, ke zhoršení služby nijak nedochází. Primár přes optiku jede bez problémů, momentálně nevidíme důvod pořizovat další okruh mezi oběma DC, ale varianta to samozřejmě je. Pokud tahle potřeba vyvstane, realizace je i v řádech dní.
A ze to dela Cloudflare jeste neznamena, ze to je optimalni - ale samozrejme kazde zbozi ma sveho kupce. Aneb i "levna a zbastlena" reseni si vzdycky taky nekdo koupi, ze? Ale jak jste si urcite vsimnul, i Cloudflare nabizi moznost zrizeni privatniho propoje - hadejte proc...
Jen tak mimochodem - Cloudflare se zameruje primarne na HTTP(S), tedy TCP... a tam to MSS clampingem jeste "nejak obejdete" a vynutite si mensi paket bez nutnosti fragmentace (ale porad je to o tom, ze na stejny objem provozu je potreba vice paketu). Na UDP uz tahle moznost hrabnout do MSS neni a zbyva vlastne jenom ta fragmentace. Na IPv4 se ocekava, ze pripadnou fragmentaci zajisti router - a je to operace v software, co ma svuj nemaly overhead (a u HW routeru se typicky offloaduje na CPU (a ta nema takovy vykon jako HW cesta). ICMP path MTU discovery moc nefunguje, protoze spousta "taky-sekuritaku" po ceste vam ty prislusne ICMP proste zahodi. No a s UDP fragmenty je dnes take sranda - ty vam po ceste muze "zabit" treba nejaky DDoS mitigator - u nich identifikovat, zda patri k validnimu spojeni nebo k utoku neni uplne trivialni. A uz jsem zaregistroval i ISP, co ty fragmenty proste zahodi uplne... a to i v CR. Aneb ruzne pasti... ktere nechcete videt ;-)
Ale vite co, delejte si tam co chcete... ja pouze napsal, ze ten GRE tunel v pateri nad IP sluzbou standardnich parametru je bastl, co do patere poradne udelane site proste nepatri... a rozhodne by si z teto casti clanku nemel brat priklad nekdo, kdo svou infrastrukturu chce stavet poradne :-) Tedy bez rizika, ze narazi na ruzne podivne problemy v nejakych meznich situacich (ktere "vase" testy vlastne ani nemusi podchytit).
Cloudflare nabizi moznost privatniho propoje, ano, jmenuje se to CNI a nevim jak vic uz vysvetlit, ze toto je - jak je v clanku i v komentari popsano - primarni trasa pro veskery traffic. Ten GRE tunel je neaktivni backup linka. Pisete o spatne architekture, ale na tom celem schematu vam zjevne vadi jenom to, ze v jednom mezi mnoha optickymi a aktivnimi propoji je jeden neaktivni, ktery jede pres tunel (kterych je navic nekolik). Podivejte se prosim na celou situaci trosku z vice koncepcniho pohledu, soustredite se na jednu pomerne nevyznamnou komponentu cele architektury, ktera vlastne vubec zadny problem nevytvari. Co se tyce UDP segmentace tak nas trapi v podstate jen SIP signalizace, kterou prevadime na TCP/TLS. RTP jsou male pakety, aby se nevesly do nejakeho MTU po trase.
O tom, co "dokaze zmrsit" zalozni trasa s vyrazne odlisnymi parametry, nez ma trasa primarni se daji psat romany. At uz je rec o tom, kdyz ma propustnost nizsi, nez jsou skutecne toky (ano, i takovi "borci" se najdou)... nebo v dalsich parametrech, treba prave v tom MTU. Ono toho je vic. A vas komentar stylem "nevyznamna komponenta" jen dokazuje, co je v Cechach casty jev - ze redundance se u nas casto podcenuje - protoze prece 99,99% casu vse funguje po primarnich trasach a ty zalozni jsou "zbytecne" vyhozene penize... koncovy zakaznik do toho typicky nevidi a kdyz se neco nejak fakt pokazi, nejaka vymluva se vzdycky vymysli.
Clanek je psany obecne, ne pro specifika (vasi) konkretni aplikace, co zrovna provozujete - kde mozne problemy v praxi nutne projevit nemusi. Ale pokud to nekdo podle vas "okopiruje", muze na to narazit a je vhodne na tyto rizika a uskali takoveho reseni pozornit (cimz ale v clanku moc cas jaksi neztracite, protoze prece u vas to funguje...). Zrovna o provozovanych aplikacich / protokolech v clanku (jen tak mimochodem) neni ani carka...
Backup nepovazuji obecne za nevyznamnou komponentu, ale v kontextu vety rikam ze implicitne rikate ze architektura je spatna na zaklade toho ze se vam nelibi jedna jeji cast, u ktere pritom na problemy nenarazime a funguje ok, jsme s tim spokojeni, problemu je s tim aktualne nula. Nicmene vzdycky je prostor ke zlepseni, takze diky za relativne konstruktivni diskuzi. Nabirame ted treba network engineera, takze pokud mate chut muzete s nama tuhle architekturu vylepsit jak pisete a mel byste prilezitost napsat takovyhle clanek treba i lepe. Diky a hezky vecer
a to je také chybná implikace, kvalita architektury se hodnotí právě podle nejslabších článků a ne podle těch nejlepších. Na co mi je třeba super chlazení, zabezpečený přístup, když mi přestanou jet sítě při výpadku?
Nezřídka má smysl i mít záložní lokalitu dimenzovanou na silnější provoz než má primár.
Argument, že na problém jste nenarazili je lichý, pořád tady pracujeme s malou pravděpodobností, ale vysokými náklady, když to nastane. Přetížení záložní lokality v případě výpadku vede ke kompletnímu kolapsu. Bohužel běžný jev.
Danny má pravdu, GRE má řadu nevýhod a pokud ho již použijete, měli byste mít všude obrovské varování a o to více testování. Z článku to vypadá, jako když s GRE je plnohodnotná alternativa, není, je to nesmysl, stejně jako vaše obhajování.
Mohu nabídnout školení, jak to dělat správně a jaká rizika existují, abyste nového zaměstnance neučili špatným návykům.
Jo jo, UDP fragmenty jsou super. Jiste firewally hojne pouzivane v korporatech je vyhodnocuji jako intrusion, protoze ignoruji ze jde o IP fragment (dalsi cast UDP paketu), ve kterem uz neni UDP hlavicka, ale jen payload. Prvni bajty z payloadu pak interpretuji jako UDP hlavicku a kouzli z toho nesmyslne UDP porty.
Díky za článek.
Je to cenné, když se někdo podělí o tyhle "nízkoúrovňové" informace.
I když se takový typ služeb nechystám provozovat, tak to považuji za užitečné, např. v souvislostí s jinými službami.
Zajímavé by byly i další podrobnosti, například o parametrech poskytovaných služeb.
Ať se vám daří.
12. 10. 2022, 13:00 editováno autorem komentáře
Na Voipa bych to fakt neriskoval. Sice nepisou jak maji reseny propoje do telefonnich siti, ale hadam ze tahat TDMko do cmoudu ( a tedy nespis konverzi skatuli na IP) za dodrzeni kvalitativnich parametru neni sranda. A to hovorime o zfusovane fuserine. Nehlede na to ze tu skatuli nekde mit musite.
Pokud mate uz konverzi do IP od operatora dava smysl to mit co nejvice kontrolovane - idealne okruh primo z jeho ustredny/signalizacniho bodu v tom samem DC.
13. 10. 2022, 14:37 editováno autorem komentáře
Daktela sice IPv6 prefix od RIPE NCC ma, ale v globalni routovaci tabulce videt pod jejich autonomnim systemem neni.
https://bgp.he.net/AS206587#_asinfo
Vzdycky me prekvapi, kdyz nekdo stavi novou infrastrukturu, ale udela to jen napul. 🤔