2024-01-30 Cisco IOS IOS-XE コンフィグ作成まとめ

筆者が主に Cisco IOS / IOS-XE でコンフィグ作成しているときに、気をつけていることをまとめました。

目的

機器のコンフィグを作成できるようにする。

切り替え用コンフィグのリスクを、評価できるようにする。

• ネットワークを安全に切り替えできる

コンフィグのクオリティを、高められるようにする。

• 他人のコンフィグをレビューできる

NIer におけるコンフィギュレーション

重要な成果物の一つです。

提案 -> 設計 -> 検証 -> 構築 -> 切替のフェーズで、主に設計から作成されます。

各フェーズごとに改善されていったコンフィグは、非常にコストの掛かったものになることも多いです。

速く・安く・確実なコンフィグを作成できるようにします。

作成ポリシー

メーカーのコンフィギュレーション ガイドに従ってコンフィグしましょう。

基本はコピー & ペーストで作成し、手打ちは極力使用しないようにします。

投入コンフィグは、変更元に依存しない内容で作成

• 投入コンフィグ = 設定後のコンフィグとなり、レビューしやすい
  • 変更元のコンフィグを参照したり、投入時の挙動を確認する必要がありません
• 例) ポートの設定は default で初期化してから、変更後のコンフィグを投入する

実機や仮想環境で挙動を確認

考えたとおりには動かない、設定したとおりに動きます。

置換は慎重に、でも多用

初心者のうちは、実機・仮想環境の検証で確認・作成します。

• コンフィグを投入することによる機器の動作を知らない

• わかっていないことがわかっていない

• 何が正しいコンフィグか判断できない = 異常があっても気づけない

1 文の間違いで多大な影響が出る部分は、複数の確認手段で品質を高める

• ACL / プレフィックス長など
  • /16 を /17 に間違えた場合、何人のユーザに影響が発生しますか ?

• 差分確認を 1/0/x と 2/0/x で取るなど

相談相手は 3 つしかありません 以下の順で相談すると信頼性が高いコンフィグに

• ドキュメント (特にコンフィギュレーションガイド)
• 実機・仮想環境
• 人

確認は機械自身にさせましょう

「うまく動作する」とエンジニアが主張するのは無意味、機械自身に検証結果で証明させましょう。

質問の仕方

コンフィギュレーションガイドに聞く

理解できなくてもよいですが、一通り読みましょう。

何が書いてあるのか概要を記憶しておき、検証時などに思い出せるようにします。

最初からコンフィギュレーション ガイドを読むのはつらいため、InfraExpert などのサイトで大まかな内容を掴むと良いです。

機械に聞く

検証でコンフィグが投入できるか、動作が正しいか確認します。

人に聞く

相手がコンフィグを確認してくれても、基本的に責任は取ってくれません。

自分が調査したこと・検証結果・見解を元に質問しましょう。

他人へ説明することで、自分の考えが整理され、間違いや改善点を発見できます。

検証の仕方

テスト項目を書きましょう

設定した機能が、設計したとおりに動作するかテストします。

エビデンスを取得しましょう

作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。

コンフィグ投入

投入するコマンドは、追加になりますか ? 削除になりますか ? 変更になりますか ?

追加

意図した箇所に追加されるか。

既存の設定を書き換え (変更され) ないか。

削除

意図した行・オプションが削除されるか。

変更

変更時にトラフィックへ影響がないか。

コンフィグ変更の例

昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのがおすすめです。

バッドプラクティス

[変更前]
interface GigabitEthernet0/1
 switchport access vlan 100
 switchport mode access

[投入コンフィグ]
interface GigabitEthernet0/1
 switchport trunk allowed vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk

[結果]
interface GigabitEthernet0/1
 switchport access vlan 100 <<< ゴミが残ってしまう
 switchport trunk allowed vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk

ベストプラクティス

[変更前]
interface GigabitEthernet0/1
 switchport access vlan 100
 switchport mode access

