図3　B社は東京と大阪で異なるAS番号のマルチホーミング環境に変更した
専用線に障害が起きても，インターネット経由で東京あてのパケットが届くようになった。

AS内部の障害は分からない

　B社のシステム担当者は専用線の障害復旧を待ちながら状況を調査した。プロバイダに対してはBGPを使って東京データ・センターと大阪データ・センターに設定したAS番号を広告（BGPによるアナウンス）していた。プロバイダのルーターは，東京あてのパケットが大阪を経由して届く経路情報を持っていた。この経路は自営の専用線を通る。このことが，専用線の障害がインターネットとの通信に影響を及ぼす原因となっていた。

　AS内部で使っていたルーティング・プロトコルOSPFでは，専用線に障害が起きたことで，東京-大阪間の経路はなくなって見える。だが，AS外部にはBGPで経路情報を広告しているので，プロバイダのルーターから見れば，東京-大阪間の経路がなくなったことは検知できなかった。

　専用線の障害時に，プロバイダのルーターの経路情報を更新させようとしても，AS番号が同じであるためBGPではAS内部の障害を外部へ通知できない。プロバイダのルーターは東京と大阪を同一のネットワークとして扱っているので，経路情報を更新する必要がないと判断してしまう。

　専用線の障害がインターネット接続へ影響を及ぼすことを防ぐため，システム担当者はもう1本専用線を契約し，専用線を冗長化する方法を考えた。しかし，これはコストがかかりすぎるので，別の方法を検討することにした。

　最終的にB社は東京のデータ・センターと同じだった大阪のデータ・センターのAS番号を変更した。これにより，広告する経路情報をASごとに分けることができた。プロバイダのルーターはAS番号によって，東京と大阪を別のネットワークとみなすので，専用線に障害が発生した場合はBGPによって障害が通知され，経路が切り替わるようになった（図3[拡大表示]）。