IOS-XR: RIB/FIB 等の転送情報に関するトラブルシューティングについて

ドキュメント

2015/02/25 - 01:31
1月 24th, 2015
User Badges:
  • Cisco Employee,


概要

本ドキュメントでは、IOS-XR が動作する Cisco ルータの、RIB/FIB 等の転送情報の確認方法について、解説をしています。
 

本ドキュメントをトラブルシューティングの参考にできるケースとしては、以下があげられます。

  • 経路変動を伴うイベント時に、想定外の packet の drop が見られる。
    • Routing Proocol のデータベースや、RIB/FIB の更新されたタイミングを確認し、どのタイミングでどの転送情報が足りなかったために、drop に至ったのかを確認します。
       
  • 特定の宛先アドレスに対して、疎通がとれない。
    • Routing Protocol のデータベースを確認するとともに、RIB や FIB においても、期待された転送情報が格納をされているかを確認します。
    • 一時的に疎通が取れない事象、でかつ発生収束に周期性がある場合は、RIB/FIB の更新タイミングについても合わせて着目します。

 

ルータ内部の転送情報と確認コマンドの対応

Routing Protocol 等によって学習された経路情報は、以下の流れでルータ内に伝播され、格納されます。
それぞれのポイントで、経路情報の詳細と、その経路がインストールされた時刻を確認します。

 

cef

 

 

サンプル構成における出力例
topology

Asr9001#1 は、Asr9001#2 に対して、Lo1 の経路を、OSPF にて広報しています。
その広報された経路について、ポイントごとに情報を確認していきます。

 

RIB
RP/0/RSP0/CPU0:ASR9001-2#show route 10.0.0.1

Routing entry for 10.0.0.1/32
  Known via "ospf test", distance 110, metric 2, type intra area
  Installed Jan 22 10:43:04.863 for 00:00:02
  Routing Descriptor Blocks
    192.168.0.1, from 172.16.0.1, via GigabitEthernet0/0/0/5
      Route metric is 2
  No advertising protos.

RP/0/RSP0/CPU0:ASR9001-2#show route 192.168.0.1

Routing entry for 192.168.0.0/24
  Known via "connected", distance 0, metric 0 (connected)
  Installed Jan 22 10:37:31.552 for 00:05:59
  Routing Descriptor Blocks
    directly connected, via GigabitEthernet0/0/0/5
      Route metric is 0
  Redist Advertisers:
    ospf test

RIB に格納されている 10.0.0.1 の経路情報について、上記出力より以下のことがわかります。

- OSPF (process test) にて学習している
- 経路をインストールした時間は Jan 22 10:43:04.863 である

- Next-Hop は 192.168.0.1 である
- そのソースは 172.16.0.1 (OSPF neighbor) である
- Gi 0/0/0/5を通じて学習している

経路情報のソース及び Next-Hop が想定された情報となっているか
また、インストール時間が想定外の時間となっていないかどうか、また短期間に何度も更新されていないかを確認します。

No advertising protos./Redis Advertisers の項目については、ルートの再配布とは関係なく、特定のconnected ルート等の local のルートが Routing protocol によって advertise されているかどうかを示しています。

同様の確認を、Next-hop アドレスについても行います。

宛先アドレスの解決に再帰的な look up を行うケースでは、宛先アドレスに到達するまでのすべてのアドレス情報の情報を確認することに留意してください。

FIB
RP/0/RSP0/CPU0:ASR9001-2#show cef 10.0.0.1

10.0.0.1/32, version 421, internal 0x4000001 0x0 (ptr 0x9dcc579c) [1], 0x0 (0x9d556a20), 0x0 (0x0)
 Updated Jan 22 10:43:04.864
 remote adjacency to GigabitEthernet0/0/0/5
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 192.168.0.1, GigabitEthernet0/0/0/5, 4 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0x9cf793e4 0x0]
    next hop 192.168.0.1
    remote adjacency

RP/0/RSP0/CPU0:ASR9001-2#show cef 192.168.0.1

192.168.0.0/24, version 377, attached, connected, internal 0xc0000c1 0x0 (ptr 0x9dcc70ec) [1], 0x0 (0x9d554cc0), 0x0 (0x0)
 Updated Jan 22 10:37:31.554
 remote adjacency to GigabitEthernet0/0/0/5
 Prefix Len 24, traffic index 0, precedence n/a, priority 0
   via GigabitEthernet0/0/0/5, 4 dependencies, weight 0, class 0 [flags 0x8]
    path-idx 0 NHID 0x0 [0x9cf793e4 0x0]
    remote adjacency

FIB に格納されている 10.0.0.1 とその Next-Hop の経路情報についても同様の確認を行います。
FIB に経路の情報が存在しており、想定通りの Next-Hop となっていることと、FIB への経路のインストール時間を確認します。
コマンド実行時に Location を指定しない場合は、RP/RSP 上の FIB の情報を表示することに留意してください。

