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

提供：hkatou_Lab
ナビゲーションに移動 検索に移動
← 古い編集
ビジュアルウィキテキスト
 
(同じ利用者による、間の11版が非表示)
38行目: 38行目:
=== 実機や仮想環境で挙動を確認 ===
=== 実機や仮想環境で挙動を確認 ===
考えたとおりには動きません。設定したとおりに動きます。
考えたとおりには動きません。設定したとおりに動きます。
設定差分確認は、動作を確認したことになりません。
Cisco であれば show コマンドで設定した機能が動作しているか確認します。


=== 置換は慎重に、でも多用 ===
=== 置換は慎重に、でも多用 ===
44行目: 48行目:
* コンフィグを投入することによる機器の動作を知らない
* コンフィグを投入することによる機器の動作を知らない


* わかっていないことがわかっていない  
* '''わかっていないことがわかっていない'''


* 何が正しいコンフィグか判断できない = 異常があっても気づけない
* 何が正しいコンフィグか判断できない = 異常があっても気づけない
55行目: 59行目:
* 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど
* 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど


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


* ドキュメント ('''特にコンフィギュレーションガイド''')
* ドキュメント ('''特にコンフィギュレーションガイド''')
* 実機・仮想環境
* 実機・仮想環境
* 人
* 人
要件次第ですが、コンフィグは厳密に作成できるものです。
人の曖昧な回答よりも、実機で動くか確認したほうが良いケースが多いです。


=== 確認は機械自身にさせましょう ===
=== 確認は機械自身にさせましょう ===
65行目: 72行目:


== 質問の仕方 ==
== 質問の仕方 ==
人の回答はアドバイスに過ぎませんが、'''機械の回答 (設定投入や試験) は「答えそのもの」'''を教えてくれます。
人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。
* 刺激的な言い方をすると、「機械でカンニングし放題」


=== コンフィギュレーションガイドに聞く ===
=== コンフィギュレーションガイドに聞く ===
75行目: 87行目:
=== 機械に聞く ===
=== 機械に聞く ===
検証でコンフィグが投入できるか、動作が正しいか確認します。
検証でコンフィグが投入できるか、動作が正しいか確認します。
検証環境で投入が成功したコンフィグを、実機の投入コンフィグにします。
通常検証機であっても、人より精度が高いです。
機械は検証の仕方などは教えてくれないため、自分が何がわかっていないか把握すると良いでしょう。


=== 人に聞く ===
=== 人に聞く ===
90行目: 108行目:
=== エビデンスを取得しましょう ===
=== エビデンスを取得しましょう ===
作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。
作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。
=== テスト駆動コンフィグ ===
テストを実施しながら設定変更しましょう。
例えば、新規 IP を設定する前から新しい IP 宛に ping を repeat で打ちっぱなしにして、設定変更後に疎通が取れるか確認します。
新規 IP を設定したけどルーティング設定を追加し忘れたときなど、足りない設定が無いかどうか、リアルタイムに確認できます。
* ソフトウェア開発の方式として、テスト駆動開発という手法があるため、これを真似たものです


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


=== 追加 ===
=== 追加 ===
106行目: 133行目:


== コンフィグ変更の例 ==
== コンフィグ変更の例 ==
昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのがおすすめです。
昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのを推奨します。
 
既存のコンフィグを把握していないと、正しいかどうかわからない投入コンフィグは、レビュー時のコストがかなり高くなってしまいます。


=== バッドプラクティス ===
=== バッドプラクティス ===
207行目: 236行目:
[結果]
[結果]
<なし>
<なし>
</syntaxhighlight>'''PACL , RACL などで使っている (普通は拡張 ACL なのでまず無いですが・・・) 場合、障害になる可能性大'''です。
</syntaxhighlight>'''PACL , RACL などで使っている場合、障害になる可能性大'''です。


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


