Názory k článku
ADSL: další podpisy

Myslím že to sdílení bude zavisle na operatorovi a poctu jeho klientu. Ve velkoobchodni nabidce je dost jasne popsan mechanismus jak si muze ISP agregaci kontrolovat. Z toho vyplyva ze kdo nenakoupi ADSL u velkych, kteri se tu predhaneji v tiskovych zpravach a zviditelnuji, ale u nekoho kdo podepise s CT a neni moc videt - vyhraje. Protoze cim mene uzivatelu (mensi operator) tim lepe. O ceny opravdu nepujde deset az dvacet korun rozdilu mesicne nikoho nevytrhne a rozdily vetsi byt nemuzou. Rovnez techn. specifikace tarifu musi byt u vsech stejna, takze neni co resit. Ja si pockam a vystouram nejakeho maleho operatora (snad budou), predpokladam vsak ze vice nabidek bude k dispozici az behem dalsich dvou mesicu .....Ale kdyz uz jsem cekal tak dlouho...

Myslite spatne. Pomer overbookingu je PEVNE dany. Pokud mate jiny nazor, citujte o co z RAO se opira.

Nazdra Michale, jestli to nebylo myšlené tak, že když bude mít ISP jen jednoho Basic zákazníka, že bude propustnost nastavená ČTc 192 kbit a vlastně k žádnému overbookingu nedojde?

Nebo bude v takovém případě propustnost 192/50 = 3,84 kbps? To snad ne, to by si první zákazníci ADSL moc neužili.

Ovšem zase nevím, který ISP by se pustil do ADSL s tím, že bude mít jednotky zákazníků, že.

Presne tak ... Kdyz si ISP koupi od CTC Carrier IP access na 10 mbitech, proc by mu mel prvnich 20 zakazniku telekom agregovat, kdyz neni s kym agregovat ??

uvědomte si, že když bude mít někdo na jednom DSLAMu jednoho či 2 zákazníků, tak se mu to ani nevyplatí na té dotyčné ústředně rozjet, protože ještě platí za ní jako celek. Takže do toho bude když bude mít třeba 100 poptávek na jednu ústřednu a tam už se agregace počítá!
A také si uvědomte, že sdílený 192 kb na 50 uživatelů neznamená, že každý bude mít 4 Kb. Může to aktivně využívat jeden či deset, a pak zbylých 40 bude mít nulu. Pochybuji, že by na obou stranách byl instalovaný inteligentní trafic shaper, který by podle počtu klientů dělil pásmo (rozhodně Telecomem zakoupené DSLAMy to sami o sobě nepodporují, mají jen jeden ATM výstup který je sdílený, takže to bude skákat po ATM rámcích, ale agregovat se to bude náhodně.

Takze neni pravda, ze Telecom bude agregovat POUZE uzivatele jednoho ISP?

ATM nemá rámce, ale buňky...:)))

A diky tem bunkam je taky taky tak shitoidni technologie(rozumnej pomala).

když tomu nerozumíte, tak o tom nepište.
ATM pomalá není. Možná tím myslíte, že má větší režii. Dobře, má o něco větší režii, takže když byste byl jediný uživatel a využíval pouze FTP přenos z nejbližšího routeru, tak to bude opravdu o něco rychlejší. Je ale tato situace reálná?
U ATM je podstatně rychlejší přepínání, u ATM se dá vždy zaručit naprosto přesně propustnost každému a to až na velikost buňky, u ATM se také díky fixní velikosti buňky velmi jednoduše a naprosto nedostižně (v IP světě) dají zaručit přenosy typu telefonie, videokonference, hry atd., které jsou náročné na zpoždění.
A o to vše nás telecom svým IP přístupem připravil, samozřejmě na IP se to dá částečně obejít (btw to už je pak režie úplně jinde), ale na IPv4 nikdy neuděláte QoS (už z principu, lepší je to pak až u IPv6) takže kvalita bude naprosto neporovnatelná.

