KokeLab

Cisco/Linux/AWS/Ansible/Kubernetes

Ansibleを使ってCatalystのVLAN管理をしてみた

お久しぶりです。コケラです。

最近Twitterで、TeraTermに関する有益な情報を発見しました。


どうやら、TeraTermの背景を任意の画像に変更できるようです。ということで、さっそく私もやってみました。

f:id:kokelabo:20190913131146p:plain
妻です……ウソです
モチベーションが上がり、よりいっそう日々の学習が捗りそうですね。皆さんもぜひ試してみてはいかがでしょうか?

閑話休題

CCNPLPICといった資格の勉強に時間を割いていたこともあり、約半年ぶりのブログ更新となってしまいました。
そんな半年ぶりの本記事で、今回、皆さんにシェアしたいのは、構成管理ツールAnsibleを利用したVLAN設定の自動化です。
Ansibleについては、1月頃に本ブログでいちばん最初に公開した記事でも少し言及しましたが、サーバやNW機器の設定を自動で実行してくれる、オープンソースPython製のツールです。
Python製といっても、ごく一般的な使い方をするだけであれば、Pythonの知識は全く必要ありません。詳しくは後述します。

AnsibleでVLAN管理をしてみたいと思ったきっかけ

そもそも、なぜこういったことを試してみたいと思ったのか。それはやはり、VLANの設定を自動化できれば、間違いなく業務のKAIZENに繋がるだろうなと、実業務を通じて感じたからです。自動化してみたいなと感じたからです。
私はいま、NWの運用業務に携わっていることもあり、顧客の方から様々なシステム更改の依頼を受けることがあります。システムの追加や廃止、拠点間通信やDHCPの固定割り当てなど、依頼は多岐にわたります。私見となりますが、このなかでも特に「システムの追加や廃止」は、膨大な量の設定作業が伴うことが多いです。
新たなシステムを追加するとき、そのシステムで使うVLANを新規で機器にアサインしないといけない場合があり、NWの構成や規模にもよりますが、その設定作業に膨大な手間と時間を要する可能性があります
例えば、以下のようなNW構成があったとします。
f:id:kokelabo:20190914120704j:plain
コア層、ディストリビューション層、アクセス層と3階層に分かれた、よくあるNW構成ですね。
このNW構成において、例えば、とある拠点に設置されているSWAのFa0/1ポートに新システム用のVLANをアサインすることになれば、どれだけの設定作業が必要になってくるでしょうか。
もったいぶらずに答えだけを言うと、Coreを含めONUに繋がっている全スイッチの(WAN用)ポートに、TrunkでVLANを透過させる設定が必要になってきます。要するに、上図でポート番号が記されている全ての箇所です。ポートに新たなVLANをアサインするからには、VLAN定義もしなければなりません
数拠点ならまだしも、これが数十拠点、数百拠点となると……想像しただけでも鳥肌が立ちますね。それに、実際の現場で運用されているようなNW構成では、コスト面や更なる冗長化の確保のために、より複雑な構成である場合が多いです。複雑であればあるほど、更に同じような設定作業が必要になってきます。
「いちいち1拠点ずつ手順書を作成して、1拠点ずつ機器にログインして設定を投入するの大変だなぁ」と、実際に作業していて感じました。もちろん、私ひとりで全部やったわけではなく、数人で手分けしてやったのですが、それでも大変な作業でした。
ある日、この作業をもっと効率よく行える方法があるのではないかと疑問に思い、ふと頭に浮かんだのがAnsibleです。
Googleで「Ansible VLAN」と検索してみると、こちらのQiita記事を見つけました。
「やっぱりできるのか!」と、興奮せざるを得ませんでした。
ただ、こちらの記事はある程度、Ansibleの使い方を分かっているエンジニア向けだったので、完全にAnsible初心者なエンジニアがこちらの記事だけを参考にして試しても、おそらく上手くいかないかと思われます。
ということで本記事では、Ansible初心者なエンジニアの方々のために、もう少し色々な要素を噛み砕きながら、VLAN設定の自動化を解説していきたいと思います。

検証環境

  • ノートPC(Windows10/i7-8550U/RAM16G)
  • Ansible 2.8.4

Ansibleのインストール

まずは、CentOSにAnsibleをインストールします。本記事執筆時点(2019/9/14)では、CentOSの標準リポジトリにAnsibleが登録されていないので、Ansibleをインストールする前に、EPEL(Extra Package for Enterprise Linux)パッケージをインストールして、EPELリポジトリを利用します。

[root@localhost ~]# yum install -y epel-release
[root@localhost ~]# yum install -y ansible

インストールが完了したら、Ansibleのバージョンを確認します。

[root@localhost ~]# ansible --version
ansible 2.8.4
   config file = /etc/ansible/ansible.cfg

最新のバージョンであることを確認してください。余談ですが、EPELパッケージをインストールせずにAnsibleをインストールすると、以下のように最新のバージョンが正しくインストールされていませんでした。

[root@localhost ~]# ansible --version
ansible 2.4.2.0
  config file = /etc/ansible/ansible.cfg

InventoryとPlaybookの編集

InventoryとPlaybookを編集する前に、CatalystSSHの設定を済ませておきましょう。コマンドプロンプト等からPingが通り、VMからSSH接続できるかどうか確認しておきます。

[v-kento@localhost ~]$ ssh spira@192.168.0.254
Password:

Tidus>

SSHの設定が完了したら、いよいよInventoryとPlaybookを編集していきます。
Inventoryとは、接続先のホスト(サーバ)を定義したり、その接続方式や認証情報を変数定義するファイルです。基本的には、どのホストに対して設定を行うのかを決めるためのファイルとなります。
説明だけでは分かりづらいと思うので、実際にInventoryを編集してみましょう。
Inventory用に新たなファイルを用意するのも良いですが、今回は/etc/ansible/配下にデフォルトで存在するhostsファイルにInventoryを置きます。というのも、後述するansible-playbookコマンドの-iオプションでInventoryを指定しなかった場合、デフォルトでhostsファイルをInventoryとして読み込んでくれるからです。わざわざInventoryを新たに用意して、オプションで指定する必要もなくなります。

[root@localhost ansible]# vi hosts
[spira] 
192.168.0.254 

[spira:vars]
ansible_connection=network_cli
ansible_network_os=ios
ansible_ssh_user=spira
ansible_ssh_pass=nagi
ansible_become=yes
ansible_become_method=enable
ansible_become_pass=yuna