=== 削除例 2 ===
=== 削除例 2 ===
228行目: 257行目:
access-list 1 permit 1.1.1.1
access-list 1 permit 1.1.1.1
access-list 1 permit 2.2.2.2
access-list 1 permit 2.2.2.2
</syntaxhighlight>削除を慎重に確認した例です。この場合は以下の対処策があります。
</syntaxhighlight>削除を慎重に確認した例です。? を入力したあと、<cr> となっているため、ACL 全体を削除するコンフィグになっていることがわかります。


* 新しい ACL を作成し、ACL を指定するところで差し替える
この場合は以下の対処策があります。
* ACL を使用している機能で適用を解除、ACL を書き換え、機能で再適用
 
* 新しい ACL を作成し、ACL を指定するところで差し替える 差し替え後に古い ACL を削除する
* ACL を使用している機能で適用を解除、ACL を書き換え、機能で ACL を再適用
* ACL を編集モードで削除する
* ACL をシーケンス番号付きで削除する
以下に後半 2 つの例について記載します。<syntaxhighlight lang="diff">
[設定済みコンフィグ]
show run | in access-list 100
access-list 100 permit ip host 10.0.0.1 host 192.168.0.1
access-list 100 permit ip host 10.0.0.2 host 192.168.0.2
access-list 100 permit ip host 10.0.0.3 host 192.168.0.3
 
 
[削除 - NG 例]
configure terminal
no access-list 100 permit ip host 10.0.0.2 host 192.168.0.2
end
 
show run | in access-list 100
<<< 何も出力されないため、使用していた場合は ACL100 が暗黙の deny でトラフィックが停止する
 
 
[ACL 編集モード削除 - OK 例 1)]
configure terminal
ip access-list extended 100
no permit ip host 10.0.0.2 host 192.168.0.2
end
show run | in access-list 100
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
- .2 のエントリが正常に削除された
 
 
[シーケンス番号付き削除 - OK 例 2)]
sh ip access-lists 100
Extended IP access list 100
    10 permit ip host 10.0.0.1 host 192.168.0.1
    20 permit ip host 10.0.0.2 host 192.168.0.2
    30 permit ip host 10.0.0.3 host 192.168.0.3
configure terminal
ip access-list extended 100
no 20 permit ip host 10.0.0.2 host 192.168.0.2
end
show run | in access-list 100
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
- .2 が正常に削除された
 
</syntaxhighlight>シーケンス番号付き削除は show ip access-lists を取得しておくか、IOS-XE 17.x 以降の show run じゃないとシーケンス番号がわかりません。


== show running-config に現れない設定 ==
== show running-config に現れない設定 ==
238行目: 315行目:
保守交換、コンフィグ流用時などには、よく確認する必要があります。
保守交換、コンフィグ流用時などには、よく確認する必要があります。


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


=== Catalyst 2k / 3k ===
=== Catalyst 2k / 3k ===
265行目: 342行目:


* show crypto key <key_name> rsa で確認
* show crypto key <key_name> rsa で確認
* 実際に SSH 接続できるか、確認したほうが良い
* show running-config に出ないため、実際に SSH 接続できるか、確認したほうが良い


== 有効にするために reload が必要な設定 ==
== 有効にするために reload が必要な設定 ==
271行目: 348行目:


コンフィギュレーション ガイドをよく確認する必要があります。
コンフィギュレーション ガイドをよく確認する必要があります。
別途ページにまとめていますので、参照してみてください。
* 参考 : [[設定に再起動が必要なコンフィグまとめ]]


=== Catalyst 2k / 3k ===
=== Catalyst 2k / 3k ===
288行目: 369行目:


* show mls cef maximum-routes で確認
* show mls cef maximum-routes で確認
参考 : [[設定に再起動が必要なコンフィグまとめ]]


== 作成手段 ==
== 作成手段 ==
307行目: 386行目:
* コマンドリファレンス
* コマンドリファレンス
* リリースノート
* リリースノート
Google で検索したり、他の案件して見つかったコンフィグを、'''内容がわからないまま流用しない'''こと。
* 障害になった時に、お客様へ説明できません
* 機器のマニュアルくらい見ろよ・・・と思われてしまう
* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合の責任
Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。


