Vlákno názorů k článku NIX byl dopoledne nakrátko mimo provoz od PJ NIX.CZ - Dobrý večer. Rád bych zde uvedl pravé důvody...
-
PJ NIX.CZ (neregistrovaný)Dobrý večer. Rád bych zde uvedl pravé důvody a průběh dnešního výpadku switche v jednom z peeringových uzlů NIX.CZ. Při rekonfiguraci přípojky jednoho člena došlo k restartu switche NIX4-acc1 (Sitel), což zapříčinilo jeho výpadek v době od 10:33-10:39 hodin. Tento výpadek afektoval pouze přípojky tohoto switche. Za výpadek se NIX.CZ omlouvá. S pozdravem PJ NIX.CZ.
-
Vypadek jenoho switche samozrejme NIX nepolozi a ani se to nestalo - pouze autor tohoto clanku ma dojem ze bude vypadat dulezite kdyz napise "katastrofickou novinku". Pouze se jeden switch restartoval. Tech switchu je samozrejme vic a zakaznici NIXu kteri byli pripojeni pouze na tento jeden switch byli chvili bez peeringu prez NIX. Ale to opet neni zadny vypadek sluzeb - slale maji fungujici tranzitni konektovitu. -
Nesouhlasim - ISP s pouze jedinou linkou do jedine lokality NIXu s timto samozrejme musi pocitat. A problem s takto mizernou redundanci se na zakaznicich musi projevovat mnohem castedi diky jinym problemum v sitich samotnych ISP. A vzhledem k tomu, ze veskere sluzby NIXu jsou pouze na L2, je jakakoliv diskuse ohledne rychlosti reakce BGP zcela mimo...
-
ZP (neregistrovaný)S tim pocatkem souhlas, byl to jeden switch, vypadek nebyl totalni, nebyl ani zasadni.
S cim ale nelze souhlasit je ta posledni veta. Ty BGP relace tecou pres ten L2 ethernet segment NIXu. Kdyz dojde k vypadku nekde jinde, ne mezi zarizenim ISP a switchem IXP, BGP resp. zadny smerovaci protokol si toho nevsimne az do okamziku, nez mu neprijdou keepalive (pokud tam neni zapnute BFD, coz ale v tomto pripade neni prave obvykle). Nekolikaminutova nedostupnost urcite casti ceskeho Internetu tak vzniknout mohla a s nejvetsi pravdepodobnosti take vznikla a to i v pripade, ze postizena byla jen jedna ze dvou existujicich pripojek dotycne site. -
anonymníNekolika minutovy vypadek nejen ze vzniknout mohl, on skutecne vznikl. Napr ze site GTS nebyly nektere prefixy min 5 minut dostupne.
Skoro mam pocit ze autor prispevku vyse (Stanislav Petr) vi o routovani mene nez domaci amatersky sitar. Ono totiz nejakou dobu (jak bylo receno) trva, nez routery zjisti ze je na lince neco spatne a BGP rozhodne nepatri mezi "rychle" routovaci protokoly.
BTW: Mozna ze kdyby nekdo pred restartem myslel hlavou a ne kolenem, tak mohl aktivne preroutovani vynutit a pak teprve switch restartnou. Navrch mi tedy neprijde zrovna koser hrabat se v konfiguraci "provozniho" zeleza za chodu a podle vseho bez otestovani jinde. -
anonymníJeden vskutku kuriozni navrh predvedl na RIPE58 zde pritomny ZP :-) Ale moc se s pochopenim nesetkal, spis demonstroval nepochopeni elementarnich RFC... ;)
-
anonymníNevim, na koho ted konkretne narazite - krome postuchovani na Lupe jsem s Vami zadnou jinou debatu nevedl a nevzpominam si, ze by tu pred 3-4 roky byl nejaky clanek, kde by se implementace VPLS kdekoliv rozebirala. Srovnani s AMS-IXem je obecne zajimave, tamni reseni je ve srovnani s NIX.CZ dlouhodobe mnohem robusnejsi a mit zde podobne reseni, dost mozna by tato zpravicka na Lupe nebyla.
Usklebek ma nicmene zcela racionalni zaklad. Ve Vasem RIPE blabolu navrhujete resetovani BGP session na urovni L2 switche. Pres tri roky tu mame RFC 4271, ktere mimo jine oznacuje implementaci TCP MD5 za povinnou (vyklad slovicka MUST naleznete v RFC 2119). Vas radobynavrh je v tomto smeru krokem zpet a popira nekolik let stara doporuceni tykajici se zabezpeceni BGP sessions. Vubec zde nerozebiram, jakou logikou by ten L2 switch musel disponovat, aby zvladnul hlidat tisice soubeznych TCP spojeni jen ve vztahu k BGP, a to se vsim, co k TCP patri. Ale hadam, ze jiz Vam nekdo v kuloarech vysvetlil, o jakou kravinu se jedna, kdyz tu takhle kopete kolem :-)
A ten zde popsany patecni problem by beztak nevyresilo ani VPLS. I jeho implementace v AMS-IXu je sporna, podle aktualniho schematu zde stale maji technologii, ktera VPLS nepodporuje, takze bud lzete Vy nebo to schema... -
ZP (neregistrovaný)Implementace MD5 je mozna povinna pro vsechny, kdo implementuji BGP protokol, ale vtip je, ze ten navrh z BGP nevyzaduje implementovat vubec nic, vyuziva se pouze nastroju cisteho TCP... Logiku maji vsechny soucasne velke switche slusnou (dokonce uz primo na linekartach), obvykle podporuji i L3 a jeste mnoho dalsich, zajimavejsich funkci, cili i tento argument je nonsens.
Dalsi vec je, ze MD5 je obecne povazovan za nedostatecny uz cca pet let. To jenom tak, abychom vedeli, nakolik se zde vubec bavime o nejake mire zabezpeceni...
Kdyz uz musite uzivat silna slova, tak byste si mohl zjistit, ze to schema uz ma sva nejlepsi leta za sebou. Zkuste treba http://www.peering-forum.eu/assets/Presentations/steenmanamsixamsixv4.pdf , je asi momentalne nejaktualnejsi. Ta migrace je mimochodem v plnem proudu od cervence, ted mame uz skoro rijen...
(ale s tim, ze patecni problem by VPLS nevyresilo, souhlasim) -
anonymníCiste TCP se ale u BGP pouziva maximalne jen v siti nejakych looseru, kteri na bezpecnost totalne kaslou (ze by to byl i Vas pripad?). Dale dokazujete, ze na zaklade obecnych proposalu kolem MD5 implikujete, ze je nesmysl je pouzivat - faktem je, ze v soucasnosti na TCP neexistuje lepsi mechanismus zabezpeceni (vynechame-li IPSEC). Ano, az bude schopen resetovat pomoci MD5 zabezpecene BGP, dejte vedet... pokud je mne znamo, tak seriozni poskytovatele vyuziti MD5 vyzaduji.
Zjevne jste nikdy neresil programovani nejakeho hardware, protoze si to ocividne predstavujete jako hurvinek valku.
Navic se mi nepozdava, ze by AMSIX na vlastnich webovych strankach neprezentoval sve aktualni technicke reseni.
Ale co, ztrapnujete se tu sam, necht kazdy vidi, jaky jste to profesional ;-) -
ZP (neregistrovaný)Jiste, vy se ztrapnit nemuzete, vas chrani vase anonymita. Jinak by vas ztrapnilo uz jen to slovo "looser" :-)
Krome toho asi netusite, ze MD5 hash je jednim ze slabych mist velkych smerovacu, pomerne maly utok dokaze velkemu boxu velmi elegantne utocit procesor. A ty BGP relace lze zabezpecit i jinak... -
anonymníNegeneralizoval bych na základě zkušeností s platformou, kterou ve Vaší síti používáte. Vaše Cisco 7600 není velký směrovač, je to velký přepínač na třetí vrstvě, měl byste se naučit tyto elementární věci odlišovat. Chyba v konkrétní implementaci navíc není chybou principielní, ale chybou právě té dané implementace. A že zrovna software pro tu Vaši platformu velkého rádoby-směrovače je plné všelijakých chyb je vcelku známý fakt. IOS coby monolitický software je svou architekturou dávno za horizontem své morální životnosti, což si uvědomuje i Cisco a na skutečně velké směrovače dodává software architektonicky zcela odlišný.
-
ZP (neregistrovaný)1. byl jsem to prave ja, kdo tu pred lety tvrdil totez, co rikate vy. slovo smerovac bylo v predchozich prispevcich pouzito jako obecne oznaceni cehokoli, co umi nejakym zpusobem na L3 forwardovat packety
2. chcete rici, ze kuprikladu GSR se necim takovym utlouci neda? :-)
(ackoli se nebudu prit o tom, ze to da o neco vice prace, nez umlatit kuprikladu Vami zminovanou hybridni platformu).
3. moznost utlouci procesor DoSem na nejakou funkci v software s monolitickou architekturou nesouvisi ani malo (aneb i v tom monolitickem software existuji procesy ci, chcete-li, thready a teoreticky by bylo mozne dat kazdemu takovemu procesu nejakou kvotu na systemove zdroje... ze by pro reseni podobneho problemu bylo idealni, aby kazdy peer ci peer-group mely samostatny takto okvotovany proces, je jina vec, zase by to bylo vykoupeno nedostatky nekde jinde, napriklad v poctu peeru, ktere ten box zvladne a opet by ten problem nesouvisel s architekturou software...) -
Ale BGP session prece neni svazana s konkretnim portem v konkretnim switchi a vsechny lokality Prazskeho NIXu jsou jeden spolecny L2 segment... Takze cela vec je spravnou konfiguraci resitelna primo na L2 a neni potreba do toho zatahovat vyzsi protokoly, protoze ty se pri odpovidajici konfiguraci o tom v podstate ani nemusi dozvedet.
-
ZP (neregistrovaný)BGP session samozrejme je svazana s konkretnim portem v konkretnim switchi. (pouzivani VRRP v NIXu zakazuje provozni rad, proxy-arp take a jen pouha predstava, ze na NIX navazuje dalsi zakruhovana L2 infrastruktura jednotlivych ISP, bude zpusobovat husi kuzi lidem nejen v NIXu, ale i u tech poskytovzatelu).
ČLÁNKY DO MAILU