Nguyên nhân của tải CPU cao trên công cụ định tuyến của bộ định tuyến Juniper

Gần đây, việc sử dụng CPU của công cụ định tuyến trên hai trong số các bộ định tuyến tiên phong Juniper của chúng tôi đã tăng từ ~ 10-20% tải trung bình lên 80 +%. Tôi đang cố gắng tìm hiểu điều gì gây ra điều này (và làm thế nào để giảm tải cao này trở lại).

Một số thông tin về các bộ định tuyến: cả hai đều chạy cùng một phiên bản JunOS, cả hai đều được kết nối với hai mạng LAN IXP tiên phong và có số lượng lớn (vài trăm) phiên (IPv4) gần như giống hệt nhau. Cả hai bộ định tuyến đều có kết nối với một nhà cung cấp dịch vụ IP khác nhau và được kết nối theo cùng một cách với phần còn lại của mạng của chúng tôi. Tải CPU của các công cụ định tuyến không phải là đường thẳng trên 80 +%, có những mức giảm trở lại mức bình thường trong vài phút đến vài giờ, nhưng những giọt này không thường xuyên.

Những điều tôi đã kiểm tra:

• không có thay đổi cấu hình nào được thực hiện tại thời điểm tăng bắt đầu
• không có sự gia tăng lưu lượng không phát trực tiếp vào mặt phẳng điều khiển
• không có thay đổi (đáng kể) về lượng lưu lượng được chuyển tiếp (mặc dù mức tăng không quan trọng)
• show system processes summarycho biết rpdquá trình gây ra tải CPU cao
• không có các đồng nghiệp BGP vỗ nhanh chóng gây ra một lượng lớn thay đổi BGP

Một lời giải thích khả dĩ tôi có thể đưa ra là một máy ngang hàng (hoặc nhiều hơn một) trên một trong hai bộ định tuyến của IXP được kết nối để gửi một số lượng lớn các bản cập nhật BGP. Hiện tại tôi chỉ có số liệu thống kê về số lượng tin nhắn BGP cho các phiên chuyển tuyến của mình (không hiển thị hoạt động bất thường) và với hàng trăm phiên BGP trên mạng LAN tiên phong, không dễ để phát hiện (các) phiên có vấn đề nếu tôi nên tạo biểu đồ cho tất cả các phiên.

Câu hỏi của tôi là:

• Có điều gì khác tôi nên kiểm tra để tìm ra nguyên nhân của sự gia tăng tải CPU trên các công cụ định tuyến không?
• Làm thế nào tôi có thể dễ dàng tìm ra phiên nào gây ra những vấn đề này (nếu giả định của tôi là đúng)? Kích hoạt theo dõi BGP tạo ra lượng dữ liệu khổng lồ, nhưng tôi không chắc liệu nó có cung cấp cho tôi bất kỳ thông tin chi tiết thực sự nào không.

Có thể có một số thông tin hữu ích cho bạn tại Trung tâm kiến ​​thức Juniper .

Nếu RPD đang tiêu thụ CPU cao, thì hãy thực hiện các kiểm tra sau và xác minh các tham số sau:

• Kiểm tra các giao diện: Kiểm tra xem có giao diện nào đang vỗ trên bộ định tuyến không. Điều này có thể được xác minh bằng cách nhìn vào đầu ra của các thông điệp nhật ký hiển thị và hiển thị các lệnh mở rộng ge-x / y / z. Khắc phục sự cố tại sao họ đang vỗ; nếu có thể, bạn có thể xem xét kích hoạt thời gian chờ để liên kết lên và liên kết xuống.

• Kiểm tra xem có thông báo lỗi nhật ký hệ thống liên quan đến giao diện hoặc bất kỳ FPC / PIC nào không, bằng cách xem đầu ra của thông báo nhật ký hiển thị.

• Kiểm tra các tuyến đường: Xác minh tổng số tuyến đường được bộ định tuyến tìm hiểu bằng cách xem kết quả đầu ra của bản tóm tắt tuyến đường. Kiểm tra nếu nó đã đạt đến giới hạn tối đa.

• Kiểm tra các nhiệm vụ RPD: Xác định những gì đang giữ cho quá trình bận rộn. Điều này có thể được kiểm tra bằng cách trước tiên cho phép thiết lập kế toán tác vụ. Quan trọng: Điều này có thể làm tăng tải cho CPU và việc sử dụng nó; vì vậy đừng quên tắt nó khi bạn hoàn thành bộ sưu tập đầu ra cần thiết. Sau đó chạy chương trình tác vụ kế toán và tìm kiếm luồng với thời gian CPU cao:

  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
  

Tìm hiểu tại sao một luồng, liên quan đến một tiền tố cụ thể hoặc một giao thức, lại chiếm CPU cao.

• Bạn cũng có thể xác minh xem các tuyến có dao động (hoặc khuấy tuyến) hay không bằng cách xem đầu ra của lệnh shell: %rtsockmon –t

• Kiểm tra bộ nhớ RPD. Đôi khi việc sử dụng bộ nhớ cao có thể gián tiếp dẫn đến CPU cao.

Tôi biết chủ đề này là cũ nhưng vì sự hoàn chỉnh:

Nếu cpu cao xảy ra ngẫu nhiên và bạn không thể xác định quy trình gây ra điều này, chúng tôi có thể tạo tập lệnh bên dưới.

Với kịch bản này, chúng tôi sẽ nắm bắt quy trình mở rộng khi một quy trình tăng hơn ngưỡng bình thường hoặc dự kiến, điều này sẽ không phá vỡ bất kỳ lưu lượng truy cập nào nhưng vẫn khuyến nghị sử dụng MW. Tuy nhiên tôi thấy bạn đã thu hẹp nó thành 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;
            }
        }
    }
}

HIỂN THỊ THIẾT LẬP ĐẦU RA>

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

Ngoài ra, bạn đã kiểm tra nếu bất kỳ tin nhắn ddos ​​đã được báo cáo? Bạn có thể chạy các lệnh sau:

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

Sau đó, tùy thuộc vào những gì bạn thấy nó có thể được thu hẹp, ví dụ:

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 cũng có một danh sách bộ sưu tập cho loại vấn đề này theo KB22637

Các lệnh CLI CPU cao

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

Bật kế toán nhiệm vụ và thu thập đầu ra chi tiết kế toán nhiệm vụ (ba lần với khoảng cách 30 giây). Đừng quên tắt nó sau khi hoàn thành.

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

Nhật ký

Lưu trữ / var / log như được chỉ định trong Bước 1 ở trên Traceoptions

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

Ngoài ra, nếu bạn đang chạy một phiên bản cũ dễ bị lỗi, bạn có thể muốn kiểm tra hỗ trợ cuộc sống của mã:

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

Một điểm khác cần đề cập có thể là một cuộc tấn công véc tơ là không bảo vệ RE của bạn khỏi lưu lượng ngoại lệ không mong muốn. Hãy chắc chắn rằng bạn có một bộ lọc tường lửa theo loopback.

Tôi đã thấy trong các tập lệnh trước đây trên bộ định tuyến gây ra cpu cao không chắc chắn nếu rpd xuất hiện trong chế độ xem của tôi, nhưng đây là điều bạn có thể không muốn bỏ qua.

Nếu bạn thấy trong nhật ký, nhiều lần truy cập với RPD_MPLS_PATH_BANDWIDTH_CHANGE, bạn có thể đang sử dụng khoảng thời gian điều chỉnh rất tích cực

Kiểm tra bất kỳ giọt nào trên "hiển thị hàng đợi hệ thống: đây là hàng đợi kernel, một số đầu mối có thể xuất hiện.