このように、InventoryはINI形式で記述するのが主流ですが、Playbookと同様にYAML形式でも記述することができます。見やすさ、編集のしやすさという意味では、INI形式で記述したほうがベターだと思われます。複雑な変数を定義したい場合は、YAML形式で記述されることもあります。

  • [任意のグループ名]で、複数の対象ホストをグループ化することができます。その下に対象ホストのIPアドレスやホスト名を列記していきます。複数台でやったほうが良い検証になりますがメンドクサイので、今回は一台だけで検証します。
  • [任意のグループ名:vars]で、グループ化した対象ホストへ接続する際の接続方式や認証情報を共通の変数として定義し列記していきます。

ansible_connection変数
⇒ネットワーク機器へのプラグイン情報を定義。network_cli以外だと、JUNOS対応のnetconfも指定可。

ansible_network_os変数
⇒プラットホームを定義。例えば、Cisco IOSならiosと指定し、JUNOS OSならjunosと指定する。
プラグイン情報としてnetwork_clinetconfを指定した場合は必須の定義となる。

ansible_ssh_user変数
SSH先のSSHユーザー名を定義。

ansible_ssh_pass変数
SSH先のSSHパスワードを定義。

ansible_become変数
⇒特権モード(enable)への移行が必要かどうかを定義。グローバルコンフィギュレーションモード(config)へ移行しないとVLAN等の設定は不可能なので、必ずyesと指定する。デフォルトではnoとなっている。

ansible_become_method変数
⇒特権モードへ移行するためのコマンドを定義。プラグイン情報としてnetwork_cliを指定していた場合はenableのみ指定可。

ansible_become_pass変数
⇒特権モードへ移行するためのパスワードを定義。

これらの変数情報は、ansible-playbookコマンドのオプションでも指定することができたり、Playbookにも記述することができますが、管理上Inventoryでまとめて定義しておいたほうが無難でしょう。
Inventoryを編集しましたので、続けてPlaybookを作成しましょう。
Playbookとは、対象ホストにどのような設定を行うのかを定義するファイルです。ChefでいうところのRecipeですね。実行したい設定情報のレシピというわけです。
先述しましたが、PlaybookはYAML形式で記述できるファイルで、いわゆるコードを書くようなプログラミングの未経験者であっても理解しやすいものとなっています。Pythonなど高度なプログラミング言語が書けなくても、サンプルを参考にすれば簡単に書くことができます。
それではさっそく、Playbookを作成していきましょう。ファイルの場所はhostsファイルと同じく、
/etc/ansible/配下とし、ファイル名はvlan.ymlとします。

[root@localhost ansible]# vi vlan.yml
---
 - hosts: spira
   gather_facts: no
   tasks:
    - name: vlan10
      ios_vlan:
        vlan_id: 10
        name: Rikku
        state: present
    - name: vlan20
      ios_vlan:
        vlan_id: 20
        name: Auron
        state: present
    - name: no vlan50
      ios_vlan:
        vlan_id: 50
        state: absent
    - name: Fa0/3
      ios_l2_interface:
        name: FastEthernet0/3
        mode: access
        access_vlan: 10
    - name: Fa0/5
      ios_l2_interface:
        name: FastEthernet0/5
        mode: access
        access_vlan: 20
    - name: Fa0/15 remove
      ios_l2_interface:
        name: FastEthernet0/15
        mode: trunk
        trunk_vlans: 50
        state: absent
    - name: Fa0/15 add
      ios_l2_interface:
        name: FastEthernet0/15
        mode: trunk
        trunk_vlans: 10,20
        state: present

今回はVLANの設定をしたいので、ios_vlanios_l2_interfaceという2つのモジュールを使います。Playbookにおけるモジュールとは、例えるなら料理の材料でしょうか。

  • - hosts: ではInventoryで定義したホストグループ名を記述します。Inventoryで[spira]と定義しましたので、hosts: spiraとします。
  • gather_facts:では対象ホストのメタデータを取得するかどうかを記述します。有効にすると、そのぶんPlaybookの実行に時間がかかりますし、今回はあくまでも検証ということでnoにしておきます。
  • - name: では対象ホストに行うタスク名を記述します。このタスク名は任意で付けるものなので、どのような名前でも構いません。

NW機器の設定に詳しい方なら、上記のPlaybookがどのような設定情報を定義しているのか、なんとなく分かるかと思います。タスクごとに、上から順番に説明していきます。

★VLAN10(Rikku)を定義
★VLAN20(Auron)を定義
★定義されていたVLAN50を削除
★定義したVLAN10をFa0/3ポートにアサイン(Access)
★定義したVLAN20をFa0/5ポートにアサイン(Access)
★Fa0/15ポートにアサイン(Trunk)されていたVLAN50をリムーブ
★定義したVLAN10とVLAN20をFa0/15ポートにアサイン(Trunk)

以上、7つのタスクを行うPlaybookとなります。
本当は1つのモジュールだけを使って、もう少しシンプルな形にしたかったのですが、ios_vlanモジュールはtrunkの設定をサポートしておらず、ios_l2_interfaceモジュールはVLAN定義の設定をサポートしていないようなので、これら2つのモジュールを組み合わせました。
ios_vlanモジュールとios_l2_interfaceモジュールは、Ansible 2.9より非推奨のモジュールになる予定とのことです。それぞれ幾つかの機能が追加されてios_vlansモジュール、ios_l2_interfacesモジュールとして生まれ変わります。複数形になります。なぜ複数形になるのかは不明です。

Playbookの実行

Playbookを実行する前に、Ansibleのpingモジュールを使って簡易的な疎通確認をしておきましょう。pingといっても、よく知られているICMPを利用したpingとは少し異なります。単に対象ホストにモジュールでSSH接続できるのかどうかを試すものです。

[v-kento@localhost ansible]$ ansible 192.168.0.254 -m ping
192.168.0.254 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

Ansibleが正常に動作していれば、このように"pong"が返ってきます。
ちゃんとSSHの設定ができていなかったり、先述しましたansible_connection変数などの変数情報を、Inventoryやオプションで指定し定義されていなければ、SUCCESSとならずPlaybookも実行できません。
もうひとつ確認しておきたいのがPlaybookに文法的な誤りがないかどうかです。--syntax-checkオプションをつけてansible-playbookコマンドを実行してみましょう。

