classic.ISPforum.cz

Dnes se nám přihodil zajímavý problém.

Cisco 7201 s IOSem "c7200p-advipservicesk9-mz.150-1.M7" se nám začalo restarovat. Tak sme vytáhli crash info a je tam následující error:



Chápu ten crash tak, že došla free memory?
je tam cca 60 statických překladů (1neveřejné C=1 veřejná IP), BGP, ACL

Vyjádření z IP_NOC: "Podle toho crash infa to ale vypadá, že nějaký jeho zákaznik pustil super NAT burst.. "
Co si mám pod tím představit? Jak to řešit? Bedna za 300 táců a nezvládne tohle?

Tak to dopadne, kdyz si clovek koupi znackovy drahy vyrobek a on pak nefunguje. Support mu erudovane vysvetli, ze to v zadnem pripade neni zavada toho zarizeni, nybrz jeho vlasnost a ze za to muze nekdo uplne jiny znacka: delam na supportu

Its not a bug,its a feature! (vyjadreni MS ohledne zpomaleni site na 10% pri pousteni hudby ve vistach)

Podle googlu ten router ma 1GB RAM, to mi neprijde jako malo, vzhledem k tomu kolik RAM maji RBcka a jak funguji...

Me spis prijde zvlastni, ze ten router misto aby zahodil nejake zaznamy v NAT tabulce a uvolnil tak misto, tak radeji uplne vytuhne na out-of-memory. Jestli on to neni nahodou enterprise. Predpokladam ze v linuxu by se neco takoveho pravdepodobne nestalo, ikdyz OOM killer by tohle asi take nevyresil...leda by zabil kernel

v linuxu bys mel v logu jen hlasku "conntract table is full"
Da se to castecne vyresit skracenim zivotnosti vyhnilich spojeni.

linux automaticky začne mazat nejstarší záznamy v tabulce.

Diky diky za odborny rady .... Poprosil bych s spis nekoho z "oboru"

sub_zero píše:Dnes se nám přihodil zajímavý problém.

Cisco 7201 s IOSem "c7200p-advipservicesk9-mz.150-1.M7" se nám začalo restarovat. Tak sme vytáhli crash info a je tam následující error:

Kód: Vybrat vše

%SYS-2-CHUNKFREE: Attempted to free nonchunk memory, chunk 87DD1FC, data B0D0B0D. -Process= "IP NAT Ager",
Total active translations: 8487 (4 static, 8483 dynamic; 8483 extended)
Peak translations: 9406, occurred 00:53:58 ago

Chápu ten crash tak, že došla free memory?
je tam cca 60 statických překladů (1neveřejné C=1 veřejná IP), BGP, ACL

Vyjádření z IP_NOC: "Podle toho crash infa to ale vypadá, že nějaký jeho zákaznik pustil super NAT burst.. "
Co si mám pod tím představit? Jak to řešit? Bedna za 300 táců a nezvládne tohle?

- nejdriv zkus jine IOSy. Alespon 4 - 5, zname cisco a jejich bugy...
- pokud ti predchozi bod nepomohl nebo nemuzes sehnat IOS, je jasny ze nemas uz moc na vyber. V tom pripade musis bezpodminecne zrusit NATku. Pomuze ti trebas policy based routing ale existujou i jiny reseni, tohle mi ale prijde nejschudnejsi.
- uz ti to musi chodit. NAT uz tam neni, BGP + routing je naprosto stabilni reseni, tam bug nebyva ani v tech nejhorsich IOSech...
- moc dobra volba to tedy kamo nebyla...

- jo a jinak, podle mne zadnej NAT burst ale legalni IOS SW chyba.

Ne, tohle nevypadá na to, že došla RAMka. Kdyby to zahučelo na nedostatek RAMky, tak to vyhodí pravděpodobně něco s %SYS-2-CHUNKEXPANDFAIL.

Jestli ti to zahučelo na %SYS-2-CHUNKFREE, tak to by měl být případ, že NAT uvolňoval použitou RAMku a alokátor zjistil, že má v té chvíli bordel v memory managementu. Což má dvě možné příčiny - chybička v softu nebo je možný i HW problém s RAMkou (ale to první je asi pravděpodbnější).
Vezmi typ bedny, verzi IOSu, blábol chyby a pohledej na http://www.cisco.com/cgi-bin/Support/Bu ... bugtool.pl , třeba se dozvíš něco, co ani raději vědět nechceš.

Možná o tom burst NATu z toho vytáhl NOC, ale pokud to zahučelo při cca 8.500 spojení a navíc to nebyla ani aktuální špička, ta byla hoďku přdtím s tím 9.406, tak se také kloním k té chybičce v SW. Možná způsobena tím, že tomu přislo moc nových spojení najednou. To si snad dokážeš posoudit, zda v daný čas to je nějak extrémní počet spojení nebo normálka stav.