RP/RSP 上では、該当の経路についての Adjacency 情報を直接持ちませんので、Adjacency については remote adjacency と表示されています。

これは、別ノードに Adjacency 情報が保持されていることを示しています。

 

RP/0/RSP0/CPU0:ASR9001-2#show cef summary

Router ID is 172.16.0.2

IP CEF with switching (Table Version 0) for node0_RSP0_CPU0

  Load balancing: L4
  Tableid 0xe0000000 (0x9d0cd1dc), Vrfid 0x60000000, Vrid 0x20000000, Flags 0x2031
  Vrfname default, Refcount 535
  257 routes, 0 protected, 0 reresolve, 9 unresolved (9 old, 0 new), 20560 bytes  12 rib, 0 lsd, 245:0 aib, 1 internal, 4 interface, 4 special, 1 default routes  253 load sharing elements, 65108 bytes, 5 references
  1 shared load sharing elements, 256 bytes
  252 exclusive load sharing elements, 64852 bytes
  0 route delete cache elements
  12 local route bufs received, 1 remote route bufs received,  0 mix bufs received
  12 local routes, 0 remote routes
  28 total local route updates processed
  0 total remote route updates processed
  0 pkts pre-routed to cust card
  0 pkts pre-routed to rp card
  0 pkts received from core card
  0 CEF route update drops, 3 revisions of existing leaves
  0 CEF route update drops due to version mis-match
-snip -

もしこの際、既に RIB と CEF の状態に差異がみられる場合は、show cef summary にて、RIB から CEF への update に問題が出ていないかを確認します。
route update に drop が見られた場合は、状況について整理するとともに、後述の case study のコマンド一覧を参考に詳細 Log を取得し、TAC へケースオープンしてください。

 

AIB
RP/0/RSP0/CPU0:ASR9001-2#show adjacency

-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
Interface                   Address                  Version  Refcount Protocol
Gi0/0/0/5                   (src mac only)               241         1(    0) ipv4
Gi0/0/0/5                   (interface)                    6         1(    0)
Gi0/0/0/5                   192.168.0.1                     242         2(    0) ipv4

CEF では、FIB と共に、AIB(Adjacency Information Base)を使用して、パケットの転送を行います。
AIB では全ての FIB entry について、L2 Next-Hop アドレスの情報を保持します。
L2 情報を使用し Single-Hop でお互い到達できる場合に、二つのノードは隣接しているとみなされます。


ここでは、Next-Hop アドレスのエントリーが、想定通りの interface に紐づいて存在していることを確認します。
もし FIB entry に対応する AIB entry が見られない場合は、ARP や NDP など、Adjacency の解決に関わるプロトコル側の動作に問題がでていないかを確認し、切り分けを行います。

 

SW FIB
RP/0/RSP0/CPU0:ASR9001-2#show cef 10.0.0.1 location 0/0/CPU0

10.0.0.1/32, version 421, internal 0x4000001 0x0 (ptr 0x88a0d728) [1], 0x0 (0x88327e60), 0x0 (0x0)
 Updated Jan 22 10:43:04.854
 local adjacency 192.168.0.1
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 192.168.0.1, GigabitEthernet0/0/0/5, 6 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x3 [0x8a688210 0x0]
    next hop 192.168.0.1
    local adjacency

SW FIB においても同様に、経路情報が存在しており、想定通りの Next-Hop となっていることと、FIB への経路のインストール時間を確認します。
また、0/0 LC 上の AIB に Adjacency 情報があるため、local adjacency となっています。



HW FIB

RP/0/RSP0/CPU0:ASR9001-2#show cef 10.0.0.1 hardware egress location 0/0/CPU0

10.0.0.1/32, version 421, internal 0x4000001 0x0 (ptr 0x88a0d728) [1], 0x0 (0x88327e60), 0x0 (0x0)
 Updated Jan 22 10:43:04.850
 local adjacency 192.168.0.1
 Prefix Len 32, traffic index 0, precedence n/a, priority 1
   via 192.168.0.1, GigabitEthernet0/0/0/5, 6 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x3 [0x8a688210 0x0]
    next hop 192.168.0.1
    local adjacency
- snip -

HW FIB においても同様に、経路情報が存在しており、想定通りの Next-Hop となっていることと、FIB への経路のインストール時間を確認します。
確認を行うルータが Transit のルータである場合は、Ingress の LC 上においても、ingress option を使用して実行します。

 

確認及び切り分けにおける留意点