[投入コンフィグ]
default interface GigabitEthernet0/1 <<< 初期化
interface GigabitEthernet0/1
 switchport <<< デフォルトが no switchport だった場合のために、明示的に switchport へ変更
 switchport trunk allowed vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown <<< デフォルト shutdown を明示的に no shutdown で有効化 

[結果]
interface GigabitEthernet0/1
 switchport trunk allowed vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk

コンフィグ削除

Q : 「no を行の先頭につけて、その行を削除するだけでしょ ?」

A : いいえ、Cisco のコンフィグ削除は、特殊な削除が行われるケースがあります。

コンフィグ削除の特殊例 1)

削除例 1

[変更前]
router ospf 1
 redistribute static metric-type 1 subnets

[投入コンフィグ]
router ospf 1
 no redistribute static metric-type 1 subnets

[結果]
router ospf 1
 redistribute static subnets <<< metric-type 1 のみ削除された

Junos に似た削除になるパターンで、オプションのみを削除する、という挙動になる場合があります。

おそらく metric-type のみ削除したい、という要望に答えた結果と思われます。

削除例 2

[変更前]
router ospf 1
 redistribute static metric-type 1 subnets

[投入コンフィグ]
router ospf 1
 no redistribute static

[結果]
router ospf 1
 <<< redistribute 全体が削除された

途中までを指定して no とすることで、redistribute static も削除することができます。

コンフィグ削除の特殊例 2)

削除例 1

[変更前]
access-list 1 permit 1.1.1.1
access-list 1 permit 2.2.2.2

[投入コンフィグ]
no access-list 1 permit 2.2.2.2


[結果]
<なし>

PACL , RACL などで使っている場合、障害になる可能性大です。

Standard Access-list (1-99) は行単位で削除できないため、コンソール経由の設定変更や新規番号に入れ替えて設定変更を行います。

削除例 2

[変更前]
access-list 1 permit 1.1.1.1
access-list 1 permit 2.2.2.2

[投入コンフィグ]
show ip access-lists 1
Standard IP access list 1
    10 permit 1.1.1.1
    20 permit 2.2.2.2
no access-list 2 ? <<< ? コマンドでシーケンス番号がないことに気づく
 <cr>

[結果]
access-list 1 permit 1.1.1.1
access-list 1 permit 2.2.2.2

削除を慎重に確認した例です。この場合は新しい ACL を作成し、ACL を指定するところで差し替えるのが良いです。

show running-config に現れない設定

show running-config を同じにすれば基本的に同じ動作になるのが Cisco の良いところですが、show running-config に出てこない設定が存在します。

保守交換、コンフィグ流用時などには、よく確認する必要があります。

キャパシティ変更系・Stack 系・VSS 系のコマンドは、ROMMON に書き込まれるため、show running-config に出てこない場合が多いです。

Catalyst 2k / 3k

SDM テンプレート : sdm prefer <template>

• show sdm prefer で確認

スイッチ番号 : switch <1-9> renumber

• show switch で確認

Catalyst 6500 (-Sup720 まで)

mls cef 最大ルート数 : mls cef maximum-routes ip <数>

• show mls cef maximum-routes で確認

Stack / VSS

スイッチ番号は ROMMON の環境変数に書き込まれます。

VSS は VSL のポート番号が ROMMON に書き込まれており、起動時に接続した Active 機へコンフィグを読み込みに行きます。

ルータ & スイッチ

HSEC など PAK 系ライセンスのインストール

SSH 接続用 RSA キー : crypto key generate rsa

• show crypto key <key_name> rsa で確認
• 実際に SSH 接続できるか、確認したほうが良い

有効にするために reload が必要な設定

設定時に reload の有無の確認 (投入したいコマンドに reload が必須だった) は重要です。

コンフィギュレーション ガイドをよく確認する必要があります。

Catalyst 2k / 3k

SDM テンプレート : sdm prefer <template>

• show sdm prefer で確認

スイッチ番号 : switch <1-9> renumber

• show switch で確認

Catalyst 4500

アップリンクのモード変更 : hw-module uplink mode

Catalyst 6500 (-Sup720 まで)

