Google誤設定によるインターネット障害とBGPルータのメモリ問題

2017/8/29-3

2017年8月25日の大規模インターネット障害の続きです。 Googleの誤設定によってBGPルータの性能が低下したかも知れないという話の背景を紹介します。

BGPで大量の経路を受け取ってしまうと動作が不安定になるBGPルータが存在するのは、BGPルータに搭載されているTCAM(Ternary Content-Addressable Memory)というメモリに関連します。フルルートが、BGPルータに搭載されたTCAMの容量を超える規模になってしまったので、著しくBGPルータの性能が落ちるなどしてネットワークが不安定になるというものです。

TCAMは、CAM(Content-Addressable Memory)と呼ばれるメモリの一種です。メモリといえば、パソコンなどで利用されるDRAM(Dynamic Random Access Memory)を思い浮かべる方々が多いと思いますが、DRAMとCAMは全く違う仕組みです。

DRAMは、指定されたアドレスに情報を格納したり、格納された情報を取り出すといった機能を持ちます。一方で、CAMは、指定された情報とマッチする情報を高速に取り出せるというものです。CAMにあらかじめ多数のデータを保持しておいた状態で、CAMに対して検索を行う情報を指定すると、それにマッチする項目が返ります。返ってくる結果が複数の場合もあります。

完全に一致する情報を探すCAMは、binary CAMと呼ばれていますが、ルータなどのネットワーク機器で利用されるのはbinary CAMではなくTCAMです。TCAMは、ビットが「マッチする」「マッチしない」「気にしない」という3種類のマッチングが行えます。

なぜTCAMが使われるかというと、TCAMを使うことでサブネットを考慮したIPアドレス検索を行いやすいためです。たとえば、32ビットのIPv4アドレスに対して経路を検索する用途でTCAMにあらかじめ保存される情報は次のようになります。TCAMにあらかじめ登録される経路表にある/24のネットワークを示す項目では上位24ビットが「マッチする」、下位8ビットは「気にしない」という条件でTCAMに登録されます。同様に、/16のネットワークであれば、上位16ビットが「マッチする」、下位16ビットが「気にしない」という条件でTCAMに登録されます。

32ビットのIPv4アドレスでTCAMを使った検索を行うと、そのIPv4アドレスにマッチする全ての経路情報が得られます。TCAMから得られた経路候補から、最も長いサブネット長を持つ経路を選ぶ、いわゆる「ロンゲストマッチ」の計算を行うのはTCAM以外の仕組みになります。

こういった仕組みを持つTCAMは、サブネットマスクやアクセスリスト(ACL / Access Control List)をハードウェアで高速に処理するためにネットワーク機器に搭載されています。

で、今回の話題では、TCAMをBGPルータのFIB(Forward Information Base)として利用するときの話です。

BGPによってルーティングテーブルが作成されますが、ルーティングテーブル作成などの作業はDRAMに対してRIB(Routing Information Base)として保存されます。DRAMに保存したうえで、BGPルータのCPUを使って個々のパケットがどこに転送されるべきかの計算をしていては処理が追いつかないので、高速処理が可能なFIBが利用されますが(ただし、全てのルータのFIBがTCAMで実現されているわけではありません)、そのFIBの容量が溢れてしまうとBGPルータの性能が低下します。 FIBの容量が溢れたとしても、ただちにそのBGPルータが破綻するわけではなく、「パケットロスが増えた」などの事例報告がされているのも、「FIBに乗っていないからといって処理できないわけではない」のが理由です。

さらに言うと、BGPルータでフルルートを扱っていたとしても、そのBGPルータが転送するトラフィックが少ないのであれば、TCAMを大量に搭載した高価な機器は必要ありません。BGPの処理だけを行い、大量のトラフィックを転送しないのであれば、一般的なPCでBGPのフルルートを受け取ることも可能です。問題はパケットを高速に転送することであり、BGPそのものの処理ではないのです(例としては、route reflector、IX等で運用されるroute server、大学等の研究で情報収集用にPCサーバがBGPソフトウェアを運用する場合など)。

フルルートが一時的に増大し、BGPルータの性能が著しく低下するという問題は2014年にも発生しています。 2014年8月12日に発生した障害は、UTC(Coordinated Universal Time / 協定世界時)の07:48にVerizonのAS 701とAS 705から約1万5千個の経路が広告されたことによって瞬間的に512K個を超えたことが原因であると推測されています。BGPMONの記事では、Verizonからの大量の経路広告が07:48で、各所での障害発生が08:00であるとしています。約1万5千個の経路は数分で取り下げられたものの、ASによっては数時間障害が続いたそうです。

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます!