Vlákno názorů k článku Černý čtvrtek českého Internetu od Marian Durkovic - Prosim Vas kde ste prisli k informacii ze...

Prosim Vas kde ste prisli k informacii ze EBONE v Bratislave
"stale pada" ? Doporucujem pozriet si http://www.ebone.net/looking-glass/ tam si zvolte router skbra201 a funkciu bgp summary - zistite ze BGP session je nepretrzite UP
3 tyzdne a 2 dni :-))))

No, kdyz uz jsem v te grafomanske nalade, tak jeste zareaguji, i kdyz uz spise placame.

Jsou (dokonce i v Cechach) firmy, ktere zalohuji rychlosti okolo E3. Ale nechme na zakaznicich, jak povazuji backup za nutny. :-)

To Ebone/HERMES musim potvrdit, melo by to byt opet 2,5G.

A pokud byste se zajimal o Bratislavu, muzete si projit Ebone statistiky, meli to tam v posledni dobe nevesele. :-(

Toto jsem, prosim, nemyslel. Jakozto ucastnik site TEN - student - asi tezko budu moci nahlednout do statistik prenosu CVUT, ale to by ani nebylo tak zajimave ;-). Ja mel na mysli napr. linky do zahranici, pripadne do NIXu. Ani by to nemuselo byt jako to maji udelano v Izraeli v ILANu: http://noc.ilan.net.il/stats/ , stacilo by: http://noc.ilan.net.il/stats/ILAN-I2-uplinks/ .

Ale da se vsechno :-)
Opravdu nevim, jaka je situace v Bratislave. Mimochodem, ja mluvil o 10 hodinach vypadku zpusobeneho prekopnutim slauchu.
V tuto chvili tusim pouze administrativni problemy vadi EBONE, aby sem dotahla Hermes - a potom budou mit v Praze dva PoPy. A myslim dokonce, ze to jde jinym zlabkem.

Co se tyce zalohovani a na novost GIN. Jiste vite, ze i CESNET mel kdysi blahe pameti 2x2 Mbps - jeden k EBONE a druhy k DANTE (viz. i nazvy nasich ASu :-) ). Az se dostanete na jine rychlosti, uvidite, ze je to malinko slozitejsi. A slozitejsi neznamena nemozne, ale slozitejsi znamena skoro vzdy 'hodne drahe'.
IMHO (ale kazdy muze mit vlastni nazor) je prekopnuti kabelu vec, kvuli ktere se nevyplati investovat. Respektive az nakonec. Pred tim fail-safe konfigurace routeru, respektive SLA na routery, pouzivani ruznych routeru na ruzne veci (viz moje pripominka o stabilite IOS), uzka spoluprace s upstream ISP (kvuli problemum ve smerovani).

Co se tyce poznamky, kterou si dovolil nekdo vyjadrit v souvislosti s traffic-shapingem, ze v backbonovem routeru jsou stejne pripojeny mraky zakazniku, tak to je prave jedna z veci (oddelit to), do ktere bych investoval sve penize jako prvni.

Ano, to je pravda a jeste doplnim, ze by to melo byt i AS6461.

Zdaleka ne všechny transatlantické linky používají stejnou upstream konektivitu - jsou připojeny v USA na AS701, AS1239, AS1800 a v Evropě na AS1800.
Nemyslím, že by v Evropě bylo víc významných providerů s jedinou upstream konektivitou.

No, z reakce jineho prispevovatele uz tedy vim, co znamena MK. Tedy preji pekny den. :-) Muj priklad proste rikal, jak se daji backupovat linky. Ze to Ebone nema optimalne udelane v USA, jsem prece nekomentoval.

Pokud Vam nestoji zalohovat kvuli 10 hod rocne, je to jiste Vas problem. To ze to Ebone vychazi dobre, ale nemusi nutne trvat vecne, podivejme se treba na Bratislavu, kde jim to pada porad.

Jinak GIN (AS9080) uz je na svete pres rok, takze presne nechapu, co Vase poznamka znamena.