[v-kento@localhost ansible]$ ansible-playbook vlan.yml --syntax-check

playbook: vlan.yml

このように何もエラーメッセージが表示されなければ、Playbookに文法的な誤りはありません。
対象ホストへの疎通確認とPlaybookの文法チェックができましたので、いよいよPlaybookを実行してみます。

[v-kento@localhost ansible]$ ansible-playbook vlan.yml

PLAY [spira] *******************************************************************

TASK [vlan10] ******************************************************************
changed: [192.168.0.254]

TASK [vlan20] ******************************************************************
changed: [192.168.0.254]

TASK [no vlan50] ***************************************************************
changed: [192.168.0.254]

TASK [Fa0/3] *******************************************************************
 [WARNING]: The value 10 (type int) in a string field was converted to u'10'
(type string). If this does not look like what you expect, quote the entire
value to ensure it does not change.

changed: [192.168.0.254]

TASK [Fa0/5] *******************************************************************
 [WARNING]: The value 20 (type int) in a string field was converted to u'20'
(type string). If this does not look like what you expect, quote the entire
value to ensure it does not change.

changed: [192.168.0.254]

TASK [Fa0/15 remove] ***********************************************************
 [WARNING]: The value 50 (type int) in a string field was converted to u'50'
(type string). If this does not look like what you expect, quote the entire
value to ensure it does not change.

changed: [192.168.0.254]

TASK [Fa0/15 add] **************************************************************
changed: [192.168.0.254]

PLAY RECAP *********************************************************************
192.168.0.254              : ok=7    changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

PLAY RECAPを見ると、: ok=7 changed=7となっています。無事に7つのタスクが正常に実行されました。
ios_l2_interfaceモジュールを使ったタスクでWARNINGが出ていますが、これはPythonの文法上の仕様によるものです。要するに「文字のデータ型がint型からstr型に変換されたけど大丈夫?数値ではなくて文字列として扱うけど大丈夫?」という警告でして、文字列として扱われても特に問題ありません。Playbookは正常に実行されていますので、気にする必要はありません。
対象ホスト(Catalyst2960)のPlaybook実行前と実行後の状態はこちらです。

★実行前★

Tidus#sh vlan bri

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4
                                                Fa0/5, Fa0/6, Fa0/7, Fa0/8
                                                Fa0/9, Fa0/10, Fa0/11, Fa0/12
                                                Fa0/13, Fa0/14, Fa0/16, Fa0/17
                                                Fa0/18, Fa0/19, Fa0/20, Fa0/21
                                                Fa0/22, Fa0/23, Fa0/24, Gi0/1
                                                Gi0/2
50   VLAN0050                         active
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup

Tidus#sh int tru

Port        Mode             Encapsulation  Status        Native vlan
Fa0/15      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/15      50

Port        Vlans allowed and active in management domain
Fa0/15      50

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/15      none

★実行後★

Tidus#sh vlan bri

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/2, Fa0/4, Fa0/6
                                                Fa0/7, Fa0/8, Fa0/9, Fa0/10
                                                Fa0/11, Fa0/12, Fa0/13, Fa0/14
                                                Fa0/16, Fa0/17, Fa0/18, Fa0/19
                                                Fa0/20, Fa0/21, Fa0/22, Fa0/23
                                                Fa0/24, Gi0/1, Gi0/2
10   Rikku                            active    Fa0/3
20   Auron                            active    Fa0/5
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup

Tidus#sh int tru

Port        Mode             Encapsulation  Status        Native vlan
Fa0/15      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/15      10,20

Port        Vlans allowed and active in management domain
Fa0/15      10,20

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/15      10,20

意図通りConfig投入されていることが分かります。

おまけ

おまけというか、Ansibleを使う上でやっておくと便利な小技を紹介します。まぁ、小技というほどのものでもないですが。
/etc/ansible/配下にある、Ansibleの各ファイルのデフォルトのパーミッションを確認してみると、以下のようになっています。

[root@localhost ansible]# ll
合計 28
-rw-r--r--. 1 root root 19980  8月 17 05:54 ansible.cfg
-rw-r--r--. 1 root root  1016  8月 17 05:54 hosts
drwxr-xr-x. 2 root root     6  8月 17 05:54 roles
-rw-r--r--. 1 root root     5  9月  4 22:26 vlan.yml

hostsファイルとPlaybook(vlan.yml)のファイルが所有者(root)ユーザーのみ書き込み可能となっています。いちいちrootユーザーになってから編集するのは非効率的で面倒なので、ファイルのパーミッションを変えましょう。sudoでも良いですが、それはそれでまた手間がかかるので、ファイルのパーミッションを変えてしまったほうがベターかと思います。

[root@localhost ansible]# chmod 666 vlan.yml
[root@localhost ansible]# chmod 666 hosts
[root@localhost ansible]# ll
合計 28
-rw-r--r--. 1 root root 19980  8月 17 05:54 ansible.cfg
-rw-rw-rw-. 1 root root  1016  8月 17 05:54 hosts
drwxr-xr-x. 2 root root     6  8月 17 05:54 roles
-rw-rw-rw-. 1 root root     5  9月  4 22:41 vlan.yml

おわりに

Ansibleを利用したVLAN設定の自動化を紹介させて頂きましたが、皆さんいかがだったでしょうか。
私自身もまだAnsibleを始めて1カ月半ほどで、細かいディティールまで詰め切れてないこともあり、まだまだ分からないことがたくさんあります。ですので、本記事を鵜呑みにして信用し過ぎるのはリスキーだと思います。しがないエンジニアによる、ただの自己満記事だと捉えて頂ければ幸いです。
Ansibleはシンプルさも奥深さも兼ね備えた良いツールだなと感じました。無限の可能性を感じますし、これからも自動化ツールとして、より普及していくことを切に願っています。
ここまで長々とお付き合い下さいまして有難うございました!(次はroleとかjinja2使って遊んでみたいな)

NW障害時の切り分けに役立つコマンド集

皆さん、おはこんばんにちは。最近、花粉のせいでSAN値ピンチなコケラです。

タイトルにもある通り、今回はNW障害時のトラブルシューティングに役立つコマンドをいくつか紹介していこうかなと思います。基本的にはCisco IOSで、もしくはMS-DOS系で使えるコマンドとなります。
内容的には、超初心者~初中級者向けとなっているので、それほど難しいものではありません。とてもよく使うコマンドを★★★に、よく使うコマンドを★★☆に、たまに使うコマンドを★☆☆と、使用頻度別に分類して紹介していきますね。