No ale ty bunky se musi nekdo slozit a to predstavuje moc velkou zatez pro routery => nizka rychlost+vysoka cena =>ATM se hodi maximalne na prenos hovoru. kde by pouziti vetsich paketu spusobovalo spozdeni pri kodovani/dekodovani(pri pouziti paketu o velikosti 512B prenos+(512+512)/8000=128ms, Dalsi vec je ze pokud budete pouzivat technologii ATM tak nemuzete nabidnout klientim pevne okruhy vyssich kapacit za prijatelnou cenu.

Ahoj Petre,
ano v pripade jednoho zakaznika to (MOZNA) bude tak, jak rikas. Bohuzel Telecom NEDAVA informace (ani operatorum) o tom, jak to cele bude realizovano.

Nepochopil jste mne. Samozrejme ze je pevne dany. V RAO je naspoano "je mozne parametry agregace kontrolovat porovnanim mereni linky Carrier IP Access a zaznamu RADIUS accounting"
Z tohy vyplyva ze je pevne dany , ale neni to rozhodne tak ze by jeden kanal sdileli vsichni uzivatele vsech ISP ...Agregace se propocitava jen ve "VLANE" toho urciteho ISP a ne komulovane pro vsechny ISP ....

Ať si podepisujou jaxou, já do toho za tyhle ceny prostě jít nemůžu.

http://ihned.cz/index.php?s1=0

A to bude dnes? Protoze clanek ma vcerejsi datum...

No system NAT a Verejne IP adresy se prece nevylucuje, ve vnitrni siti budou neverejne ip adresy a na routeru mezi internetem a vnitrni siti bude realizovan nat preklad 1:1 kterej bude resenej dinamicky podle toho jak se uzivatele prihlasuji.( V podstate totez jsem programoval, a zatim to podle popisu vypada ze ma Telecom reseni ktere je velmi podobne) a dalsi vec je ze normalni NAT je problem kuli tomu ze se za nim velmi spatne hledaji hrisnici !!

PS asi by by bylo asi vhodnejsi zvolit PPPoE vyse zminenej postup je vhodnej pro WISP operatory kde uzivatel dostane pres NAT stejnou IP adresu v ktere koliv casti nasi republiky, ale pro ADSL uzivatele kteri necestuji to je silenej opruz se neustale logovat.

No, drobná nepříjemnost (pro některé aplikace dist velká) je, že sice z pohledu vnějšího Internetu IP adresa toho stroje veřejná je, ale ten stroj sám neví a těžko může zjistit, jaká. Takže pokdud některé aplikace posílají IP adresu jako součást protokolu, třeba ftp v aktivním režimu, tak budou mít smůlu. Stejně jako IPsec.

Ale Crha v online rozhovoru tvrdi:

Bezproblémový bude provoz většiny standardních protokolů - např. http, https, ftp (v pasivním i aktivním modu), DNS , ICQ, atd.

To se uvidí - může to být vyřešeno, že ten NAT bude umět měnit i obsah paketů, nejenom hlavičky. A pak je otázka, které protokoly bude podporovat. Zatím jsem se to nikde nedočetl.

To je samozrejme technicky a teoreticky mozne, uz se tesim, jak zase ICQ zmeni protokol, uz se tesim na tu masinu, co bude na aplikacni/relacni urovni proxovat vselijake exoticke protokoly...

BTW Ten IPsec neuvedl proc? Inu, protoze to skutecne nepujde... a ruzne proprietalni VPN (napr. CIPE) rovnez ne (znad vyjma SSH ci SSL tunelu). K cemu tedy takove orezavatko a navic cena, hmmm opravdovy sunt je mozno prodavat jen za opravdu suntovni cenu...'-)

CIPE pres NAT neni problem. Naopak, je to idealni VPN (jen ten port do Win neni moc dobry :( ).

Ciste teoreticky by klient poskytovatel mohl nabidnout sluzbu s verejnout a pevnou IP tak, ze by vyrobil ke klientovi tunel (treba std. IPIP, pripadne CIPE).

Jediny predpoklad je vhodne vybaveni u klienta a castecne muze byt problem s MTU < 1500 coz v nekterych vyjmecnych pripadech (ale opravdu pouze vyjmecnych :) ) muze delat problemy.

Pro vyreseni problemu s MTU je vhodne nastavit v IPinIP
nad interface Tunnel (Cisco) MTu vetsi.
Fragmentuje se IPinIP ale packety uvnitř zůstávají v původním stavu. Což je lepší varianta.

T

S IPSecem pres NAT je to trosku jinak a samozrejme komplikovanejsi.

IPSec se sklada ze dvou protokolu AH a ESP
AH resi bezpecnost hlavicek packetu (bez TTL a dalsich co se dynamicky meni pruchodem pres router) a vysledek se prepocita MD5 nebo SHA algoritmem.
Destination peer provede stejný výpočet a porovná výsledek.
Stejný = packet je OK, špatný = packet drop.

ESP skutečná šifrovaná část dat pomocí DES nebo 3DES.
Tvoří ji v podstatě data.

V tomto okamžiku je výsledek, že přes NAT se IPSec nedostane. ale...

IPsec funguje ve dvou modech. Tunnel a transparent.
Tunnel vezme cely L3 packet a přidá mu nové hlavičky.
Transparent provede AH a ESP nad stejnými daty.

Co bude fungovat ?
Z hlediska bezpečnosti a průchodnosti přes NAT je varianta
použití TUNNEL modu (hlavicky jsou šifrovany 3DES, takže je to lepší než jen MD5) a MUSI BYT VYPNUT AH na celém packetu. To že se mění vnější hlavičky už ničemu neubližuje.
A IPSec funguje.

T

Vse co jste napsal znam, jenze kdyz vypnete AH-cko v tunnel modu, tak jste s bezpecnosti trochu jinde.. - to uz mohu pouzit treba CIPE, ci jiny nestandardni tunel... nebo treba L2TP+PPTP..:-)<p>PS: Ja IPsec bez AH zasadne nepouzivam a nevim o nikom, kdo by tak ('dobrovolne') cinil, neco jineho je, ze cesti ISP delaji VPNka casto pouze s DES-56... dobre tak zakaznikum, ze si to nepohlidaji nebo nenajmou konzultanta, ktery to zajisti/proveri...