mls cef 最大ルート数 : mls cef maximum-routes ip <数>

• show mls cef maximum-routes で確認

参考 : 設定に再起動が必要なコンフィグまとめ

作成手段

導入する実機がある場合は、その実機で作成するのが最も品質が良いです。

基本的に実機が納入される前に程度作成できたほうが良いため、色々な手段を用いて事前に作成します。

検証で作成

実機で実際にコンフィグを投入して作成。

仮想環境でコンフィグを投入して作成。

机上で作成

ドキュメントで確認。

• コンフィギュレーションガイド
• コマンドリファレンス
• リリースノート

Google で検索して見つかったコンフィグを、そのまま流用しないこと。

• 障害になった時に、お客様へ説明できません
• 機器のマニュアルくらい見ろよ・・・と思われてしまう

• 「Google で調べた情報を設定しました」 -> 設定した人の責任になり、めちゃめちゃ怒られます
• 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合の責任

Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。

コピー & ペースト

基本的にコピー & ペーストで作成します。

作業品質が低いエンジニア

show run と投入コンフィグで差分が多く出るコンフィグを作成する人には、気をつけたほうが良いでしょう。

• 大文字と小文字が異なる、スペースの数が不適切
  • interface gigabitethernet 1/0/1 << interface GigabitEthernet1/0/1 が正しい
• インデントされたスペースの数が異なる
  • Winmerge で差分を取ったときに差が大量に出てしまう
• show run と投入順番が異なる
  • ACL 定義後に PACL を設定するなど、あえてやる場合もあります
• 投入コンフィグと投入後の show run に改善できる差分がある

1 回のレビューで 3 回以上必要ない差分が出るような人は、作業が雑だな、と筆者は判断します。

ツール

テキストエディタ

最低限、以下の機能を持つエディタを使用します。

• 検索キーワードを色つけできる、シンタックスハイライト機能
• 検索した文字を書き換えられる、置換機能
• 記録した動作を繰り返し実施できる、マクロ機能

筆者は MKEditor を使用しています。(マクロ機能は使っていません)

Winmerge

テキストを比較し、差分がある場合は色がつけられてチェックできます。

行の途中でどの部分に差分があるか、行中チェックができますが、文字単位で表示してくれる差分比較ソフトは少ないです。

STP Simulator

STP の挙動をアニメーションで確認できます。

Java なので、最近はインストールしづらいですね。

置換と正規表現

コンフィグ作成は通常テキストエディタで行いますが、置換する際に知っておくべきトピックが、正規表現です。

簡単な正規表現の例

行末のスペースを削除したい :

• “ $” (スペースとドルマーク) で検索 -> “ \n” の場合も
• “” (何もなし) に置換

Stack 1 号機のポートを 2 号機に変換したい :

• “interface GigabitEthernet1/0/” で検索
• “interface GigabitEthernet2/0/” に置換

show interfaces status をログファイルから検索したい :

• show int.*status で検索
  • interfaces って打つのがめんどい
• 例) show run | s int.*Gi.*1/0/4

デフォルト コンフィグの動作の違い

ルータ

インターフェースはシャットダウンされています。

スイッチ

Catalyst 2k / 3k / 4k :

スイッチポートで Vlan1 が割り当てられています。

インターフェースは有効になっています。

Catalyst 6k :

ルーテッドポートで Vlan は割り当てられていません。

インターフェースはシャットダウンされています。

• 投入コンフィグを作成する場合、no shutdown が必要

投入コンフィグは、デフォルトコンフィグを考慮して作成します

デフォルト コンフィグが何であろうと、同じ結果が得られる投入コンフィグが良いです。

show running-config で表示されないデフォルトコンフィグは、show running-config all で表示可能です。

ただし all でも表示されないコンフィグは存在します。

プラットフォーム依存・非依存

コンフィグは大きくわけて 2 種類の違いがあります。

機種 (プラットフォーム) によってコンフィグの書き方が異なるコンフィグ

主にハードウェアに依存する機能。

