татко Крокодил

(някой се беше оплакал, че не пиша по работа)

Днес около рутинно оглеждане на разни графики забелязах на втория ни router в проекта (първия вече се напълни) как процесора стои на около 60%. Видя ми се адски странно, понеже другия router е далеч по-пълен, търкаля 15тина BGP сесии и един-два порядъка повече трафик и стои на 8-10%. Реших, че не трябва да стои така и седнах да дебъгвам…

Като за начало, в списъка процеси проблем нямаше, но за сметка на това повечето CPU отиваше в interrupt-ове. Отне ми малко време да го разбера, поради веселия начин, по който това се вижда в sh processes cpu, след което се зачетох как точно мога да разбера какво става. Четенето доведе до извода, че трябва да пусна един profile и да видя какво става, понеже нищо друго не звучеше подходящо.

Цялата процедура по профилирането ме върна почти във времената на DOS и на debug.com … В общи линии процедурата е се видят началния и краен адрес на main:text (т.е. самия изпълняващ се код на IOS-а), да се подадат на една команда, на която единия параметър изисква внимателно прочитане на документацията и чакане 5 минути. После по документация – спираме профилирането и казваме sh profile terse.
Аз го направих и при вида на изхода така изпсувах, че вероятно са ме чули в съседния блок.

r2#sh profile terse
PROF 8000000 BFFFFFF 2
PROFSKIP 806AA40
 0 0 0 0 2 0 0 0
PROFSKIP 806AED0
 0 0 0 0 0 0 1 0
...

(и така прилично количество екрани)

Другият вариант на изхода беше почти толкова полезен. Стигнах до извода, че ми трябва начин да направя map между тоя адрес в паметта и функцията на ios-а, която се вика (имаше на няколко места по-големи стойности), след като не намерих документация по въпроса (човек открива “show profile” командите в списъците с недокументирани IOS команди и толкова, доста възможно е да греша какво извежда). Не го намерих (логично) в show memory и реших, че така няма да стане и ми липсват няколкото месеца ровене в кода на IOS-а, за да мога в някакво нормално време да намеря проблема.

Почнах да събирам допълнително информация и се оказа, че натоварването е започнало да расте заедно с трафика. Последва сравняване на всякакви възможни параметри на двата router-а и в крайна сметка се оказа, че на интерфейса, който гледа навътре (един VLAN с много портове в него) на единия router понеже съм сложил два адреса (имах един в 10/8 за разни тестове), автоматично се слага и no ip redirects. Пробвах го на другия и магически 60% от натоварването изчезнаха.
(нямам никакъв трафик, който реално да изисква пращането на redirect-и, проверих. Да припомня, icmp redirect се праща ако router-а трябва да върне някакъв пакет през същия интерфейс, от който го е получил.)

Вероятно съм се набил в някакъв бъг я на IOS-а (12.2SRC), или на някоя от картите, които търкалят пакети и твърде много пакети се качват до layer3 частта, вместо директно да се switch-нат. Google нищо не намери по въпроса…

Tags: cisco, работа

This entry was posted on Saturday, July 31st, 2010 at 18:02 and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.