[TroubleShoot] 上位回線がダウンしたとき、私は何をしたか

Homenoc Operator’s Groupの回線がダウンしました。

本日の昼頃に突如ネットがつながらなくなり、通信が出来なくなりまして何事かな?と。その後、Homenoc Operators Groupさんから以下のようなツイートやFacebookのフィード連絡が入ってきて、なるほどなぁと。



増え行くインターネットルート件数に対して、機器の負荷が限界に達しつつあるとのこと。Homenocさんにて対象ルーターを再起動いただきひとまず沈静化したようです。収容ルーターですが、決して弱々ルーターではなく、普通個人では持たないレベルの機器です。

Juniper MX80

2Uサイズのシャーシ型ルーターでありまして、追加モジュールが何が入ってるかまでは私自身存じ上げないので何とも言えないんですが、一つ言えることは家で稼働させるには余りにもしんどい機器ではあると言うことですかね。

これがメモリ不足でディスクスワッピングする訳なのだから、まぁまぁエラいこっちゃですよ、たぶん。

自分で解決できそうな所は解決しよう

というわけで、Homenocさんの回復を待つのもよしなのですが、ネットがつながらないのは辛いなと。とは言え、先方に「何とかしろ」って言ったところでどーにもなりませんで、だったら自分の出来るところで対策をしましょうよと思い、事前に備えていたことをやってその場をしのぎました。今回の記事で書くのはその内容について。

我が家のゲートウェイ構成

我が家には色々幸い事が重なり、論理的には合計3つの回線を持っています。

  • Flet’s回線系
    • Homenoc Operator’s Group回線(IPoE:IPv4/IPv6)
    • Interlink IPoE回線(IPv4/CGN経由)
    • Interlink PPPoE回線(IPv4/固定IP)
  • 別系統回線
    • QTNET 回線(IPv4/CGN経由)

現状、Interlink PPPoE回線はMastodonなど対外サービス向けの接続を担保しているところであり、ここの切り替えは結構面倒なので却下と。また、Interlink IPoE回線はNATのポート数制限があり、1024しかアサインできないことから実は積極利用していません。

よって、元々は実家間の通信をするためのQTNET回線を使用することにしてます。

そして、インターネットゲートウェイとしては、IPv4接続を担保する「Sophos UTM9」とIPv6通信を担保する「Sophos XG Firewall」を使用しています。今回これらを使って外部向け通信をQTNET回線への集約しました。

UTM9:Uplink Monitoring

UTM9には、外部向けトラフィックにActive/Standbyを持たせることが出来る、アップリンクモバランスという機能があります。今回これを活用してActive系の切り替えを行いました。本来は上位リンクの不達を検知すると自動的にフェールオーバーしてくれるんですが、今回のケースは「つながったりつながらなかったり」と言う状況が発生し、この機能が正常に働かないことがあるので、手動で対応しています。

アップリンクバランス

上図はアップリンクバランスの画面で、元々上記のようにアクティブインタフェースとスタンバイインタフェースを配置しています。で、強制的にスタンバイへ切り替えさせるために以下の通りHomenoc側のインタフェースをダウンさせました。

具体的にはリンクをオフりました

UTM9には、インタフェースのON/OFFを切り替えるボタンが存在し、これをOFFにする事で対応します。すると、オフにしたインタフェースでは通信できなくなるため、アップリンクバランスの機能によりQTMインタフェースがアップし、インターネット向けの通信が出来るようになります。

これで通常だとうまくネットにつながるようになるわけなのですが、これだと実はFacebook等IPv6アドレスを公開しているサイトにアクセスできません。IPv6で通信可能なトラフィックがXG Firewallを流れてしまい、Homenoc経由で接続しようとするからです。

XG Firewall:インタフェース接続のカットによるIPv6停止

IPv4環境とは異なり、IPv6通信については、実は代替経路がありません。一時はTunnel Brokerのお世話にもなろうかと思ったりした時期はあるのですが、あれは余り接続が安定して居らず、結構つながらなくなるケースが多いのです。よって、IPv6に関しては障害状況が改善するまで接続を解除することにしました。

XG Firewallは確かにアップリンクモニタリングの機能を持っては居るのですが、対外サイトに無尽蔵にポーリングさせるわけにも行かず、私の環境では直近のゲートウェイしか監視していません。本日のトラブルでは、直近のルーターや対外接続点には何ら問題がないため、XG Firewallは接続障害を検知せず、そのままパケットを配送しようとします。(そして失敗する)

おまけに、UTM9とは異なりインタフェース画面にOFFボタンがないのです(行の右端の「三」と書かれたところをクリックしたら出るかと思いきやインタフェースの編集しかできず、そこでもリンクダウンだけさせることは出来ませんでした。

XG Firewallのインタフェース画面

よって、ここではVMware側でvSwitchの接続を外すことで対処をすることにしました。vCenterに接続し、VMの編集画面から「接続中」のチェックボックスをOFFにするだけです。変更が確定した時点で無事IPv4のみで通信するようになりました。

最終的な影響

影響としては、私の環境で利用しているMicrosoft AzureとのVPNが障害期間中は接続できなくなりました。一時は経路変更の設定を行って実家サイトのVPNを通すことも考えたのですが、私が使ってるVPN GatewayのSKUがBasicであり、動的ルート構成が取れないため、かなーり面倒な作業を必要するためやめとくことに。

後は内部で発報用途で動かしてるメールプロキシが通信できなくなるということが起きました。

でも影響ってその程度のもんでした。結局の所、

  • フレッツが障害になったわけじゃないんで、対外サービスは問題なく稼働した
  • ブログはMicrosoft Azure上で動いており、その接続点には全く影響しない

と言うことで、余り大きな影響にはならぬのです。

故に、手動で切り替えるという何ともダサい手法を採用したわけです。

こういう場合の対応って、相手方に何かを要求するだけではなく、その間にどのような手法が取れるかを検討し、如何に早期に暫定対処まではこぎ着けておくか・・・・と言うのが重要になると考えています。怒鳴ってて何かが解決するならとっくに解決してるワイという奴ですね。

取れる対処には技術レベルの上下とか関係ないです。その時その場で把握している内容、それだけで足りなければその環境を知る別の有識者に相談するなりして何かしらの対処をするというのは、恐らくどこでも取り得る対応策ではないかなと感じています。

中の人に「これは大規模とは言わない」と言われるかもしれないのですが、ネットワークエンジニアリングの経験が圧倒的に少ない私には十分これは大規模障害事例に見えます。こういう事から対応している内容などを眺めさせて貰いながら学んでいくのも、それはそれで勉強になるなぁと再認識した今日この頃であります。