== コピー & ペースト ==
== コピー & ペースト ==
324行目: 393行目:


* OS が同じなら良いですが、特に別メーカーだと使えません
* OS が同じなら良いですが、特に別メーカーだと使えません
* 実装変更される機能は、投入できません
** 例) NetFlow -> Flexible NetFlow


=== 新規機器のデフォルト コンフィグからコピペ ===
=== 新規機器のデフォルト コンフィグからコピペ ===
* ポート番号などを把握するのに、デフォルト コンフィグが便利です


=== 実機・仮想環境で投入した結果のコンフィグからコピペ ===
=== 実機・仮想環境で投入した結果のコンフィグからコピペ ===
* かなり精度の高いやり方です


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


=== 作業品質が低いエンジニアの例 ===
== バッドプラクティス例 ==
show running-config と投入コンフィグで差分が多く出るコンフィグを作成する人には、気をつけたほうが良いでしょう。
 
=== 作業品質が低いコンフィグの例 ===
レビュアーとして他人のコンフィグをレビューする場合、show running-config と投入コンフィグで差分が多く出るコンフィグには、気をつけたほうが良いでしょう。


* 大文字と小文字が異なる、スペースの数が不適切
* 大文字と小文字が異なる、スペースの数が不適切
338行目: 415行目:
*** 誤 : Gigabit , Ethernet の頭が小文字になっている
*** 誤 : Gigabit , Ethernet の頭が小文字になっている
*** 誤 : net と 1/ の間にスペースがある
*** 誤 : net と 1/ の間にスペースがある
** 手打ちしている可能性大
* インデントされたスペースの数が異なる
* インデントされたスペースの数が異なる
** Winmerge で差分を取ったときに差が大量に出てしまう
** Winmerge で差分を取ったときに差分が大量に出てしまう
* show running-config と投入順番が異なる
* show running-config と投入順番が異なる
** ACL 定義後に PACL を設定するなど、あえてやる場合もあります
** ACL 定義後に PACL を設定するなど、あえてやる場合もあります
345行目: 423行目:


1 回のレビューで 5 回以上必要ない差分が出るような人は、'''作業が雑だな'''、と筆者は判断します。
1 回のレビューで 5 回以上必要ない差分が出るような人は、'''作業が雑だな'''、と筆者は判断します。
=== 悪いコピペ ===
Google で検索したり、他の案件して見つかったコンフィグを、'''内容がわからないまま流用してしまう'''。
* 障害になった時に、お客様へ説明できません / 障害を修正できません
* 機器のマニュアルくらい見ろよ・・・と思われてしまう
* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任 or 検証していない NIer の責任
Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。


== ツール ==
== ツール ==
355行目: 444行目:
* 記録した動作を繰り返し実施できる、'''マクロ'''機能
* 記録した動作を繰り返し実施できる、'''マクロ'''機能


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


最近は Cisco IOS 用のシンタックス ハイライトが手軽にインストールできる、Visual Studio Code が良さそうです。
最近は Cisco IOS 用のシンタックス ハイライトが手軽にインストールできる、Visual Studio Code が良さそうです。
367行目: 456行目:
STP の挙動をアニメーションで確認できます。
STP の挙動をアニメーションで確認できます。


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


== 置換と正規表現 ==
== 置換と正規表現 ==
392行目: 481行目:


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


=== スイッチ ===
=== スイッチ ===


==== 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 が割り当てられています。


407行目: 502行目:


* 投入コンフィグを作成する場合、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 が割り当てられています。
インターフェースは有効になっています。


=== 投入コンフィグは、デフォルト コンフィグを考慮して作成します ===
=== 投入コンフィグは、デフォルト コンフィグを考慮して作成します ===
443行目: 573行目:
プラットフォーム非依存のプロトコルは、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 ===
455行目: 587行目:
Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。
Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。


医者で言う症例カンファレンスですね。
医療で言う症例カンファレンスに該当します。


