はじめに

netmiko、NAPALM、Ansible のように、既存のネットワークを自動化できるOSSが増えてきました。それでもやはり、自動化しやすい機器としにくい機器があるなと考えています。

この記事では機器使用面、環境面含めてそれぞれれまとめます。（当たり前と思われるかもしれませんが、改めて。）

■ TELNET のみ対応の機器

「はじめに」でご紹介したような OSS は、基本的に SSH 接続が前提です。NETCONF や HTTP API に対応しているものもあります。

TeraTerm マクロの延長で考えると、接続方法（TELNET/SSH）は特に関係ないのではと思われるかもしれません。TeraTerm マクロの場合は、接続処理を TeraTerm 本体が担っていています。一方で、上記のような OSS は TeraTerm とは別の仕組みを利用しており、接続方法はその仕様に依存します。 Python では Paramiko という Python で書かれた SSH 実装を利用している OSS が多いです。

一応、netmiko で telnet ができたり、Ansible に telnet モジュールがあったりはします。

Ansible の場合

Ansible で Cisco IOS の機器に対して、show version を実行する場合に、telnet と SSH でどのように Playbook の書き方が異なるか見てみます。

telnet (telnet モジュール)

telnet するには telnet モジュールを利用します。（公式ドキュメントから引用）

- name: run show commands
  telnet:
    user: cisco
    password: cisco
    login_prompt: "Username: "
    prompts:
      - "[>|#]"
    command:
      - terminal length 0
      - show version

SSH (ios_command モジュール)

SSH で Cisco IOS も show コマンドを実行するには ios_command モジュールを利用します。（公式ドキュメントから引用）

- name: run show version on remote devices
  ios_command:                   # 注釈）認証情報は別途定義したものを利用（標準機能）
      commands: show version

違いは？

ご覧いただいたように、ios_command モジュールのほうがシンプルに書けます。telnet モジュールの各オプションで指定しているような、

ログインする際のプロンプトはどのような文字列か
CLI のプロンプトはどのような文字があり得るか
ページャを無効にするための terminal length 0

といった定義は、ios_command モジュール内にあらかじめ組み込まれています。そのため、Playbook はシンプルに書けます。

また、各種OSSは SSH や、NETCONF、WEB API 対応が中心であるため、もし telnet 接続機能にバグがあって、issue やプルリクエストを出しても、低い優先度で扱われてしまう可能性もあります。

TELNET が自動化しにくい理由まとめ

各種OSSは SSH や、NETCONF、WEB API 対応が中心
telnet できる機能があったとしても、おまけ的

もちろんセキュリティの観点もあります。

[2019/07/28 追記] twitterでこんな意見もいただきました

特に
1. データを保存&ダウンロード取得がtelnet単体でできない
2. 標準出力の取得時にへんなゴミが入って動作が想定外になりやすい
3. 若者が身につけるべき専門知識としてはもう賞味期限切れ (教養として知っていれば良い)
あたりが、「telnetがやめよう」の根拠です。
— HATANO Hirokazu (@tcsh) 2019年7月28日

■ Web UI のみ対応の機器

Web UI は人が直接操作するのに適している UI であり、自動化（機械的に処理）するには向いていません。 selenium で自動化しようとしても、ちょっとした画面の変更で動かなくなったりする可能性があります。本来作りこみたい処理に比べて、画面遷移処理などのオーバーヘッドが高くなりがちです。

■ 踏み台の向こう側の機器

手作業に踏み台サーバーにログインして、そこからさらに対象のネットワーク機器にログインする運用もあると思います。自動化するときも踏み台を経由しなければいけない場合は、一工夫必要になります。環境によっては難しいケースもあるかもしれません。また、複雑な環境によりトラブルシューティングもしにくくなってしまう可能性があります。

参考: Ansible FAQ
- How do I configure a jump host to access servers that I have no direct access to?

自動化のしやすさの面では直接接続できる環境のほうが良いと思います。構成次第ではAnsibleをインストールしたサーバー自体を踏み台と見なせるケースもありそうです。

さいごに

今回は大枠での私見をまとめました。抜けてる観点などありましたら @akira6592 へご連絡いただけると幸いです。 SSH ができても show コマンド結果が json などのマリンリーダブルな形式で出力できない、など細かいところではまだあると思います。

てくなべ (tekunabe)

ansible / network automation / 学習メモ

ネットワーク自動化しにくい機器（TELNET/WebUI/踏み台の向こう）