差分

ナビゲーションに移動 検索に移動
1行目: 1行目:  +
君はこのドキュメントを[https://w.atwiki.jp/yougosq/pages/4624.html 参考にしてもいいし、しなくてもいい]。
    
== Cisco ==
 
== Cisco ==
   −
=== OSPF ===
+
=== レイヤ 1 ===
 +
 
 +
==== link debounce タイマー ====
 +
{| class="wikitable"
 +
|+Catalyst 9000
 +
!カテゴリ
 +
!デフォルト
 +
!デフォルト設定
 +
!変更値
 +
!確認コマンド
 +
!備考
 +
|-
 +
|[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-8/configuration_guide/int_hw/b_178_int_and_hw_9500_cg/configuring_link_debounce_timer.html#Cisco_Task.dita_bd3b1a49-1679-41a4-ba69-237371034f81 link debouce]
 +
|Disable
 +
|240 ms
 +
| 120 - 1200ms まで 120 刻み
 +
|show interface debounce
 +
|ハードウェアでリンクダウン検出を行う時間を遅延させる設定
 +
Catalyst 9500 では IOS-XE 17.6.1- で対応
 +
 
 +
Catalyst 9600 では IOS-XE 17.3.3- で対応
 +
 
 +
 
 +
RJ-45 とファイバーで遅延時間が異なる
 +
 
 +
 
 +
なお無効であっても遅延時間自体は存在する
 +
|}
 +
{| class="wikitable"
 +
|+Nexus 9000
 +
!カテゴリ
 +
!デフォルト
 +
!デフォルト設定
 +
!変更値
 +
!確認コマンド
 +
!備考
 +
|-
 +
|[https://www.cisco.com/c/ja_jp/td/docs/switches/datacenter/nexus9000/sw/93x/interfaces/configuration/guide/b-cisco-nexus-9000-nx-os-interfaces-configuration-guide-93x/b-cisco-nexus-9000-nx-os-interfaces-configuration-guide-93x_chapter_01110.html#task_6414C84081D3492E9817031E9362DEC1 link debouce]
 +
|Disable
 +
|0 ms
 +
| 0 - 5000ms
 +
|show interface debounce
 +
|ハードウェアでリンクダウン検出を行う時間を遅延させる設定
 +
0 で無効化
 +
 
 +
link-up オプションで up 時も遅延させることが可能
 +
|}
 +
 
 +
=== レイヤ 2 ===
 +
==== LAN Switching ====
 +
{| class="wikitable"
 +
|+Catalyst
 +
!カテゴリ
 +
!デフォルト
 +
!デフォルト設定
 +
!変更値
 +
!確認コマンド
 +
!備考
 +
|-
 +
|spanning-tree portfast [trunk]
 +
 
 +
 
 +
spanning-tree portfast edge [trunk]
 +
|Disable
 +
|no spanning-tree portfast [trunk]
 +
 
 +
 
 +
spanning-tree portfast edge [trunk]
 +
|  -
 +
|show spanning-tree
 +
|断時間を測定する ping ホストを収容するポートで portfast 未設定 + RSTP の場合、BPDU Proposal を送信して、対向側の Agreement 送信を数十秒待機するため、断時間が延びてしまう
 +
 
 +
 
 +
 
 +
 
 +
PC など RSTP Agreement を返さない機器を収容するポートに、portfast を設定する
 +
 
 +
冗長試験では ping 端末や IXIA のポートに設定しておくのを忘れがち
 +
|-
 +
|[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/3se/consolidated_guide/command_reference/b_consolidated_3650_3se_cr/b_consolidated_3650_3se_cr_chapter_0100.html#wp2980123731 switchport nonegotiate]
 +
|Disable
 +
|switchport mode dynamic auto
 +
| -
 +
|show interfaces switchport
 +
|Administrative Mode Dynamic がデフォルト設定で、DTP によるネゴシエートが行われる
 +
 
 +
* リンクダウン冗長試験からのリンクアップ復旧時に、DTP ネゴシエーションの時間復旧が遅れる
 +
 
 +
 
 +
短くしたい場合は switchport nonegotiate を設定する
 +
|}
 +
 
 +
=== レイヤ 3 ===
 +
 
 +
==== carrier-delay タイマー ====
 +
{| class="wikitable"
 +
|+IOS-XE
 +
!カテゴリ
 +
!デフォルト
 +
!デフォルト設定
 +
!変更値
 +
!確認コマンド
 +
!備考
 +
|-
 +
|[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-cr-book/ir-c1.html#wp2997457714 carrier-delay]
 +
|Disable
 +
|2 seconds
 +
| <nowiki>ルータ : [up | down] {</nowiki><var>seconds</var><nowiki> | msec </nowiki><var>milliseconds</var>}
 +
 
 +
スイッチ : {<var>seconds</var> | msec <var>milliseconds</var>}
 +
 
 +
 
 +
Cat3850 の場合
 +
 
 +
seconds : <0-60>
 +
 
 +
msec : <0-1000>
 +
|?
 +
|リンクダウンをソフトウェアが検知するまでの遅延時間を制御する
 +
 
 +
 
 +
歴史的に IOS はルータで使用されており、当時の貧弱な CPU リソースを保護するため、リンク フラッピングによるルーティング プロトコルの切り替え・切り戻しの再計算に時間を確保する必要があった
 +
 
 +
 
 +
 
 +
ルータのみ up 時も設定可能
 +
 
 +
ISP 用途では、対向側の IX 事業者が光スイッチを切り替える際に、ローカル側の ISP で光の瞬断を検出させないように carrier-delay 値を大きくするケースが存在する <ref>[https://www.janog.gr.jp/meeting/janog26/doc/post-ixp-touda.pdf JANOG26 IXPセッション ~頑張ってトラフィック支えてます~]
 +
 
 +
光スイッチによる可用性向上
 +
 
 +
顧客間トラヒックへの影響の極小化 『顧客ルータがLink断検知しない』 ⇒ BGP peer 断しない 顧客ルータでLink断検知のconfig調整が必要な場合あり</ref>
 +
|}
 +
{| class="wikitable"
 +
|+IOS-XR
 +
!カテゴリ
 +
!デフォルト
 +
!デフォルト設定
 +
!変更値
 +
!確認コマンド
 +
!備考
 +
|-
 +
|[https://www.cisco.com/c/ja_jp/td/docs/rt/servprovideredgert/asr9000aggregationservsrt/cr/040/b_interfaces_cr43xasr9k/b_interfaces_cr43xasr9k_chapter_011.html#wp2431295976 carrier-delay]
 +
|Disable
 +
|0 second
 +
| { down <var>milliseconds</var> [ up <var>milliseconds</var><nowiki> ] | up </nowiki><var>milliseconds</var> [ down <var>milliseconds</var> ] }
 +
 
 +
 
 +
msec : <0 ~ 65535 >
 +
|show interface
 +
|IOS-XR は IOS と比較して新しい Network OS であり、CPU リソースが潤沢 + ルーティング プロトコルの収束を高速に行いたいため、carrier-delay のデフォルト値は 0 秒となっている
 +
|}
 +
{| class="wikitable"
 +
|+NX-OS (Nexus5000)
 +
!カテゴリ
 +
!デフォルト
 +
!デフォルト設定
 +
!変更値
 +
!確認コマンド
 +
!備考
 +
|-
 +
|[https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/interfaces/command/cisco_nexus_5000_interfaces_command_ref/c_commands.html#wp3379326320 carrier-delay]
 +
|Disable
 +
|0 second ??
 +
| {<var>delay-seconds</var><nowiki> | msec </nowiki><var>milliseconds</var>}
 +
 
 +
 
 +
seconds : <0-60>
 +
 
 +
msec : <0-1000>
 +
|show interface
 +
|Vlan インターフェースで使用可能
 +
|}
 +
 
 +
==== OSPF ====
 
{| class="wikitable"
 
{| class="wikitable"
 
|+router ospf <process_id>
 
|+router ospf <process_id>
23行目: 198行目:     
Cisco NSF helper support enabled
 
Cisco NSF helper support enabled
|隣接 NSF ルータがフェイルオーバーした際、自ルータが FIB を保持する
+
|隣接 NSF ルータが SSO フェイルオーバーした際、'''自ルータが FIB を保持'''する
 
|-
 
|-
 
|NSF
 
|NSF
34行目: 209行目:  
Non-Stop Forwarding enabled
 
Non-Stop Forwarding enabled
 
|自ルータが SSO フェイルオーバーした際、
 
|自ルータが SSO フェイルオーバーした際、
隣接ルータで OSPF が Down しても FIB を保持してもらう
+
'''隣接ルータで''' OSPF が Down しても '''FIB を保持してもらう'''
 
|-
 
|-
 
|NSR
 
|NSR
44行目: 219行目:     
Non-Stop Routing enabled
 
Non-Stop Routing enabled
|実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い
+
|常時 OSPF プロセスの状態を SSO Active と Standby で同期する
常時 OSPF プロセスの状態を SSO Active と Standby で同期する
+
実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い
 
+
自ルータが SSO フェイルオーバーした際、隣接ルータに影響を与えない
自ルータが SSO フェイルオーバーした際、
  −
 
  −
隣接ルータに影響を与えない
  −
 
      
歴史的には NSF のほうが先に実装されている + IETF 標準であるため、NSF のほうが不具合が少なそう
 
歴史的には NSF のほうが先に実装されている + IETF 標準であるため、NSF のほうが不具合が少なそう
63行目: 234行目:  
    Condition: on startup while BGP is converging, State: inactive
 
    Condition: on startup while BGP is converging, State: inactive
 
|再起動後、BGP の経路を受信し終わるまで、LSA のメトリックを最大にして、OSPF でトラフィックを処理しない
 
|再起動後、BGP の経路を受信し終わるまで、LSA のメトリックを最大にして、OSPF でトラフィックを処理しない
 +
フルルートのように収束に時間がかかる環境で有効
 
|-
 
|-
 
| rowspan="3" |timers
 
| rowspan="3" |timers
88行目: 260行目:  
3:最大遅延
 
3:最大遅延
   −
OSPF はリンクダウン時に 6 秒程度の断時間が発生するが、これは最初の 5000msec の時間による
+
Cisco Classic IOS の OSPF はリンクダウン時に 6 秒程度の断時間が発生するが、これは最初の 5000msec の SPF 遅延時間による
 +
 
 +
* 昔の CPU で高速に収束させると、CPU 負荷が高かったため
       
IOS-XE 16.5.1b 以降は、[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-16-8/segrt-xe-16-8-book/sr-fast-convergence-default-optimize.pdf Fast Convergence Default Optimize] でタイマーが高速化された
 
IOS-XE 16.5.1b 以降は、[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-16-8/segrt-xe-16-8-book/sr-fast-convergence-default-optimize.pdf Fast Convergence Default Optimize] でタイマーが高速化された
 +
 +
* OSPF を設定すると、タイマーが Optimize された旨のメッセージが出力される
 
|-
 
|-
 
|Enable
 
|Enable
138行目: 314行目:  
|}
 
|}
   −
=== BGP ===
+
 
 +
<span></span><ins class="adsbygoogle" style="display:block; text-align:center;" data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-1930311742297749" data-ad-slot="5409634032"></ins><span></span><span></span>
 +
 
 +
==== BGP ====
 
{| class="wikitable"
 
{| class="wikitable"
 
|+router bgp <AS_Number>
 
|+router bgp <AS_Number>
184行目: 363行目:  
|bgp update-delay 120
 
|bgp update-delay 120
 
|bgp update-delay 1
 
|bgp update-delay 1
| -
+
| -
 
|1 つ目のピアとセッションを確立したあと、最適経路選択・経路通知を遅延させる時間
 
|1 つ目のピアとセッションを確立したあと、最適経路選択・経路通知を遅延させる時間
   190行目: 369行目:  
ただし、すべてのピアが Up した際は、最適経路選択・経路通知を行う
 
ただし、すべてのピアが Up した際は、最適経路選択・経路通知を行う
   −
SSO かつ VSS などのクラスタリング系技術で、論理ルータが 1 台のみの場合に使用し、再起動時のトラフィック断を減らすことが可能
+
SSO かつ VSS などのクラスタリング系技術を使っており、かつ NSF / NSR を使用しておらず、論理ルータが 1 台のみの場合に使用すると、再起動後のトラフィック断を減らすことが可能
 +
 
 +
* Ex) VSS で SSO フェイルオーバーし、再起動するまで 1 つのピアが Down しつづける時
      198行目: 379行目:  
|bgp aggregate-timer 30
 
|bgp aggregate-timer 30
 
|bgp aggregate-timer 0
 
|bgp aggregate-timer 0
| -
+
| -
 
|0 の場合、集約ルートの広報を即時行う
 
|0 の場合、集約ルートの広報を即時行う
   205行目: 386行目:       −
筆者の経験上、このパラメータは断時間とは関係がない
+
対向側ピアでサブネットルートをフィルタリングしている場合に有効と思われる
 
|-
 
|-
 
|Enable
 
|Enable
216行目: 397行目:  
|キープアライブタイマーを 60 -> 10 秒、
 
|キープアライブタイマーを 60 -> 10 秒、
 
ホールドダウンタイマーを 180 -> 30 秒に変更する
 
ホールドダウンタイマーを 180 -> 30 秒に変更する
 +
 +
 +
eBGP フルルート環境だとここまで短縮している例は見た記憶が無い
 +
 +
* フルルートの受信に数分 - 十数分程度はかかるため、BGP ピアが Flap するのは CPU 使用率の観点から避けたい
 +
 +
 +
eBGP では 15 / 45 , 20 / 60 くらいが一般的と思われる
 
|-
 
|-
 
|[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/bgp_additional_paths.pdf BGP Additional Paths] (PIC-Edge)
 
|[https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/bgp_additional_paths.pdf BGP Additional Paths] (PIC-Edge)
 
|Disable
 
|Disable
| -
+
| -
 
|bgp additional-paths select all
 
|bgp additional-paths select all
 
bgp additional-paths send receive
 
bgp additional-paths send receive
230行目: 419行目:     
  Additional Paths receive capability: advertised
 
  Additional Paths receive capability: advertised
|バックアップ BGP ルートを RIB に保持することで、アクティブな FIB ルートが削除された際、すぐに切り替えられる機能で、EIGRP のフィージブル サクセサと類似している
+
|バックアップ BGP ルートを RIB に保持することで、アクティブな FIB ルートが削除された際、すぐに切り替えられる機能
    +
* EIGRP のフィージブル サクセサと類似している
 +
 +
 +
 +
 +
 +
特に無効時のフルルート環境はルートを受信し終わるまで、ルート未受信の宛先トラフィックがダウンし続けてしまう
 +
 +
有効にすることで即時に FIB を切り替えられ、断時間を大幅に短くできるため、有効な機能といえる
   −
特にフルルート環境はルートを受信し終わるまで、ルート未受信の宛先トラフィックがダウンし続けるため、有効な機能といえる
        241行目: 438行目:  
また、RIB の保持にメモリを使用するため要注意
 
また、RIB の保持にメモリを使用するため要注意
    +
* FIB のルート数は足りているのに、RIB の消費メモリ量が多くなりすぎて、BGP が Flap する事例があった
 +
* 発生してしまった場合は、soft-reconfiguration inbound とともに Add-path は削除すると良い
   −
スイッチではほとんど対応していない
+
 
 +
スイッチではあまり対応していない
 +
 
 +
* Catalyst 9500 では非サポート <ref>[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-3/release_notes/ol-17-3-9500.html#concept_oz3_3j4_xkb__unsupp-9500 Unsupported Features: Cisco Catalyst 9500 Series Switches]
 +
 
 +
[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-3/release_notes/ol-17-3-9500.html#concept_oz3_3j4_xkb__unsupp-9500 Border Gateway Protocol (BGP) Additional Paths]</ref>
 +
* Catalyst 9500H では 16.8.1a- サポート  <ref>[https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-10/configuration_guide/rtng/b_1710_rtng_9500_cg/configuring_bgp_additional_paths.html#feature-history-bbgp-additional-paths Feature History for BGP Additional Paths]
 +
 
 +
Support for this feature was introduced only on the C9500-32C, C9500-32QC, C9500-48Y4C, and C9500-24Y4C models of the Cisco Catalyst 9500 Series Switches.</ref>
 
|}
 
|}
 +
 +
=== 用語解説 ===
 +
 +
==== [https://www.cisco.com/cisco/web/support/JP/docs/SW/CampusLANSWT-CoreDistribution/CAT6500SWT/CG/001/stateful_switchover.pdf SSO] = Stateful Switch Over. ====
 +
ルータのルートプロセッサや、スイッチのスーパーバイザエンジンを、なるべく断時間が短くなるように切り替える仕組みのこと。
 +
 +
よくある勘違いとして、以下がある。
 +
 +
* 勘違い : SSO + NSF 切替時は OSPF や BGP が隣接ルータでダウンしない (実際にはダウンする)
 +
** ネイバー・ピア ダウンしても NSF Helper で転送させる、NSR でダウンさせないなどの対処が必要
 +
** NSF はネイバー・ピア ダウンしても、FIB を保持する技術
 +
* 勘違い : HSRP も SSO により短時間で切り替えられる
 +
** 機種によるが、SSO Aware HSRP 機能が必要
 +
** ない場合は HSRP が両系でダウンするため、十数秒単位でトラフィック断が発生する
    
=== リファレンス ===
 
=== リファレンス ===
249行目: 470行目:     
[https://www.cisco.com/c/ja_jp/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16-10/irg-xe-16-10-book/irg-xe-16-10-book_chapter_01000001.html BGP の追加パス]
 
[https://www.cisco.com/c/ja_jp/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16-10/irg-xe-16-10-book/irg-xe-16-10-book_chapter_01000001.html BGP の追加パス]
 +
 +
[https://null.53bits.co.uk/index.php?page=ospf-ldp-bgp-convergence-tuning IGP/LDP/BGP Convergence Tuning (IOS/IOS-XE)]
 +
 +
 +
 +
 +
== Juniper ==
 +
hold-time up <milliseconds> down <milliseconds>
 +
 +
== 更新履歴 ==
 +
2021/10/17 初版作成
 +
 +
2023/09/14 link debounce , carrier-delay を追加
 +
 +
== 引用 ==
 +
{{#seo:
 +
|title={{#if: {{{page_title|}}} | {{{page_title}}} | 2021-10-17 プロトコル別 断時間チューニング}}
 +
|titlemode={{{title_mode|}}}
 +
|keywords={{{keywords|}}}
 +
|description={{{description|}}}
 +
}}
 +
[[カテゴリ:チューニング]]

案内メニュー