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

提供:hkatou_Lab
ナビゲーションに移動 検索に移動
214行目: 214行目:
[結果]
[結果]
<なし>
<なし>
</syntaxhighlight>'''PACL , RACL などで使っている (普通は拡張 ACL なのでまず無いですが・・・) 場合、障害になる可能性大'''です。
</syntaxhighlight>'''PACL , RACL などで使っている場合、障害になる可能性大'''です。


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


=== 削除例 2 ===
=== 削除例 2 ===
235行目: 235行目:
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 を編集モードで削除する
* ACL をシーケンス番号付きで削除する
* ACL をシーケンス番号付きで削除する
284行目: 286行目:
- .2 が正常に削除された
- .2 が正常に削除された


</syntaxhighlight>
</syntaxhighlight>シーケンス番号付き削除は show ip access-lists を取得しておくか、IOS-XE 17.x 以降の show run じゃないとシーケンス番号がわかりません。
 
== show running-config に現れない設定 ==
== show running-config に現れない設定 ==
show running-config を同じにすれば基本的に同じ動作になるのが Cisco の良いところですが、show running-config に出てこない設定が存在します。
show running-config を同じにすれば基本的に同じ動作になるのが Cisco の良いところですが、show running-config に出てこない設定が存在します。
382行目: 385行目:


=== コンフィギュレーション ガイドのコンフィグからコピペ ===
=== コンフィギュレーション ガイドのコンフィグからコピペ ===
== バッドプラクティス例 ==


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


* 大文字と小文字が異なる、スペースの数が不適切
* 大文字と小文字が異なる、スペースの数が不適切
524行目: 529行目:
</syntaxhighlight>机上作成時のクオリティをアップさせます。
</syntaxhighlight>机上作成時のクオリティをアップさせます。


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


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

2024年1月19日 (金) 22:30時点における版

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

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

削除例 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 に出てこない設定が存在します。

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

キャパシティ変更系・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 は異なるのが正しいです。

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

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

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

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

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

例えば Catalyst 3850 は以下の 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 に表示されます。

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

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

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 コマンドについて追記

リファレンス

賢い質問のしかた

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