シナプス技術者ブログ

シナプスの技術者公式ブログ。インターネットで、鹿児島の毎日を笑顔にします。

Juniper でイベントポリシーを検証してみました

技術 ネットワーク JUNOS イベントポリシー

シナプスの技術部ネットワーク課の福山と申します。

先日、弊社の機器間で iBGP が一時的に切断される事象が発生し、その調査の一環として、Juniper のイベントポリシーを利用してみました。
事前にイベントポリシーでどういったことができるのか検証したので、その内容について記載します。

Juniper のイベントポリシーとは

Juniper のイベントポリシーとは、「if-then-else（条件分岐）」構造を用いて、システムログメッセージやSNMPトラップなどのイベントを受信した際に実行するアクションを定義するものです。
ポリシーでは、以下のようなアクションを設定することができます。

  • 指定された宛先にファイルをアップロードする
  • 運用モードのコマンドを実行する
  • イベントスクリプトを実行する
  • 設定を変更する

このように、イベントポリシーを活用することで、イベント発生時の対応を柔軟かつ自動化することが可能になります。

www.juniper.net

検証環境

Juniper vLabs でトポロジー「BGP - Multi-AS」の一部を利用して検証しました。

  • Junos OS 21.1R3.11
  • デフォルトで以下のような基本的な設定は投入済みです。
    • インターフェース、IPアドレス
    • IGPとしてOSPF
    • vMX1 ～ vMX2 間は iBGP

ネットワーク構成とIPアドレスは以下の通りです。

検証 1

やりたいこと

  • vMX1で、vMX2とのBGPネイバー（10.100.100.2）が切断した際に、show コマンドと ping の結果をファイルに保存する

設定内容

# BGP セッションの状態変化（アップまたはダウン）をログに記録する
set protocols bgp log-updown

# イベントポリシー TEST1 を作成し、rpd_bgp_neighbor_state_changed イベント（BGP ネイバー状態の 変更）を 監視対象とする
set event-options policy TEST1 events rpd_bgp_neighbor_state_changed

# セッションがダウンした場合（Established 状態から他の状態に遷移）にアクションを実行する
set event-options policy TEST1 attributes-match rpd_bgp_neighbor_state_changed.old-state matches Established

# イベントの対象が BGP ネイバー「10.100.100.2」である場合にアクションを実行する
set event-options policy TEST1 attributes-match rpd_bgp_neighbor_state_changed.peer-name matches 10.100.100.2

# イベントが発生した際に、指定したコマンドを順に実行する
set event-options policy TEST1 then execute-commands commands "show system memory"
set event-options policy TEST1 then execute-commands commands "show system processes extensive"
set event-options policy TEST1 then execute-commands commands "show bgp neighbor 10.100.100.2"
set event-options policy TEST1 then execute-commands commands "ping 10.100.100.2 rapid"

# 実行結果を TEST1 というファイル名で保存
set event-options policy TEST1 then execute-commands output-filename TEST1

# コマンド実行結果の保存先を EVENT_LOG に指定
set event-options policy TEST1 then execute-commands destination EVENT_LOG

# 実行結果をテキスト形式で保存
set event-options policy TEST1 then execute-commands output-format text

# ログのアーカイブ先を指定
set event-options destinations EVENT_LOG archive-sites /var/home/jcluser

検証

  • vMX2で、vMX1とのBGPネイバー（10.100.100.1）をシャットダウンする
[edit]
jcluser@vMX2# set protocols bgp group IBGP neighbor 10.100.100.1 shutdown 

[edit]
jcluser@vMX2# commit 
commit complete
  • vMX1で、vMX2とのBGPネイバー（10.100.100.2）とのBGPセッションが「Established」から「Idle」に遷移したことがログに記録される
Jan  5 10:12:34  vMX1 rpd[16252]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.100.100.2 (Internal AS 64522) changed state from Established to Idle (event RecvNotify) (instance master)
  • vMX1で、指定したアーカイブ先にファイルが作成されていることが確認できた
jcluser@vMX1> file list /var/home/jcluser/ detail 

/var/home/jcluser/:
total blocks: 96
-rw-r-----  1 root  wheel      40118 Jan 5  10:12 vMX1_20250105_101234_TEST1
total files: 1
  • ファイルには指定したコマンドの結果が記録されていることが確認できた
jcluser@vMX1> file show /var/home/jcluser/vMX1_20250105_101234_TEST1 
 
 
root@vMX1> show system memory
 
System memory usage distribution:
          Total memory: 4143116 Kbytes (100%)
    Reserved memory:  134112 Kbytes (  3%)
         Wired memory:  277508 Kbytes (  6%)
         Active memory:  142584 Kbytes  (  3%)
       Inactive memory: 1682528 Kbytes ( 40%)
         Cache memory:       0 Kbytes      (  0%)
            Free memory: 1906380 Kbytes ( 46%)

<<途中省略>>

root@vMX1> show system processes extensive
 
