IOS-XR: router reload 中の ISIS traffic drop シナリオについて

[tafujish]

• はじめに
• set-overload-bit config について - 前提知識 -
• router reload 中の traffic drop シナリオ - 概要 -
• router reload 中の traffic drop シナリオ - 詳細 -
• 解決策 -"Suppress Adjacency" bit -

 

はじめに

本ドキュメントでは IOS-XR router で ISIS を使用している環境において発生する可能性のある
router reload 中の traffic drop シナリオについて drop sequence や解決策等をまとめています。

set-overload-bit config について - 前提知識 -

前提として、 IOS-XR には overload bit が設定可能です。

router isis 10
 set-overload-bit on-startup 600
!    

 overload bit を on-startup オプションと共に有効にすることで、設定値の間(上記例だと 600 秒の間) reload router を介して routing しないよう設定することができます。
たとえば以下のような構成の場合、RT2 に set-overload-bit on-startup 600 を設定することで RT2 が reload し起動している間は traffic が RT2 を経由しないよう、600 秒間 RT2 が送信する LSP に overload-bit を set するような動作となります。

router reload 中の traffic drop シナリオ - 概要 - 

しかしながら overload bit を設定しているにもかかわらず router reload 中に traffic が drop してしまうことが報告されています。drop が確認されるまでの流れは以下となります。構成については上記の図を参照してください。

0. RT2 には set-overload-bit on-startup 600 設定済、各 router には Segment-Routing / ISIS 設定済
1. traffic は RT1 > RT2 > RT3 を経由し流れている
2. RT2 を reload
3. traffic が RT1 > RT2 > RT3 から RT1 > RT4 > RT3 に failover する想定
4. traffic failover 後 RT2 で traffic drop が数秒発生

RP/0/RSP0/CPU0:RT-02#show drops all location all
show controller np counters:
[np:NP0] RSV_DROP_SRTE_LEAF_NO_MATCH: 18253

router reload 中の traffic drop シナリオ - 詳細 - 

overload bit を設定しているにもかかわらず発生してしまう drop の詳細について以下に記載します。

0. RT2 が起動し RT2 上の ISIS process も起動
1. RT1 - RT2 間で adjacency 確立
2. RT1 は RT2 の古い LSP をもとに SPF 実行(RT1 は reload 前の RT2 LSP を保持している)
3. RT1 から見てRT2 は best path となる
4. RT2 で ISIS/RIB が準備できていないため、RT2 で drop が発生してしまう

5. RT2 は sequence0 で LSP を overload bit を set して RT1 に送信する
6. RT1 は RT2 から受信した sequence0 LSP を無視する(RT1 が保持している古い LSP の方が新しく見えるため)
7. RT1 は古い RT2 の LSP を sequenceX で送信する
8. RT2 は受け取った LSP の sequence をインクリメント(X+1)し、overload bit を set して RT1 に送信する
9. RT1 は best path 再計算、RT1 から見て RT4 が best path となる
  

解決策  - "Suppress Adjacency" bit -

上記の drop sequence については ISIS の仕様によるものであり、RFC5306 によって対処され
"Suppress Adjacency" bit が 7.0.1 より導入されました。
"Suppress Adjacency" bit については以下の資料を参考にしてください。
なお、IOS XR router では "Suppress Adjacency" bit は常に有効であり、configurable なものではありません。

Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 7.0.x
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-0/routing/configuration/guid...

IS-IS Restart Signaling Support

The IS-IS Restart Signaling Support feature enables a restarting router to signal to its neighbors that it is restarting. This signaling allows neighboring routers to reestablish their adjacencies without going through the down state. At the same time, the neighboring routers initiate the synchronization of the database.

When an IS-IS router restarts, there is a temporary disruption of routing due to events in both the restarting router and the neighbors of the restarting router. The router that has restarted computes its own routes before it synchronizes the database with its neighbors.

The restarting router sends Suppress Adjacency (SA) advertisement toward the neighbor. The restarting router sends Intermediate-to-Intermediate Hello (IIH) messages to its neighbor to suppress the advertisement of the adjacency until the router is able to propagate newer versions of LSPs. The neighbor continues to suppress the advertisement of adjacency until it receives the SA bit clear message.

The IS-IS Restart Signaling Support conforms to the specifications detailed in RFC 5306.

RFC5306

https://datatracker.ietf.org/doc/html/rfc5306

3.2.2. Use of the SA Bit

The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs.