=== 実績のある、類似案件のコンフィグと比較 ===
=== 実績のある、類似案件のコンフィグと比較 ===
472行目: 604行目:
</syntaxhighlight>机上作成時のクオリティをアップさせます。
</syntaxhighlight>机上作成時のクオリティをアップさせます。


L2SW の場合、理想的には jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させると良いです。
L2SW のコンフィグを多数作成する場合、jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させる、などの方法を用いると生成もレビューも楽をできて良いです。


=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
522行目: 654行目:
</syntaxhighlight>上記の例では Port-Channel 番号は同一なのが正しく、description は異なるのが正しいです。
</syntaxhighlight>上記の例では Port-Channel 番号は同一なのが正しく、description は異なるのが正しいです。


同一が正しいのか、異なるのが正しいのか、判断できるようになりましょう。
同一が正しいのか、異なるのが正しいのか、気付ける + 判断できるようになりましょう。
 
== インターフェース コンフィグの TIPS ==
 
=== Catalyst 2k / 3k は、provision コマンドでインターフェース コンフィグを作成できます ===
Catalyst 2k / 3k の場合は、provision コマンドを使用することで、指定する SKU (=型式) のインターフェース コンフィグを事前投入することができます。
 
ラボの機器で provision して投入コンフィグを作成、実機が届いたら投入することで、事前に実機で答え合わせした上で、投入コンフィグを作成できます。
 
例えば Catalyst 3850 + IOS-XE 16.12.x は以下の SKU のコンフィグを作成可能です。<syntaxhighlight lang="diff">
switch(config)#switch 3 pro
switch(config)#switch 3 provision ?
  ms390-24          Meraki 390 Series Switch with 24x1Gig Interfaces
  ms390-24p        Meraki 390 Series Switch with 24x1Gig POE Interfaces
  ms390-24u        Meraki 390 Series Switch with 24x1Gig UPOE Interfaces
  ms390-24ux        Meraki 390 Series Switch with 24 TenGig UPOE Interfaces
  ms390-48          Meraki 390 Series Switch with 48x1Gig Interfaces
  ms390-48p        Meraki 390 Series Switch with 48x1Gig POE Interfaces
  ms390-48u        Meraki 390 Series Switch with 48x1Gig UPOE Interfaces
  ms390-48ux        Meraki 390 Series Switch with 36 2.5G and 12 mGig UPOE
                    Interfaces
  ms390-48ux2      Meraki 390 Series Switch with 48x5G UPOE Interfaces
  ws-c3650-12x48fd  Catalyst 3650 Series Switch with 36 GE and 12 TenGE POE
                    Interfaces
  ws-c3650-12x48uq  Catalyst 3650 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3650-12x48ur  Catalyst 3650 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3650-12x48uz  Catalyst 3650 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3650-24pd    Catalyst 3650 Series Switch with 24 GE POE and 2GE+2TenGE
                    Interfaces
  ws-c3650-24pdm    Catalyst 3650 Series Switch with 24 GE POE and 2GE+2TenGE
                    Interfaces
  ws-c3650-24ps    Catalyst 3650 Series Switch with 24 GE POE and 4 GE
                    Interfaces
  ws-c3650-24td    Catalyst 3650 Series Switch with 24 GE and 2GE+2TenGE
                    Interfaces
  ws-c3650-24ts    Catalyst 3650 Series Switch with 24 GE and 4 GE Interfaces
  ws-c3650-48fqm    Catalyst 3650 Series Switch with 48 GE POE and 4 TenGE
                    Interfaces
  ws-c3650-48pd    Catalyst 3650 Series Switch with 48 GE POE and 2GE+2TenGE
                    Interfaces
  ws-c3650-48pq    Catalyst 3650 Series Switch with 48 GE POE and 4 TenGE
                    Interfaces
  ws-c3650-48ps    Catalyst 3650 Series Switch with 48 GE POE and 4 GE
                    Interfaces
  ws-c3650-48td    Catalyst 3650 Series Switch with 48 GE and 2GE+2TenGE
                    Interfaces
  ws-c3650-48tq    Catalyst 3650 Series Switch with 48 GE and 4 TenGE
                    Interfaces
  ws-c3650-48ts    Catalyst 3650 Series Switch with 48 GE and 4 GE Interfaces
  ws-c3650-8x24pd  Catalyst 3650 Series Switch with 24 TenGE POE Interfaces
  ws-c3650-8x24uq  Catalyst 3650 Series Switch with 24 TenGE UPOE Interfaces
  ws-c3850-12s      Catalyst 3850 Series Switch with 12 1GE SFP Interfaces
  ws-c3850-12x48u  Catalyst 3850 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3850-12xs    Catalyst 3850 Series Switch with 12 10GE SFP Interfaces
  ws-c3850-24p      Catalyst 3850 Series Switch with 24 GE POE Interfaces
  ws-c3850-24s      Catalyst 3850 Series Switch with 24 1GE SFP Interfaces
  ws-c3850-24t      Catalyst 3850 Series Switch with 24 GE Interfaces
  ws-c3850-24u      Catalyst 3850 Series Switch with 24 GE UPOE Interfaces
  ws-c3850-24xs    Catalyst 3850 Series Switch with 24 10GE SFP Interfaces
  ws-c3850-24xu    Catalyst 3850 Series Switch with 24 TenGE UPOE Interfaces
  ws-c3850-48p      Catalyst 3850 Series Switch with 48 GE POE Interfaces
  ws-c3850-48t      Catalyst 3850 Series Switch with 48 GE Interfaces
  ws-c3850-48u      Catalyst 3850 Series Switch with 48 GE UPOE Interfaces
  ws-c3850-48xs    Catalyst 3850 Series Switch with 48 10GE Interfaces and 4
                    40G Interfaces
 
