Przyczyna dużego obciążenia procesora w silniku routingu routera równorzędnego Juniper

Ostatnio wykorzystanie procesora przez silnik routingu na dwóch naszych routerach równorzędnych Juniper wzrosło z ~ 10-20% średniego obciążenia do 80 +%. Próbuję dowiedzieć się, co to powoduje (i jak przywrócić to wysokie obciążenie).

Kilka informacji na temat routerów: oba działają w tej samej wersji JunOS, oba są podłączone do tych samych dwóch równorzędnych sieci LAN IXP i mają dużą liczbę (kilkaset) (prawie identycznych) sesji IPv4 i IPv6. Oba routery mają połączenie z innym dostawcą tranzytowym IP i są podłączone w ten sam sposób do reszty naszej sieci. Obciążenie procesora silników routingu nie jest równe 80%, spadki wracają do normalnych poziomów od minut do godzin, ale spadki te nie są tak częste.

Rzeczy, które sprawdziłem:

• w chwili rozpoczęcia zwiększania nie wprowadzono żadnych zmian konfiguracji
• nie ma wzrostu ruchu bez emisji pojedynczej skierowanego na płaszczyznę kontrolną
• nie ma (istotnej) zmiany w ilości przekazywanego ruchu (choć nawet wzrost nie powinien mieć znaczenia)
• show system processes summarywskazuje, że rpdproces powoduje duże obciążenie procesora
• nie ma szybko trzepoczących peerów BGP powodujących dużą liczbę zmian BGP

Jednym z możliwych wyjaśnień, jakie mogę wymyślić, jest peer (lub więcej) na jednym z IXP, oba routery są podłączone do wysyłania dużej liczby aktualizacji BGP. Obecnie mam tylko statystyki dotyczące liczby komunikatów BGP dla moich sesji tranzytowych (nie wykazujących nienormalnej aktywności), a przy kilkuset sesjach BGP w równorzędnych sieciach LAN nie jest łatwo dostrzec problematyczne sesje, jeśli powinienem utworzyć wykresy dla wszystkie sesje.

Moje pytania to:

• czy są jeszcze inne rzeczy, które powinienem sprawdzić, aby znaleźć przyczynę tego wzrostu obciążenia procesora w silnikach routingu?
• jak mogę łatwo dowiedzieć się, które sesje powodują te problemy (jeśli moje założenie jest słuszne)? Włączenie opcji śledzenia BGP generuje ogromne ilości danych, ale nie jestem pewien, czy daje mi to prawdziwy wgląd.

W Centrum wiedzy Juniper mogą znajdować się przydatne informacje .

Jeśli RPD zużywa duży procesor, wykonaj następujące czynności kontrolne i sprawdź następujące parametry:

• Sprawdź interfejsy: Sprawdź, czy jakieś interfejsy nie trzepoczą na routerze. Można to zweryfikować, patrząc na wyniki komunikatów show log i interfejsów show obszernych poleceń ge-x / y / z. Rozwiąż problemy, dlaczego trzepoczą; jeśli to możliwe, możesz rozważyć włączenie czasu wstrzymania połączenia w górę i w dół.

• Sprawdź, czy istnieją komunikaty o błędach syslog związane z interfejsami lub jakimkolwiek FPC / PIC, patrząc na wyniki komunikatów dziennika dziennika.

• Sprawdź trasy: Sprawdź całkowitą liczbę tras, które router poznaje, sprawdzając wyniki podsumowania trasy pokazu. Sprawdź, czy osiągnął maksymalny limit.

• Sprawdź zadania RPD: Zidentyfikuj, co utrzymuje proces zajęty. Można to sprawdzić, włączając najpierw ustawienie rozliczania zadań. Ważne: samo to może zwiększyć obciążenie procesora i jego wykorzystanie; więc nie zapomnij go wyłączyć, gdy skończysz z wymaganą kolekcją danych wyjściowych. Następnie uruchom rozliczanie zadań show i poszukaj wątku o wysokim czasie procesora:

  user@router> show task accounting
  Task                       Started    User Time  System Time  Longest Run
  Scheduler                   146051        1.085        0.090        0.000
  Memory                           1        0.000            0        0.000  <omit>
  BGP.128.0.0.4+179              268       13.975        0.087        0.328
  BGP.0.0.0.0+179      18375163 1w5d 23:16:57.823    48:52.877        0.142
  BGP RT Background              134        8.826        0.023        0.099
  