ping [アドレス](★★★)

いわずもがな、IT技術に携わる全ての人たちが知っておくべき超定番コマンドです。ネットワークやサーバとの疎通確認ができます。

Router#ping 34.0.0.4 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms 

Cisco IOSでは、上記のように!!!!!マークが表示されれば通信成功です。

MS-DOS系だと以下のようになります。

C:\Users\●●●>ping 127.0.0.1

127.0.0.1 に ping を送信しています 32 バイトのデータ:
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128

127.0.0.1 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 0ms、平均 = 0ms

ping [アドレス] -t(★★☆)

pingコマンドに-tオプションを付けることで、Ctrl+Cで明示的に終了させるまでずっと、pingを連続実行することができます。

C:\Users\●●●>ping 127.0.0.1 -t

127.0.0.1 に ping を送信しています 32 バイトのデータ:
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128

127.0.0.1 の ping 統計:
    パケット数: 送信 = 9、受信 = 9、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 0ms、平均 = 0ms
Ctrl+C
^C

こうした連続pingを実行したい場合や、例えば複数のIPアドレスに連続pingを実行したい場合は、ExPingというツールがよく使われたりします。非常に有名な定番ツールなので、覚えておいて損はないでしょう。

ping [アドレス] -n 回数(★★☆)

MS-DOS系で、実行する回数を指定してpingを実行させたい時は-nオプションを付けます。Cisco IOSなら、-nをrepeatに変えてください。ハイフンは不要です。

C:\Users\●●●>ping 127.0.0.1 -n 10

127.0.0.1 に ping を送信しています 32 バイトのデータ:
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128
127.0.0.1 からの応答: バイト数 =32 時間 <1ms TTL=128

127.0.0.1 の ping 統計:
    パケット数: 送信 = 10、受信 = 10、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 0ms、平均 = 0ms

ping vrf [vrf名] [アドレス](★★☆)

VRFによって、L3でシステムを分離させている場合、各システムで設定したVRF名を指定しないとpingを実行できません。VRFに関しては、いずれまた別記事でまとめようかと思います。とりあえずは、VLANのL3バージョンだという認識で良いです。

CoreSW#ping vrf Kokera 192.168.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/38/44 ms

telnet [アドレス](★★★)

pingと同じくらい重要なコマンドです。指定したアドレスが設定されている機器へ接続し、遠隔で操作することができます。telnetで機器に遠隔で接続し、showコマンドで機器の状態を調べたり、機器の設定を変更したりすることができます。

Router#telnet 10.10.10.1
Tryng 10.10.10.1 ... Open
User Access Verification

Password:

telnet [アドレス] /vrf [VRF名](★★☆)

VRFが設定されている機器へtelnet接続を行う場合、pingと同様、VRF名を指定しないといけません。pingの時とは少しVRF名の指定方法が異なるのでややこしいです。末尾に/vrf [vrf名]を付けてください。

CoreSW#telnet 10.10.10.1 /vrf Kokera
Tryng 10.10.10.1 ... Open
User Access Verification

Password:

show logging(★★★)

sh logも定番のコマンドです。主に機器のインターフェースのリンク状況を調べたい時に使います。

Switch#sh log
*Feb 31 17:14:01.095: %LINK-3-UPDOWN: Interface FastEthernet 0/1, changed state to up
*Feb 31 17:14:01.103: %LINK-3-UPDOWN: Interface GigabitEthernet1/0, changed state to up
*Feb 31 17:14:01.111: %LINK-3-UPDOWN: Interface GigabitEthernet2/0, changed state to up
*Feb 31 17:15:02.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Feb 31 17:15:02.223: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0, changed state to down

例えば、1行目の「*Feb 31 17:14:01.095: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up」を見ると、Switch1のFa0/1が2月31日の17時14分にリンクアップして、
4行目の「*Feb 31 17:14:02.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down」で、17時15分にリンクダウンしていることが分かります。
このログによって「Fa0/1に繋がっているケーブルの接触が悪いか故障したのかも?あるいは、機器を移動させたりするために、誰かがケーブルを抜き差ししてるのかも?」と推測することができます。
余談ですが、デフォルトの状態では、上記のように日時が表示されません。日時が表示されないとあまり意味がないので、以下のコマンドを投入しましょう。

Switch(config)#service timestamps log datetime msec

show version(★★★)

sh verでは主に、機器のIOSのバージョンやFlashメモリのサイズ、シリアルナンバーや機器が起動してからの経過時間を確認することができます。これらの4項目はどれも重要ですが、運用・保守業務において特に重要なのは「機器が起動してからの経過時間」です。

Router#sh ver
Cisco IOS Software, C860 Software (C860-UNIVERSALK9-M), Version 12.4(24)T3, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Tue 23-Mar-10 18:07 by prod_rel_team

ROM: System Bootstrap, Version 12.4(22r)YB5, RELEASE SOFTWARE (fc1)

Router uptime is 1 minute
System returned to ROM by power-on
System image file is "flash:c860-universalk9-mz.124-24.T3.bin"

(略)

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 861 (MPC8300) processor (revision 1.0) with 249856K/12288K bytes of memory.
Processor board ID ●●●●●
5 FastEthernet interfaces
256K bytes of non-volatile configuration memory.
125440K bytes of ATA CompactFlash (Read/Write)

License Information for 'c860-data'
    License Level: advsecurity   Type: Permanent
    Next reboot license Level: advsecurity


Configuration register is 0x2102

show ip interface brief(★★☆)

機器のすべてのインターフェースに設定されているIPアドレスおよび、それらの物理層データリンク層の状態を確認できます。

Router#sh ip int brief

Interface              IP-Address      OK? Method Status                Protocol
Serial1/0              192.168.1.1     YES unset  administratively down down
Serial1/1              172.16.1.1      YES unset  administratively down down
Serial1/2              unassigned      YES unset  administratively down down
Serial1/3              unassigned      YES unset  administratively down down
FastEthernet0/0        10.1.1.1        YES unset  up                    up

show interfaces status(★☆☆)

機器のすべてのインターフェースのリンクステータス、Vlan番号、Duplex/Speedの状態を確認できます。意外と使う機会がないように感じます。

Switch#sh int status