</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 アドレスの設定]


== 文字列のバッドプラクティス ==
== 文字列のバッドプラクティス ==
529行目: 780行目:
ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。
ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。


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


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


PRIVATE-IP (ハイフン) を使用していた場合、” | in” にヒットせず、表示されません
PRIVATE-IP (ハイフン) を使用していた場合、” | in” にヒットせず、表示されません
== 更新履歴 ==
2023/09/07 書版作成
2023/12/12 provision コマンドについて追記
2024/01/30 スタティックルートについて追記


== リファレンス ==
== リファレンス ==

2024年4月19日 (金) 11:54時点における最新版

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

目的

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

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

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

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

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

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

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

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

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

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

作成ポリシー

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

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

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

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

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

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

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

考えたとおりには動きません。設定したとおりに動きます。

設定差分確認は、動作を確認したことになりません。

Cisco であれば show コマンドで設定した機能が動作しているか確認します。

置換は慎重に、でも多用

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

  • コンフィグを投入することによる機器の動作を知らない
  • わかっていないことがわかっていない
  • 何が正しいコンフィグか判断できない = 異常があっても気づけない

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

  • ACL / プレフィックス長など
    • /16 を /17 に間違えた場合、何人のユーザに影響が発生しますか ?
  • 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど

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

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

要件次第ですが、コンフィグは厳密に作成できるものです。

人の曖昧な回答よりも、実機で動くか確認したほうが良いケースが多いです。

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

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

質問の仕方

人の回答はアドバイスに過ぎませんが、機械の回答 (設定投入や試験) は「答えそのもの」を教えてくれます。

人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。

  • 刺激的な言い方をすると、「機械でカンニングし放題」

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

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

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

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

機械に聞く

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

検証環境で投入が成功したコンフィグを、実機の投入コンフィグにします。

通常検証機であっても、人より精度が高いです。

機械は検証の仕方などは教えてくれないため、自分が何がわかっていないか把握すると良いでしょう。

人に聞く

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

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

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

検証の仕方

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

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

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

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

テスト駆動コンフィグ

テストを実施しながら設定変更しましょう。

例えば、新規 IP を設定する前から新しい IP 宛に ping を repeat で打ちっぱなしにして、設定変更後に疎通が取れるか確認します。