Pane Vesely,
popis toho, jak se clen TEN-155 CZ dostane ke svym statistikam, byl dan clenum na posledni valne hromade sdruzeni.

Spise by bylo zajimave se dozvedet, pane Krsek, proc vlasne nebyly jeste zpristupneny ONLINE statistiky zatizeni jednotlivych linek(nebo alespon tech hlavnich), o cemz se jiz drive mluvilo - a ktere ma mnohy ucastnik evropskych TENu.

Muzeme si o tom promluvit po roce provozu Vasi site.
Mozna, pokud jste si nevsiml, tak EBONE pouziva topologicke zalohovani (zakruhovanim). EBONE ma take sice vice transatlantickych linek, ale vsechny pouzivaji upstream konektivitu MCI Worldcom - a pokud v MCI Worldcom klekne smerovani nebo jim prekopnou kabel ... :-(
Muzu Vam garantovat, ze ta frakce E3 mezi RAB a EBS Prague je desne stabilni. :-)
Zalohovat linku jen proto, abych jednou za rok prisel kvuli prekopnute optice na 10 hodin o konektivitu je vyhazovani penez oknem - podotykam, ze penez zakazniku.

Asi jsem na vas zbytecne vyjel, omlouvam se. Ono "dobre rady"
jsou obcas nebezpecny artikl :-).
CAR je neco jineho nez traffic shape a dovedu si predstavit,
ze ISP o uroven vys v takove situaci pomuze neco udelat
s trafficem. Jenze je rada duvodu proc to objektivne nemusi
nebo nekdy nemuze udelat. Od stareho hardware, ktery treba
nepodporuje CEF, pres bugy v urcitych verzich IOSu, slaby
VIP, orezanou verzi IOSu, ktera CAR nepodporuje, vysokou
zatez routeru, ktera nedovoluje v konkretni situaci do konfigurace
prilis dloubat, ci riziko dopadu na jine kriticke sluzby.
Takze i kdyz na druhe strane mate kamarada, ktery vam nedoporuci
upgradeovat zalozni linku, jeste zdaleka nemusi byt vyhrano.
Nemusi byt vyhrano ani pokud se CAR podari zrealizovat a pokud
budete prubezne optimalizovat nastaveni podle zmen ve strukture
provozu. Z pohledu uzivatele, nema nefunkcni konektivita
prilis mnoho odstinu. Tim, ze mu sice nefunguje jeho oblibeny
web, ale zato mu funguje DNS a z vaseho serveru odchazi mail
zadne extra body neziskate, ono mu to nefunguje. Navic nejake
preference pro ruzne druhy provozu, stejne vetsina ISP uz
pouziva, takze zmena nebude dramaticka.
Filtrace delsich prefixu je fakt. Takhle to dela treba SPRINT.
Primarni efekt, je ze mate horsi routing, protoze vas provoz
bude rychle vyhozen ze site takoveho ISP, aby nezatezoval
tranzitem. Tak mate jednak asymetricky routing k vsem zakaznikum
takoveho ISP, jednak horsi a mene spolehlivou zpetnou cestu
pro pakety. Pokud k tomu pripocteme routery, ktere maji jiste
potize s vytahovanim prefixu z BGP, ci jine drobne chyby v BGP,
je prusvih na obzoru. Bude to trvat nejakou dobu nez se na to
prijde, protoze se to bude projevovat velmi nespecificky
a podivne. Pak vam nezbyde nez presvedcit treba SPRINT, ze vas
zakaznik v Horni Dolni, jehoz jmeno jim vubec nic nerika
a ktery ma nejakou smesnou 64 kbps linku je priporita dne :-).
Ja vim, ze obcas obchodnici ve snaze prodat slibi vsechno
mozne od toho, ze se nebude muset precislovat az po featury
v realnem svete nevidane. Nekdy to treba projde, dlouhy prefix
zagreguje nadrazeny provider a bude se to chovat rozumne. Nekdy
ne. 194.50.x.x je PI adresa z last-resort bloku a 192.108 jsou
adresy pridelovane pres SRI-NIC pred CIDR. Tyhle adresy se
postupne vraci a zakaznici prechazeji na PA adresy.