Port    Name               Status       Vlan     Duplex Speed   Type
------- ------------------ ------------ -------- ------ ------- ----
Fa0/1                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/2                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/3                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/4                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/5                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/6                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/7                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/8                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/9                      notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/10                     notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/11                     notconnect   1         Auto   Auto   100BaseTX/FX
Fa0/12                     notconnect   1         Auto   Auto   100BaseTX/FX

show interfaces [インターフェース] | include broadcasts(★★☆)

該当機器の配下でループ接続になっている場合、ブロードキャストストームが発生する時があります。このコマンドは、指定したインターフェースが受け取ったブロードキャスト値だけを抜き出して確認することができます。
数回コマンドを実行し、受け取ったブロードキャスト値が激しく増加していたら、該当機器の配下でのループを疑いましょう。

Router#sh int fa 1 | include broadcasts
Received 153355 broadcasts , 0 runts, 0 giants, 0 throttles

show ip dhcp binding(★★☆)

DHCPによって配布されたIPアドレスの払い出し状況を確認することができます。配下のクライアント端末が何台あって、どのIPアドレスがどの端末に配布されたのか調べることができます。

Router#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
172.16.1.2          0100.9f31.0a00.00       Jan 18 2014 04:36 PM    Automatic
172.16.1.3          0100.9f31.0b00.00       Jan 18 2014 04:38 PM    Automatic

show mac address-table(★★☆)

機器が学習しているMACアドレスの情報をインターフェース毎に確認することができます。

Switch#sh mac address-table               
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 All    0100.0ccc.cccc    STATIC      CPU    
 All    0180.c200.0001    STATIC      CPU
 All    0180.c200.0002    STATIC      CPU
 All    0180.c200.0003    STATIC      CPU
 All    0180.c200.0004    STATIC      CPU
 All    0180.c200.0005    STATIC      CPU
 All    0180.c200.0006    STATIC      CPU
 All    0180.c200.0007    STATIC      CPU
 All    0180.c200.0008    STATIC      CPU
 All    0180.c200.0009    STATIC      CPU
 All    0180.c200.000a    STATIC      CPU
 All    0180.c200.000b    STATIC      CPU
 All    0180.c200.000c    STATIC      CPU
 All    0180.c200.000d    STATIC      CPU
 All    0180.c200.000e    STATIC      CPU
 All    0180.c200.000f    STATIC      CPU
 All    0180.c200.0010    STATIC      Fa0/1
 All    ffff.ffff.ffff    STATIC      CPU
Total Mac Addresses for this criterion: 20

show process cpu(★☆☆)

機器での過去5秒間、1分間、5分間のCPU使用率をプロセス毎に確認できます。historyを付け加えると、過去60秒間、60分間、72時間におけるCPU使用率をグラフィカルに表示させることもできます。

Switch#sh process cpu
CPU utilization for five seconds: 16%/4%; one minute: 17%; five minutes: 17%
 PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process
   1           0      1956      0   0.00%  0.00%  0.00%   0 Load Meter
   2          47        18   2611   0.20%  0.01%  0.00%   0 Exec
   3        6374      1162   5485   0.00%  0.04%  0.05%   0 Check heaps
   4           0         1      0   0.00%  0.00%  0.00%   0 Chunk Manager
   5           0         1      0   0.00%  0.00%  0.00%   0 Pool Manager
   6           0         2      0   0.00%  0.00%  0.00%   0 Timers
   7          21         3   7000   0.00%  0.00%  0.00%   0 Entity MIB API
   8          46      2442     18   0.00%  0.00%  0.00%   0 HC Counter Timer
   9          11       165     66   0.00%  0.00%  0.00%   0 ARP Input
  10         760      9702     78   0.00%  0.00%  0.00%   0 Enet Aging
  11           0         1      0   0.00%  0.00%  0.00%   0 Critical Bkgnd
  12         129      4673     27   0.00%  0.00%  0.00%   0 Net Background

(後略)

show tech-support(★☆☆)

障害時に参考になるであろう確認コマンドを全てまとめて実行してくれるコマンドです。どういう時に使うのか、察しの良い方なら気付かれるでしょう。要するにこういうことです。
どんだけ調べても障害の原因が分からねーから、超絶エキスパートな人に障害切り分け丸投げだー!という時に使います。
もちろんシスコの中の人でも良いですし、シスコ機器の取り扱い企業No1のNOS(ネットワンシステムズ)のサポートに、このsh techを送り付けるのも良いでしょう。サポート契約を結んでないと出来ませんが。
当然ながら、コマンドの実行例は割愛させて頂きます。とてつもなく膨大な量ですし、文字通りいろいろな確認コマンドをまとめて実行しているだけなので。

以上でコマンド紹介を終わらせて頂きます。いかがだったでしょうか。本記事で紹介したコマンドは、すべて実際に業務で使用したことがあるので、かなり実用的な内容になったのではないかと思います。
本記事の内容が、少しでも皆さんのお役に立てれば幸いです。

Flex Linkの設定

どうも、お久しぶりです。コケラです。

前回はどちらかというと「自分語り系」の記事となりましたが、今回は「技術系」の記事とさせて頂きます。
技術系の記事では、私が実際に自学習や現場での経験で学んで、「面白いなぁ」「覚えておきたいなぁ」と感じた技術を紹介していきます。
技術系の記事としては、記念すべき第一回目。今回、皆さんにシェアしたいのは、Flex Linkという技術です。

Flex Linkとは

Flex LinkはL2における冗長化の設定です。L2で冗長化というと、真っ先に思いつくのがSTP(Spanning Tree Protocol)ですよね。あとは、EtherChannelなどでしょうか。まぁ今回はちょっとEtherChannelのことは忘れてください。EtherChannel?なにそれ美味しいの?
リング構成(ループ構成)でL2のネットワークを冗長化させている場合、STPを実装しないとブロードキャストストームが発生してしまいます。
なので、下図(トポロジー1)のように、スパニングツリーアルゴリズムで特定のスイッチのポートからブロッキングポート(以下BP)を選出し、ARPのフレームがぐるぐると無限にループしないようにすることで、ブロードキャストストームの発生を未然に防ぐわけです。