新規 IP を設定したけどルーティング設定を追加し忘れたときなど、足りない設定が無いかどうか、リアルタイムに確認できます。

  • ソフトウェア開発の方式として、テスト駆動開発という手法があるため、これを真似たものです

コンフィグ投入

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

追加

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

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

削除

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

変更

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

コンフィグ変更の例

昨今 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 などで使っている場合、障害になる可能性大です。

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

削除例 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

削除を慎重に確認した例です。? を入力したあと、<cr> となっているため、ACL 全体を削除するコンフィグになっていることがわかります。

この場合は以下の対処策があります。

  • 新しい ACL を作成し、ACL を指定するところで差し替える 差し替え後に古い ACL を削除する
  • ACL を使用している機能で適用を解除、ACL を書き換え、機能で ACL を再適用
  • ACL を編集モードで削除する
  • ACL をシーケンス番号付きで削除する

以下に後半 2 つの例について記載します。

[設定済みコンフィグ]
show run | in access-list 100
access-list 100 permit ip host 10.0.0.1 host 192.168.0.1
access-list 100 permit ip host 10.0.0.2 host 192.168.0.2
access-list 100 permit ip host 10.0.0.3 host 192.168.0.3


[削除 - NG 例]
configure terminal
no access-list 100 permit ip host 10.0.0.2 host 192.168.0.2
end

show run | in access-list 100
<<< 何も出力されないため、使用していた場合は ACL100 が暗黙の deny でトラフィックが停止する


[ACL 編集モード削除 - OK 例 1)]
configure terminal
ip access-list extended 100
 no permit ip host 10.0.0.2 host 192.168.0.2
end
show run | in access-list 100
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
- .2 のエントリが正常に削除された


[シーケンス番号付き削除 - OK 例 2)]
sh ip access-lists 100
Extended IP access list 100
    10 permit ip host 10.0.0.1 host 192.168.0.1
    20 permit ip host 10.0.0.2 host 192.168.0.2
    30 permit ip host 10.0.0.3 host 192.168.0.3
configure terminal
ip access-list extended 100
 no 20 permit ip host 10.0.0.2 host 192.168.0.2
end
show run | in access-list 100
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
- .2 が正常に削除された

シーケンス番号付き削除は show ip access-lists を取得しておくか、IOS-XE 17.x 以降の show run じゃないとシーケンス番号がわかりません。

show running-config に現れない設定

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

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

TCAM キャパシティ変更系・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 で確認
  • show running-config に出ないため、実際に 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 で確認

作成手段

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

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

検証で作成

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

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

机上で作成

ドキュメントで確認。

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

コピー & ペースト

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

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

  • OS が同じなら良いですが、特に別メーカーだと使えません
  • 実装変更される機能は、投入できません
    • 例) NetFlow -> Flexible NetFlow

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

  • ポート番号などを把握するのに、デフォルト コンフィグが便利です

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

  • かなり精度の高いやり方です

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

バッドプラクティス例

作業品質が低いコンフィグの例

レビュアーとして他人のコンフィグをレビューする場合、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 回以上必要ない差分が出るような人は、作業が雑だな、と筆者は判断します。

悪いコピペ

Google で検索したり、他の案件して見つかったコンフィグを、内容がわからないまま流用してしまう。

  • 障害になった時に、お客様へ説明できません / 障害を修正できません
  • 機器のマニュアルくらい見ろよ・・・と思われてしまう
  • 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
  • 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任 or 検証していない NIer の責任

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

ツール

テキストエディタ

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

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

筆者は 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 / 9200 / 9300 [1] :

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

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

Catalyst 6k :

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

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

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

Catalyst 9500 [2] :

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

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

Catalyst 9500 ハイパフォーマンス -16.11 以前 [2] :

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

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

Catalyst 9500 ハイパフォーマンス 16.11.1 以降 [3] :

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

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

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

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

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 に対応しません [4]

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 は異なるのが正しいです。

