Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: brk 18. 12. 2013, 22:05:39
-
Posledních cca deset dnu pozoruji, že mi po cca dvou, třech hodinách "přestane fungovat Firefox". Moc jsem to neřešil. Říkal jsem si, že to budě nějaký drobný bug, který brzy opraví. Dnes jsem si všiml, že mi v ten okamžik přestaly proudit data po preferovaném IPv6 a měl jsem přenesený "přesně" 1GB v toleranci výpisu ifconfig.
Nevíte někdo, jestli daný tunel nemá něco jako FUP? Cca měsíc a půl poslouchám streamovanou hudbu z Google Play a Google je na tom s IPv6 dost dobře, takže to chodí tunelem.
Tohle byla první věc, co mě napadla, než začnu "honit duchy", ale nenarazil jsem na popis podobných limitů někde na webu.
-
Kde mas endpoint? HE pouzivam a to nemalo a podobny problem nepozoruju...
-
Spíš bych se zeptal (IPv4) ISP, jestli takový limit na jednotlivá spojení (nebo „divné L4 protokoly“) nevynucuje.
-
Na HE se vybodni, udelej si 6to4 to je nejspolehlivejsi.
SIXX.NET se vyhnout velkym obloukem, ty jsou nejhorsi.
-
HE je naprosto vpohode:
month rx | tx | total | avg. rate
------------------------+-------------+-------------+---------------
Jan '13 18.79 GiB | 1.87 GiB | 20.66 GiB | 64.71 kbit/s
Feb '13 23.94 GiB | 1.85 GiB | 25.80 GiB | 89.45 kbit/s
Mar '13 23.76 GiB | 2.03 GiB | 25.78 GiB | 80.75 kbit/s
Apr '13 19.58 GiB | 1.92 GiB | 21.50 GiB | 69.57 kbit/s
May '13 20.91 GiB | 2.10 GiB | 23.02 GiB | 72.09 kbit/s
Jun '13 22.43 GiB | 2.30 GiB | 24.73 GiB | 80.03 kbit/s
Jul '13 18.77 GiB | 1.90 GiB | 20.67 GiB | 64.75 kbit/s
Aug '13 18.54 GiB | 1.92 GiB | 20.46 GiB | 64.07 kbit/s
Sep '13 30.57 GiB | 2.54 GiB | 33.11 GiB | 107.14 kbit/s
Oct '13 206.41 GiB | 6.57 GiB | 212.98 GiB | 667.03 kbit/s
Nov '13 83.69 GiB | 4.01 GiB | 87.70 GiB | 283.82 kbit/s
Dec '13 48.67 GiB | 2.34 GiB | 51.01 GiB | 253.96 kbit/s
-
HE je naprosto vpohode:
Pokud mate pozavavky na prenosovku 250 kbit tak to je v pohode uplne vsechno.
Porad zapominam ze tady je to totalni widlakov, u nas zakaznici ocekavaji reseni ktere bude mit prenosovku radove 1000x vyssi.
-
Nám by se v práci taky občas hodila konektivita řádově 1000x větší než 1000x větší než 250kbps, ale nechápu, jakou to má souvislost s tímto tématem.
Sám mám doma HE (nad UPC) a nemám problém ani s ořezáváním, ani s trafficem (j ale dělá měsíčně víc).
-
udelej si 6to4 to je nejspolehlivejsi.
Právě naopak, 6to4 je jedna z nejméně spolehlivějších technologií kvůli asymetrické povaze (a nedá se s tím nic dělat, kromě přechodu na 6rd – což by ovšem musel chtít ISP a kdyby chtěl tak by radši mohl nasadit nativní IPv6). Že to celkem dobře funguje pro přístup z ČR na obsah v ČR (nejspíše díky veřejné bráně u CZ.NIC) na věci nic nemění. Více třeba zde: https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really
SIXX.NET se vyhnout velkym obloukem, ty jsou nejhorsi.
SixXS tunel servery jsou (zdarma) hostovány různými subjekty, podle toho se jejich kvalita může odlišovat. Osobně používám několik tunelů na server provozovaný Ignem a je to zcela bez problému. Na připojeních bez veřejné IPv4 adresy jde o jedinou rozumnou možnost.
-
6to4 ma nasledujci vyhody:
a/ Prichozi trafik jde rovnou k vam
b/ IP6 rozsah je vas, ne provozovatele tunelu ktereho kdyz zmenite tak musite precislovat
c/ odchozich gatewayi je mnoho a muzete je menit dle libosti beze zmeny IP6 adres. My delame komercni GW 1 Gbit asi za 1000 USD/mesic.
d/ k dispozici mate 65k siti
e/ nemusite cpat udaje o vas do whois6
Ip6rd je napytel, neznam nikoho kdo by to nasadil ve velkem, proc se s tim srat kdyz muzu mit ip6 nativne.
-
6to4 ma nasledujci vyhody:
6to4 má ale i spoustu nevýhod:
a/ Prichozi trafik jde rovnou k vam
To vůbec není pravda. Příchozí pakety jdou přes 6to4 gateway kterou naprosto nemáte možnost ovlivnit, a někdy je to dost průšvih - kvalita různých 6to4 gw je proměnlivá. Pokud jste v ČR a použijete pražskou gw od he.net nebo sixxs.net, jste na tom z tohoto pohledu mnohem lépe.
b/ IP6 rozsah je vas, ne provozovatele tunelu ktereho kdyz zmenite tak musite precislovat
IP6 rozsah není váš, ten je majitele vaší IP4 adresy. U he.net nebo sixxs.net je IP6 rozsah váš i poté co musíte IP4 adresu změnit.
c/ odchozich gatewayi je mnoho a muzete je menit dle libosti beze zmeny IP6 adres. My delame komercni GW 1 Gbit asi za 1000 USD/mesic.
To beru pouze jako reklamu, navíc nechápu jak si někdo na 6to4 může platit za odchozí GW když ho stejně bude ničit proměnlivá kvalita příchozích GW. Pochopil bych komerční GW pouze pokud by byla obousměrná, s garantovanou latencí a rychlostí.
d/ k dispozici mate 65k siti
To u he.net i sixxs.net taky (a dokonce víc).
e/ nemusite cpat udaje o vas do whois6
U he.net i sixxs.net to taky nemusíte - udělá to za vás automaticky provider. U 6to4 jsou ve whois ty samé informace (u IP4 adresy).
Ip6rd je napytel, neznam nikoho kdo by to nasadil ve velkem, proc se s tim srat kdyz muzu mit ip6 nativne.
Pokud máte komplikovanou IP4 síť do které IP6 nedokážete s rozumnými náklady dostat nativně (např. proto že je postavena na obskurních blackboxech), jste rád i za IP6RD.
-
Pokud mate pozavavky na prenosovku 250 kbit tak to je v pohode uplne vsechno.
Porad zapominam ze tady je to totalni widlakov, u nas zakaznici ocekavaji reseni ktere bude mit prenosovku radove 1000x vyssi.
Ja ti nevim, ale momentalne jsem pres svuj HE tunel na WIFI nameril 25Mbps/10Mbps, kabel kvuli tomu pripojovat nebudu, ale davam bez problemu pres 90Mbit
-
Ip6rd je napytel, neznam nikoho kdo by to nasadil ve velkem
Možná je na čase seznámit se s francouzským Free (http://ripe58.ripe.net/content/presentations/ipv6-free.pdf). Čtyři miliony přípojek, to žádné malé nasazení nebude.
-
To vůbec není pravda. Příchozí pakety jdou přes 6to4 gateway kterou naprosto nemáte možnost ovlivnit, a někdy je to dost průšvih - kvalita různých 6to4 gw je proměnlivá
K pouziti prichozi 6to4 gateway treti strany dojde pouze v pripade, kdy spravce AS protistrany si sam nevyresi zapouzdreni prislusneho odchoziho provozu do 6to4, nebo to aspon necha na svem upstream providerovi.
IMHO by se prefix 2002::/16 nemel propagovat skrz peeringove linky, tim by bylo po problemu.
-
Kde mas endpoint?
Vypadá to na Prahu.
Spíš bych se zeptal (IPv4) ISP, jestli takový limit na jednotlivá spojení (nebo „divné L4 protokoly“) nevynucuje.
Komunikaci s UPC na toto téma bych se raději vyhnul. Navíc jak říkám, nejsem si jist, jestli to je o tunelu. Výpadky pozoruji cca dva týdny a myslel jsem si, že to zlobí Fireforx, než jsem si při posledním všiml, že mi zrovna přestala fungovat i IPv6. Proto jsem se zeptal, jestli tam není nějaký veřejně známý FUP.
Pokud mate pozavavky na prenosovku 250 kbit tak to je v pohode uplne vsechno.
Teď mi ten tunel sice jede trošku pomaleji (cca 20Mbps), ale co jsem to v minulosti zkoušel, tak to jelo skoro vždy 30Mbps, což se v podstatě to, co mi UPC prodává.
6to4 jsem kdysi používal, ale jak jsem vyměnil router, tak se mi tu vyskytly nějaké problémy. Už nevím přesně, co to bylo, ale jelikož tu byl zrovna na návštěvě Péťa Krčmářů, tak mi rozumným argumenty vysvětlil, že to co chci, je spíše něco ve stylu tunelu od HE a pomohl mi s nastavením. Bylo to někdy více než před rokem a od té doby jsem na to nemusel sahat. Tunel je otevřený na routeru s OpenWrt a ve zbytku sítě to už funguje tak nějak samo.
Poslední týden byl naprosto šílený, takže jsem zatím neměl ani čas zjišťovat, jestli při výpadku přestane fungovat IPv6 v celé síti.
-
Příchozí pakety jdou přes 6to4 gateway kterou naprosto nemáte možnost ovlivnit, a někdy je to dost průšvih - kvalita různých 6to4 gw je proměnlivá
K pouziti prichozi 6to4 gateway treti strany dojde pouze v pripade, kdy spravce AS protistrany si sam nevyresi zapouzdreni prislusneho odchoziho provozu do 6to4, nebo to aspon necha na svem upstream providerovi.
No ale kde máte záruku že správce AS protistrany (nebo jeho upstream provider) bude provozovat dostatečně kvalitní 6to4 gw? Prostě je to totálně bez záruky, takže nestabilita takového asymetrického řešení jako je 6to4 je hlavní problém - někdy funguje perfektně a někdy naprosto hrozně. Oproti tomu symetrické řešení typu he.net nebo sixxs.net funguje stabilně, a tím že máme v Praze jejich endpointy tak je to pro klienty v ČR mnohem lepší řešení.
IMHO by se prefix 2002::/16 nemel propagovat skrz peeringove linky, tim by bylo po problemu.
Takže tam kde nebude funkční 6to4 gw tak mají klienti prostě smůlu? V tu chvíli by 6to4 bylo mrtvé, protože by ho klienti přestali používat (protože by se nedostali všude). Svým způsobem je to vlastně dobré řešení, ale nejsem si jistý že to bylo takhle myšlené.
-
Santiago ma pravdu, tohle je presne ta pointa. Vsichni si nastavi pokud maji dual stack na border routeru odchozi IPv6->IPv4 6to4 a je po problemech.
Navic tunel je SPOF. V sitarine je nejlepsi byt co mozna nejvic nezavisly a ne zavistet s IP6 konektivitou na tom jak se u HE vyspi.
-
Santiago ma pravdu, tohle je presne ta pointa. Vsichni si nastavi pokud maji dual stack na border routeru odchozi IPv6->IPv4 6to4 a je po problemech.
Kdyby to tak fungovalo, bylo by to super. Ale v praxi to tak bohužel nefunguje, proto to super není. Hlavní průšvih je že nemáte jak všechny ostatní ISP donutit aby to dělali tak jak by se vám líbilo.
Navic tunel je SPOF. V sitarine je nejlepsi byt co mozna nejvic nezavisly a ne zavistet s IP6 konektivitou na tom jak se u HE vyspi.
To je obecná nevýhoda všech tunelů - samozřejmě že nativní IP6 je lepší, ale když není tak holt tunel...
-
To si nastavi na border routeru ZAKAZNIK, ne ISP. Pokud ISP zvladne routovat IP6 ve svy siti tak uz ma davno IP6 nativne.
-
To si nastavi na border routeru ZAKAZNIK, ne ISP.
Předpokládám že jde o situaci kdy ten zákazník nemá nativní IP6 konektivitu a na svém border routeru (s patřičnou veřejnou IP4 adresou) nakonfiguruje 6to4 gw. Pak pořád zůstává problém s tím, jak se IP6 routuje k němu - tím svým nastavením totiž ovlivní jen jak se IP6 routuje od něj. Konkrétně je problém jak IP6 servery v internetu se kterými chce zákazník komunikovat najdou spolehlivou 6to4 gw která zajistí převod IP6->IP4 pro posílání odpovědí k zákazníkovi (potom už pakety běží přes IP4 až na border router zákazníka, který zajistí převod IP4->IP6 a routování do vnitřní sítě zákazníka).
-
Takže nic, HE je v pohodě. Blbý odhad. Další vytuhnutí a když jsem sáhl po mobilu na mojí WiFině ve stejné síti, tak nebezi.cz běží. Něco se mi rozbilo na stanici.
-
No ale kde máte záruku že správce AS protistrany (nebo jeho upstream provider) bude provozovat dostatečně kvalitní 6to4 gw?
Provoz privatni 6to4 gateway neni nic, co by bylo 'kvalitni' ci 'nekvalitni', nema smysl se na to koukat, jak by slo provoz databaze nebo webserveru. Je to v podstate jedna routa v routovaci tabulce, ktera se od bezneho forwardingu lisi tim, ze se paket obali jeste jednou hlavickou (samozrejme, pokud ma nekdo routery, ktere mu prosty forwarding delaji v hardware, ale 6to4 zapouzdeni v hardware nezvladnou, tak musi provozovat dostatecne dimenzovany softwarovy router jako 6to4 branu).
Problem je s 6to4 gatewayema tretich stran je primarne v tom, ze v podstate poskytuji zahranicni konektivitu zdarma, takze jsou svym zpusobem dotovani provozovatelem a ten nema zadnou primou motivaci zajistit dostatecne dimenzovani. Oproti tomu brana pro vlastni potrebu je z hlediska site bezny IPv4 provoz, na ktery je sit dimenzovana tak jako tak.
Prostě je to totálně bez záruky, takže nestabilita takového asymetrického řešení jako je 6to4 je hlavní problém - někdy funguje perfektně a někdy naprosto hrozně.
Tady je videt, jak tvuj zaver ohledne 6to4 je zatizen atribucni chybou - problem pri komunikaci mezi nativnim IPv6 a 6to4 automaticky prisuzujes na stranu 6to4. Daleko vystiznejsi je ale rict, ze ani nativni IPv6 neni vsespasne - pokud ma nekdo nativni IPv6 od ISP, ktery zanedba svou 6to4 branu, tak mu spatne funguje komunikace do 6to4 siti.
Takže tam kde nebude funkční 6to4 gw tak mají klienti prostě smůlu? V tu chvíli by 6to4 bylo mrtvé, protože by ho klienti přestali používat (protože by se nedostali všude). Svým způsobem je to vlastně dobré řešení, ale nejsem si jistý že to bylo takhle myšlené.
Pokud mi upstream nedoda routu pro 2002::/16, tak je to zavazny problem s upstreamem, ktery by si mel dany AS poresit. Pokud by mi upstream nedodal prefix HE.NET, tak bych se z meho AS take nedostal do site HE.NET (a zakaznici HE.NET by se take nedostali vsude). Pokud by mi upstream nedodal prefix UPC, tak by ty same potize meli zakaznici UPC. A urcite existuji i nativni IPv6 prefixy, ktere jsou daleko mene vyznamne nez prefix 2002::/16 co do poctu komunikujicich.
-
No ale kde máte záruku že správce AS protistrany (nebo jeho upstream provider) bude provozovat dostatečně kvalitní 6to4 gw?
Provoz privatni 6to4 gateway neni nic, co by bylo 'kvalitni' ci 'nekvalitni', nema smysl se na to koukat, jak by slo provoz databaze nebo webserveru. Je to v podstate jedna routa v routovaci tabulce, ktera se od bezneho forwardingu lisi tim, ze se paket obali jeste jednou hlavickou (samozrejme, pokud ma nekdo routery, ktere mu prosty forwarding delaji v hardware, ale 6to4 zapouzdeni v hardware nezvladnou, tak musi provozovat dostatecne dimenzovany softwarovy router jako 6to4 branu).
Odpověděl sis sám - vidíš že to vždy není "jedna routa v routovací tabulce". Například když má ISP drahé routery (třeba i v HA zapojení) u kterých si šetří CPU na důležitější věci než je nějaké 6to4, s radostí se na nějaké speciální řešení pro 6to4 vykašle.
Problem je s 6to4 gatewayema tretich stran je primarne v tom, ze v podstate poskytuji zahranicni konektivitu zdarma, takze jsou svym zpusobem dotovani provozovatelem a ten nema zadnou primou motivaci zajistit dostatecne dimenzovani. Oproti tomu brana pro vlastni potrebu je z hlediska site bezny IPv4 provoz, na ktery je sit dimenzovana tak jako tak.
Další argumenty proč se spousta ISP na provoz 6to4 gw vykašle, takže utopické teoretické řešení kdy každý ISP má kvalitní 6to4 gw (dostupností i výkonem) se prostě nepotkává s realitou.
Prostě je to totálně bez záruky, takže nestabilita takového asymetrického řešení jako je 6to4 je hlavní problém - někdy funguje perfektně a někdy naprosto hrozně.
Tady je videt, jak tvuj zaver ohledne 6to4 je zatizen atribucni chybou - problem pri komunikaci mezi nativnim IPv6 a 6to4 automaticky prisuzujes na stranu 6to4. Daleko vystiznejsi je ale rict, ze ani nativni IPv6 neni vsespasne - pokud ma nekdo nativni IPv6 od ISP, ktery zanedba svou 6to4 branu, tak mu spatne funguje komunikace do 6to4 siti.
K nativnímu IPv6 nemusí ISP nic řešit, prostě použije kvalitní routery (které stejně má pro IPv4) a je to. U 6to4 se toho dá pokazit mnohem více, proto jsem přesvědčený že je naprosto legitimní předpokládat že ve většině případů je to právě špatně fungující 6to4 gw která může za problémy. Některé z argumentů viz výše - ISP prostě nejsou nijak motivováni k provozu kvalitních 6to4 gw, je to pro ně pouze zbytečná zátěž.
Takže tam kde nebude funkční 6to4 gw tak mají klienti prostě smůlu? V tu chvíli by 6to4 bylo mrtvé, protože by ho klienti přestali používat (protože by se nedostali všude). Svým způsobem je to vlastně dobré řešení, ale nejsem si jistý že to bylo takhle myšlené.
Pokud mi upstream nedoda routu pro 2002::/16, tak je to zavazny problem s upstreamem, ktery by si mel dany AS poresit. Pokud by mi upstream nedodal prefix HE.NET, tak bych se z meho AS take nedostal do site HE.NET (a zakaznici HE.NET by se take nedostali vsude). Pokud by mi upstream nedodal prefix UPC, tak by ty same potize meli zakaznici UPC. A urcite existuji i nativni IPv6 prefixy, ktere jsou daleko mene vyznamne nez prefix 2002::/16 co do poctu komunikujicich.
Umazal jsi svou větu "IMHO by se prefix 2002::/16 nemel propagovat skrz peeringove linky, tim by bylo po problemu." na kterou jsem reagoval. Nejspíš to bylo myšlené v kombinaci s tím že každý ISP má mít svou 6to4 gw která bude umět zpracovávat 2002::/16, což je ale utopie.
-
Problem je s 6to4 gatewayema tretich stran je primarne v tom, ze v podstate poskytuji zahranicni konektivitu zdarma, takze jsou svym zpusobem dotovani provozovatelem a ten nema zadnou primou motivaci zajistit dostatecne dimenzovani. Oproti tomu brana pro vlastni potrebu je z hlediska site bezny IPv4 provoz, na ktery je sit dimenzovana tak jako tak.
Další argumenty proč se spousta ISP na provoz 6to4 gw vykašle, takže utopické teoretické řešení kdy každý ISP má kvalitní 6to4 gw (dostupností i výkonem) se prostě nepotkává s realitou.
Tenhle argument se tyka pouze provozu 6to4 bran tretich stran, tedy nikoliv te, kterou by si AS delal sam, nebo kterou by vyuzival od sveho upstream providera.
Tady je videt, jak tvuj zaver ohledne 6to4 je zatizen atribucni chybou - problem pri komunikaci mezi nativnim IPv6 a 6to4 automaticky prisuzujes na stranu 6to4. Daleko vystiznejsi je ale rict, ze ani nativni IPv6 neni vsespasne - pokud ma nekdo nativni IPv6 od ISP, ktery zanedba svou 6to4 branu, tak mu spatne funguje komunikace do 6to4 siti.
Některé z argumentů viz výše - ISP prostě nejsou nijak motivováni k provozu kvalitních 6to4 gw, je to pro ně pouze zbytečná zátěž.
Neni motivace pouze k provozu verejnych 6to4 gw. Motivace k provozu privatnich 6to4 gw pro svuj odchozi provoz do 2002::/16 existuje, pokud ho prave nesabotuji ti, kteri jsou ochotni verejnou gw (ve smeru IPv6->IPv4, tedy prefix 2002::/16) propagovat skrz peering.
Pokud mi upstream nedoda routu pro 2002::/16, tak je to zavazny problem s upstreamem, ktery by si mel dany AS poresit. Pokud by mi upstream nedodal prefix HE.NET, tak bych se z meho AS take nedostal do site HE.NET (a zakaznici HE.NET by se take nedostali vsude). Pokud by mi upstream nedodal prefix UPC, tak by ty same potize meli zakaznici UPC. A urcite existuji i nativni IPv6 prefixy, ktere jsou daleko mene vyznamne nez prefix 2002::/16 co do poctu komunikujicich.
Umazal jsi svou větu "IMHO by se prefix 2002::/16 nemel propagovat skrz peeringove linky, tim by bylo po problemu." na kterou jsem reagoval. Nejspíš to bylo myšlené v kombinaci s tím že každý ISP má mít svou 6to4 gw která bude umět zpracovávat 2002::/16, což je ale utopie.
Je vhodne rozlisovat peering a upstream. Argument byl takovy, ze ISP by mel but vyuzivat svou 6to4 branu, nebo pouzit routu na 2002::/16, kterou dostane od upstreamu. Nemel by pouzivat ty od peeru (a protoze to je pro nej vyhodnejsi, tak ten argument je spis naopak -> nepropagovat 2002::/16 peerum. Ale nevim, jestli to v praxi vubec nekdo dela.)