1,986
回編集
差分
ナビゲーションに移動
検索に移動
38行目:
38行目: + + + + 44行目:
48行目: − + 55行目:
59行目: − + + + + 65行目:
72行目: − + + + 82行目:
91行目: + + 97行目:
108行目: + + + + + + + + + − 投入するコマンドは、追加になりますか ? 削除になりますか ? 変更になりますか ?+ 113行目:
133行目: − + + + 216行目:
238行目: − + 268行目:
290行目: − + 293行目:
315行目: − + 320行目:
342行目: − + 326行目:
348行目: + + + + 343行目:
369行目: − − 参考 : [[設定に再起動が必要なコンフィグまとめ]] 362行目:
386行目: − − Google で検索したり、他の案件して見つかったコンフィグを、'''内容がわからないまま流用しない'''こと。 − − * 障害になった時に、お客様へ説明できません − * 機器のマニュアルくらい見ろよ・・・と思われてしまう − − * 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます − * 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合の責任 − − Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。 379行目:
393行目: + + + + + + 388行目:
408行目: − + − + 395行目:
415行目: + − + 402行目:
423行目: + + + + + + + + + + + 412行目:
444行目: − + 424行目:
456行目: − + 449行目:
481行目: − インターフェースはシャットダウンされています。+ − + + + + + + + 464行目:
502行目: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 500行目:
573行目: − 共通のコードからマージするタイミングによるため、一緒にならない場合もあります。+ − + + + 512行目:
587行目: − 医者で言う症例カンファレンスですね。+ 529行目:
604行目: − + 579行目:
654行目: − 同一が正しいのか、異なるのが正しいのか、判断できるようになりましょう。+ − + − + 650行目:
725行目: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 656行目:
780行目: − 設計書でルール化して、どちらか片方しか使わなくするなどの対応を取ります+ 688行目:
812行目: + +
→実機や仮想環境で挙動を確認
=== 実機や仮想環境で挙動を確認 ===
=== 実機や仮想環境で挙動を確認 ===
考えたとおりには動きません。設定したとおりに動きます。
考えたとおりには動きません。設定したとおりに動きます。
設定差分確認は、動作を確認したことになりません。
Cisco であれば show コマンドで設定した機能が動作しているか確認します。
=== 置換は慎重に、でも多用 ===
=== 置換は慎重に、でも多用 ===
* コンフィグを投入することによる機器の動作を知らない
* コンフィグを投入することによる機器の動作を知らない
* わかっていないことがわかっていない
* '''わかっていないことがわかっていない'''
* 何が正しいコンフィグか判断できない = 異常があっても気づけない
* 何が正しいコンフィグか判断できない = 異常があっても気づけない
* 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど
* 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど
=== 相談相手は 3 つしかありません 以下の順で相談すると信頼性が高いコンフィグに ===
=== 相談相手は 3 つしかありません 以下の順で相談すると信頼性が高いコンフィグにできます ===
* ドキュメント ('''特にコンフィギュレーションガイド''')
* ドキュメント ('''特にコンフィギュレーションガイド''')
* 実機・仮想環境
* 実機・仮想環境
* 人
* 人
要件次第ですが、コンフィグは厳密に作成できるものです。
人の曖昧な回答よりも、実機で動くか確認したほうが良いケースが多いです。
=== 確認は機械自身にさせましょう ===
=== 確認は機械自身にさせましょう ===
== 質問の仕方 ==
== 質問の仕方 ==
人の回答はアドバイスに過ぎませんが、'''機械の回答は「答えそのもの」'''を教えてくれます。
人の回答はアドバイスに過ぎませんが、'''機械の回答 (設定投入や試験) は「答えそのもの」'''を教えてくれます。
人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。
人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。
* 刺激的な言い方をすると、「機械でカンニングし放題」
=== コンフィギュレーションガイドに聞く ===
=== コンフィギュレーションガイドに聞く ===
通常検証機であっても、人より精度が高いです。
通常検証機であっても、人より精度が高いです。
機械は検証の仕方などは教えてくれないため、自分が何がわかっていないか把握すると良いでしょう。
=== 人に聞く ===
=== 人に聞く ===
=== エビデンスを取得しましょう ===
=== エビデンスを取得しましょう ===
作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。
作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。
=== テスト駆動コンフィグ ===
テストを実施しながら設定変更しましょう。
例えば、新規 IP を設定する前から新しい IP 宛に ping を repeat で打ちっぱなしにして、設定変更後に疎通が取れるか確認します。
新規 IP を設定したけどルーティング設定を追加し忘れたときなど、足りない設定が無いかどうか、リアルタイムに確認できます。
* ソフトウェア開発の方式として、テスト駆動開発という手法があるため、これを真似たものです
== コンフィグ投入 ==
== コンフィグ投入 ==
投入するコンフィグは、追加になりますか ? 削除になりますか ? 変更になりますか ?
=== 追加 ===
=== 追加 ===
== コンフィグ変更の例 ==
== コンフィグ変更の例 ==
昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのがおすすめです。
昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのを推奨します。
既存のコンフィグを把握していないと、正しいかどうかわからない投入コンフィグは、レビュー時のコストがかなり高くなってしまいます。
=== バッドプラクティス ===
=== バッドプラクティス ===
</syntaxhighlight>'''PACL , RACL などで使っている場合、障害になる可能性大'''です。
</syntaxhighlight>'''PACL , RACL などで使っている場合、障害になる可能性大'''です。
'''通常 Access-list は行単位で削除できない'''ため、コンソール経由の設定変更や新規番号に入れ替えて設定変更を行います。
'''通常 Access-list は行単位で削除できない'''ため、コンソール経由の設定変更や新規 ACL に入れ替えて設定変更を行います。
=== 削除例 2 ===
=== 削除例 2 ===
access-list 100 permit ip host 10.0.0.1 host 192.168.0.1
access-list 100 permit ip host 10.0.0.1 host 192.168.0.1
access-list 100 permit ip host 10.0.0.3 host 192.168.0.3
access-list 100 permit ip host 10.0.0.3 host 192.168.0.3
- .2 が正常に削除された
- .2 のエントリが正常に削除された
保守交換、コンフィグ流用時などには、よく確認する必要があります。
保守交換、コンフィグ流用時などには、よく確認する必要があります。
キャパシティ変更系・Stack 系・VSS 系のコマンドは、ROMMON に書き込まれるため、show running-config に出てこない場合が多いです。
TCAM キャパシティ変更系・Stack 系・VSS 系のコマンドは、ROMMON に書き込まれるため、show running-config に出てこない場合が多いです。
=== Catalyst 2k / 3k ===
=== Catalyst 2k / 3k ===
* show crypto key <key_name> rsa で確認
* show crypto key <key_name> rsa で確認
* 実際に SSH 接続できるか、確認したほうが良い
* show running-config に出ないため、実際に SSH 接続できるか、確認したほうが良い
== 有効にするために reload が必要な設定 ==
== 有効にするために reload が必要な設定 ==
コンフィギュレーション ガイドをよく確認する必要があります。
コンフィギュレーション ガイドをよく確認する必要があります。
別途ページにまとめていますので、参照してみてください。
* 参考 : [[設定に再起動が必要なコンフィグまとめ]]
=== Catalyst 2k / 3k ===
=== Catalyst 2k / 3k ===
* show mls cef maximum-routes で確認
* show mls cef maximum-routes で確認
== 作成手段 ==
== 作成手段 ==
* コマンドリファレンス
* コマンドリファレンス
* リリースノート
* リリースノート
== コピー & ペースト ==
== コピー & ペースト ==
* OS が同じなら良いですが、特に別メーカーだと使えません
* OS が同じなら良いですが、特に別メーカーだと使えません
* 実装変更される機能は、投入できません
** 例) NetFlow -> Flexible NetFlow
=== 新規機器のデフォルト コンフィグからコピペ ===
=== 新規機器のデフォルト コンフィグからコピペ ===
* ポート番号などを把握するのに、デフォルト コンフィグが便利です
=== 実機・仮想環境で投入した結果のコンフィグからコピペ ===
=== 実機・仮想環境で投入した結果のコンフィグからコピペ ===
* かなり精度の高いやり方です
=== コンフィギュレーション ガイドのコンフィグからコピペ ===
=== コンフィギュレーション ガイドのコンフィグからコピペ ===
== バッドプラクティス例 ==
== バッドプラクティス例 ==
=== 作業品質が低いエンジニアの例 ===
=== 作業品質が低いコンフィグの例 ===
レビュアーとして他人のコンフィグをレビューする場合、show running-config と投入コンフィグで差分が多く出るコンフィグを作成する人には、気をつけたほうが良いでしょう。
レビュアーとして他人のコンフィグをレビューする場合、show running-config と投入コンフィグで差分が多く出るコンフィグには、気をつけたほうが良いでしょう。
* 大文字と小文字が異なる、スペースの数が不適切
* 大文字と小文字が異なる、スペースの数が不適切
*** 誤 : Gigabit , Ethernet の頭が小文字になっている
*** 誤 : Gigabit , Ethernet の頭が小文字になっている
*** 誤 : net と 1/ の間にスペースがある
*** 誤 : net と 1/ の間にスペースがある
** 手打ちしている可能性大
* インデントされたスペースの数が異なる
* インデントされたスペースの数が異なる
** Winmerge で差分を取ったときに差が大量に出てしまう
** Winmerge で差分を取ったときに差分が大量に出てしまう
* show running-config と投入順番が異なる
* show running-config と投入順番が異なる
** ACL 定義後に PACL を設定するなど、あえてやる場合もあります
** ACL 定義後に PACL を設定するなど、あえてやる場合もあります
1 回のレビューで 5 回以上必要ない差分が出るような人は、'''作業が雑だな'''、と筆者は判断します。
1 回のレビューで 5 回以上必要ない差分が出るような人は、'''作業が雑だな'''、と筆者は判断します。
=== 悪いコピペ ===
Google で検索したり、他の案件して見つかったコンフィグを、'''内容がわからないまま流用してしまう'''。
* 障害になった時に、お客様へ説明できません / 障害を修正できません
* 機器のマニュアルくらい見ろよ・・・と思われてしまう
* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任 or 検証していない NIer の責任
Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。
== ツール ==
== ツール ==
* 記録した動作を繰り返し実施できる、'''マクロ'''機能
* 記録した動作を繰り返し実施できる、'''マクロ'''機能
筆者は MKEditor を使用しています。(マクロ機能は使っていません)
筆者は MKEditor を使用しています。マクロ機能は使っていません。
最近は Cisco IOS 用のシンタックス ハイライトが手軽にインストールできる、Visual Studio Code が良さそうです。
最近は Cisco IOS 用のシンタックス ハイライトが手軽にインストールできる、Visual Studio Code が良さそうです。
STP の挙動をアニメーションで確認できます。
STP の挙動をアニメーションで確認できます。
Java なので、最近はインストールしづらいですね。
Java なので、最近はインストールしづらいです。
== 置換と正規表現 ==
== 置換と正規表現 ==
=== ルータ ===
=== ルータ ===
インターフェースはデフォルトでシャットダウンされています。
=== スイッチ ===
=== スイッチ ===
==== Catalyst 2k / 3k / 4k : ====
==== Catalyst 2k / 3k / 4k / 9200 / 9300 <ref>Interface and Hardware Components Configuration Guide, Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches)
[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-6/configuration_guide/int_hw/b_176_int_and_hw_9300_cg/configuring_interface_characteristics.html#concept_hhl_zbr_b1b Default Ethernet Interface Configuration]
Port enable state
All ports are enabled.</ref> : ====
スイッチポートで Vlan1 が割り当てられています。
スイッチポートで Vlan1 が割り当てられています。
* 投入コンフィグを作成する場合、no shutdown が必要
* 投入コンフィグを作成する場合、no shutdown が必要
==== Catalyst 9500 <ref name=":0">Interface and Hardware Components Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9500 Switches)
[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-9/configuration_guide/int_hw/b_169_int_and_hw_9500_cg/configuring_interface_characteristics.html#concept_hhl_zbr_b1b Default Ethernet Interface Configuration]
'''Operating mode'''
Layer 3 or routed port for C9500-32C, C9500-32QC, C9500-48Y4C, and C9500-24Y4C models of the Cisco Catalyst 9500 Series Switches
'''Port enable state'''
All ports are enabled.</ref> : ====
スイッチポートで Vlan1 が割り当てられています。
インターフェースは有効になっています。
==== Catalyst 9500 ハイパフォーマンス -16.11 以前 <ref name=":0" /> : ====
ルーテッドポートで Vlan は割り当てられていません。
インターフェースは有効になっています。
==== Catalyst 9500 ハイパフォーマンス 16.11.1 以降 <ref>Release Notes for Cisco Catalyst 9500 Series Switches, Cisco IOS XE Gibraltar 16.11.x
[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-11/release_notes/ol-16-11-9500.html#task_wfn_vrl_ghb Changing the Default Interface and Upgrading or Downgrading in Install Mode (for Cisco Catalyst 9500 Series Switches - High Performance Only)]
'''Purpose'''
Starting in Cisco IOS XE Gibraltar 16.11.1, the above mentioned devices will bootup with interfaces in the default Layer 2 state. In all earlier releases, the default is Layer 3.
'''Reason for this Change'''
The default interface is changed to Layer 2, to enable day 0 discovery when using Cisco Digital Network Architecture (DNA) Center (or Cisco DNA Center).</ref> : ====
スイッチポートで Vlan1 が割り当てられています。
インターフェースは有効になっています。
=== 投入コンフィグは、デフォルト コンフィグを考慮して作成します ===
=== 投入コンフィグは、デフォルト コンフィグを考慮して作成します ===
プラットフォーム非依存のプロトコルは、Cisco IOS の場合、共通のコードを使用しており、挙動も同じになる場合が多いです。
プラットフォーム非依存のプロトコルは、Cisco IOS の場合、共通のコードを使用しており、挙動も同じになる場合が多いです。
共通のコードから機種ごとのコードへマージするタイミングによるため、一緒にならない場合もあります。
ルーティングプロトコルの場合、スイッチよりもルータのほうが高機能なケースが多いです。
ルーティングプロトコルの場合、スイッチよりもルータのほうが高機能なケースが多いです。
* 例) Catalyst 9500 スイッチは BGP PIC-Edge に対応しません
* 例) Catalyst 9500 スイッチは BGP PIC-Edge に対応しません <ref>[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-11/release_notes/ol-16-11-9500.html#concept_gyh_m21_mgb__unsupp-1611x-9500 Unsupported Features—Cisco Catalyst 9500 Series Switches]
Border Gateway Protocol (BGP) Additional Paths</ref>
=== IOS と NX-OS ===
=== IOS と NX-OS ===
Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。
Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。
医療で言う症例カンファレンスに該当します。
=== 実績のある、類似案件のコンフィグと比較 ===
=== 実績のある、類似案件のコンフィグと比較 ===
</syntaxhighlight>机上作成時のクオリティをアップさせます。
</syntaxhighlight>机上作成時のクオリティをアップさせます。
L2SW のコンフィグを多数作成する場合、理想的には jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させると良いです。
L2SW のコンフィグを多数作成する場合、jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させる、などの方法を用いると生成もレビューも楽をできて良いです。
=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
</syntaxhighlight>上記の例では Port-Channel 番号は同一なのが正しく、description は異なるのが正しいです。
</syntaxhighlight>上記の例では Port-Channel 番号は同一なのが正しく、description は異なるのが正しいです。
同一が正しいのか、異なるのが正しいのか、気付ける + 判断できるようになりましょう。
== インターフェース コンフィグの TIPS ==
== インターフェース コンフィグの TIPS ==
=== Catalyst 2k / 3k は、provision コマンドでインターフェース コンフィグを作成できます ===
=== Catalyst 2k / 3k は、provision コマンドでインターフェース コンフィグを作成できます ===
Catalyst 2k / 3k の場合は、provision コマンドを使用することで、指定する SKU のインターフェース コンフィグを事前投入することができます。
Catalyst 2k / 3k の場合は、provision コマンドを使用することで、指定する SKU (=型式) のインターフェース コンフィグを事前投入することができます。
ラボの機器で provision して投入コンフィグを作成、実機が届いたら投入することで、事前に実機で答え合わせした上で、投入コンフィグを作成できます。
ラボの機器で provision して投入コンフィグを作成、実機が届いたら投入することで、事前に実機で答え合わせした上で、投入コンフィグを作成できます。
例えば Catalyst 3850 は以下の SKU のコンフィグを作成可能です。<syntaxhighlight lang="diff">
例えば Catalyst 3850 + IOS-XE 16.12.x は以下の SKU のコンフィグを作成可能です。<syntaxhighlight lang="diff">
switch(config)#switch 3 pro
switch(config)#switch 3 pro
switch(config)#switch 3 provision ?
switch(config)#switch 3 provision ?
</syntaxhighlight>アップリンク モジュールのポート番号も、搭載しなくても show running-config に表示されます。
</syntaxhighlight>アップリンク モジュールのポート番号も、搭載しなくても show running-config に表示されます。
== スタティック ルーティングのベスト プラクティス ==
=== name オプション ===
スタティックルートには、name オプションを付けましょう。筆者は宛先の機器名を付与しています。
メリットとしては変更や削除をしやすくなる点が挙げられます。影響を受ける機器がコンフィグから読み取れるためです。
==== name オプション例 ====
<syntaxhighlight lang="diff">
ip route 10.0.0.1 255.255.255.255 172.16.0.1 name L3SW_Lo0
</syntaxhighlight>対向側の L3SW の Lo0 が変更や削除になった場合、このルートを持つ機器でも変更しなければならないことがわかります。
=== next-hop と送信元インターフェース名指定 ===
next-hop と送信元インターフェースを元に、送信元インターフェースが決定されます。
両方設定するのが一番良いですが、インターフェースの指定は面倒なため、next-hop のみ設定する事例が多いです。
next-hop のみ指定する場合、再帰検索で next-hop を解決しようとしないか、把握しなければなりません。(後述のバッドプラクティスを参照)
== スタティック ルーティングのバッド プラクティス ==
=== 送信元インターフェース名のみを指定 ===
next-hop と送信元インターフェースを元に、送信元インターフェースが決定されます。
一見インターフェースを指定すれば良いように思えますが、基本的に使用するべきではありません。
next-hop を指定しないと、どの IP (=ルータ) 宛にパケットを送信しないといけないかわかりません。
このため、送信元インターフェースに多数の ARP エントリが登録されてしまい、CPU 負荷が高騰します。
* 参考 : [https://www.cisco.com/c/ja_jp/support/docs/routers/7500-series-routers/41180-highcpu-processes.html プロセスによって CPU 使用率が高くなる場合のトラブルシューティング]
ありがちな設定としては、デフォルトルートに WAN インターフェースのみを指定してしまうケースがあります。
PPPoE など、ARP を使用しない場合にはむしろインターフェース指定が一般的なため、違いを把握する必要があります。
* 参考 : [https://community.cisco.com/t5/tkb-%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9-%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/pppoe-%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%AE%E8%A8%AD%E5%AE%9A%E4%BE%8B/ta-p/3166456 PPPoE クライアントの設定例]
=== next-hop のみを指定 ===
next-hop のみを指定した場合、冗長切替時に想定外の動作をするケースがあります。
例えば主系インターフェース切断で、従系インターフェースのフローティング ルートに切り替えたいケースを想定します。
主系断したものの、別のスタティックルートにより主系ルートの next-hop が再帰検索されてしまい、想定通りルートが切り替わらない場合があります。
対策としては next-hop と主系インターフェース名を、スタティックルートに設定する、となります。
* 詳細 : [https://www.cisco.com/c/ja_jp/support/docs/dial-access/floating-static-route/118263-technote-nexthop-00.html スタティックルートのネクストホップ IP アドレスの設定]
== 文字列のバッドプラクティス ==
== 文字列のバッドプラクティス ==
ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。
ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。
設計書でルール化して、どちらか片方しか使わなくするなどの対応を取ります。
=== show run | in <name> で、名前が正しく定義・適用されているか確認します ===
=== show run | in <name> で、名前が正しく定義・適用されているか確認します ===
2023/12/12 provision コマンドについて追記
2023/12/12 provision コマンドについて追記
2024/01/30 スタティックルートについて追記
== リファレンス ==
== リファレンス ==