⚠ Wysokie obciążenie procesora (QFP)?
Poznaj rozwiązanie problemu! Strefa eksperta

Jeśli jesteś posiadaczem ASR z serii 1000 (np. 1001-X), to być może zaobserwowałeś skokowe zużycie procesora QFP na wykresach z narzędzi monitorujących. Rozwiewając być może pewne wątpliwości – QFP jest procesorem (chipem), nazwijmy go data-plane, odpowiadającym za przetwarzanie pakietów. Nie należy go mylić ze standardowym CPU (control-plane), również obecnym na pokładzie ASR, który to z kolei obsługuje np. działanie protokołów routingowych.

Przyczyny/skutki

Wysycanie zarówno jednego i drugiego procesora jest oczywiście niepożądane. Standardowe CPU może na przykład gubić sąsiedztwa dynamicznych protokołów routingowych. Natomiast jak może objawiać się wysokie obciążenie QFP? Najczęściej poprzez zwiększone opóźnienia pakietów, również widoczne w zwykłych „pingach” czy „trace’ach”. Przy wyższych skokach pakiety mogą być najzwyczajniej dropowane. Najbardziej ucierpią więc na tym interaktywne aplikacje.

NAT – główny winowajca?

Najczęstszym powodem powyższych dolegliwości jest NAT. Ale już spieszymy z doprecyzowaniem, ponieważ NAT sam w sobie jest jak najbardziej w porządku ? Problem pojawia się wtedy, gdy na tym samym interfejsie/subinterfejsie mamy sporą mieszankę ruchu podlegającego pod NAT i takiego, który ma zostać przeroutowany bez NATa. Na platformie ASR 1000 zaalokowany jest bufor dla ruchu wyłączonego spod translacji adresów, a który może okazać się niewystarczający w pewnych sytuacjach. A co to znaczy sporą mieszankę? Ciężko odpowiedzieć na to pytanie, ponieważ zależy to od wielu czynników – ilości ruchu łącznie, wielkości pakietów (co za tym idzie wartości pps), na ile interfejsów L3 rozkłada się NAT itd. Z naszego doświadczenia wynika, że przyczyniać może się do tego również protokół netflow – w momencie, gdy zbieramy cały ruch sieciowy z interfejsów klienckich i wypuszczamy go na collector (oczywiście bez NAT), to jest spora szansa, że jest to główny powód skoków QFP. Można by więc wysnuć wniosek – „Aha! Włączyłem netflow i od tego czasu skacze mi QFP. To on powoduje problem! Gdy wyłączam netflow problem mija!” A więc jak widać, można pomylić się w (co najmniej) trzech kwestiach: wyciągnąć złe wnioski, przestać korzystać z „obciążających” feature’ów (np. netflow) i ostatecznie nawet nie rozwiązać problemu.

A więc co zrobić?

Skontaktować się z Network Expert – mamy wieloletnie doświadczenie w budowie i zarządzaniu siecią oraz zespół doświadczonych inżynierów, więc jesteśmy w stanie pomóc w rozwiązaniu nawet naprawdę skomplikowanych problemów sieciowych!

A co pomaga w większości przypadków? Zwiększenie defaultowego bufora, o którym była mowa wcześniej. Standardowo przydzielone jest 8KB cache’u, poniżej przedstawiamy jakim poleceniem możemy to zweryfikować i sprawdzić aktualne jego wykorzystanie (tutaj podchodzące już „pod korek”):

Zwiększenie bufora to jedno polecenie:

Co jeśli to nie pomaga?

Drugim powodem może być zaafektowane oprogramowanie przez bug CSCvx37176, który de facto również jest powiązany z NATem – w sytuacji gdy skonfigurowaliśmy rate limit’ing w NAT. W takim wypadku należy przeprowadzić upgrade do softu wolnego od buga, np. 16.9.8.

Co jeśli to dalej nie pomaga?

Napisz do nas!