pardon za translit. nekotorye vozmozhno budut proinformirovany iz "kompetentnykh istochnikov", nekotorye net. pishu eto pis'mo, chtoby podcherknut' vazhnost' dannogo bug'a, kotoryj cisco derzhala v sekrete (minimum - tol'ko to, chto mne izvestno) 2.5 mesyatsa. primerno 2.5 mesyatsa nazad my zakonchili ocherednoj upgrade IOS vo vsej nashej ne malen'koj seti. ne proshlo i nedeli kak vsplyla cisco s rekomendatsiej *nemedlenno* upgradit'sya na sled. versiyu. my, estestvenno, stali nedoumevat': da vy chto, okhreneli? my zh tol'ko chto upgrade zakonchili. oni togda priznalis', chto obnaruzhili v IOS *takoj* bug, o kotorom skazat' ne mogut, no esli ne khotim nepriyatnostej na popu, to nado upgradit'sya. :D nu ladno, sdelali upgrade, po-bystren'komu, za nedelyu. vchera v conference call'e (u nas s nimi takovye prokhodyat raz v nedelyu, po otkrytym cases, etc.) oni nakonets-to priznalis', chto v IOS imeet mesto byt' ochen' ser'eznaya dyra, kotoraya suschestvovala vo vsekh trains so vremen tsarya Gorokha, a imenno s version 10.0. skazali, chto na dnyakh opublikujut oficial'noe soobschenie na website. segodnya vecherom oni ego taki opublikovali: http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml est' tak zhe versiya dlya tekh, u kogo est' support contract: http://www.cisco.com/en/US/customer/products/hw/routers/ps341/products_secur... no po-moemu ona nichem ne otlichaetsya :-) primechatel'no to, chto oni rekomendujut ACLs as workaround, kotorye na nekotorykh platformakh prosto protivopokazany. bezboleznennogo vam upgrade'a, dorogie kollegi :-) osobenno tebe, Doka@ :-) P.S. ne podumajte chto zanimayus' reklamoj, no ochen' rekomenduju Juniper. bug'ov na nes-ko poryadkov men'she chem u Cisco, priyaten v ispol'zovanii, men'she hidden commands, unbeatable support, i JunOS sdelana iz FreeBSD 4, kotoroe bol'shinstvo zdes' prisutstvujuschikh ves'ma lyubit :-) moemu frustration with Cisco prosto net predela. esli vdrug kogo zainteresujet pochemu imenno, pishite off list - a to vdrug zdes' est' predstaviteli onoj - pob'yut escho.. :-)) Regards, Igor Chunikhin. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Jul 17, 2003 at 07:09:49AM +0300, igor@ktts.kharkov.ua wrote:
primerno 2.5 mesyatsa nazad my zakonchili ocherednoj upgrade IOS vo vsej nashej ne malen'koj seti. ne proshlo i nedeli kak vsplyla cisco s rekomendatsiej *nemedlenno* upgradit'sya na sled. versiyu. my, estestvenno, stali nedoumevat': da vy chto, okhreneli? my zh tol'ko chto upgrade zakonchili. oni togda priznalis', chto obnaruzhili v IOS *takoj* bug, o kotorom skazat' ne mogut, no esli ne khotim nepriyatnostej na popu, to nado upgradit'sya. :D
security шантаж называется ;_)
segodnya vecherom oni ego taki opublikovali: http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
я так понимаю, что дырка только в CPU-routed траффике для самого роутера? то есть если траффик транзитный или его обрабатывает карта (как там оно называется в циске... hardware-switched, что ли?) то это неактуально?
primechatel'no to, chto oni rekomendujut ACLs as workaround, kotorye na nekotorykh platformakh prosto protivopokazany.
типа закрыть на вход все пакеты для management адресов, или поставить входной ACL на самих роутерах? а что тут такого? а вообще - хороший повод купить новое железо 36xx серии ;) о, еще один workaround, не упомянутый cisco - не включать ipv4 на самих роутерах, оставить только ipv6... интересно, работает ли у них tftp и rshell через ipv6?
P.S. ne podumajte chto zanimayus' reklamoj, no ochen' rekomenduju Juniper. bug'ov na nes-ko poryadkov men'she chem u Cisco, priyaten v ispol'zovanii, men'she hidden commands, unbeatable support, i JunOS sdelana iz FreeBSD 4, kotoroe bol'shinstvo zdes' prisutstvujuschikh ves'ma lyubit :-) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
In original message =?koi8-r?B?RG1pdHJ5IEtvaG1hbnl1ayDkzcnU0snKIOvPyM3BzsDL?= writes:
http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
я так понимаю, что дырка только в CPU-routed траффике для самого роутера? то есть если траффик транзитный или его обрабатывает карта (как там оно называется в циске... hardware-switched, что ли?) то это неактуально?
nazyvaetsya CEF - Cisco Express Forwarding. otdel'nayta pesnya. escho est' Process Switched Packets - eto kogda CEF disabled i vsyo routitsya cherez GRP/RSP (CPU). v documente mutno napisano: "A rare, specially crafted sequence of IPv4 packets which is handled by the processor on a Cisco IOS device may force the device to incorrectly flag the input queue on an interface as full....." - delo v tom, chto v bol'shikh router'akh tipa 75xx i 12xxx kazhdaya linecard eto otdel'nyj Cisco IOS device and handled by the processor :D no v documente oni privodyat ACL gde transit razreshen, tak chto pokhozhe, chto s nim vsyo ok.
primechatel'no to, chto oni rekomendujut ACLs as workaround, kotorye na nekotorykh platformakh prosto protivopokazany.
типа закрыть на вход все пакеты для management адресов, или поставить входной ACL на самих роутерах? а что тут такого?
a takogo tut to, chto naprimer na serii 12xxx (GSR) ACLs, policy i/ili netflow na interface IOS na linecard ili na GRP/RSP crash'itsya. khotite verlte, khotite net. :-)
а вообще - хороший повод купить новое железо 36xx серии ;)
da, a chem tebe 36xx pomozhet? :-)
о, еще один workaround, не упомянутый cisco - не включать ipv4 на самих роутерах, оставить только ipv6... интересно, работает ли у них tftp и rshell через ipv6?
nu, IPv6, esli ya ne oshibayus', tol'ko v T train'e poka est', a eto dlya samoubijts :-) plus k tomu, etot workaround budet rabotat' tol'ko esli transit traffic dejstvitel'no not affected. Regards, Igor. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Jul 17, 2003 at 08:28:11AM +0300, igor@ktts.kharkov.ua wrote:
In original message =?koi8-r?B?RG1pdHJ5IEtvaG1hbnl1ayDkzcnU0snKIOvPyM3BzsDL?= writes:
http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml
я так понимаю, что дырка только в CPU-routed траффике для самого роутера? то есть если траффик транзитный или его обрабатывает карта (как там оно называется в циске... hardware-switched, что ли?) то это неактуально?
nazyvaetsya CEF - Cisco Express Forwarding. otdel'nayta pesnya. escho est' Process Switched Packets - eto kogda CEF disabled i vsyo routitsya cherez GRP/RSP (CPU).
heh... CEF и hardware-switched - это несколько разные песни, да и process-switching бывает не только когда cef disabled...
v documente mutno napisano: "A rare, specially crafted sequence of IPv4 packets which is handled by the processor on a Cisco IOS device may force the device to incorrectly flag the input queue on an interface as full....." - delo v tom, chto v bol'shikh router'akh
Похоже на то, что все-таки эти пакеты должны идти на сам раутер, и именно поэтому попадать в process switching. Пакеты, идущие транзитом (в то числе первый пакет, который может быть process-switched) раутер не аффектят, в том числе в случаях Flow или Fast switching'а. (по крайней мере workaround'а типа "срочно включайте CEF" там нет.)
tipa 75xx i 12xxx kazhdaya linecard eto otdel'nyj Cisco IOS device and handled by the processor :D no v documente oni privodyat ACL gde transit razreshen, tak chto pokhozhe, chto s nim vsyo ok.
primechatel'no to, chto oni rekomendujut ACLs as workaround, kotorye na nekotorykh platformakh prosto protivopokazany.
типа закрыть на вход все пакеты для management адресов, или поставить входной ACL на самих роутерах? а что тут такого?
a takogo tut to, chto naprimer na serii 12xxx (GSR) ACLs, policy i/ili netflow na interface IOS na linecard ili na GRP/RSP crash'itsya. khotite verlte, khotite net. :-)
Работает и не крэшится :)) Правда, netflow исключительно sampled, но из GSR'а больше и не вынешь... И вообще, GSR'ы - это исключительно core железка, ставить ее на ingress point не стоит. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
In original message Alexandre Snarskii writes:
escho est' Process Switched Packets - eto kogda CEF disabled i vsyo routitsya cherez GRP/RSP (CPU).
heh... CEF и hardware-switched - это несколько разные песни, да и process-switching бывает не только когда cef disabled...
bezuslovno. eto bylo vkrattse. pozhalujsta, pros'ba ne somnevat'sya v znanii predmeta :-))
Похоже на то, что все-таки эти пакеты должны идти на сам раутер, и именно поэтому попадать в process switching. Пакеты, идущие транзитом (в то числе первый пакет, который может быть process-switched) раутер не аффектят, в том числе в случаях Flow или Fast switching'а. (по крайней мере workaround'а типа "срочно включайте CEF" там нет.)
ya tozhe tak schitayu.
tipa 75xx i 12xxx kazhdaya linecard eto otdel'nyj Cisco IOS device and handled by the processor :D no v documente oni privodyat ACL gde transit razreshen, tak chto pokhozhe, chto s nim vsyo ok.
primechatel'no to, chto oni rekomendujut ACLs as workaround, kotorye na nekotorykh platformakh prosto protivopokazany.
типа закрыть на вход все пакеты для management адресов, или поставить входной ACL на самих роутерах? а что тут такого?
a takogo tut to, chto naprimer na serii 12xxx (GSR) ACLs, policy i/ili netflow na interface IOS na linecard ili na GRP/RSP crash'itsya. khotite verlte, khotite net. :-)
Работает и не крэшится :)) Правда, netflow исключительно sampled, но из GSR'а больше и не вынешь... И вообще, GSR'ы - это исключительно core железка, ставить ее на ingress point не стоит.
rabotaet tol'ko Engine 4+ i Engine 2. a, zabyl escho rate limit dobavit' - ot nego tozhe crashitsya, bo tozhe rabotaet cherez PSA. estestvenno chto na core routers access lists i prochiya ne nuzhny. za isklyucheniem tekh sluchaev, kogda nuzhno srochno ostanovit' DDoS attack. mogu rasskazat' strashilku, kotoraya proizoshla nakanune Novogo Goda. koe-kto iz etogo spiska ee uzhe slyshal, posemu ne obessud'te :-) takaya znachit kartinka: Customer <--T3--> AR <--OC-3--> CR-1 <--OC-48--> CR-2 AR - Access router, 7513, k kotoromu podklyuchen customer OC-3 - 155MBit CR-1 - Core Router 1, GSR 12016. CR-2 - Core Router 2, GSR 12416. OC-48 - 2.4GBit T3 - 45.87MBit atakovali customera nashego customera :-) pakety, estestvenno, zabivayut naproch' T3 link. pomimo etogo IS-IS mezhdu AR i CR-1, i CR-1 i CR-2 nachinaet flap'at'. dlya bol'shoj seti eto big deal - SPF calculation, IBGP dokhnet, etc. OC-3 i OC-48 links zagruzheny na 28 i 23% sootvetstvenno. voznikaet zakonnyj vopros: kakogo khrena flap'aet IS-IS? posle 3-kh dnej razbiratel'stva Cisco support vydal: "a huge amount of traffic is coming INTO this interface POS 1/0 destined to be switched OUT of a slower interface on CR-1 (POS 0/1 which connects to AR) causing backpressure. " kak mozhno mozhno ubit' link v 2.4GBit vsego lish' zagadiv 45mbit? okazyvaetsya vozmozhno. In Cisco World only :-) estestvenno, pervoe chto ya navchal delat', eto stavit' rate-limit i access-lists na CR routers. stavit' na AR router ne pomogalo, potomu chto eto ne reshalo problemy "backpressure". tut to i nachalos' samoe interesnoe. linecards na CR-1 nachali sypat'sya odna za drugoj. prichem inogda byvalo chto dazhe ne te, na kotorye stavil access-list/rate-limit, a drugie :-) Cisco tak tolkom nichego i ne posovetovala krome kak uvelichit' input queue, chto ne sil'no pomoglo. A, escho posovetovali upgradit' hardware na Engine 4+ linecards :-) navernoe mesyats 3 ikhnikh inzhenera ezhednevno sypali desyatkami hidden komand :-) i chto, pomoglo eto im (kak v anekdote pryamo)? ugadajte s trekh raz :-) pomoglo tol'ko to, chto customer gramotnyj okazalsya - nauchilsya za paru minut otlavlivat' attack destination, posylal nam etot /32 po BGP so special'noj community, a my ego tut zhe blackhole'ili. Regards, Igor. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (3)
-
Alexandre Snarskii -
Dmitry Kohmanyuk Дмитрий Кохманюк -
igor＠ktts.kharkov.ua