Ani ja nejsem z NAToveho reseni extremne nadsen, je to
trochu plytvajici, ale funkcni reseni. DNS samozrejme je
rychlejsi nez BGP, protoze BGP ohlaseni se musi rozpropagovat
po vsech routovacich tabulkach. Nikdo z velkych provideru
nebude plytvat vykonem routeru na okamzite zmeny tabulek
kvuli padajici lince s 1 routovanym C. Viditelnost techle
zmen konci vetsinou na hranic AS, pokud se dostanou ven
maji odpovidajici tlumeni. Zmena v DNS je otazka TTL
na zaznamu a synchronizace zon pres bind notify. K NATovemu
reseni bylo nejake povidani asi pred rokem na IETF meetingu,
je to nekde na webu.

Myslim, ze finalni reseni jsou hostovaci centra na infrastrukture
ISP s kompletnim technickym zabezpecenim a zalohovanim
na urovni SDH. Ostatni reseni nemohou obstat pri rustu provozu.

Hmm, ale on ve svem prispevku prece nepsal, ze to je nemozne. Pouze konstatoval, ze to je drahe s cimz muzu jen souhlasit. Ale backupuji se i 2,5G linky (viz vetsina uzlu Ebone, tedy treba zrovna ne ta nestastna Praha ci Bratislava). Proste pouze musim trvat na tom, ze rozumny provider ma zalohu vyresenou! At uz ma 512 kbps ci 4,5 Mbps ci 155Mbps.

Ahoj Petre,
pokud se tyce CISCO prirucek, je velmi obvykle, ze to neni tak snadne, jak je tam popisovane. Pokud jsi nekdy prisel do styku byt i jen s malymi boxy, vis, ze tuta verze IOS podporuje neco, jina podporuje neco jineho a v te, ktera podporuje obe dve pozadovane veci, je nejaky tezky bug ... :-)
Co se filtrovani delsich prefixu, opravdu tomu tak v nekterych US sitich je. Vysledkem nebyva obvykle nedostupnost, ale slozitejsi smerovani.
Pokud se tyce spolehlivosti, tak napriklad TEN-155 CZ ve sve vyrocni zprave uvedla na http://www.ten.cz/doc/zprava1999/provoz4.html statistiky provozu. Na nich muzes videt, kolik a jakych vypadku v siti TEN-155 CZ za rok 1999 bylo.

Protoze tomu tak neni. Viz prispevek Jirky Orsaga.

Porad nechapu, proc tak silne oponujete, ze to neni mozne. Sit GIN presto,
ze prisla o znacnou cast kapacity sve zahranicni konektivity,
fungovala bez vetsich a vaznejsich problemu. Problem backupu v 4,5Mbps
ci 100Mbps zustava stejny. Proste rozumny ISP si drzi linky nejmene 2 a
ma na nich dostatecnou rezervu.