Ve skutecnosti je to tak, ze AH a ESP mode jsou kazdy urceny pro zajisteni trochu neceho jineho a obecne nejsou rozhodne zamenne jeden za druhy. AH zajistuje autenticitu hlavicek paketu - tedy zjednodusene to, ze paket opravdu byl odeslan tamodsud odkud je psano, ze byl odeslan a ze cilova adresa je take autenticka. Nezajistuje ale ani neporusenost obsahu dat a ani jeji utajeni.ESP mode zajistuje prave neporusenost celeho paketu (tedy hlavicek i dat) a zajistuje i jeho utajeni.

Ja znam realne pripady nasazeni, kdy je ('dobrovolne') pouzivan ESP mode bez soucasneho pouziti AH - ackoliv by samozrejme autentizace "vnejsich" hlavicek zapouzdrenych paketu byla v zasade mozna. V mnoha pripadech totiz takove nasazeni neprinasi zadne realne vylepseni bezpecnosti - cimz nevylucuji, ze v konkretnich pripadech to muze byt jinak - ostatne, v pripade bezpecnosti je vzdy nutne provest analyzu konkretniho problemu a reseni prizpusibit realnym loklanim podminkam, potrebam a situaci.

Jo, jenomže ta věta před tím to popírá - cituji komplet

Použité řešení v překladu adres zaručuje provoz všech aplikací, které nepoužívají vkládání IP adres do datové části rámce. Běžné problému různých aplikací s překladem adres se nebudou vyskytovat především díky použitému překladu 1:1. Bezproblémový bude provoz většiny standardních protokolů - např. http, https, ftp (v pasivním i aktivním modu), DNS , ICQ, atd.

Takže informační hodnota je nulová - pan Crha není technik a tudíž neví, že třeba zrovna v aktivním módu ftp se vkládá IP adresa do datové části rámce.

Ja jen vim, ze u nas ve firme mame na firewallu linuxovej masquarading a aktivni FTP mi normalne funguje...

Však už jsem to psal, na Linux existují moduly, které umějí měnit i datový obsah paketů, třeba ip_masq_ftp, ip_conntrack_ftp, ip_masq_icq atd. Jak to ale bude u ČTc ADSL nevím.

Použití FTP v aktivním modu může a nemusí být funkční. To záleží na dané verzi SW. Občas se vyskytnou problémy s určitým IOSem ale jindy to zase bez problémů funguje.
Předpokládám, že funkční to bude.

T

>> ale pro ADSL uzivatele kteri necestuji to je silenej opruz se neustale logovat

urcite sikovny programator vymysli soft, ktory bude mat ikonku v systemovej liste a bude zabezpecovat prihlasenie a udrzanie spojenia ...

podobnu haluz som pouzival vo Svedsku - tam bolo potrebne sa logovat do WiFi - sialene dlhe username/password (asi 10 krkolomnych znakov) ... ten softik mi odporucali hned technici ;-)

Ale o tom PIsu pro WISP providery je tot reseni vhodne ale proc to delat takhle i u ADSL ?

