トラヒックのルート変更とは?冗長化やコンフィグ設定ミスはあった?

7/2未明、KDDI社にて大規模な通信障害が発生しました。

7/3中には復旧作業を終了し、ネットワーク試験の検証完了の上完全復旧見込みとのことですが、個人の携帯電話サービスが影響を受けるとともに、一部銀行のATMが使えなくなったり、ヤマト運輸の宅配にも影響、貨物列車の遅延によりゆうパックの配送にも影響が出たりと、とても大きな混乱が起こっています。

また、会見の際に障害が起こった経緯として、「コアルータ交換時、トラヒックのルート変更作業中に不具合が生じた」と発表しています。

トラヒックのルート変更と聞いて、ピンとくる方はどのくらいいらっしゃるのでしょうか?

そこで、トラヒックのルート変更について確認していくとともに、ルータの設定を誤ってしまうとどうなるか詳しく見ていきましょう。

KDDI社の当初の発表内容については、前記事もご参考にされてください。

目次

トラヒックのルート変更とは?

KDDI社は今回、メンテナンスの一環としてルータ本体を交換しているようです。その際に、トラヒック(データ)のルート変更中に不具合が起こったと説明しています。

KDDI社より詳細な説明はまだありませんが、トラヒックのルート変更というのは、おそらくルータの設定を変更して、データの通る順序等を変更したという意味ではないかと思います。

そして、今回新しいルータを交換した(けど切り戻した)と発表しているので、

  • 新しいルータに、今まで設置していたルータと別のルート設定を施した上で交換したが、その設定が誤りであったため、不具合が起こった

と予想します。

新ルータの設定(コンフィグ)誤りの可能性は?

ここで、皆さんが思っているルータというのは、家庭用のインターネットの出入り口にある弁当箱くらいの機械だと思われていると思います。しかし、業務用のルータは、高いもので何百万もする機器で、データのやり取りのルートを設定したりすることができるのです。

技術者はルーターに対して、データの順番やセキュリティ設定などを、専用のコマンドで設定(コンフィグ)入力していきます。

今回、新しい機器に、新しいルートをコンフィグに追加したが、そのコンフィグに誤りがあって、データのルートが誤っていて適切な場所にデータが送らなかったので障害につながったのではないかという予想です。

現に、KDDI社の発表によると、旧ルータへの切り戻しを実施したところ、時間はかかったものの輻輳が解消されてきているということですので、旧ルータのコンフィグであれば通信ができているということがわかりますので、新しいルータコンフィグに不具合があるのではないかという判断です。

冗長化されている(と思われる)ルーターとの整合性は?

通常、大規模なネットワークの場合、1台が故障しても影響を少なくするため「冗長化」をしています。

冗長化とは?

冗長化(じょうちょうか)」とは、コンピュータや機器、システムに何らかの障害が発生した際に備えて、予備の設備やサブシステムなどを平常時から運用しておくことをいいます。

 例えばルータを2台用意して、一方のルータ(ルータAとする)でネットワークを稼働させ、もう一方のルータ(ルータBとする)は待機状態にしておく。そうすることで、ルータAが機器の故障などで停止しても、すぐにルータBでネットワークを稼働するよう切り替えることが出来ます。

今回、コアルータを交換したとのことで、冗長化している別のルータのコンフィグと整合性が取れなくなってしまったという予想もできます。詳しく言うと、コンフィグ自体の誤り、OSファイルのバージョンの違いなどですかね。


以上のことより、今回の障害の原因は、技術者の設定ミスではないかと予想します。

設定ミスが原因ならば、なぜ設定ミスが起こった?

KDDI社が明らかにしていませんので、今回の原因が技術者の設定ミスかどうかはわかりません

しかし、設定するのは人間ですのでミスはあるかもしれませんよね。

では、なぜ設定ミスが起こってしまうのでしょうか?


大事な作業の時は、作業する人と、横で確認・立会する人複数人で対応すべきだと考えますが、人材不足などで作業員のみで作業してしまうと、ミスに気付かず作業を続行してしまうというケースがあります

また、今回の作業時間が深夜AM1時頃とのことでした。

筆者も経験がありますが、深夜作業はやはり眠くなるものです。もしかしたら、深夜作業の影響もあるかもしれませんね。

いずれにせよ、前記事でもお話ししましたが、完全復旧を目指して今日も作業をしている方が数多くいらっしゃるということを忘れてはなりませんし、作業員も人間であることを忘れてはなりませんね。

【追記】設定ミスではなく手順書のミスだった!

2022/7/29にKDDI社が会見を行いました。

手順書が2通りあり、古いほうを使ってしまったことが原因」とのことでした。

古いほうの手順書と新しいほうの手順書では、ルーティングのポリシー(ルート変更)に違いがあったようです。

本記事では、今回の原因を以下のように予想していました。

今回、新しい機器に、新しいルートをコンフィグに追加したが、そのコンフィグに誤りがあって、データのルートが誤っていて適切な場所にデータが送らなかったので障害につながったのではないかという予想です。

今回の会見では、手順書が変わっていたということしかわからないですが、ルート変更が行われているということはコンフィグの書き換えがあったのかもしれません。したがって、本記事の予想が当たっているか外れているかはいまだに不明です。

また、技術者の設定ミスではなく、その前段階(手順書自体)のミスだということでした。この点については本記事の予想は外れています。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

CAPTCHA


目次