A router that is starting has no maintained forwarding function state.
This may or may not be the first time the router has started.
If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network.
These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router.
This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers.
The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations.

When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs.
Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed.
If the adjacency transitions to the "UP" state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received.

[tafujish]

 

はじめに

本ドキュメントでは IOS-XR router で ISIS を使用している環境において発生する可能性のある
router reload 中の traffic drop シナリオについて drop sequence や解決策等をまとめています。

set-overload-bit config について - 前提知識 -

前提として、 IOS-XR には overload bit が設定可能です。

router isis 10
 set-overload-bit on-startup 600
!    

 overload bit を on-startup オプションと共に有効にすることで、設定値の間(上記例だと 600 秒の間) reload router を介して routing しないよう設定することができます。
たとえば以下のような構成の場合、RT2 に set-overload-bit on-startup 600 を設定することで RT2 が reload し起動している間は traffic が RT2 を経由しないよう、600 秒間 RT2 が送信する LSP に overload-bit を set するような動作となります。

router reload 中の traffic drop シナリオ - 概要 - 

しかしながら overload bit を設定しているにもかかわらず router reload 中に traffic が drop してしまうことが報告されています。drop が確認されるまでの流れは以下となります。構成については上記の図を参照してください。

0. RT2 には set-overload-bit on-startup 600 設定済、各 router には Segment-Routing / ISIS 設定済
1. traffic は RT1 > RT2 > RT3 を経由し流れている
2. RT2 を reload
3. traffic が RT1 > RT2 > RT3 から RT1 > RT4 > RT3 に failover する想定
4. traffic failover 後 RT2 で traffic drop が数秒発生

RP/0/RSP0/CPU0:RT-02#show drops all location all
show controller np counters:
[np:NP0] RSV_DROP_SRTE_LEAF_NO_MATCH: 18253

router reload 中の traffic drop シナリオ - 詳細 - 

overload bit を設定しているにもかかわらず発生してしまう drop の詳細について以下に記載します。

0. RT2 が起動し RT2 上の ISIS process も起動
1. RT1 - RT2 間で adjacency 確立
2. RT1 は RT2 の古い LSP をもとに SPF 実行(RT1 は reload 前の RT2 LSP を保持している)
3. RT1 から見てRT2 は best path となる
4. RT2 で ISIS/RIB が準備できていないため、RT2 で drop が発生してしまう

5. RT2 は sequence0 で LSP を overload bit を set して RT1 に送信する
6. RT1 は RT2 から受信した sequence0 LSP を無視する(RT1 が保持している古い LSP の方が新しく見えるため)
7. RT1 は古い RT2 の LSP を sequenceX で送信する
8. RT2 は受け取った LSP の sequence をインクリメント(X+1)し、overload bit を set して RT1 に送信する
9. RT1 は best path 再計算、RT1 から見て RT4 が best path となる
  

解決策  - "Suppress Adjacency" bit -

上記の drop sequence については ISIS の仕様によるものであり、RFC5306 によって対処され
"Suppress Adjacency" bit が 7.0.1 より導入されました。
"Suppress Adjacency" bit については以下の資料を参考にしてください。
なお、IOS XR router では "Suppress Adjacency" bit は常に有効であり、configurable なものではありません。

Routing Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 7.0.x
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-0/routing/configuration/guid...

IS-IS Restart Signaling Support

The IS-IS Restart Signaling Support feature enables a restarting router to signal to its neighbors that it is restarting. This signaling allows neighboring routers to reestablish their adjacencies without going through the down state. At the same time, the neighboring routers initiate the synchronization of the database.

When an IS-IS router restarts, there is a temporary disruption of routing due to events in both the restarting router and the neighbors of the restarting router. The router that has restarted computes its own routes before it synchronizes the database with its neighbors.

The restarting router sends Suppress Adjacency (SA) advertisement toward the neighbor. The restarting router sends Intermediate-to-Intermediate Hello (IIH) messages to its neighbor to suppress the advertisement of the adjacency until the router is able to propagate newer versions of LSPs. The neighbor continues to suppress the advertisement of adjacency until it receives the SA bit clear message.

The IS-IS Restart Signaling Support conforms to the specifications detailed in RFC 5306.

RFC5306

https://datatracker.ietf.org/doc/html/rfc5306

3.2.2. Use of the SA Bit

The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs.

A router that is starting has no maintained forwarding function state.
This may or may not be the first time the router has started.
If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network.
These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router.
This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers.
The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations.

When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs.
Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed.
If the adjacency transitions to the "UP" state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received.