Takova malickost... kdyz dojdou verejne routovatelne adresy pri prihlaseni, tak co? Odmitne mi dashboard sluzbu, kterou jsem si zaplatil a kterou platim mesicnim pronajmem? Vzdyt to prece neni charakter jako u modemu - zavolam, odmitne, muzu drzet hubu, protoze je to free. Taky bych se rozciloval, kdybych mel komercni dial-up...

Ja jsem to resim tamk ze kdyz vytrarim uzivatele tak mu pridelim bud
1)pevou verejnou IP adresu,
2)plovouci verejnou IP adresu.
3)Pouziva preklad.

takze pokud je uzivatel pripojen na AC kterej mu nemuze namapovat jeho IP adresu tak se pouzije jedna z verejnych, a pokud nejsou volne verejne Ip adresy tak se pouzije nat preklad.

Otazky a odpovedi ohledne ADSL na serveru ihned.cz - Online rozhovor s mluvčím Telecomu.

Tohle je perla:

Ceny jsou stanoveny rozumně a s ohledem na stávající podmínka na českém trhu. Srovnáváte-li země jako je Maďarsko nebo Polsko(poznamka: kde to maji levnejsi), musíte brát do úvahy skutečnost, že liberalizace telekomunikačního trhu v těchto státech zdaleka nepokročila tak jako v ČR. K výši cen a dalším parametrům jsem se již vyjadřoval v předchozích otázkách

hmm, taky me to zaujalo. nevim jestli si pan crha mysli, ze jsme skutecne vsichni takovi blbci, nebo co? kazdopadne, uroven vetsiny tiskovych mluvcich podobnych vypecenych spolecnosti, jako je CT, je velice podobna, no koneckoncu, jsou placeni za lzi a mlzeni.

Mno dnes jsem sledoval tiskovou konferenci o ADSL CTc a musim rict ze panove z Telecomu byli na urovni. Vyjimkou byl snad jen prvni prispevek od prvniho vzdaleneho (telekonference) cloveka z CTc, ktery me opravdu pobavil. Prislo mi ze to co cetl videl poprve v zivote :-) To ze i ostatni si obcas pletli kilobity a megabity take neni tak podstatne. Ale co si myslim jednoznacne je to, ze by mel pan Sova zapracovat sam na sobe. Jeho projevy byly prilis emotivni a neprofesionalni. Pane Sova, zkuste to trosku v klidu :-)

Take jsem to sledoval a musim souhlasit ze trocha klidu by u pana Sovi neuskodila :)..ale jinak si ho velmi vazim. Treba pan Peterka mel projev co si pamatuju velmi dobry.
Jen sem porad nepochopil jak to je s tim NATem :). Kdyz se jich na to p. Peterka ptal tak delali jako by tam vubec byt nemel ( rikal to clovek z IOL ..i u Basicu ), ale pak zase v online diskuzi pan Crha rikal ze u Basicu bude NAT 1:1...no sem z toho zmaten..ale jelikoz je nat i v referencni nabidce tak tam asi fakt bude ..jen IOL nevi co vlastne dela.

Já se polepším:-)Asi nejsem tak kovanej jako profesionálové od Telecomu a zapoměl jsem si vzít nějaká sedativa, ale to srovnání s Polskem,Německem a Belgií mě trochu nadzvedlo. Omlouvám se:-))

Každopádně jsme se v zákulisí dozvědeli jak to bude s tou agregací.U profi variant ani při vysoké zátěži nedojde k spomalení rychlosti a základních variant se nám po dlouhé diskusi podařilo dospět k nějakým hodnotám, ale předem upozorňuji že se jedná pouze o odhady, skutečně se to nedá dopředu zodpovědně spočítat. Takže při plném vytížení by to bylo něco kolem 20% rychlosti dolů, u té varianty 192 padlo snad číslo 145Kb/s ovšem znovu upozorňuji,že se jedná pouze odhad - jak to bude ve skutečnosti ukáže až reálný provoz.

No, to jsem zvedav, co napisou do smlouvy. Nejspis neco jako prohlasujou o dialu, ze garantujou 9600, presto, ze z principu je to blbost, protoze pokud dodrzej ty 4kHz tak to je podstatne vic. Takze pocitam, ze garance veskera zadna. Bud tam neuvedou nic - a pak budou rikat, ze tam nic o nejake garanci nestoji, nebo tam daj tak 1/3 a za tehle podminek je kazdej rozumnej clovek posle nekam.