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