Lidí se zkušenostmi s provozem velké sítě až tak moc není a proto jsem rád, když sem někdo z nich napíše. Já mám znalosti jen vyčtené a vypozorované.
Rozdíl mezi tím, když někdo překopne optiku podél ropovodu a tím, když se mi přihodí nějaká závada lokálně je v tom, že v prvním případě nemůžu dělat nic jiného než čekat, až bude závada odstraněna. Pokud se pokazí něco lokálně, mám mnohem větší šanci s tím něco udělat.
Traffic shape - ten klasický funguje jen v odchozím směru, ale pokud jsem se díval do Cisco QoS příručky, jsou i obousměrné metody, třeba CAR. Nebo jsem to pochopil špatně? Navíc snad nejsou stovky linek zákazníků připojeny do stejného routeru jako zahraniční linky?
Opravdu jsou multihomed zákazníci historie? Řekl bych, že tak polovina nově registrovaných AS jsou právě zákazníci.
S tím filtrováním delších prefixů než /19 se mi to nezdá. Třeba Inway posílá do světa zbytečné specifické sítě 212.24.128.0/24 a další, a šíří se naprosto identicky jako 212.24.128.0/19. Delší prefixy než /24 jsem viděl filtrovat, to ano. A třeba 194.50.2.0/24 spadá do sítě Českého Telecomu, tedy AS5610, kdyby se někde filtrovaly prefixy /24, tak by vůbec neměla ČMZRB spojení do světa, ne? Navíc to vypadá, že někteří provideři to PA neberou moc vážně a posílají do světa řadu specifických rout, i s různým routingem. A pokud si vzpomínám, staré /24 adresy 192.108.xx.0 jsou používány na střidačku v Česku a na Slovensku, to by také nemohlo fungovat.
Řešení s NATem a PA adresami od providera neřeší problém dostupnosti mé sítě ze světa - to bych nemohl provozovat žádné služby. Nebo dát obě IP adresy do DNS a spolehnout se na round robin? to by ale obě cesty musely být plnohodnotné, ne jedna záložní. Propagace změn v DNS je přeci jen pomalejší než v BGP.
Jednoduché řešení asi nebude, nicméně stále vyšší spolehlivost vzhledem ke komerčnímu využití Internetu bude vyžadována.

Inu, to jsou takove ty rady lidi, kteri nikdy s provozem velke
site neprisli do styku.
Ve skutecnosti je zajisteni 100% zalohovani s rustem prenosove
kapacity cim dal dulezitejsi ale i cim dal slozitejsi a drazsi.
Verit v zalohovani pomoci tranzitu pres jineho ISP mohou jen mensi
provideri s kapacitami par megabitu toku. Predstavovat si, ze je mozne obstastnit jineho providera nebo dokonce NIX treba 70 mbps
tokem bez nasledku je naivni. Vzajemne zalohovani je mozne pouze
u provideru srovnatelne velikosti s dostatkem rezervni kapacity.
Soucasny pad cen sluzeb na internetu vsak providerum nedava
velkou sanci na udrzovani dostatku nevyuzite kapacity pro
zalohu jineho ISP. Zalohovani tranzitem, ma vsak dost podstatne
slabiny. Tou prvni je lokalni pripojeni, tedy ten jeden svazek
kabelu, ktere vedou od centralniho uzlu k ruznym poskytovatelum
infrastruktury. To je jedno z nejpravdepodobnejsich mist zavady.
Sance, ze nekdo spolu s ropovodem prerve i vasi optiku je proti
pravdepodobnosti poskozeni lokalnich pripojeni, lidske
nebo hardwareove chybe pri provozu infrastruktury miziva. Druhou
slabinou zalohovani tranzitem je komplikovanejsi externi
routing, ktery mnohem casteji vede k problemum a k ztrate konektivity do nekterych casti Internetu.
K ruznym navrhovanym metodam reseni problemu vypadku:
-vypnuti news - u linek E3 a vic je efekt news zanedbatelny
-traffic shape - problem je v tom, ze traffic shape funguje
obracene nez by clovek potreboval (ono je to i logicke), a
umoznuje omezit odchozi provoz do interface. Tim byste mohl bud
zbrzdit odchozi provoz z vasi site na zahranicni lince, coz
nebude potreba, nebo budete muset implementovat omezeni na
stovkach linek k zakaznikum. Takovy zasah zpusobi v kombinaci
s distribuovanym cachingem s vysokou pravdepodobnosti mnohem
zavaznejsi provozni problemy nez prosty vypadek.
-multi-homed pripojeni zakaznici - zase jeden zbytek z historie
internetu. Aby zakaznik mohl byt pripojen s vlastnim AS pres vice
provideru, musi mit PI adresy. To znamena zridit vlastni lokalni
registrar a platit za nej. Tim dostane par vlastnich adres C
a bude moci zacit propagovat do Internetu vice cestami vlastni
prefix. Problem je, ale ze velci ISP v BGP filtruji prefixy
delsi nez /19 nebo /20 (tj 16 nebo 32C). To znamena nedostupnost
velke casti Internetu nebo minimalne vyrazne horsi routing.
Dalsi cenou, kterou bude muset zakaznik zaplatit je tlumeni
oscilaci BGP horsi nez u kratkych prefixu ISP. To znamena,
ze pri vypadku lokalniho pripojeni si zakaznik bude muset pockat
nez routery ISP znovu zaradi jeho prefix do routovacich
tabulek. Reseni s vlastnim AS je proto, stale casteji
nahrazovano resenim s NAT a PA adresami od 2 ISP. To, ale znamena
dvounasobnou spotrebu adres a ani to neni obecne doporucitelna
cesta.

Vůbec si nedělám legraci, připadá mi normální, jestli někdo chce kvalitnější službu, aby za to také více zaplatil.
Jestli budeu mít inet jen na browsení po webu, tak mi může být celkem jedno, jestli to a tam vypadne a občas i na celý den. Připojím se přes dialup jinam, a jsem v pohodě.
Ovšem jestli vedu přes Internet všechnu komunikaci s dodavateli a zákazníky a jednodenní výpadek mi může výrazně ohrozit obchody, připlatím si za spolehlivější linku, nebo spolehlivějšího providera. Pořád to vyjde mnohem levněji a jednodušeji, než se domluvat s českými providery o BGP a mít ke dvěma linku.

Pokud se tyce backup linky, nevim, kdo to v CR nabizi. Jedine, co si muzete koupit je UBR pasmo pres ATM, ale to zas tolik spolecnosti v CR nenabizi :-(
Hm ... Mate maly problem. Pokud udelate prilis tvrdy traffic shaping, mate smulu, protoze se tam useri stejne nedostanou. Pokud prilis mekky, dojde Vam kapacita. Potom take muzete usmazit router - pripadne obsluhu ...
Stejne musite mit v zaloze mezi 60-70 procenty bezneho trafficu, coz je dost.
S temi 2 typy smluv si delate legraci, ze ? :-)

Většina diskusních příspěvků se točila okolo toho, je-li únosné zajistit 100% zálohování. Pochopitelně není a není to ani nutné, Internet má tu vlastnost, že se umí vyrovnat i se sníženou kapacitou linek. Ale je řada způsobů, jak může ISP dosáhnout toho, aby byli uspokojeni zákazníci, kteří jsou na Internetu životně závislí. Jen pár poznámek:
- backup linky od backbone providerů bývají levnější než plnohodnotné stále využívané
- záložní spoj nemusí mít stejně velkou kapacitu
- na záloze se lze dohodnout s jiným ISP a zálohovat přes NIX
- po dobu výpadku hlavního spoje lze omezit provoz např.
-- přestat stahovat news
-- udělat traffic shaping na některé služby, třeba protokol ftp nebo server download.microsoft.com nebo jiné, které podstatně zatěžují zahraniční linku
-- mít se zákazníky 2 typy smluv, kde v té levnější bude staboveno, že v případě výpadku zahraniční linky bude dotyčný zákazník odpojen
A jistě by se našla i další opatření. To bylo, co může udělat český ISP pro své zákazníky. Pochopitelně se může domluvit i s dodavatelem trasy na záloze. Další pro zvětšení své spolehlivosti může udělat backbone provider, a ISP si může podle toho vybírat.
No a nakonec se může zabezpečit i zákazník. Ovšem plnohodnotnou zálohu získá jen v případě, kdy má vlastní autonomní systém a BGP routing - jinak se přes záložní linku sice dostane ven, ale nikdo k němu. A řešení s vlastním AS je sice ve světě obvyklé, nikoliv však v Česku. Stačí se podívat do RIPE databáze a zjitíte, že každá větší firma nebo banka v Evropě má vlastní AS a připojení na více providerů.