Juniper peering yönlendiricinin yönlendirme motorunda yüksek CPU yükünün nedeni


20

Son zamanlarda Juniper eşleme yönlendiricilerimizden ikisinde yönlendirme motoru CPU kullanımı, ortalama% 10-20'den% 80 + 'ya yükseldi. Bu (ve bu yüksek yük geri almak nasıl) neden olduğunu anlamaya çalışıyorum.

Yönlendiriciler hakkında bazı bilgiler: her ikisi de aynı JunOS sürümünü çalıştırır, her ikisi de aynı iki IXP LAN'a bağlanır ve çok sayıda (neredeyse yüzlerce) IPv4 ve IPv6 oturumuna sahiptir. Her iki yönlendiricinin de farklı bir IP geçiş sağlayıcısına bağlantısı vardır ve ağımızın geri kalanına aynı şekilde bağlanır. Yönlendirme motorlarının CPU yükü% 80 + 'da yatay değil, dakikalar veya saatler boyunca normal seviyelere düşüyor, ancak bu damlalar o kadar sık ​​değil.

Kontrol ettiğim şeyler:

  • artış başladığı anda hiçbir yapılandırma değişikliği yapılmadı
  • kontrol düzlemine yönlendirilen tek yönlü olmayan trafikte artış yok
  • yönlendirilen trafik miktarında (önemli) bir değişiklik yok (bir artış bile önemli olmamalı)
  • show system processes summaryrpdişlemin yüksek CPU yüküne neden olduğunu belirtir
  • çok sayıda BGP değişikliğine neden olan hızla çırpılan BGP eşleri yoktur

Gelebileceğim olası bir açıklama, IXP'nin her iki yönlendiricisinin çok sayıda BGP güncellemesi göndermeye bağlı olduğu bir eş (veya birden fazla). Şu anda yalnızca geçiş oturumlarım için (anormal etkinlik göstermiyor) BGP mesajlarının sayısı hakkında istatistiklere sahibim ve eşlenen LAN'larda yüzlerce BGP oturumuyla, grafikler oluşturmam gerekirse sorunlu oturumları tespit etmek o kadar kolay değil tüm oturumlar.

Sorularım:

  • yönlendirme motorlarındaki CPU yükündeki bu artışın nedenini bulmak için kontrol etmem gereken başka şeyler var mı?
  • hangi oturumların bu sorunlara neden olduğunu nasıl kolayca bulabilirim (varsayım doğru ise)? BGP traceoptions'ı etkinleştirmek büyük miktarda veri üretir, ancak bana gerçek bir bakış açısı sağlayıp sağlamadığından emin değilim.

Yanıtlar:


17

Ardıç Bilgi Merkezi'nde sizin için bazı yararlı bilgiler olabilir .

RPD yüksek CPU tüketiyorsa, aşağıdaki kontrolleri yapın ve aşağıdaki parametreleri doğrulayın:

  • Arabirimleri kontrol edin: Yöneltici üzerinde herhangi bir arabirim olup olmadığını kontrol edin. Bu, show log mesajlarının çıktısına ve ge-x / y / z kapsamlı komutlarının show arayüzlerine bakarak doğrulanabilir. Neden çırptıklarını giderin; mümkünse bağlantı kurma ve bağlantı kesme için bekleme süresini etkinleştirmeyi düşünebilirsiniz.

  • Şov günlüğü iletilerinin çıktısına bakarak arabirimlerle veya herhangi bir FPC / PIC ile ilgili syslog hata iletileri olup olmadığını kontrol edin.

  • Rotaları kontrol edin: Rotayı göster özetinin çıktısına bakarak yönlendirici tarafından öğrenilen toplam rota sayısını doğrulayın. Maksimum sınıra ulaşıp ulaşmadığını kontrol edin.

  • RPD görevlerini kontrol edin: Süreci neyin meşgul ettiğini belirleyin. Bu, ilk olarak ayarlanan görev muhasebesi etkinleştirilerek kontrol edilebilir. Önemli: Bu, CPU üzerindeki yükü ve kullanımını artırabilir; bu nedenle, gerekli çıktı koleksiyonuyla işiniz bittiğinde kapatmayı unutmayın. Sonra show task hesaplamayı çalıştırın ve yüksek CPU zamanına sahip iş parçacığını arayın:

    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
    