同一が正しいのか、異なるのが正しいのか、気付ける + 判断できるようになりましょう。

インターフェース コンフィグの TIPS

Catalyst 2k / 3k は、provision コマンドでインターフェース コンフィグを作成できます

Catalyst 2k / 3k の場合は、provision コマンドを使用することで、指定する SKU (=型式) のインターフェース コンフィグを事前投入することができます。

ラボの機器で provision して投入コンフィグを作成、実機が届いたら投入することで、事前に実機で答え合わせした上で、投入コンフィグを作成できます。

例えば Catalyst 3850 + IOS-XE 16.12.x は以下の SKU のコンフィグを作成可能です。

switch(config)#switch 3 pro
switch(config)#switch 3 provision ?
  ms390-24          Meraki 390 Series Switch with 24x1Gig Interfaces
  ms390-24p         Meraki 390 Series Switch with 24x1Gig POE Interfaces
  ms390-24u         Meraki 390 Series Switch with 24x1Gig UPOE Interfaces
  ms390-24ux        Meraki 390 Series Switch with 24 TenGig UPOE Interfaces
  ms390-48          Meraki 390 Series Switch with 48x1Gig Interfaces
  ms390-48p         Meraki 390 Series Switch with 48x1Gig POE Interfaces
  ms390-48u         Meraki 390 Series Switch with 48x1Gig UPOE Interfaces
  ms390-48ux        Meraki 390 Series Switch with 36 2.5G and 12 mGig UPOE
                    Interfaces
  ms390-48ux2       Meraki 390 Series Switch with 48x5G UPOE Interfaces
  ws-c3650-12x48fd  Catalyst 3650 Series Switch with 36 GE and 12 TenGE POE
                    Interfaces
  ws-c3650-12x48uq  Catalyst 3650 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3650-12x48ur  Catalyst 3650 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3650-12x48uz  Catalyst 3650 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3650-24pd     Catalyst 3650 Series Switch with 24 GE POE and 2GE+2TenGE
                    Interfaces
  ws-c3650-24pdm    Catalyst 3650 Series Switch with 24 GE POE and 2GE+2TenGE
                    Interfaces
  ws-c3650-24ps     Catalyst 3650 Series Switch with 24 GE POE and 4 GE
                    Interfaces
  ws-c3650-24td     Catalyst 3650 Series Switch with 24 GE and 2GE+2TenGE
                    Interfaces
  ws-c3650-24ts     Catalyst 3650 Series Switch with 24 GE and 4 GE Interfaces
  ws-c3650-48fqm    Catalyst 3650 Series Switch with 48 GE POE and 4 TenGE
                    Interfaces
  ws-c3650-48pd     Catalyst 3650 Series Switch with 48 GE POE and 2GE+2TenGE
                    Interfaces
  ws-c3650-48pq     Catalyst 3650 Series Switch with 48 GE POE and 4 TenGE
                    Interfaces
  ws-c3650-48ps     Catalyst 3650 Series Switch with 48 GE POE and 4 GE
                    Interfaces
  ws-c3650-48td     Catalyst 3650 Series Switch with 48 GE and 2GE+2TenGE
                    Interfaces
  ws-c3650-48tq     Catalyst 3650 Series Switch with 48 GE and 4 TenGE
                    Interfaces
  ws-c3650-48ts     Catalyst 3650 Series Switch with 48 GE and 4 GE Interfaces
  ws-c3650-8x24pd   Catalyst 3650 Series Switch with 24 TenGE POE Interfaces
  ws-c3650-8x24uq   Catalyst 3650 Series Switch with 24 TenGE UPOE Interfaces
  ws-c3850-12s      Catalyst 3850 Series Switch with 12 1GE SFP Interfaces
  ws-c3850-12x48u   Catalyst 3850 Series Switch with 36 GE and 12 TenGE UPOE
                    Interfaces
  ws-c3850-12xs     Catalyst 3850 Series Switch with 12 10GE SFP Interfaces
  ws-c3850-24p      Catalyst 3850 Series Switch with 24 GE POE Interfaces
  ws-c3850-24s      Catalyst 3850 Series Switch with 24 1GE SFP Interfaces
  ws-c3850-24t      Catalyst 3850 Series Switch with 24 GE Interfaces
  ws-c3850-24u      Catalyst 3850 Series Switch with 24 GE UPOE Interfaces
  ws-c3850-24xs     Catalyst 3850 Series Switch with 24 10GE SFP Interfaces
  ws-c3850-24xu     Catalyst 3850 Series Switch with 24 TenGE UPOE Interfaces
  ws-c3850-48p      Catalyst 3850 Series Switch with 48 GE POE Interfaces
  ws-c3850-48t      Catalyst 3850 Series Switch with 48 GE Interfaces
  ws-c3850-48u      Catalyst 3850 Series Switch with 48 GE UPOE Interfaces
  ws-c3850-48xs     Catalyst 3850 Series Switch with 48 10GE Interfaces and 4
                    40G Interfaces