last pid: 19061;  load averages:  0.20,  0.20,  0.23  up 0+03:24:13    10:12:34
349 processes: 2 running, 294 sleeping, 53 waiting
 
Mem: 140M Active, 1643M Inact, 271M Wired, 63M Buf, 1860M Free
Swap: 3072M Total, 3072M Free
 
<<途中省略>>

root@vMX1> show bgp neighbor 10.100.100.2
 
Peer: 10.100.100.2 AS 64522    Local: 10.100.100.1 AS 64522
  Group: IBGP                  Routing-Instance: master
  Forwarding routing-instance: master   
  Type: Internal    State: Active         Flags: <>
  Last State: Idle          Last Event: Start

<<途中省略>>
  
root@vMX1> ping 10.100.100.2 rapid
 
PING 10.100.100.2 (10.100.100.2): 56 data bytes
!!!!!
--- 10.100.100.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.590/0.777/1.149/0.194 ms

検証 2

やりたいこと

  • vMX1で、vMX2への ping に失敗した際に、vMX2との接続インターフェースをシャットダウンする

設定内容

# RPM（Real-Time Performance Monitoring）の設定
# vMX2(10.100.12.2)へのPingを 1秒ごとに実行し、3回連続して失敗した場合に、テストを「失敗」と判定する
set services rpm probe ping-probe test ping-test probe-type icmp-ping
set services rpm probe ping-probe test ping-test target address 10.100.12.2
set services rpm probe ping-probe test ping-test test-interval 1
set services rpm probe ping-probe test ping-test thresholds successive-loss 3

# PING_TEST_FAILED のログが出力されるように設定 
set system syslog file syslog-event-daemon-info daemon info

# RPM テストの失敗（ping_test_failed）イベントをトリガーとするポリシーを作成
set event-options policy TEST2 events ping_test_failed
set event-options policy TEST2 attributes-match ping_test_failed.test-owner matches ping-probe
set event-options policy TEST2 attributes-match ping_test_failed.test-name matches ping-test

# イベントが 10秒以内に 3回発生した場合にアクションを実行する
# 4回以上発生しても同じアクションを実行しないようにする 
set event-options policy TEST2 within 10 trigger on
set event-options policy TEST2 within 10 trigger 3
set event-options policy TEST2 within 15 trigger until
set event-options policy TEST2 within 15 trigger 4

# イベント発生時に指定した設定変更コマンドを実行する
# 設定変更コマンドを実行するユーザーを指定する
set event-options policy TEST2 then change-configuration commands "set interfaces ge-0/0/3 disable"
set event-options policy TEST2 then change-configuration user-name jcluser

検証

  • vMX2で、vMX1からの ping が失敗するように、vMX1との接続インターフェースをシャットダウンする
[edit]
jcluser@vMX2# set interfaces ge-0/0/3 disable    

[edit]
jcluser@vMX2# commit 
commit complete
  • vMX1で、vMX2との接続インターフェースがシャットダウンしていることが確認できた
jcluser@vMX1> show interfaces ge-0/0/3 terse 
Interface               Admin Link Proto    Local                 Remote
ge-0/0/3               down  down
ge-0/0/3.0             up      down inet    10.100.12.1/24  
                                               multiservice
  • ログを確認すると、PING_TEST_FAILED のログが出力されていることと、イベントにより設定変更が実施されていることがわかる
jcluser@vMX1> show log syslog-event-daemon-info | grep PING  
<<抜粋>>
Jan 13 11:31:29  vMX1 rmopd[18334]: PING_TEST_COMPLETED: pingCtlOwnerIndex = ping-probe, pingCtlTestName = ping-test
Jan 13 11:31:48  vMX1 rmopd[18334]: PING_TEST_COMPLETED: pingCtlOwnerIndex = ping-probe, pingCtlTestName = ping-test
Jan 13 11:32:04  vMX1 rmopd[18334]: PING_TEST_FAILED: pingCtlOwnerIndex = ping-probe, pingCtlTestName = ping-test
Jan 13 11:32:08  vMX1 rmopd[18334]: PING_TEST_FAILED: pingCtlOwnerIndex = ping-probe, pingCtlTestName = ping-test
Jan 13 11:32:12  vMX1 rmopd[18334]: PING_TEST_FAILED: pingCtlOwnerIndex = ping-probe, pingCtlTestName = ping-test

jcluser@vMX1> show log messages | grep eventd  
<<抜粋>>
Jan 13 11:32:13  vMX1 eventd: EVENTD_CONFIG_CHANGE_SUCCESS: Configuration change successful: while executing policy TEST2 with user jcluser privileges

さいごに

  • 利用できるイベントはたくさんありますが、実際には問題が発生した時に出力されるログを確認し、そのログをトリガーとしてアクションを起こすという活用が主になると思いました。
  • アクションとしては、show コマンドや ping の確認など軽い操作であれば問題なく実行できますが、設定変更に関しては、意図しない動作を防ぐために十分な検証が必要だと思いました。