以下の点に留意してください。

  • 情報を取得する際には、Next-Hop アドレスの情報も確認する
  • 再帰的な look up を行っている場合は、宛先アドレスに到達するまでに経由する、すべてのアドレス情報の情報を確認する。
  • 経路の印加や、トラフィック印加を行っている場合はその有無が事象に影響を与えるか確認する。
  • 特定のイベントに関連する事象の場合は、類似のイベントで同様の結果となるかを確認する。( LC OIR と LC の S/W reload での事象差分等)
  • 事象が特定の経路情報のみに見られているのか、あるまとまりの単位で見られているのかを確認する。
  • 特定の契機によって事象が発生/回復する場合は、正常時の出力についても合わせて取得し、比較を行う。
  • VRF を使用している場合には、Log 取得の際 vrf option を使用する。
    show route vrf <vrf名>
    show cef vrf <vrf名>
  • IPv6 の場合は、Log 取得の際に ipv6 option を使用する。
    show route ipv6 <prefix>
    show cef ipv6 <prefix>



Case Study:  LC 起動時に通信断が発生する

これまで解説した内容を実際に活用し、原因の絞り込みを行うことができた事例について、以下にご紹介します。
 

事象概要:

ASR9006 を使用しており、二つの Line  Card (以下 LC)をまたいだ Bundle-ether interface を使用している構成において、片方の LC を抜き差しした際、数秒から十数秒程度の通信断が発生する。

case

 

調査に当たっての主な切り分けの観点:
  1. IPv4/IPv6 traffic の詳細情報
    • IPv4/IPv6 それぞれ 40フローずつ、双方向で 1000pps 印加
       
  2. IPv4/IPv6 それぞれの印加経路数
    また、経路数が多い場合は、減らした場合に同様の動作となるか。
    • 特段経路数は多くなく、経路数に依存した問題では無いように見える
       
  3. traffic を送出する宛先 prefix によって断時間に変化はあるか。
    逆に、宛先が固定である場合、断時間は固定となるか。
    • 宛先prefix によって、断時間に有意な変化は見られず、使用する prefix を変更する試験は行っていない。
       
  4. shut/no shut や、LC の電源 OFF/ON でも同様の挙動となるか。
    • ケーブル挿抜による試験では瞬断となる。LC リロードの場合は同様の断時間。

TAC から依頼するコマンド例:

事前
------
admin show install active summary
admin show platform
admin show inventory
admin show hw-module fpd location all
show running-config
show controllers np ports all location  <LC>

show interface <Bundle-ether if>
show interface <Phy if>
show bundle bundle-ether <IF>

show route ipv4 <prefix> detail
show route ipv6 <prefix> detail
show cef ipv4 <prefix> detail location <LC>
show cef ipv4 <prefix> hardware egress detail location <LC>
show cef ipv4 <prefix> hardware ingress detail location <LC>
show cef ipv6 <prefix> detail location <LC>
show cef ipv6 <prefix> hardware egress detail location <LC>
show cef ipv6 <prefix> hardware ingress detail location <LC>
show cef ipv4 drops location <LC>
show cef ipv6 drops location <LC>

show drops location <LC>
show controllers np counters all location <LC>
### <prefix> は着目すべき、宛先 prefix をすべて指定
### <LC> についてはすべての関連する LC にて取得


LC抜去後
------

show interface <Bundle-ether if>
show interface <Phy if>
show bundle bundle-ether <IF>

show route ipv4 <prefix> detail
show route ipv6 <prefix> detail
show cef ipv4 <prefix> detail location <LC>
show cef ipv4 <prefix> hardware egress detail location <LC>
show cef ipv4 <prefix> hardware ingress detail location <LC>
show cef ipv6 <prefix> detail location <LC>
show cef ipv6 <prefix> hardware egress detail location <LC>
show cef ipv6 <prefix> hardware ingress detail location <LC>
show cef ipv4 drops location <LC>
show cef ipv6 drops location <LC>
show drops location <LC>
show controllers np counters all location <LC>
### <prefix> は着目すべき、宛先 prefix をすべて指定
### <LC> についてはすべての関連する LC にて取得

LC挿入後
------

show interface <Bundle-ether if>
show interface <Phy if>
show bundle bundle-ether <IF>

show route ipv4 <prefix> detail
show route ipv6 <prefix> detail
show cef ipv4 <prefix> detail location <LC>
show cef ipv4 <prefix> hardware egress detail location <LC>
show cef ipv4 <prefix> hardware ingress detail location <LC>
show cef ipv6 <prefix> detail location <LC>
show cef ipv6 <prefix> hardware egress detail location <LC>
show cef ipv6 <prefix> hardware ingress detail location <LC>
show cef ipv4 drops location <LC>
show cef ipv6 drops location <LC>
show drops location <LC>
show controllers np counters all location <LC>
### <prefix> は着目すべき、宛先 prefix をすべて指定
### <LC> についてはすべての関連する LC にて取得


show logging

show tech-support bundles
show tech-support rib ipv4
show tech-support cef ipv4 detail location <LC>
show tech-support rib ipv6
show tech-support cef ipv6 detail location <LC>