アップリンク モジュールのポート番号も、搭載しなくても show running-config に表示されます。

スタティック ルーティングのベスト プラクティス

name オプション

スタティックルートには、name オプションを付けましょう。筆者は宛先の機器名を付与しています。

メリットとしては変更や削除をしやすくなる点が挙げられます。影響を受ける機器がコンフィグから読み取れるためです。

name オプション例

ip route 10.0.0.1 255.255.255.255 172.16.0.1 name L3SW_Lo0

対向側の L3SW の Lo0 が変更や削除になった場合、このルートを持つ機器でも変更しなければならないことがわかります。

next-hop と送信元インターフェース名指定

next-hop と送信元インターフェースを元に、送信元インターフェースが決定されます。

両方設定するのが一番良いですが、インターフェースの指定は面倒なため、next-hop のみ設定する事例が多いです。

next-hop のみ指定する場合、再帰検索で next-hop を解決しようとしないか、把握しなければなりません。(後述のバッドプラクティスを参照)

スタティック ルーティングのバッド プラクティス

送信元インターフェース名のみを指定

next-hop と送信元インターフェースを元に、送信元インターフェースが決定されます。

一見インターフェースを指定すれば良いように思えますが、基本的に使用するべきではありません。

next-hop を指定しないと、どの IP (=ルータ) 宛にパケットを送信しないといけないかわかりません。

このため、送信元インターフェースに多数の ARP エントリが登録されてしまい、CPU 負荷が高騰します。

ありがちな設定としては、デフォルトルートに WAN インターフェースのみを指定してしまうケースがあります。

PPPoE など、ARP を使用しない場合にはむしろインターフェース指定が一般的なため、違いを把握する必要があります。

next-hop のみを指定

next-hop のみを指定した場合、冗長切替時に想定外の動作をするケースがあります。

例えば主系インターフェース切断で、従系インターフェースのフローティング ルートに切り替えたいケースを想定します。

主系断したものの、別のスタティックルートにより主系ルートの next-hop が再帰検索されてしまい、想定通りルートが切り替わらない場合があります。

対策としては next-hop と主系インターフェース名を、スタティックルートに設定する、となります。

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

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

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

更新履歴

2023/09/07 書版作成

2023/12/12 provision コマンドについて追記

2024/01/30 スタティックルートについて追記

リファレンス

賢い質問のしかた

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

  1. ↑ Interface and Hardware Components Configuration Guide, Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches) Default Ethernet Interface Configuration Port enable state All ports are enabled.
  2. ↑ 2.0 2.1 Interface and Hardware Components Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9500 Switches) 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.
  3. ↑ Release Notes for Cisco Catalyst 9500 Series Switches, Cisco IOS XE Gibraltar 16.11.x 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).
  4. ↑ Unsupported Features—Cisco Catalyst 9500 Series Switches Border Gateway Protocol (BGP) Additional Paths
「http://hkatou.net/index.php?title=2024-01-30_Cisco_IOS_IOS-XE_コンフィグ作成まとめ&oldid=1933」から取得