「2024-08-28 プロトコル別 断時間チューニング」の版間の差分

提供：hkatou_Lab
ナビゲーションに移動 検索に移動
ビジュアルウィキテキスト
ページの作成:「 == Cisco == === OSPF === {| class="wikitable" |+router ospf <process_id> !カテゴリ !デフォルト !デフォルト設定 !変更値 !備考 |- |NSF Helper |Enable…」
 
編集の要約なし
 
(同じ利用者による、間の31版が非表示)
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>
9行目: 184行目:
!デフォルト設定
!デフォルト設定
!変更値
!変更値
!確認コマンド
!備考
!備考
|-
|-
16行目: 192行目:
nsf ietf helper
nsf ietf helper
| -
| -
|隣接 NSF ルータがフェイルオーバーした際、自ルータが FIB を保持する
|show ip ospf
 
 
IETF NSF helper support enabled
 
Cisco NSF helper support enabled
|隣接 NSF ルータが SSO フェイルオーバーした際、'''自ルータが FIB を保持'''する
|-
|-
|NSF
|NSF
22行目: 204行目:
| -
| -
|nsf
|nsf
|show ip ospf
Non-Stop Forwarding enabled
|自ルータが SSO フェイルオーバーした際、
|自ルータが SSO フェイルオーバーした際、
隣接ルータで OSPF が Down しても FIB を保持してもらう
'''隣接ルータで''' OSPF が Down しても '''FIB を保持してもらう'''
|-
|-
|NSR
|NSR
29行目: 215行目:
| -
| -
|nsr
|nsr
|実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い
|show ip ospf
常時 OSPF プロセスの状態を SSO Active と Standby で同期する
 
 
Non-Stop Routing enabled
|常時 OSPF プロセスの状態を SSO Active と Standby で同期する
実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い
自ルータが SSO フェイルオーバーした際、隣接ルータに影響を与えない
 
歴史的には NSF のほうが先に実装されている + IETF 標準であるため、NSF のほうが不具合が少なそう
|-
|BGP
|Disable
| -
|max-metric router-lsa on-startup wait-for-bgp
|show ip ospf


自ルータが SSO フェイルオーバーした際、


隣接ルータに影響を与えない
    Condition: on startup while BGP is converging, State: inactive
|再起動後、BGP の経路を受信し終わるまで、LSA のメトリックを最大にして、OSPF でトラフィックを処理しない
フルルートのように収束に時間がかかる環境で有効
|-
|-
| rowspan="3" |timers
| rowspan="3" |timers
|Enable
|Enable
|timers throttle spf  5000 10000 10000
|timers throttle spf  5000 10000 10000
|timers throttle spf 10 100 5000
 
 
Cisco IOS XE Everest 16.5.1b 以降
 
timers throttle spf 50 200 5000
|timers throttle spf '''10 100 5000'''
|show ip ospf
 
 
Initial SPF schedule delay 10 msecs
 
Minimum hold time between two consecutive SPFs 100 msecs
 
Maximum wait time between two consecutive SPFs 5000 msecs
|単位 msec
|単位 msec
1:SPF 遅延
1:SPF 遅延
46行目: 259行目:


3:最大遅延
3:最大遅延
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] でタイマーが高速化された
* OSPF を設定すると、タイマーが Optimize された旨のメッセージが出力される
|-
|-
|Enable
|Enable
|timers throttle lsa 0 5000 5000
|timers throttle lsa 0 5000 5000
|timers throttle lsa 10 100 5000
 
 
Cisco IOS XE Everest 16.5.1b 以降
 
timers throttle lsa 50 200 5000
|timers throttle lsa '''10 100 5000'''
|show ip ospf
 
 
Initial LSA throttle delay 10 msecs
 
Minimum hold time for LSA throttle 100 msecs
 
Maximum wait time for LSA throttle 5000 msecs
|単位 msec
|単位 msec
1 : 最初の LSA 生成遅延
1 : 最初の LSA 生成遅延
56行目: 291行目:


