「2024-01-30 Cisco IOS IOS-XE コンフィグ作成まとめ」の版間の差分

提供：hkatou_Lab
ナビゲーションに移動 検索に移動
← 古い編集新しい編集 →
ビジュアルウィキテキスト
65行目: 65行目:


== 質問の仕方 ==
== 質問の仕方 ==
人の回答はアドバイスに過ぎませんが、'''機械の回答は「答えそのもの」'''を教えてくれます。
人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。


=== コンフィギュレーションガイドに聞く ===
=== コンフィギュレーションガイドに聞く ===
75行目: 78行目:
=== 機械に聞く ===
=== 機械に聞く ===
検証でコンフィグが投入できるか、動作が正しいか確認します。
検証でコンフィグが投入できるか、動作が正しいか確認します。
検証環境で投入が成功したコンフィグを、実機の投入コンフィグにします。
通常検証機であっても、人より精度が高いです。


=== 人に聞く ===
=== 人に聞く ===

2023年10月6日 (金) 07:37時点における版

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

目的

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

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

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

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

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

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

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

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

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

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

作成ポリシー

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

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

実機に入力して、適用されたコンフィグを show running-config で表示させ、コピペで投入コンフィグとして使用するのが一番良いです。

  • 投入順はアレンジが必要 or したほうが良いケースがあります

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

  • 投入コンフィグ = 設定後のコンフィグとなり、レビューしやすい
    • 変更元のコンフィグを参照したり、投入時の挙動を確認する必要がありません
  • 例) ポートの設定は 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 も削除することができます。

Junos らしい挙動で、IOS には珍しいパターンです。

コンフィグ削除の特殊例 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 などで使っている (普通は拡張 ACL なのでまず無いですが・・・) 場合、障害になる可能性大です。

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 を指定するところで差し替える
  • 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 の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。

コピー & ペースト

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

リプレース元のコンフィグからコピペ

  • OS が同じなら良いですが、特に別メーカーだと使えません

新規機器のデフォルト コンフィグからコピペ

実機・仮想環境で投入した結果のコンフィグからコピペ

コンフィギュレーション ガイドのコンフィグからコピペ

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

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

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

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

ツール

テキストエディタ

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

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

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

最近は Cisco IOS 用のシンタックス ハイライトが手軽にインストールできる、Visual Studio Code が良さそうです。

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

同じ Catalyst であっても、シリーズが違えば基本的にコンフィグは流用できません。

Catalyst 9000 シリーズでは UADP シリーズなど、ASIC のタイプが一緒ならかなり流用が効きます。

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

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

IOS 共通のコード

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

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

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

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

IOS と NX-OS

ハードウェアはもちろんルーティング プロトコルも実装が異なるため、別物として扱ったほうがよいです。

比較チェック

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 が異なっていること

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

L2SW の場合、理想的には jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させると良いです。

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” にヒットせず、表示されません

リファレンス

賢い質問のしかた

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

「http://hkatou.net/index.php?title=2024-01-30_Cisco_IOS_IOS-XE_コンフィグ作成まとめ&oldid=1484」から取得