Belirli bir önek veya protokolle ilişkili bir iş parçacığının neden yüksek CPU aldığını öğrenin.

  • Ayrıca kabuk komutunun çıktısına bakarak rotaların salınımlı (veya rota dönüşümleri) olup olmadığını da doğrulayabilirsiniz: %rtsockmon –t

  • RPD Belleği kontrol edin. Bazı durumlarda Yüksek bellek kullanımı dolaylı olarak yüksek CPU'ya neden olabilir.


1
RPD biraz can sıkıcı bir kara kutu. Büyük önerilerin üstünde rtsockmon -t ve görev hesabını göster, ayrıca potansiyel olarak yararlı bir araç olarak 'show krt kuyruğunu' eklemek istiyorum.
ytti

show krt kuyruğu, denetimden veri düzlemine giden tüm rota güncellemelerini gösterir. Çoğu zaman sıraya alınmış hiçbir şey görmemelisiniz. Bir flep olduğunda bu oldukça uzun bir süre sıraya girebilir
mellowd

PR836197 nedeniyle kelimenin tam anlamıyla saatlerde olabilir :(
ytti

Bu noktalardan birkaçından söz etmek çok açıktı (arayüzleri çırpıyor, günlüklerdeki hatalar), ancak rtsockmon ve görev muhasebesi önerileri anlayışlıydı. SNMP için çok fazla CPU döngüsü kullanıldığına benziyor, bu yüzden bir sonraki adım hangi yönlendiricilerin ve bu yönlendiricileri yokladığını bulmak.
Teun Vink

1
Çok açık olsaydı özür dilerim, bir kullanıcı takılı bir güçlük olup olmadığını kontrol etmek için bir destek arka plan geliyor!
Artanix

2

Bu konu eski ama tamlık uğruna biliyorum:

Yüksek işlemci rastgele oluşursa ve buna neden olan işlemi belirleyemiyorsanız, aşağıdaki komut dosyasını oluşturabiliriz.

Bu komut dosyasıyla, bir işlem normal veya beklenen eşik değerden daha fazla yükseldiğinde süreci kapsamlı olarak yakalayacağız, bu herhangi bir trafiği bozmamalıdır, ancak yine de bir MW önerilir. Ancak RPD olarak daralttığını görüyorum.

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;
            }
        }
    }
}

EKRAN AYAR ÇIKIŞI>

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

Ayrıca herhangi bir ddos ​​mesajı bildirilip bildirilmediğini kontrol ettiniz mi? Aşağıdaki komutları çalıştırabilirsiniz:

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

Sonra gördüğünüz şeye bağlı olarak daraltılabilir, örneğin:

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, KB22637 altındaki bu tür sorunlar için bir koleksiyon listesine de sahiptir.

Yüksek CPU CLI Komutları

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

Görev muhasebesini açın ve görev muhasebesi detay çıktısını toplayın (30 saniye boşluk ile üç kez). Bitirdikten sonra kapatmayı unutmayın.

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ütükler

Traceoptions'ın yukarıdaki 1. Adımında belirtildiği gibi arşiv / var / log

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

Ayrıca, hatalara eğilimli eski bir sürümünü çalıştırıyorsanız, kodun yaşam desteğini kontrol etmek isteyebilirsiniz:

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

Bir vektör saldırısı olabilecek başka bir nokta, RE'nizi istenmeyen istisna trafiğinden korumuyor olmaktır. Geridöngü altında bir güvenlik duvarı filtreniz olduğundan emin olun.

Yönlendiricideki geçmiş komut dosyalarında rpd'nin görüşüme girip girmediğinden emin değilim, yüksek cpu'ya neden oldum, ancak bu göz ardı etmek istemeyeceğiniz bir şey.

Günlüklerde RPD_MPLS_PATH_BANDWIDTH_CHANGE ile çok sayıda isabet görürseniz, çok agresif bir ayar aralığı kullanıyor olabilirsiniz

"Sistem kuyruğunu göster" seçeneğinde herhangi bir düşüş olup olmadığını kontrol edin: bu çekirdek kuyruğudur, bazı ipuçları görünebilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.