3 : 最大 LSA 生成遅延
3 : 最大 LSA 生成遅延
OSPF はリンクダウン時に 6 秒程度の断時間が発生するが、これは最初の 5000msec の時間による
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] でタイマーが高速化された
|-
|-
|Enable
|Enable
|timers lsa arrival 1000
|timers lsa arrival 1000
|timers lsa arrival 80
Cisco IOS XE Everest 16.5.1b 以降
 
timers lsa arrival 100
|timers lsa arrival '''80'''
|show ip ospf
 
 
Minimum LSA arrival 80 msecs
|単位 msec
|単位 msec
LSA の最小受信間隔
LSA の最小受信間隔
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] でタイマーが高速化された
|}
|}
<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"
|+router bgp <AS_Number>
!カテゴリ
!デフォルト
!デフォルト設定
!変更値
!確認コマンド
!備考
|-
|NSF
|Disable
|  -
|bgp graceful-restart
|show ip bgp neighbors <Peer_IP>
Graceful Restart Capabilty:advertised and received
|自ルータが SSO フェイルオーバーした際、隣接ルータで BGP が Down しても FIB を保持してもらう
|-
|NSR
|Disable
|  -
|bgp graceful-restart
bgp sso route-refresh-enable
iBGP / eBGP :  neighbor <BGP_Peer_IP> ha-mode sso
|show ip bgp neighbors <Peer_IP>
  SSO is enabled
|実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い
常時 BGP プロセスの状態を SSO Active と Standby で同期する
自ルータが SSO フェイルオーバーした際、隣接ルータに影響を与えない
歴史的には NSF のほうが先に実装されている + IETF 標準であるため、NSF のほうが不具合が少なそう
|-
| rowspan="3" |timers
|Enable
|bgp update-delay 120
|bgp update-delay 1
|  -
|1 つ目のピアとセッションを確立したあと、最適経路選択・経路通知を遅延させる時間
ただし、すべてのピアが Up した際は、最適経路選択・経路通知を行う
SSO かつ VSS などのクラスタリング系技術を使っており、かつ NSF / NSR を使用しておらず、論理ルータが 1 台のみの場合に使用すると、再起動後のトラフィック断を減らすことが可能
* Ex) VSS で SSO フェイルオーバーし、再起動するまで 1 つのピアが Down しつづける時
もともとフルルートで収束に時間がかかることから動作しているタイマーであるため、フルルートの環境には向いていない
|-
|Enable
|bgp aggregate-timer 30
|bgp aggregate-timer 0
|  -
|0 の場合、集約ルートの広報を即時行う
有効な場合、タイマーの間サブネットルートを広報する
対向側ピアでサブネットルートをフィルタリングしている場合に有効と思われる
復旧にかかる時間を短縮可能
|-
|Enable
|timers bgp 60 180
|timers bgp 10 30
|show ip bgp neighbors
  Last read 00:00:01, last write 00:00:09, hold time is 30, keepalive interval is 10 seconds
|キープアライブタイマーを 60 -> 10 秒、
ホールドダウンタイマーを 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)
|Disable
|  -
|bgp additional-paths select all
bgp additional-paths send receive
neighbor <Peer_IP> additional-paths send receive
|show ip bgp neighbors
  Additional Paths send capability: advertised
  Additional Paths receive capability: advertised
