【Juniper機器でnetconfを有効にする】
---Juniper機器でnetconfを有効にする---
Ansibleを使ってJuniper機器のnetconfを有効化する。
Junos機器にAnsibleでconfig設定をする場合、接続プロトコルが複数ある。どの接続プロトコルを使うかは、利用するAnsibleモジュールに依存。
varsで以下のようにansible_connectionとansible_network_osを指定する。
ansible_network_os=junos
ansible_connection=netconfまたはnetwowk_cli等
■(参考)Ansible公式ページ「How Network Automation is Different」より
| ansible_connection | Protocol | Requires | Persistent |
| network_cli | CLI over SSH | network_os setting | yes |
| netconf | XML over SSH | network_os setting | yes |
| httpapi | API over HTTP/HTTPS | network_os setting | yes |
| local | depends on provider | provider setting | no |
Junosの設定は、Ansibleの公式ページのモジュールで設定する方法と、ansible-galaxyで提供されているjuniper.junosのrolesを使う方法がある。
Ansibleの公式ページのモジュールは複数のconnectionをサポートしており、公式ドキュメントを参考に適切なconnection設定をする必要がある。juniper.junosのrolesを使う場合は実機で確認できている限りlocalまたはnetconfを指定すれば動作する。
juniper.junosでは、通常運用で利用するレベルの設定が網羅されていて、Junosの運用経験があればyamlの構文を知らなくてもコピぺで簡単にplaybookの作成ができる。JunosをAnsibleで設定するなら、まずsshもnetconfも有効化して、juniper.junosのrolesから始めるのがお勧め。
＜＜netconfを有効化する手順書＞＞
| 大項目 | 項目番号 | 項目 | 対象機器 | 設定/確認コマンド/出力確認 | |
|---|---|---|---|---|---|
| 事前確認 | 1_1 | 設定モードuser確認 | SW | user@SW> show system users fpc0: -------------------------------------------------------------------------- 1:26PM up 185 days, 18:37, 2 users, load averages: 0.00, 0.03, 0.03 USER TTY FROM LOGIN@ IDLE WHAT |
NW機器で設定モードのユーザがいないこと |
| 1_2 | ssh設定無し確認 | SW | user@SW> show configuration system services ftp; telnet; ssh; |
netconfの出力がないこと | |
| 1_3 | lo向けアクセスフィルタ確認 | SW | user@SW>show configuration firewall family inet filter JUNIPER_Lo term TELNET { from { source-address { 192.168.1.0/24; } destination-address { 10.10.10.1/32; } destination-port 23; } then accept; } |
許可フィルタ設定が無いこと | |
| 設定 | 2_1 | 排他制御して設定モード移行 | SW | user@SW> configure exclusive Entering configuration mode {master:0} user@SW# |
エラーがないこと。設定モードに移行することを以下のプロンプト出力で確認 # |
| 2_2 | netconf有効化 | SW | set system services netconf ssh port 830 set system services netconf traceoptions file netconf.log set system services netconf traceoptions flag all |
プロンプト表示のみ確認 | |
| 2_3 | lo向けアクセスフィルタ 設定階層へ移動 |
SW | user@SW# edit firewall family inet filter JUNIPER_Lo {master:0}[edit firewall family inet filter JUNIPER_Lo] user@SW# |
階層移動後プロンプト表示確認 | |
| 2_4 | lo向けアクセスフィルタ ssh許可 |
SW | {master:0}[edit firewall family inet filter JUNIPER_Lo] user@SW# ここに以下設定を貼り付け set term NETCONF from source-address 192.168.1.0/24 set term NETCONF from destination-address 10.10.10.1/32 set term NETCONF from destination-port 830 set term NETCONF then accept |
階層移動後プロンプト表示に戻ること エラーがないこと |
|
| 事後確認 | 3_1 | 設定差分確認 | SW | user@SW# show | compare + port 830; [edit system services netconf] + traceoptions { + file netconf.log; + flag all; + } {master:0}[edit] miwapinn@SW104# |
差分表示が正しいこと |
| 3_2 | 設定config構文確認 | SW | user@SW# commit check configuration check succeeds {master:0}[edit firewall family inet filter JUN_lo] |
configuration check succeeds 表示確認 |
|
| 3_3 | commit | SW | user@SW# commit configuration check succeeds commit complete |
commit complete 表示確認 |
|
| 3_4 | ssh設定config確認 | SW | user@SW> show configuration system services ftp; ssh; telnet; netconf { ssh { port 830; } } |
netconfの設定出力があること | |
| 3_5 | lo向けアクセスフィルタ確認 | SW | user@SW>show configuration firewall family inet filter JUNIPER_Lo term TELNET { from { source-address { 192.168.1.0/24; } destination-address { 10.10.10.1/32; } destination-port 830; } then accept; } ---snip--- |
許可フィルタ設定があること | |
| 3_6 | netconf疎通確認 | サーバ | ssh -l user@192.168.3.39 -p 830 netconf user@192.168.3.39's password: PTY allocation request failed on channel 0 shell request failed on channel 0 [usert@controller ansible]# ssh -s user@192.168.3.39 -p 830 netconf user@192.168.3.39's password: ---snip--- |
netconf接続可能なこと ※サーバ側の設定はサーバ側手順書参照 |
|
| 3_7 | netconfログ出力確認 | SW | user@SW> run show log netconf.log Feb 2 13:17:00 [63571] Outgoing: Feb 2 13:17:09 Started tracing session: 63587 Feb 2 13:17:14 [63587] Outgoing: |
netconfの接続ログが 取得できていること |
|
※この手順書は実工事とは関係ない架空のものです。
netconfを有効化するだけの手順書を自動化するために必要な工程を考慮して書きだすと結構な工数になった。
運用中のNW機器は、SOシステムや管理システム他、手動の保守オペレーションのなどでNW機器のconfigが変更される可能性がある。NWの運用を自動化するには設定前後のconfigだけでなくそんな装置の状態を確実に定義(コード化)して、ハンドリングして、あるべき状態にもっていかないといけない。漏れがあっては自動化できない。
特に自動化の過渡期は、連携していない多くのシステムほとんどのため、NW機器へのログイン時は排他制御は入れておいた(手順1-1、2-1)
＜＜設定してみること＞＞
- 排他的に設定を入れるため処理
netconfでの自動投入設定をtraceできるようにログ出力の設定netconfでのアクセスを許可するためのtermをフィルタの途中に追加netconf設定後の疎通確認
＜＜確認すること＞＞
- configの冪等性を担保できること
- 排他的に設定モードに入れること
- 排他的にcommitできること
netconfが有効になっていること- 通信フィルタで
netconfポート（デフォルトでTCP830）設定が正しい順序で投入されていること。 - ログ出力設定が確認できること
netconfポートへの疎通確認
＜＜結果＞＞
- 公式モジュールの
junos_netconfを使ってnetconfが有効になり、冪等性が担保されることは確認できた。冪等性担保できたのはこれのみ。
＜＜課題＞＞
junos_commandsとjunos_configはstateはサポートしておらず、setで設定投入する場合には問題ないが、deleteでは削除すると2回目からはfailedになってしまう。junos_netconfとjunos_commands、junos_configは接続connectionが異なるため同じplaybookで一度に実行できない- 公式モジュールの機能で排他ログインはできない
- 公式モジュールの機能で排他的なcommitはできなかった。競合していてもcommitまでしてしまう
- 公式モジュールの
junos_commandsではフィルタの挿入位置(判定順)まで確認することはできない - 公式モジュールでファイルの有り無しを判定する方法はなさそう
- 公式モジュールで疎通確認する仕組みもなさそう
＜＜playbook＞＞
junos_830_1.yml
- hosts: junos
gather_facts: no
tasks:
- name: enable netconf service
junos_netconf:
state: absent
- name: set JUN_Lo filter term NETCONF
junos_config:
lines:
- set firewall family inet filter JUN_Lo term NETCONF from destination-port 830
- set firewall family inet filter JUN_Lo term NETCONF then accept
- insert firewall family inet filter JUN_Lo term NETCONF before term ALL_discard
- name: set NETCONF trace
junos_config:
lines:
- set system services netconf traceoptions file netconf.log
- set system services netconf traceoptions flag all
- name: before config backup
junos_config:
backup: yes
＜＜inventory＞＞
[junos] SW ansible_host=192.168.3.39 [junos:vars] ansible_ssh_user=hogehoge ansible_ssh_pass=hoge1234 ansible_network_os=junos ansible_connection=netconf #ansible_connection=network_cli
＜＜思ったこと＞＞
公式モジュールのサンプルを使ってすぐにできたことはnetconfの有効化のみ。
yamlの記載で対応できるところはがんばりたい。習熟しないと。
Junosの場合、cisco機器のように1行設定する毎に動作に反映するわけではないので、設定も状態確認もcommit単位で行うのがよさそう。
シーケンスとしては、
①現在の装置の状態をshowコマンドで確認
②「commit後の想定config」を装置に上書き、commitは未だしない
③「現在のconfig」⇔「commit後の想定config」を比較確認
④確認結果に問題がなければcommit
⑤commit後のの装置の状態をshowコマンドで確認
⑥確認結果に問題がなければ終了、ダメならrollback
config全体を②で上書きするのでフィルタの挿入位置など考慮がいらないし
③の比較ももともとJunosが具備している機能を使えばよい。
やはり①と⑤の状態確認をどう実装するかがキモかも。
次回以降のJunosは、juniper.junosのrolesを組み合わせて運用手順を自動化してみる。
