1,944
回編集
差分
ナビゲーションに移動
検索に移動
38行目:
38行目: + + + + 44行目:
48行目: − + 55行目:
59行目: − + + + + 68行目:
75行目: + + 124行目:
133行目: − + 333行目:
342行目: − + 399行目:
408行目: − + − + 406行目:
415行目: + − + 421行目:
431行目: − + 577行目:
587行目: − 医者で言う症例カンファレンスですね。+ 594行目:
604行目: − + 653行目:
663行目: − + 770行目:
780行目: − 設計書でルール化して、どちらか片方しか使わなくするなどの対応を取ります+
→実機や仮想環境で挙動を確認
=== 実機や仮想環境で挙動を確認 ===
=== 実機や仮想環境で挙動を確認 ===
考えたとおりには動きません。設定したとおりに動きます。
考えたとおりには動きません。設定したとおりに動きます。
設定差分確認は、動作を確認したことになりません。
Cisco であれば show コマンドで設定した機能が動作しているか確認します。
=== 置換は慎重に、でも多用 ===
=== 置換は慎重に、でも多用 ===
* コンフィグを投入することによる機器の動作を知らない
* コンフィグを投入することによる機器の動作を知らない
* わかっていないことがわかっていない
* '''わかっていないことがわかっていない'''
* 何が正しいコンフィグか判断できない = 異常があっても気づけない
* 何が正しいコンフィグか判断できない = 異常があっても気づけない
* 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど
* 差分確認をインターフェースの 1/0/x と 2/0/x で取るなど
=== 相談相手は 3 つしかありません 以下の順で相談すると信頼性が高いコンフィグに ===
=== 相談相手は 3 つしかありません 以下の順で相談すると信頼性が高いコンフィグにできます ===
* ドキュメント ('''特にコンフィギュレーションガイド''')
* ドキュメント ('''特にコンフィギュレーションガイド''')
* 実機・仮想環境
* 実機・仮想環境
* 人
* 人
要件次第ですが、コンフィグは厳密に作成できるものです。
人の曖昧な回答よりも、実機で動くか確認したほうが良いケースが多いです。
=== 確認は機械自身にさせましょう ===
=== 確認は機械自身にさせましょう ===
人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。
人に聞くのは、「方向性に迷った時」など、曖昧さが含まれる疑問があるときに効果が大きいです。
* 刺激的な言い方をすると、「機械でカンニングし放題」
=== コンフィギュレーションガイドに聞く ===
=== コンフィギュレーションガイドに聞く ===
== コンフィグ変更の例 ==
== コンフィグ変更の例 ==
昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのがおすすめです。
昨今 Ansible で出てくる、冪等性 (= 何度やっても同じ結果になる) を確保できる投入コンフィグを作成するのを推奨します。
既存のコンフィグを把握していないと、正しいかどうかわからない投入コンフィグは、レビュー時のコストがかなり高くなってしまいます。
既存のコンフィグを把握していないと、正しいかどうかわからない投入コンフィグは、レビュー時のコストがかなり高くなってしまいます。
* show crypto key <key_name> rsa で確認
* show crypto key <key_name> rsa で確認
* 実際に SSH 接続できるか、確認したほうが良い
* show running-config に出ないため、実際に SSH 接続できるか、確認したほうが良い
== 有効にするために reload が必要な設定 ==
== 有効にするために reload が必要な設定 ==
== バッドプラクティス例 ==
== バッドプラクティス例 ==
=== 作業品質が低いエンジニアの例 ===
=== 作業品質が低いコンフィグの例 ===
レビュアーとして他人のコンフィグをレビューする場合、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 を設定するなど、あえてやる場合もあります
* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
* 「Google で調べた情報を設定しました」「他の案件のコンフィグからコピペしました」 -> 設定した人の責任になり、めちゃくちゃ怒られます
* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任
* 「コンフィギュレーションガイドの通りに設定しましたが、S/W 不具合でトラフィックが失われました」 -> S/W 不具合 (=Cisco) の責任 or 検証していない NIer の責任
Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。
Google の検索結果はあくまで参考に、コンフィギュレーション ガイドを尊重します。
Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。
Winmerge で差分比較を行い、コンフィグの妥当性を確認、有識者を交えてレビューを行います。
医療で言う症例カンファレンスに該当します。
=== 実績のある、類似案件のコンフィグと比較 ===
=== 実績のある、類似案件のコンフィグと比較 ===
</syntaxhighlight>机上作成時のクオリティをアップさせます。
</syntaxhighlight>机上作成時のクオリティをアップさせます。
L2SW のコンフィグを多数作成する場合、jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させる、などの方法を用いると生成もレビューも楽できて良いです。
L2SW のコンフィグを多数作成する場合、jinja2 テンプレートから .csv のパラメータシートを読み込んでコンフィグを生成させる、などの方法を用いると生成もレビューも楽をできて良いです。
=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
=== Stack / VSS で 1 号機と 2 号機のポートを比較 ===
ラボの機器で 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 ?
ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。
ip access-list extended <名前> など、任意の文字列を使用できる箇所で、見間違える文字を使用してしまうケースです。
設計書でルール化して、どちらか片方しか使わなくするなどの対応を取ります。
=== show run | in <name> で、名前が正しく定義・適用されているか確認します ===
=== show run | in <name> で、名前が正しく定義・適用されているか確認します ===