f:id:kokelabo:20190207015050p:plain
[トポロジー1]BP選出によるループ回避
BPは冗長リンクとしての役割も果たします。例えば、SWA-B間で障害が発生した場合、SWCのポートがBPのままだと、PCA-B間で通信ができなくなりますよね。とはいえ、いつも「ケーブルかスイッチ交換するまで通信断だわー、あははーw」となるわけではありません。当然ですが、救済措置が用意されています。SWA-B間で障害が発生すると、BPだったSWCのポートが自動的に開放され、トラフィックの送受信ができるようになります。
これ以上STPの詳細な動作やらBPDUの具体的な動きやらを説明すると、それこそ冗長な記事になってしまうので、さすがに本記事では省かせて頂きます。STPはやや複雑な技術で管理も難しく、導入のハードルが少し高いです。詳しいことは、Google先生にでも訊いてください。
というわけで、Flex Linkの話に戻りますが、Flex LinkはこのSTPの代替ソリューションとして利用されることがあります。要するに「ちょっとSTP使いたくないから、Flex Linkにするわ」というケースが発生し得るのです。先述しました通り、STPは仕組みが複雑な分、管理が少し難しいです。また、障害発生時に、BPが開放されるまでのコンバージェンスに50秒ほどの時間を要します。たかが50秒でも、状況によっては大惨事となります。そして、BPDUの動作で、無駄なトラフィックが流れてしまうこともあります。
こういったSTPのデメリットを回避できるよう、CatalystにはFlex Linkという機能が用意されています。STPでは、BPDUを使って複数のスイッチ間で連携し合いながら動作するのに対し、Flex Linkは該当機器単体だけで動作します。なので、STPに比べると非常にシンプルで分かりやすく、導入のハードルも低いといえるでしょう。障害を検知してからの切り替えも、STPだと50秒ですが、Flex Linkは100ミリ秒以内でコンバージェンスします。説明だけでは分かりにくいかと思うので、実際に設定しながら解説していきます。

コンフィグ

f:id:kokelabo:20190209120951p:plain
[トポロジー2]SWBFlex Linkの設定
Flex Linkでは、2つのスイッチポートを利用して、アクティブリンクとスタンバイリンクのペアを明示的に作成します。上図(トポロジー2)のようにCatalystを3台用意し、そのうちSWBのFa0/1を平常時に使うアクティブポートに、Fa0/5を障害時に切り替わるスタンバイポート(バックアップポート)とし、実際にコンフィグを投入していきましょう。
余談ですが、L2のループ構成にして、なにも設定しないデフォルトの状態では、自動的にSTPが動作します。下図(画像1、2)のように、SWAのFa0/1が自動的にBPとして選出され、オレンジ点灯となりました。
f:id:kokelabo:20190217161042j:plainf:id:kokelabo:20190217164935p:plain
[画像1、2]SWAのFa0/1がBPとして選出

SWB(config)#int fa0/1
SWB(config-if)#switchport backup int fa0/5
SWB(config-if)#exit

これらのコンフィグを投入すると、SWBのFa0/5が即座にオレンジ点灯となり、30秒から40秒ほどでSWAのFa0/1がグリーン点灯に変わりました(画像3)。

f:id:kokelabo:20190217172524j:plain
[画像3]SWBのFa0/5がバックアップポートとなりオレンジ点灯
これでループを回避しつつ、SWB-C間で障害が発生すると、バックアップルートだったSWA-B間が開放され、自動的に通信ができるようになります。
SWAのFa0/1のランプ状態が正常になったことからも分かるように、Flex Linkの設定をすると、当然ですがSTPの設定は無効となります。設定がこのままの状態ですと、障害が復旧しても、継続してSWA-B間で通信が行われます。リンクの切り戻しは行われません。例えば、平常時のSWB-C間では100Mbpsの速度で通信が行われる設定がなされていて、バックアップルートのSWA-B間は30Mbpsの速度だった場合、いつまでもSWA-B間のままではマズいですよね?というわけで、障害が復旧したら、ちゃんと通信がSWB-C間に戻るように設定しないといけません。Preemptの設定を投入しましょう。

SWB(config)#int fa0/1
SWB(config-if)#switchport backup int fa0/5 preemption mode forced
SWB(config-if)#switchport backup int fa0/5 preemption delay 30
SWB(config-if)#end

Preemptの設定は以上です。障害復旧時、30秒後に、再びSWB-C間の通信へと切り戻されるようになります。上記コンフィグ3行目の「delay」に続く数字が、切り戻しまでの秒数です。では、このFlex Linkの設定を確認できるShowコマンドを見てみましょう。

SWB#sh int switchport backup detail

Switch Backup Interface Pairs:

Active Interface        Backup Interface        State
------------------------------------------------------------------------
FastEthernet0/1         FastEthernet0/5         Active Up/Backup Standby
        Preemption Mode  : forced
        Preemption Delay : 30 seconds
        Multicast Fast Convergence  : Off
        Bandwidth : 100000 Kbit (Fa0/1), 100000 Kbit (Fa0/5)
        Mac Address Move Update Vlan : auto

間違いなく設定されています。本当に思った通りの動作をしてくれるのか、実際に検証してみましょう。SWCのFa0/1からケーブルを抜去します。すると、オレンジ点灯だったSWBのFa0/5が、グリーン点灯に変わりました(画像4)。また、先ほどのShowコマンドをもう一度見ると、Fa0/5のStateが「Backup Up」になっていることが分かります。

f:id:kokelabo:20190217184045j:plain
[画像4]SWBのFa0/5がグリーン点灯

SWB#sh int switchport backup detail

Switch Backup Interface Pairs:

Active Interface        Backup Interface        State
------------------------------------------------------------------------
FastEthernet0/1         FastEthernet0/5         Active Down/Backup Up
        Preemption Mode  : forced
        Preemption Delay : 30 seconds
        Multicast Fast Convergence  : Off
        Bandwidth : 100000 Kbit (Fa0/1), 100000 Kbit (Fa0/5)
        Mac Address Move Update Vlan : auto

アクティブリンクの切り替わりが確認できましたので、ケーブリングを元に戻すと、しっかりと30秒後にSWB-C間への切り戻しも行われました。動作検証は無事成功です。

まとめ

