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

2026年6月3日 (水) 06:08にHkatouによる

2026-06-03T06:08:49Z

← 古い版		2026年6月3日 (水) 15:08時点における版
343行目:		343行目:
	* show crypto key <key_name> rsa で確認		* show crypto key <key_name> rsa で確認
	* show running-config に出ないため、実際に SSH 接続できるか、確認したほうが良い		* show running-config に出ないため、実際に SSH 接続できるか、確認したほうが良い

			== パスワード ==
			既存コンフィグで Type 7 パスワードを使用している場合、復号化が可能です。

			既存のコンフィグを IOS に投入し、show key chain で復号化した文字列を確認できてしまいます。

			また、Type 7 パスワードを復号化できると謳う Web サイトに入力してしまうと、情報が漏洩するおそれがありますので、やめましょう。

			セキュリティを高めるために、enable パスワードは復号化できないように、enable secret でハッシュ化して保存しましょう。

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

Hkatou: /* 実機や仮想環境で挙動を確認 */

2024-04-19T02:54:55Z

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

← 古い版		2024年4月19日 (金) 11:54時点における版
38行目:		38行目:
	=== 実機や仮想環境で挙動を確認 ===		=== 実機や仮想環境で挙動を確認 ===
	考えたとおりには動きません。設定したとおりに動きます。		考えたとおりには動きません。設定したとおりに動きます。

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

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

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

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

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

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

	* ドキュメント ('''特にコンフィギュレーションガイド''')		* ドキュメント ('''特にコンフィギュレーションガイド''')
	* 実機・仮想環境		* 実機・仮想環境
	* 人		* 人
			要件次第ですが、コンフィグは厳密に作成できるものです。

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

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

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

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

	=== コンフィギュレーションガイドに聞く ===		=== コンフィギュレーションガイドに聞く ===
124行目:		133行目:

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

	既存のコンフィグを把握していないと、正しいかどうかわからない投入コンフィグは、レビュー時のコストがかなり高くなってしまいます。		既存のコンフィグを把握していないと、正しいかどうかわからない投入コンフィグは、レビュー時のコストがかなり高くなってしまいます。
333行目:		342行目:

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

	== 有効にするために reload が必要な設定 ==		== 有効にするために reload が必要な設定 ==
399行目:		408行目:
	== バッドプラクティス例 ==		== バッドプラクティス例 ==

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

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

	* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます		* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
	* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任		* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任 or 検証していない NIer の責任

	Google の検索結果はあくまで参考に、コンフィギュレーションガイドを尊重します。		Google の検索結果はあくまで参考に、コンフィギュレーションガイドを尊重します。
577行目:		587行目:
	Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。		Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。

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

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

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

	=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===		=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
653行目:		663行目:
	ラボの機器で 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 ?
770行目:		780行目:
	ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。		ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。

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

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

2024年1月31日 (水) 02:45にHkatouによる

2024-01-31T02:45:33Z

← 古い版		2024年1月31日 (水) 11:45時点における版
99行目:		99行目:
	=== エビデンスを取得しましょう ===		=== エビデンスを取得しましょう ===
	作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。		作成したコンフィグについて、動作確認に使う show コマンドを調べましょう。

			=== テスト駆動コンフィグ ===
			テストを実施しながら設定変更しましょう。

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

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

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

	== コンフィグ投入 ==		== コンフィグ投入 ==

Hkatou: Hkatou がページ「2023-12-12 Cisco IOS IOS-XE コンフィグ作成まとめ」を「2024-01-30 Cisco IOS IOS-XE コンフィグ作成まとめ」に移動しました

2024-01-30T03:22:55Z

Hkatou がページ「2023-12-12 Cisco IOS IOS-XE コンフィグ作成まとめ」を「2024-01-30 Cisco IOS IOS-XE コンフィグ作成まとめ」に移動しました

← 古い版	2024年1月30日 (火) 12:22時点における版
(相違点なし)

Hkatou: /* 質問の仕方 */

2024-01-30T03:22:43Z

質問の仕方

差分を表示

Hkatou: /* スタティックルーティングのベストプラクティス */

2024-01-30T02:36:24Z

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

← 古い版		2024年1月30日 (火) 11:36時点における版
661行目:		661行目:
	<syntaxhighlight lang="diff">		<syntaxhighlight lang="diff">
	ip route 10.0.0.1 255.255.255.255 172.16.0.1 name L3SW_Lo0		ip route 10.0.0.1 255.255.255.255 172.16.0.1 name L3SW_Lo0
	</syntaxhighlight>		</syntaxhighlight>対向側の L3SW の Lo0 が変更や削除になった場合、このルートを持つ機器でも変更しなければならないことがわかります。

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

2024年1月30日 (火) 02:30にHkatouによる

2024-01-30T02:30:34Z

← 古い版		2024年1月30日 (火) 11:30時点における版
650行目:		650行目:

	</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>

			=== 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 アドレスの設定]

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

Hkatou: /* コンフィグ削除の特殊例 2) */

2024-01-19T13:30:56Z

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

← 古い版		2024年1月19日 (金) 22:30時点における版
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 号機のポートを比較 ===

Hkatou: /* コンフィグ削除の特殊例 2) */

2023-12-15T08:38:50Z

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

@@ 216行目: / 216行目: @@
 </syntaxhighlight>'''PACL , RACL などで使っている (普通は拡張 ACL なのでまず無いですが・・・) 場合、障害になる可能性大'''です。
-'''Standard Access-list (1-99) は行単位で削除できない'''ため、コンソール経由の設定変更や新規番号に入れ替えて設定変更を行います。
+'''Access-list は行単位で削除できない'''ため、コンソール経由の設定変更や新規番号に入れ替えて設定変更を行います。
 === 削除例 2 ===
@@ 239行目: / 239行目: @@
 * 新しい ACL を作成し、ACL を指定するところで差し替える
 * ACL を使用している機能で適用を解除、ACL を書き換え、機能で再適用
 == show running-config に現れない設定 ==
 show running-config を同じにすれば基本的に同じ動作になるのが Cisco の良いところですが、show running-config に出てこない設定が存在します。

Hkatou: Hkatou がページ「2023-09-07 Cisco IOS IOS-XE コンフィグ作成まとめ」を「2023-12-12 Cisco IOS IOS-XE コンフィグ作成まとめ」に移動しました

2023-12-12T02:39:51Z

Hkatou がページ「2023-09-07 Cisco IOS IOS-XE コンフィグ作成まとめ」を「2023-12-12 Cisco IOS IOS-XE コンフィグ作成まとめ」に移動しました

← 古い版	2023年12月12日 (火) 11:39時点における版
(相違点なし)

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

2026年6月3日 (水) 06:08にHkatouによる

Hkatou: /* 実機や仮想環境で挙動を確認 */

2024年1月31日 (水) 02:45にHkatouによる

Hkatou: Hkatou がページ「2023-12-12 Cisco IOS IOS-XE コンフィグ作成まとめ」を「2024-01-30 Cisco IOS IOS-XE コンフィグ作成まとめ」に移動しました

Hkatou: /* 質問の仕方 */

Hkatou: /* スタティック ルーティングのベスト プラクティス */

2024年1月30日 (火) 02:30にHkatouによる

Hkatou: /* コンフィグ削除の特殊例 2) */

Hkatou: /* コンフィグ削除の特殊例 2) */

Hkatou: Hkatou がページ「2023-09-07 Cisco IOS IOS-XE コンフィグ作成まとめ」を「2023-12-12 Cisco IOS IOS-XE コンフィグ作成まとめ」に移動しました

Hkatou: /* スタティックルーティングのベストプラクティス */