ログ解析:
RP/0/RSP0/CPU0:ASR9006#show logging
- snip -
RP/0/RSP0/CPU0:Dec  3 23:03:54.084 : invmgr[253]: %PLATFORM-INV-6-OIRIN : OIR: Node 0/1/0 inserted <<< 0/1 LC が抜去後、挿入された
- snip -
LC/0/1/CPU0:Dec  3 23:04:06.962 : ifmgr[200]: %PKT_INFRA-LINK-3-UPDOWN : Interface TenGigE0/1/0/1, changed state to Up
LC/0/1/CPU0:Dec  3 23:04:06.963 : ifmgr[200]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line protocol on Interface TenGigE0/1/0/1, changed state to Up
RP/0/RSP0/CPU0:Dec  3 23:04:06.968 : BM-DISTRIB[1119]: %L2-BM-6-ACTIVE : TenGigE0/1/0/1 is Active as part of Bundle-Ether1 <<< Link Up 後、Te 0/1/0/1 が BE1 に参加

show logging より、23:03:54 に 0/1 LC が挿入されたことと、その後該当 interface が Up となり、23:04:06 にBundle-member として、Bundle に参加していることが確認できます。
 

RP/0/RSP0/CPU0:ASR9006#show route ipv4 172.16.0.0 detail <<< next-hop となる connected の prefix を確認

Routing entry for 172.16.0.0/29
  Known via "connected", distance 0, metric 0 (connected)
  Installed Dec  3 19:02:16.661 for 04:02:44     <<< RIB 上の経路情報については、変化なし
  Routing Descriptor Blocks
    directly connected, via Bundle-Ether1
- snip -

RIB においては、特に経路情報をアップデートするイベントを受けておらず、LC の挿抜以前から経路情報を保持していたことがわかります。
 

RP/0/RSP0/CPU0:ASR9006#show cef ipv4 172.16.0.0 detail location 0/1/cpu0

172.16.0.0/32, version 0, broadcast
  Updated Dec  3 23:04:12.235    <<< LC の SW FIB 上の経路情報は、Link Up 後、約 6秒遅れて install されている。
  Prefix Len 32
- snip -

しかし、0/1 LC 上の S/W FIB を確認すると、LC 起動後の CEF への経路情報の install は、Link Up より約 6秒遅れていることがわかります。
 

RP/0/RSP0/CPU0:ASR9006#show cef drops location 0/1/cpu0 <<< 挿入前

CEF Drop Statistics
Node: 0/1/CPU0
  Unresolved drops     packets :               0
  Unsupported drops    packets :               0
  Null0 drops          packets :               0
  No route drops       packets :           42725   <<<

RP/0/RSP0/CPU0:ASR9006#show cef drops location 0/1/cpu0 <<< 挿入後

CEF Drop Statistics
Node: 0/1/CPU0
  Unresolved drops     packets :               0
  Unsupported drops    packets :               0
  Null0 drops          packets :               0
  No route drops       packets :           49636   <<<

また、show cef drops の結果をLC挿入前と、LC挿入後で確認した結果、No route drops がカウントアップしていることが確認できます。
これは CEF 上に経路情報がなかったために、drop が発生していたことを意味します。

 


調査結果:

事象内容

二つの LC をまたいだ Bundle-ether interface を使用している構成において
片方の LC を抜き差しした際、LC の起動時に数秒から十数秒程度の通信断が発生する。
 

解析結果

TenGigE0/1/0/1 が BE1 に組み込まれたのは 23:04:06 となっているが
0/1 LC 上の CEF が更新された時間は 23:04:12 前後となっていることが確認でき
通信断と同じ時間、CEF の更新に遅れが見られた。

また show cef drop の結果から、No route drops の増加がみられ
CEF 上に経路情報がなかったために、drop が発生してることが確認できた。

原因

Bundle-Ether は RSP での管理となるため、LC1 上の転送情報の準備が
完了してしまっていないにもかかわらず、パケットは LC1 へ転送され、drop が発生していた。

 

設定追加、もしくはラインカードの起動時など、ラインカード上の interface が
初めてBundle-Ether に加わるタイミングにおいては
CEF のインストールに一定の時間が掛かることは実装動作となるため、本動作は期待された動作となる。

 

回避方法

carrier-delay up を十分な時間とり、LC 上の FIB に経路情報がインストールされた後に interface を
Bundle-Ether に参加させることによって、本動作に起因する drop は回避可能。

 

RP/0/RSP0/CPU0:ASR9006(config-if)#carrier-delay up ?
<0-2147483647>  Delay in milliseconds

 

IPv4/IPv6 の差異や、経路数等の環境条件に依存するため、値のチューニングについては検証による確認が必要となる。

Loading.

アクション

このドキュメントについて