Hlavní navigace

Vlákno názorů k článku Multihoming - všelék nebo cesta ke zkáze? od David Rohleder - 1. BGP umoznuje pouziti pouze priblizne 65000 AS,...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 1. 2001 15:24

    David Rohleder (neregistrovaný)
    1. BGP umoznuje pouziti pouze priblizne 65000 AS, takze takova vec jako multihoming mezi vice provideru je ponekud problematicka z hlediska pridelovani cisel AS.

    2. musite mit dost velkou sit, aby vas provideri pri kazdem zahoupani site neodrizli na hodne dlouhou dobu.

    3. chudaci technici, kdyz budete kupovat kazdy tyden konektivitu od nekoho jineho a oni budou muset pracne vyvazovat BGP :-)

    Pro spoustu aplikaci by klidne stacilo mit konektivitu od vice provideru bez AS a pouzivat jenom vice A zaznamu v DNS. Treba takto:


    www.lupa.cz IN A ip_od_jednoho_prov.
    IN A ip_od_druheho_prov.


    Neni to nic moc, ale na zakladni dostupnost by to snad mohlo stacit.
  • 29. 1. 2001 16:05

    MK (neregistrovaný)
    Davide,
    verim, ze problem s poctem AS se da relativne snadno obejit. Na poslednim RIPE meetingu byla tato vec zminovana a vysledkem bylo konstatovani, ze existuji zalezitosti, ktere dojdou drive - napriklad IPv4 adresy :-)

    Je otazkou, zda-li budou muset technici vyvazovat BGP cesty. Treba shodite vsechny ostatni okruhy. Uz dnes se uvazuje o spusteni burzy konektivity (ne u nas) - tj. muzete nakoupit na pristi mesic STM-1 do USA na burze. Pritom muzete shodit sve soucasne pripojky. Myslim, ze cenove se to (casem, ne dnes) vyplati i pri vetsi praci techniku.

    Navrh round-robin DNS je uplne to nejhorsi, co muze byt pro normalniho uzivatele. On totiz absolutne potom nepozna, proc mu ten web nejede. A zkuste jako normalni user rict svemu TCP/IP stacku, ze ma znovu zresolvovat dany zaznam ... Myslim, ze se Vam to nepodari.

  • 29. 1. 2001 16:31

    PG (neregistrovaný)
    > www.lupa.cz IN A ip_od_jednoho_prov.
    > IN A ip_od_druheho_prov.

    tohle je napad, ktery prinasi vic problemu nez uzitku. Vubec neresi zalohovani jedne linky druhou a navic musite resit, odkud prisel DNS dotaz a podle toho vracet IP adresu cile (v opacne pripade dopadnete jako E-city).



  • 29. 1. 2001 16:56

    Petr Souček (neregistrovaný)
    To mě zajímá - jak se dají problémy s nedostatkem čísel pro AS obejít? Musím říct, že mě docela překvapuje, že dříve dojdou IPv4 adresy než čísla AS, protože, alespoň v měřítku ČR, přibývají přdělené IPv4 adresy v řádu jednotek procent ročně, ale čísla AS v řádu desítek procent ročně.
  • 29. 1. 2001 18:54

    MK (neregistrovaný)
    CR neni pupek sveta :-) Co se prirustku tyce, nezapomente na fakt, ze zatimco IP adresy se prideluji po blocich, tak cisla AS je prideluji po jednotkach. Tim padem jen tezko odhadnete, jak rychle roste spotreba IP adres u nas. Granularita narustu je nesrovnatelna.

    No ten clovik tam rikal, ze prinejhorsim BGP5 rulez :-)

  • 29. 1. 2001 20:12

    David Rohleder (neregistrovaný)
    Jenze jake moznosti ma normalni vlastnik serveru, ktery chce zajistit, aby byl jeho stroj stale dostupny?

    1. muze umistit stroj u nejakeho housovaciho centra, ktere ma svuj vlastni AS, ale treba ma citliva data, nebo chce casto zalohovat nebo mu to nevyhovuje z jinych duvodu.

    2. muze mit vlastni AS, coz ma nasledujici nevyhody:
    i) pokud ma maly rozsah IP adres, tak ho BGP pri kazdem zahoupani site dumpne na nekolik desitek minut.
    ii) pocet AS neni nafukovaci a toto reseni neni pro kazdeho.

    3. muze mit prave round-robin DNS s tim, ze
    i) bude mit dostatecne nizke TTL u zaznamu, takze se v cache neudrzi prilis dlouho. Pak muze automaticky zjistovat stav linek a patricne zaznamy vyhazovat z DNS. Zvedne se mu sice provoz na DNS, ale to se snad da ustat.
    ii) slusne aplikace postavene na TCP mohou zkouset vsechny adresy, ktere dostanou a ne se hned sesypat na prvnim ICMP unreachable. Takove chovani jsem pozoroval treba u telnetu na un*xu. Vetsina sluzeb je dneska TCP, takze by to nebyl takovy problem. Staci dostatecne dobra libc :-)
  • 30. 1. 2001 9:32

    MK (neregistrovaný)
    Primarne NEBYL diskutovan pripad poskytovatele obsahu.

    Vase Unixocentricnost ve me vyvolava pobaveny usmev.

  • 30. 1. 2001 10:20

    David Rohleder (neregistrovaný)
    Dobre tedy, tak co tedy bylo diskutovano? Kdyz rozdelime Interenet na poskytovatele obsahu, prepravni infrastrukturu a koncoveho odberatele takoveho obsahu, tak ke ktere skupine miril?

    Tvrdite, ze nebyl diskutovan pripad poskytovatele obsahu, pak ale u ISP je slusnost mit vlastni AS (s linkami k ruznym providerum) a koncoveho uzivatele jste snad na mysli mit nemohl. Nebo ze by existovala jeste nejaka jina, mne neznama, skupina uzivatelu Internetu?

    Ad ma unixocentricnost: nevim proc by se takto nemohl chovat treba TCP/IP stack od Microsoftu, ja jsem jenom ukazal, ze pokud se pouzije vhodny TCP/IP stack a dobre napsana aplikace, tak muze byt round-robin DNS take reseni. Nehlede na to, ze dostatecne male TTL u tech zaznamu by tento problem take castecne resilo. To, ze nemam dost velke zkusenosti se stackem od Microsoftu muze byt z vasi strany povazovano za mou fatalni neznalost, ale bohuzel jsem nezpozoroval zadny padny argument proti popisovanemu reseni.
  • 30. 1. 2001 10:26

    MK (neregistrovaný)
    Cilovou skupinou byli ISP a firmy :-) Asi jsem to mel precizneji formulovat.

    U ISP je NAOPAK velmi neefektivni mit linky k ruznym tranzitnim sitim - zkuste o tom podiskutovat v TEN-provoz :-).

    Vami navrhovane reseni znamena prepsat vetsinu soucasnych TCP/IP stacku (a aplikaci). Snizenim TTL v DNS zaznamu docilite pouze toho, ze se problem projevi u VETSIHO poctu uzivatelu.

  • 30. 1. 2001 15:36

    PG (neregistrovaný)
    > Linky ke 2 providerum maji zase tu nevyhodu, ze pri
    > vypadku obou linek a malem pridelenem rozsahu IP
    > adres se cesta ztrati z internetu na pomerne dlouhou
    > dobu, diky dumpovani cest v BGP.

    S tim dumpovanim bych to nevidel tak tragicky. K tomu dojde pouze pokud zacne linka flapovat. Obvykly vypadek a zpetny nabeh se negativne neprojevi.

    Na velikosti rozsahu u PI myslim az tak nezalezi, ono to stejne nejde agregovat, takze to vystupuje jako samostatny prefix. Nebo se snad pletu?
  • 30. 1. 2001 15:58

    David Rohleder (neregistrovaný)
    Na rozsahu IP adres opravdu nemusi zalezet, zalezi spis na parametrech Penalty, half-life-time, suppress limit, reuse limit. Ale i tak se muze pri oscilovani jednat spise o desitky minut, kdy je ta linka uz OK.

    Ja samozrejme proti reseni pomoci AS nic nemam, ale tvrdim, ze neni dostatecne rozsiritelne pouzitelne (prave diky limitu na 65000 AS).

    Jeste mne navic nikdo nepresvedcil, ze reseni pomoci round-robin DNS je nepouzitelne.
  • 30. 1. 2001 11:22

    David Rohleder (neregistrovaný)
    Takze:

    Cilovou skupinou byli ISP: kazdy slusny ISP ma vlastni AS, takze o cem je rec?

    Cilovou skupinou byly firmy: to jsou poskytovatele obsahu, nebo jejich konzumenti?

    Netvrdim, ze je efektivni mit linky k ruznym tranzitnim sitim, ale ze je to z hlediska pripadne havarie lepsi (vsichni si pamatujeme prekopnuty kabel od MERO v nemecku). Bud budu mit dve linky k ruznym providerum, nebo muzu mit dve linky k jednomu providerovi do dvou ruznych lokalit (a z ruznych vychozich bodu). Aby az zacne v metru horet o stanici dal, cela sit nebyla odriznuta do doby nez se to opravi.

    Proc snizenim TTL dosahnu toho, ze problem se projevi u VETSIHO poctu uzivatelu jaksi vubec nechapu. Nejaky podrobnejsi popis by nebyl?
  • 30. 1. 2001 11:38

    David Rohleder (neregistrovaný)
    Myslim, ze i se skromnymi prostredky toho lze hodne udelat. Pri dostatecne nizkem TTL vim, ze se zaznamy v TCP/IP stacku v podstate vubec nedokazou udrzet a tak v pripade vypadku linky muzu tu spatnou IP adresu z DNS smazat.

    Pokud mam jeste navic schopny DNS server, tak muzu dokonce vhodne rozkladat zatez podle aktualniho zatizeni linky (procentualni zmeny cetnosti odpovedi na DNS dotazy). Pokud tedy vychazim z predpokladu, ze moje linky jsou uzsi nez linky poskytovatele a maji tak na konektivitu nejvetsi vliv.

    Tento postup predpoklada kroky pouze na strane serveru (tj. toho, kdo chce mit redundantni spojeni) a ne na strane klienta. Tedy pokud se ten klient chova v souladu se standardy (a necachuje DNS zaznamy pres dobu jejich zivotnosti).
  • 30. 1. 2001 12:55

    PG (neregistrovaný)
    > Myslim, ze i se skromnymi prostredky toho lze hodne
    > udelat. Pri dostatecne nizkem TTL vim, ze se zaznamy v
    > TCP/IP stacku v podstate vubec nedokazou udrzet a tak v
    > pripade vypadku linky muzu tu spatnou IP adresu
    > z DNS smazat

    jo, akorat ze vypadky zasadne prichazeji v dobe, kdy nelze dostatecne rychle reagovat (nejlepe pozde v noci ze soboty na nedeli a to pouze tehdy, kdyz vsichni administratori odjeli na dovolenou do pralesa) :-)

    > Pokud mam jeste navic schopny DNS server, tak muzu
    > dokonce vhodne rozkladat zatez podle aktualniho zatizeni
    > linky (procentualni zmeny cetnosti odpovedi na DNS
    > dotazy). Pokud tedy vychazim z predpokladu, ze moje
    > linky jsou uzsi nez linky poskytovatele a maji tak na
    > konektivitu nejvetsi vliv.

    uff, chcete odhadovat zatizeni linky podle cetnosti DNS dotazu? Hodne stesti (ale nezalezi na IP adrese zdroje dotazu vice nez na vytizeni liky?. Na druhou stranu, BGP rozhodne nevyvazuje podle zatizeni linky, to ho prakticky nezajima, pouze se snazi za pouziti svych kriterii nalezt nejvyhodnejsi cestu).

    Reseni u firmy (nebo poskytovatele obsahu) bych videl bud v existenci 2 nezavislych linek ke stejnemu ISP (samozrejme to musi byt ISP trochu na urovni) a pouziti nejakeho rychle konvergujiciho smerovaciho protokolu (nebo staticke smerovani s pouzitim metriky za predpokladu, ze jedna z cest je ciste zalozni), nebo pouzit PI space a linky k ruznym ISP.


  • 30. 1. 2001 15:03

    David Rohleder (neregistrovaný)
    > jo, akorat ze vypadky zasadne prichazeji v dobe, kdy nelze > dostatecne rychle reagovat (nejlepe > pozde v noci ze soboty na nedeli a to pouze tehdy, kdyz
    > vsichni administratori odjeli na dovolenou do pralesa) :-)

    To si pak nesmite zrizovat vzdy dosazitelny server. Nehlede na to, ze to jde delat automaticky.

    > uff, chcete odhadovat zatizeni linky podle cetnosti DNS
    > dotazu? Hodne stesti (ale nezalezi na IP adrese zdroje
    > dotazu vice nez na vytizeni liky?. Na druhou stranu, BGP
    > rozhodne nevyvazuje podle zatizeni linky, to ho prakticky
    > nezajima, pouze se snazi za pouziti svych kriterii nalezt
    > nejvyhodnejsi cestu).

    Spatne jste mne pochopil. Chtel jsem podle zatizeni linek generovat odpovedi na DNS dotazy. Tj. pomer zatizeni 60:40, generuj odpovedi tak, aby byl pomer odpovedi 40:60 na tu spravnou linku. Pri padu linky zmenim jedno cislo na 0, tj. generuj odpovedi v pomeru 0:100.

    Samozrejme, ze by bylo nutne to trochu vyladit, aby odpovedi neskakaly 100:0, 0:100, ale to je takovy maly statisticky problemek, ktery je lehce resitelny.

    Reseni je samozrejme, jak pisete, 2 nezavisle linky k jednomu providerovi, jenze problem je vetsinou v tom, ze vnitrni infrastruktura ISP nemusi byt dostatecne redundantni (popripade je pripojen pouze k jednomu poskytovateli mezinarodni konektivity, nebo ke dvema, ale linky jdou jednim kabelem (MERO :-))

    Linky ke 2 providerum maji zase tu nevyhodu, ze pri vypadku obou linek a malem pridelenem rozsahu IP adres se cesta ztrati z internetu na pomerne dlouhou dobu, diky dumpovani cest v BGP.
  • 30. 1. 2001 19:19

    MK (neregistrovaný)
    Zbyva jen presvedcit nekoho, aby to reseni implementoval. V opacnem pripade je to TEZCE akademicka diskuse :-)
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).