今回はFlex LinkというL2冗長化の技術を紹介させて頂きました。いかがだったでしょうか。設定は非常に簡単ですし、仕組みもかなりシンプルですよね。この設定の簡単さ、仕組みのシンプルさが、このFlex Linkのいちばん良いところかなぁと思っています。
Flex Linkは、一見、万能な技術のようにも見えますが、デメリットもあります。先述しました通り、Flex LinkはSTPとは異なり、該当機器だけで動作します。障害が発生しても、ポートのリンクさえアップしていれば、障害は検知しません。極端な話、監視拠点から「通信の速度が遅くなった」等といったヘルプの申告がなければ、ほぼほぼ障害に気付くことができません。これが、Flex Linkのウィークポイントです。なので、「一時的に速度が落ちたりしても良いから、なにがなんでも通信断の可能性だけは狭めたいんや!」といった場合に利用されることが多いです。また、要件定義・設計のフェーズでFlex Linkを導入するケースも、ほとんどないです。最初からループフリーな構成にしたり、EtherChannelを利用することで要件を満たせてしまいます。あくまでも、運用・保守のフェーズで使われることがあるという認識で良いでしょう。
以上で、Flex Linkの技術解説を終わります。ここまで長々とお付き合い頂きまして、ありがとうございました!

ガチ文系出身がNWの運用・保守業務を1年間やってみた

はじめまして。コケラと申します。

このたびは、私のチンケな研究所KokeLab(コケラボ)にお越し下さいまして、誠にありがとうございます。

 記念すべきブログ記事1本目ということで、少し緊張感もありますが、うだうだ色んなことを語りすぎても野暮なので、さっそく本題のほうへ移りましょう。 

ガチ文系出身です

 私の職業はITエンジニアです。もっと詳しくいうと、中~大規模の公共系NWの運用・保守業務を担当しているNWエンジニアです。あとはデータセンタのお守りもしています。昨年の2月から、NWエンジニアとして就業を開始しまして、もうすぐ1年が経とうとしています。

 「あぁなるほど。じゃあ、コケラさんは情報系の高専卒、あるいはコンピューターサイエンスやら何やらを大学で専攻された方なのかなぁ」と予想されたそこのあなた。

残念ながら不正解です。まぁ記事のタイトルとか見たら分かりますよね。

昔から本を読むのが好きで、あとは中学生のときから何故か英語が得意科目だったので、「文学部ええんちゃう?なんかよう分からへんけど英語の成績も良いし、英米文学専攻とか、自分に合ってるんとちゃう?」と安易といえば安易な考えで、高校生の頃に進路を決めた記憶があります。

 そして、努力の甲斐もあってか、無事に某大学の文学部(英米文学専攻)に進学することができました。やったね!ワイえらい!

そうです。私は文学部出身です。ガチ文系なのです。

ガチ文系でもITエンジニアになれるの?

結論から申しますとなれます情報工学とかそういうのを大学で学ばなくてもできます。業務未経験でも大丈夫です

「数学できないと厳しいんじゃないの?」みたいなイメージを持たれてる方は、少なからずいるかと思いますが、私はいまのところ「もっと数学勉強しておけば良かったなぁ、数学の知識がないとちょっとツライなぁ」と感じたことは、一度たりともありません。正直、+-×÷の四則演算さえできれば全く問題ないです。

 もちろん、少しばかりの例外はあります。例えば、開発系エンジニアになって「*1Python機械学習やらAIの開発をガッツリやりたいんや!」という方なら、高度な数学の知識が必要になってくるかと思います。

もしインフラ系エンジニアを目指されるのであれば、高度な数学の知識を要する場面にはまず出くわすことはないでしょう。私はまだNWの運用・保守の業務経験しかないですが、設計・構築であろうがサーバ側の業務であろうが、例えば微分だの線形代数だの、そんな知識を使うイメージは全く湧きませんし、聞いたこともありません。ネットでよく情報収集もしますが、そんな情報は一切ないです。

 「エンジニアになりたいけど文系だしなぁ。どうせ門前払いされるんだろうなぁ」と気後れする必要は全くありません。

 「たった1年しか経験してないのに何を偉そうにw」という批難は甘んじて受け入れます。ですが、いまや文系出身のエンジニアはたくさんいますし、高度な数学の知識も開発系エンジニアの一部の業務で使うことがある程度なのは事実なので、興味のある方は自信を持ってチャレンジするべきです。

NWの運用・保守ってどんな仕事?

 私はいま、良い現場に恵まれたこともあり、NWの運用・保守業務をかなり網羅的に経験させて頂いてます。具体的には、監視・障害対応ヘルプデスクシステム更改等に伴うNW機器への*2Config投入の手順書作成・機器へのConfig投入などです。では、それらの仕事が一体どういう内容なのか。詳しい中身を説明していきます。
  1. 監視・障害対応⇒監視しているNWで異常・障害を検知したら、状況に応じた対応をする業務です。そのまんまやん。先述しました通り、私の現場は公共系NWの運用・保守をしているので、ひとつ監視拠点の例として挙げると、例えば、とある公立高校に設置しているNW機器に何らかの異常が発生したとします。そのせいで、校務で使っているシステムが使えなくなったり、インターネットに繋がらなくなったりするわけです。そういったNW機器の異常を*3監視ツールが検知します。監視ツールが異常を検知したら、その公立高校に設置してあるNW機器に遠隔でログインして状態を調べたり、公立高校の担当者(教頭先生とかネットに詳しい先生とか)に電話で連絡をしてコミュニケーションをとり、いろいろな問診を行います。インターネット回線の異常だと*4通信事業者(キャリア)に連絡して確認したりもします。異常が起こり得る原因を一つずつ潰していって、被疑箇所を切り分けて特定していくわけです。いわゆるトラブルシューティングというやつですね。
  2. ヘルプデスク⇒上記の監視・障害対応と、ほとんど内容的には大差ありません。こちらから拠点に問い合わせるか、拠点から問い合わせがあったかどうかの違いです。ヘルプデスクは、拠点から問い合わせがあれば障害対応を行います。あまり詳しく説明し過ぎると、会社の秘匿情報の侵害に繋がったり、技術的に難しい話になってしまったりするので控えますが、監視ツールだけでは検知し得ないNW上の異常や障害等もあります。そういった場合、拠点からの問い合わせがないと異常や障害を知りようがないですよね。ヘルプデスクは基本的に、監視ツールの検知範囲外の事象に対応していきます。
  3. システム更改等(以下略)⇒運用・保守業務のなかでは、最も技術的な知識が必要な業務です。新設拠点ができる場合や、既存の拠点から「仕事で新しいシステムを使いたい」「あのシステムはもう使わないから廃止してほしい」などといった要望があった場合や、こちらから「セキュリティ上、このシステムを強靭化したほうが良い」と提案して、実際にシステムの強靭化を行ったりする場合があります。こういった時には、もちろんNW機器の設定を変更しないといけません。そのための手順書を作成し、パソコンとNW機器をケーブルで繋いだり、遠隔でログインしてConfigを投入していくというのが、このシステム更改等(以下略)という業務になります。もっと詳しく知りたい方は、*5CCNAという資格を勉強し、実際にNW機器を中古で購入してConfig投入をやってみるのが、いちばん手っ取り早いかと思います。
 他にも、新設拠点にNW機器を設置(ラッキング)しに行ったり、拠点のNW機器が物理的に故障したら、予備の機器にConfigを投入して取り替えに行ったりすることもあって、これもNWの運用・保守業務の一環です。