|バックアップ BGP ルートを RIB に保持することで、アクティブな FIB ルートが削除された際、すぐに切り替えられる機能
* EIGRP のフィージブル サクセサと類似している
特に無効時のフルルート環境はルートを受信し終わるまで、ルート未受信の宛先トラフィックがダウンし続けてしまう
有効にすることで即時に FIB を切り替えられ、断時間を大幅に短くできるため、有効な機能といえる
有効時にピアが Down / Up するため、メンテナンス時間が必要
また、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>
|}
==== Stack ====
{| class="wikitable"
!カテゴリ
!デフォルト
!デフォルト設定
!変更値
!確認コマンド
!備考
|-
|stack-mac
|Disable
| -
|[https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9300/software/release/17-3/command_reference/b_173_9300_cr/stack_manager_and_high_availability_commands.html#wp3566399843 stack-mac persistent timer 0]
|[https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9300/software/release/17-3/command_reference/b_173_9300_cr/stack_manager_and_high_availability_commands.html#wp3647919377 show switch]
Mac persistency wait time: Indefinite
|MAC アドレスを使用するプロトコル・機能の、再収束を無くします
* STP ブリッジ ID
* [https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9300/software/release/16-6/configuration_guide/b_166_lyr2_lyr3_9300_cg/b_166_lyr2_lyr3_9300_cg_chapter_011.html#con_1342634 LACP / PAgP] <ref>[https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9300/software/release/16-6/configuration_guide/b_166_lyr2_lyr3_9300_cg/b_166_lyr2_lyr3_9300_cg_chapter_011.html#concept_F06AB167EE3B4A16AA158999901757A5 デバイス スタックおよび LACP]
LACP の場合、システム ID は、アクティブ デバイスから取得したスタック MAC アドレスが使用されます。アクティブ デバイスに障害が発生したり、スタックを離れ、スタンバイ デバイスが新しいアクティブ デバイスが変更になっても、LACP システム ID は変更されません。デフォルトでは、LACP 設定はアクティブ デバイスの変更後も影響を受けません。</ref> <ref>[https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9300/software/release/17-3/command_reference/b_173_9300_cr/stack_manager_and_high_availability_commands.html#wp3566399843 stack-mac persistent timer]
'''（注）  '''PAgP フラップを回避するには、'''stack-mac persistent timer 0''' を使用してスタック MAC 永続待機タイマーを無期限に設定する必要があります。</ref>
* SVI <ref>'''[https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9300/software/release/17-3/command_reference/b_173_9300_cr/stack_manager_and_high_availability_commands.html#wp3566399843 stack-mac persistent timer]'''
'''（注）''' スタック MAC アドレスを変更しない場合、レイヤ 3 インターフェイスのフラップが発生しません。</ref>
未設定の場合は、筐体切替時に Active 機の MAC を Standby 機で引き継がないため、再収束が発生し断時間となります
|}
=== 用語解説 ===
==== [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 が両系でダウンするため、十数秒単位でトラフィック断が発生する
=== リファレンス ===
[https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/211432-Change-of-Default-OSPF-and-IS-IS-SPF-and.html Change of Default OSPF and IS-IS SPF and Flooding Timers and iSPF Removal]
[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 ==
set interfaces <int_id> hold-time up <milliseconds> down <milliseconds>
set protocols ospf overload timeout <seconds>
set protocols ospf3 overload timeout <seconds>
* BGP が未収束の状態で、OSPF でルーティングされることを防ぐ
* オーバーロード = 過負荷に見せる
== 更新履歴 ==
2021/10/17 : 初版作成
2023/09/14 : link debounce , carrier-delay を追加
2024/08/28: stack-mac persistent timer 0 を追加
== 引用 ==
{{#seo:
|title={{#if: {{{page_title|}}} | {{{page_title}}} | 2021-10-17 プロトコル別 断時間チューニング}}
|titlemode={{{title_mode|}}}
|keywords={{{keywords|}}}
|description={{{description|}}}
}}
[[カテゴリ:チューニング]]

2024年9月12日 (木) 15:37時点における最新版

君はこのドキュメントを参考にしてもいいし、しなくてもいい。

Cisco

レイヤ 1

link debounce タイマー

Catalyst 9000
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
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 とファイバーで遅延時間が異なる


なお無効であっても遅延時間はデフォルト値が存在する

Nexus 9000
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
link debouce Disable 0 ms 0 - 5000ms show interface debounce ハードウェアでリンクダウン検出を行う時間を遅延させる設定

0 で無効化

link-up オプションで up 時も遅延させることが可能

レイヤ 2

LAN Switching

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 のポートに設定しておくのを忘れがち

switchport nonegotiate Disable switchport mode dynamic auto - show interfaces switchport Administrative Mode Dynamic がデフォルト設定で、DTP によるネゴシエートが行われる
  • リンクダウン冗長試験からのリンクアップ復旧時に、DTP ネゴシエーションの時間復旧が遅れる


短くしたい場合は switchport nonegotiate を設定する

レイヤ 3

carrier-delay タイマー

IOS-XE
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
carrier-delay Disable 2 seconds ルータ : [up | down] {seconds | msec milliseconds}

スイッチ : {seconds | msec milliseconds}


Cat3850 の場合

seconds : <0-60>

msec : <0-1000>

? リンクダウンをソフトウェアが検知するまでの遅延時間を制御する


歴史的に IOS はルータで使用されており、当時の貧弱な CPU リソースを保護するため、リンク フラッピングによるルーティング プロトコルの切り替え・切り戻しの再計算に時間を確保する必要があった


ルータのみ up 時も設定可能

ISP 用途では、対向側の IX 事業者が光スイッチを切り替える際に、ローカル側の ISP で光の瞬断を検出させないように carrier-delay 値を大きくするケースが存在する [1]

IOS-XR
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
carrier-delay Disable 0 second { down milliseconds [ up milliseconds ] | up milliseconds [ down milliseconds ] }


msec : <0 ～ 65535 >

show interface IOS-XR は IOS と比較して新しい Network OS であり、CPU リソースが潤沢 + ルーティング プロトコルの収束を高速に行いたいため、carrier-delay のデフォルト値は 0 秒となっている
NX-OS (Nexus5000)
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
carrier-delay Disable 0 second ?? {delay-seconds | msec milliseconds}


seconds : <0-60>

msec : <0-1000>

show interface Vlan インターフェースで使用可能

OSPF

router ospf <process_id>
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
NSF Helper Enable nsf cisco helper

nsf ietf helper

- show ip ospf


IETF NSF helper support enabled

Cisco NSF helper support enabled

隣接 NSF ルータが SSO フェイルオーバーした際、自ルータが FIB を保持する
NSF Disable - nsf show ip ospf


Non-Stop Forwarding enabled

自ルータが SSO フェイルオーバーした際、

隣接ルータで OSPF が Down しても FIB を保持してもらう

NSR Disable - nsr show ip ospf


Non-Stop Routing enabled

常時 OSPF プロセスの状態を SSO Active と Standby で同期する

実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い 自ルータが SSO フェイルオーバーした際、隣接ルータに影響を与えない

歴史的には NSF のほうが先に実装されている + IETF 標準であるため、NSF のほうが不具合が少なそう

BGP Disable - max-metric router-lsa on-startup wait-for-bgp show ip ospf


    Condition: on startup while BGP is converging, State: inactive

再起動後、BGP の経路を受信し終わるまで、LSA のメトリックを最大にして、OSPF でトラフィックを処理しない

フルルートのように収束に時間がかかる環境で有効

timers Enable timers throttle spf 5000 10000 10000


Cisco IOS XE Everest 16.5.1b 以降

timers throttle spf 50 200 5000

timers throttle spf 10 100 5000 show ip ospf


Initial SPF schedule delay 10 msecs

Minimum hold time between two consecutive SPFs 100 msecs

Maximum wait time between two consecutive SPFs 5000 msecs

単位 msec

1:SPF 遅延

2:1つ目と2つ目の SPF 計算の間の遅延

3:最大遅延

Cisco Classic IOS の OSPF はリンクダウン時に 6 秒程度の断時間が発生するが、これは最初の 5000msec の SPF 遅延時間による

  • 昔の CPU で高速に収束させると、CPU 負荷が高かったため


IOS-XE 16.5.1b 以降は、Fast Convergence Default Optimize でタイマーが高速化された

  • OSPF を設定すると、タイマーが Optimize された旨のメッセージが出力される
Enable timers throttle lsa 0 5000 5000


Cisco IOS XE Everest 16.5.1b 以降

timers throttle lsa 50 200 5000

timers throttle lsa 10 100 5000 show ip ospf


Initial LSA throttle delay 10 msecs

Minimum hold time for LSA throttle 100 msecs

Maximum wait time for LSA throttle 5000 msecs

単位 msec

1 : 最初の LSA 生成遅延

2 : 最小 LSA 生成遅延

3 : 最大 LSA 生成遅延

OSPF はリンクダウン時に 6 秒程度の断時間が発生するが、これは最初の 5000msec の時間による


IOS-XE 16.5.1b 以降は、Fast Convergence Default Optimize でタイマーが高速化された

Enable timers lsa arrival 1000

Cisco IOS XE Everest 16.5.1b 以降

timers lsa arrival 100

timers lsa arrival 80 show ip ospf


Minimum LSA arrival 80 msecs

単位 msec

LSA の最小受信間隔


IOS-XE 16.5.1b 以降は、Fast Convergence Default Optimize でタイマーが高速化された


BGP

router bgp <AS_Number>
カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
NSF Disable - bgp graceful-restart show ip bgp neighbors <Peer_IP>


Graceful Restart Capabilty:advertised and received

自ルータが SSO フェイルオーバーした際、隣接ルータで BGP が Down しても FIB を保持してもらう
NSR Disable - bgp graceful-restart

bgp sso route-refresh-enable


iBGP / eBGP : neighbor <BGP_Peer_IP> ha-mode sso

show ip bgp neighbors <Peer_IP>


  SSO is enabled

実装難易度が高いため、低価格製品や IPv6 は対応していない場合が多い

常時 BGP プロセスの状態を SSO Active と Standby で同期する

自ルータが SSO フェイルオーバーした際、隣接ルータに影響を与えない


歴史的には NSF のほうが先に実装されている + IETF 標準であるため、NSF のほうが不具合が少なそう

timers Enable bgp update-delay 120 bgp update-delay 1 - 1 つ目のピアとセッションを確立したあと、最適経路選択・経路通知を遅延させる時間


ただし、すべてのピアが Up した際は、最適経路選択・経路通知を行う

SSO かつ VSS などのクラスタリング系技術を使っており、かつ NSF / NSR を使用しておらず、論理ルータが 1 台のみの場合に使用すると、再起動後のトラフィック断を減らすことが可能

  • Ex) VSS で SSO フェイルオーバーし、再起動するまで 1 つのピアが Down しつづける時


もともとフルルートで収束に時間がかかることから動作しているタイマーであるため、フルルートの環境には向いていない

Enable bgp aggregate-timer 30 bgp aggregate-timer 0 - 0 の場合、集約ルートの広報を即時行う


有効な場合、タイマーの間サブネットルートを広報する


対向側ピアでサブネットルートをフィルタリングしている場合に有効と思われる

復旧にかかる時間を短縮可能

Enable timers bgp 60 180 timers bgp 10 30 show ip bgp neighbors


  Last read 00:00:01, last write 00:00:09, hold time is 30, keepalive interval is 10 seconds

キープアライブタイマーを 60 -> 10 秒、

ホールドダウンタイマーを 180 -> 30 秒に変更する


eBGP フルルート環境だとここまで短縮している例は見た記憶が無い

  • フルルートの受信に数分 - 十数分程度はかかるため、BGP ピアが Flap するのは CPU 使用率の観点から避けたい


eBGP では 15 / 45 , 20 / 60 くらいが一般的と思われる

BGP Additional Paths (PIC-Edge) Disable - bgp additional-paths select all

bgp additional-paths send receive

neighbor <Peer_IP> additional-paths send receive

show ip bgp neighbors


  Additional Paths send capability: advertised

  Additional Paths receive capability: advertised

バックアップ BGP ルートを RIB に保持することで、アクティブな FIB ルートが削除された際、すぐに切り替えられる機能
  • EIGRP のフィージブル サクセサと類似している



特に無効時のフルルート環境はルートを受信し終わるまで、ルート未受信の宛先トラフィックがダウンし続けてしまう

有効にすることで即時に FIB を切り替えられ、断時間を大幅に短くできるため、有効な機能といえる


有効時にピアが Down / Up するため、メンテナンス時間が必要


また、RIB の保持にメモリを使用するため要注意

  • FIB のルート数は足りているのに、RIB の消費メモリ量が多くなりすぎて、BGP が Flap する事例があった
  • 発生してしまった場合は、soft-reconfiguration inbound とともに Add-path は削除すると良い


スイッチではあまり対応していない

  • Catalyst 9500 では非サポート [2]
  • Catalyst 9500H では 16.8.1a- サポート [3]

Stack

カテゴリ デフォルト デフォルト設定 変更値 確認コマンド 備考
stack-mac Disable - stack-mac persistent timer 0 show switch


Mac persistency wait time: Indefinite

MAC アドレスを使用するプロトコル・機能の、再収束を無くします

未設定の場合は、筐体切替時に Active 機の MAC を Standby 機で引き継がないため、再収束が発生し断時間となります

用語解説

SSO = Stateful Switch Over.

ルータのルートプロセッサや、スイッチのスーパーバイザエンジンを、なるべく断時間が短くなるように切り替える仕組みのこと。

よくある勘違いとして、以下がある。

  • 勘違い : SSO + NSF 切替時は OSPF や BGP が隣接ルータでダウンしない (実際にはダウンする)
    • ネイバー・ピア ダウンしても NSF Helper で転送させる、NSR でダウンさせないなどの対処が必要
    • NSF はネイバー・ピア ダウンしても、FIB を保持する技術
  • 勘違い : HSRP も SSO により短時間で切り替えられる
    • 機種によるが、SSO Aware HSRP 機能が必要
    • ない場合は HSRP が両系でダウンするため、十数秒単位でトラフィック断が発生する

リファレンス

Change of Default OSPF and IS-IS SPF and Flooding Timers and iSPF Removal

BGP の追加パス

IGP/LDP/BGP Convergence Tuning (IOS/IOS-XE)



Juniper

set interfaces <int_id> hold-time up <milliseconds> down <milliseconds>

set protocols ospf overload timeout <seconds>

set protocols ospf3 overload timeout <seconds>

  • BGP が未収束の状態で、OSPF でルーティングされることを防ぐ
  • オーバーロード = 過負荷に見せる

更新履歴

2021/10/17 : 初版作成

2023/09/14 : link debounce , carrier-delay を追加

2024/08/28: stack-mac persistent timer 0 を追加

引用

  1. ↑ JANOG26 IXPセッション ～頑張ってトラフィック支えてます～ 光スイッチによる可用性向上 顧客間トラヒックへの影響の極小化 『顧客ルータがLink断検知しない』 ⇒ BGP peer 断しない 顧客ルータでLink断検知のconfig調整が必要な場合あり
  2. ↑ Unsupported Features: Cisco Catalyst 9500 Series Switches Border Gateway Protocol (BGP) Additional Paths
  3. ↑ 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.
  4. ↑ デバイス スタックおよび LACP LACP の場合、システム ID は、アクティブ デバイスから取得したスタック MAC アドレスが使用されます。アクティブ デバイスに障害が発生したり、スタックを離れ、スタンバイ デバイスが新しいアクティブ デバイスが変更になっても、LACP システム ID は変更されません。デフォルトでは、LACP 設定はアクティブ デバイスの変更後も影響を受けません。
  5. ↑ stack-mac persistent timer （注）  PAgP フラップを回避するには、stack-mac persistent timer 0 を使用してスタック MAC 永続待機タイマーを無期限に設定する必要があります。
  6. ↑ stack-mac persistent timer （注） スタック MAC アドレスを変更しない場合、レイヤ 3 インターフェイスのフラップが発生しません。
「http://hkatou.net/index.php?title=2024-08-28_プロトコル別_断時間チューニング&oldid=2242」から取得