機種が変わっても書き方が一緒のコンフィグ

主にソフトウェアに依存する機能。

プラットフォーム依存の例

基本的には ASIC などハードウェアに依存する機能が該当します。

• Stack / VSS
• QoS (Router・Cat4k/3k(IOS-XE) : MQC / Cat2k  : MLS QoS)
• インターフェース ID

プラットフォーム非依存の例

• ソフトウェアで実装される機能が主に該当します。
• ルーティング プロトコル (RIP / OSPF / BGP)
• 管理系 (syslog / SNMP / NTP)

IOS 共通のコード

プラットフォーム非依存のプロトコルは、Cisco IOS の場合、共通のコードを使用しており、挙動も同じになる場合が多いです。

共通のコードからマージするタイミングによるため、一緒にならない場合もあります。

ルーティングプロトコルの場合、スイッチよりもルータのほうが高機能なケースが多いです。

• 例) Catalyst 9500 スイッチは BGP PIC-Edge に対応しません

比較チェック

Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。

医者で言う症例カンファレンスですね。

拠点 1 と 2 ののコンフィグを比較

拠点 1
interface Vlan1
 description kanri
 ip address 192.168.0.181 255.255.255.0

拠点 2
interface Vlan1
 description kanri
 ip address 192.168.0.182 255.255.255.0 <<< IP が異なっていること

机上作成時のクオリティをアップさせます。

Stack / VSS で 1 号機と 2 号機のポートを比較

差分が出ないのが正解なのか、差分が出るのが正解なのか、判断できなければなりません。

VSS 1 号機

VSS 1 号機
interface TenGigabitEthernet1/1/1
 description L2SW_1_Te1/1/15
 switchport private-vlan trunk allowed vlan 20
 switchport private-vlan association trunk 499 399
 switchport private-vlan association trunk 400 300
 switchport mode private-vlan trunk
 switchport nonegotiate
 storm-control broadcast level 10.00
 storm-control action trap
 channel-group 1 mode desirable non-silent

 service-policy output PMAP_QoS
 no shutdown
!
interface TenGigabitEthernet1/1/2
 description L2SW_13_Te1/1/16_Reserved
 shutdown
!

VSS 2 号機

VSS 2 号機
interface TenGigabitEthernet2/1/1 <<< シャーシ番号
 description L2SW_1_Te2/1/15  <<< 対向ポート番号
 switchport private-vlan trunk allowed vlan 20
 switchport private-vlan association trunk 499 399
 switchport private-vlan association trunk 400 300
 switchport mode private-vlan trunk
 switchport nonegotiate
 storm-control broadcast level 10.00
 storm-control action trap
 channel-group 2 mode desirable non-silent <<< Channel ID 間違い
 service-policy output PMAP_QoS
 no shutdown
!
interface TenGigabitEthernet2/1/2
 description L2SW_13_Te2/1/16_Reserved
   <<< 2 号機で shutdown 忘れ
!

上記の例では Port-Channel 番号は同一なのが正しく、description は異なるのが正しいです。

文字列のバッドプラクティス

設定で任意に定義できる名前で “-” と “_” を間違えてしまう

ip access-list extended <名前> など

設計書でルール化して、どちらか片方しか使わなくするなどの対応を取ります

show run | in <name> で、名前が正しく定義・適用されているか確認します

良い例

show run | i PRIVATE_IP|line vty

ip access-list standard PRIVATE_IP

snmp-server community public RO PRIVATE_IP

line vty 0 4

access-class PRIVATE_IP in

line vty 5 15

access-class PRIVATE_IP in

上記の例では、PRIVATE_IP をキーワードとして IOS に show run を検索させます

ACL に PRIVATE_IP の名前が定義されていること

SNMP の ACL に PRIVATE_IP が適用されていること

telnet の ACL に PRIVATE_IP が適用されていること

PRIVATE-IP (ハイフン) を使用していた場合、” | in” にヒットせず、表示されません

リファレンス

賢い質問のしかた

技術系メーリングリストで質問するときのパターン・ランゲージ