どういった仕事なのか、だいたい理解して頂けたでしょうか。現場によって業務内容の細かい部分は少し違うかもしれませんが、こういった仕事がNWの運用・保守業務となります。意外とコミュニケーション能力は必要な仕事なのです。一方で、奥深い理系知識とかは、全く必要ありません。この仕事に文系とか理系とかあんまり関係ないですよね?

インフラ系と開発系

 ITエンジニアは、大きく二つに分類することができます。将来どんなエンジニアになりたいのか、しっかりと決めておいたほうが良いです。本記事の趣旨からは少し離れますが、ITエンジニアに興味があって目指そうとされている方は、ある程度、把握しておいたほうが良い情報なので紹介させて頂きます。

  1. インフラ系エンジニア⇒インフラ系エンジニアは、開発系エンジニアが開発したアプリやソフトを動かせるようにして(デプロイ)、それらを動かす道路を整備するのが主な仕事です。もの凄くざっくりとした表現ですが、とりあえずそういう認識で良いです。NWエンジニア、サーバエンジニア、クラウドエンジニアを総称してインフラエンジニアと呼ばれています。「NWもサーバもクラウドも完全に理解した!」という人もインフラエンジニアと呼ばれています。将来そんなエンジニアに、私もなりたいですね。
  2. 開発系エンジニア⇒WEBエンジニア、フロントエンジニア、ゲームエンジニア。こういったエンジニアの方々は、開発系エンジニアと呼ばれています。いわゆるプログラマーです。WEBサイトを構築したり、ゲームを開発したりします。私はインフラ系で、開発系にはあまり詳しくないので、これ以上の言及は避けたいと思います。
こうして二つに分類されてはいますが、インフラ系エンジニアにプログラミングの知識は全く必要ないのか、開発系エンジニアにNWやサーバの知識は全く必要ないのかというと、そういうわけではありません。最近は、NW機器の制御やインフラの構築をプログラムに任せよう(*6IaC)という時代の潮流がありまして、インフラ系エンジニアにもプログラミングの知識が求められるようになってきました。開発系エンジニアも、少し極端な例えですが、自動運転車を開発するとして、道路には信号機があり、信号機が交通を整備しているということを知らないと、赤信号であろうが何だろうが、交差点をビュンビュン走ってしまうような自動運転車を開発してしまうことになります。とても危ないですよね。やはり、開発系エンジニアであっても、ある程度NWやサーバの知識にも精通しておいたほうが良いのです。
こういったことも、これからITエンジニアを目指すのであれば、念頭に置いておくべきでしょう。自身のITエンジニアとしてのキャリアパスを、より柔軟に考えられることにも繋がります。

ITエンジニアにとって大切なこと

 ITエンジニアとって大切なこととは何でしょう。NWの運用・保守業務を1年間やってみて感じたことは、やはり仕事に対するモチベーション保ち続けることが大切であるということです。これはITエンジニアに限らず、他のどんな仕事にも言えることですが、IT業界では特に、そういったモチベーション維持の重要性を犇々と感じています。

「好きこそ物の上手なれ」という言葉がありますが、好きじゃない人は好きな人には絶対に敵いません。技術的好奇心を持ち続けることは、ITエンジニアとして成長していく上では必要不可欠です。何か一つの技術に興味を持てば、そこから樹形図状に他の技術を習得することにも繋がっていきます。要するに、「Aという技術に興味を持ち、Aという技術を理解するためにBという技術を理解する必要が生じ、Bという技術を理解するためにCという技術を理解する必要が生じ(以下ループ)」と、学習の連鎖が発生するのです。技術的好奇心を持つことの重要性を理解して頂けたでしょうか?ITエンジニアは、こうして成長していくものなのではないでしょうか。

こうした学習の連鎖にずっと耐えていくには、技術が好きであること、つまり熱意・情熱はもちろん、モチベーションも維持していかなければなりません。モチベーションを維持するには、互いに切磋琢磨できるような仲間がいると良いかもしれません。残念ながら、いまの私の職場には周りにそのような方がいないので、SNSで私と同じような新米エンジニアの方々や、とてつもない技術力を持ったエンジニアの方々をフォローし、その方々から刺激を得ることでモチベーションを維持しています。SNSがあってよかったなぁ。なかったらダメエンジニアになってたかも。

おわりに

さて、そろそろ本記事も終わりにしたいと思います。ここまで長々とお付き合い頂きまして、本当にありがとうございました。長すぎましたスミマセン。私はまだまだ駆け出しエンジニアで、これからもITエンジニアに対する考え方がコロコロ変わっていく可能性は十分ありますが、「あぁ、あの頃の自分はこういう風に考えていたんだなぁ」と思い出せるような、備忘録的な役割を将来果たしてくれるかもしれません。

本記事の内容が、少しでも読者の皆様のお役に立てれば幸いです。

*1:プログラミング言語の一種。

*2:configurationの略で、要するに機器の設定のこと。

*3:Zabbixが最も有名です。トラフィックの状況を監視できるMRTGも覚えておいて損はないです。ちなみに、異常検知するまで監視モニターをずっと見つめているわけにもいかないので、監視ツールは一般的に「警子ちゃん」のような、異常を検知すると警告音で知らせてくれるような装置と接続させます。

*4:NTTなどのことです。

*5:NW機器で世界のトップシェアを占めるシスコシステムズ社さん主催の認定資格です。NWエンジニアにとっては登竜門的な資格で、NWエンジニアを目指されるのであれば、絶対に取得したほうが良いです。

*6:Infrastructure as Codeの略で、インフラ構築を自動化させるAnsibleというツールが特に有名です。