Dowiedz się, dlaczego wątek związany z określonym prefiksem lub protokołem zajmuje dużo procesora.

• Możesz również sprawdzić, czy trasy oscylują (czy marnują trasy), sprawdzając dane wyjściowe polecenia powłoki: %rtsockmon –t

• Sprawdź pamięć RPD. Czasami Wysokie wykorzystanie pamięci może pośrednio prowadzić do wysokiego procesora.

Wiem, że ten wątek jest stary, ale ze względu na kompletność:

Jeśli wysokie cpu występuje losowo i nie jesteś w stanie określić procesu powodującego to, możemy utworzyć skrypt poniżej.

Za pomocą tego skryptu uchwycimy proces szeroko zakrojony, gdy proces przekroczy próg normalny lub oczekiwany, nie powinno to zakłócać żadnego ruchu, ale nadal zaleca się MW. Widzę jednak, że zawęziłeś to do RPD.

snmp {
    health-monitor {
        interval 30;
        rising-threshold 60;
        falling-threshold 50;
    }
}

event-options {
    policy MONITOR-CPU {
        events snmpd_health_mon_thresh_cross;
        attributes-match {
            snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising";
        }
        then {
            execute-commands {
                commands {
                    "show system processes extensive";
                }
                output-filename cpu-processes;
                destination local-flash;
                output-format text;
            }
        }                               
    }
    destinations {
        local-flash {
            archive-sites {
                /var/tmp;
            }
        }
    }
}

WYŚWIETL. USTAW WYJŚCIE>

set snmp health-monitor interval 30
set snmp health-monitor rising-threshold 60
set snmp health-monitor falling-threshold 50
set event-options policy MONITOR-CPU events snmpd_health_mon_thresh_cross
set event-options policy MONITOR-CPU attributes-match snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising"
set event-options policy MONITOR-CPU then execute-commands commands "show system processes extensive"
set event-options policy MONITOR-CPU then execute-commands output-filename cpu-processes
set event-options policy MONITOR-CPU then execute-commands destination local-flash
set event-options policy MONITOR-CPU then execute-commands output-format text
set event-options destinations local-flash archive-sites /var/tmp

Czy sprawdziłeś także, czy zgłoszono jakieś wiadomości DDO? Możesz uruchomić następujące polecenia:

show ddos-protection protocols statistics brief
show ddos-protection statistics
show ddos-protection version

Następnie w zależności od tego, co widzisz, można zawęzić na przykład:

show ddos-protection protocols ttl statistics
show ddos-protection protocols ttl violations
show ddos-protection protocols ttl flow-detection detail  */*this cm needs prior config*/*

Juniper ma również listę kolekcji tego typu problemów w ramach KB22637

Polecenia CLI o wysokim CPU

set cli timestamp
show chassis routing-engine (multiple snapshots, atleast 5)
show system processes extensive (multiple snapshots atleast 5)
show system users
show system connections
show system statistics

Włącz rozliczanie zadań i zbierz dane wyjściowe szczegółów rozliczania zadań (trzy razy z 30-sekundową przerwą). Nie zapomnij go wyłączyć po zakończeniu.

set task accounting on 
show task accounting detail
set task accounting off

show task memory detail
show task memeory summary
show task io
show task history
show task statistics
show task job
show task jobs
show krt queue
show krt state

Kłody

Zarchiwizuj / var / log zgodnie z opisem w kroku 1 powyżej Traceoptions

user@router# show routing-options 
traceoptions { 
file routing-trace size 10m files 20 world-readable; 
flag task; 
flag state; 
flag timer; 
}

Również jeśli korzystasz ze starej wersji, która jest podatna na błędy, możesz sprawdzić wsparcie życia kodu:

http://www.juniper.net/support/eol/junos.html

Innym punktem, który należy wspomnieć, który może być atakiem wektorowym, jest brak ochrony RE przed niepożądanym ruchem wyjątków. Upewnij się, że masz filtr zapory sieciowej pod pętlą zwrotną.

Widziałem w przeszłości skrypty na routerze powodujące wysokie cpu, nie jestem pewien, czy rpd pojawił się w moim widoku, ale jest to coś, czego możesz nie chcieć przeoczyć.

Jeśli widzisz w dziennikach wiele trafień z RPD_MPLS_PATH_BANDWIDTH_CHANGE, być może używasz bardzo agresywnego interwału dostosowywania

Sprawdź wszelkie upuszczenia na „pokaż kolejkę systemową: jest to kolejka jądra, może pojawić się pewna wskazówka.