リナンバを食らった。

ある日のリモートワーク(それもミーティング)中のこと。突然我が家のインターネット接続が壊れた。なんも繋がらない。

プライベート用のVLANでも症状を確認。ただしこちらは一部のページは繋がる。繋がるサイトをみるにどうもIPv4だけ死んでいる気がする。

我が家はひかり電話を入れておらず光クロスでもないので、IPv6プリフィクスが/64しかもらえず、プライベート用のVLANだけがIPv6/IPv4デュアルスタックになっている。リモートワーク用のVLANはIPv4オンリーだ。IPv4が死んだならリモートワーク用VLANは完全に死んだ状態ということになる。ひとまずは会社から支給されているスマホのテザリングで業務を続けることを優先。

とはいえ支給スマホで使えるデータ量にも限度があるので、このままにはできない。隙間隙間でちょいちょい見ていく。まずはJPIXの障害情報を確認するが、特に何も出ていない。

ゲートウェイルーターのダッシュボードを見に行くと、プライベート用のIPIPトンネルとリモートワーク用のMAP-Eトンネルの両方ともに発生時点からトラヒックのグラフが平らになっている。なんだなんだ、プロバイダ料金の決済エラーでも出たか？と思って見に行くも、とくに問題なく引き落とされている。

ゲートウェイルーターまるごと再起動してみると、IPIPトンネル自体はリンクアップしていて送信パケットカウントは上がるが、受信パケットカウントが0のままである。MAP-Eのルールも取れている。なんで？configもいじってないし何？

……と困惑していたが、結局発生から1時間後に自然回復した。なんだったんだ……。

あとになってからTECHINFOを出力してステータスを細かく確認していると、過去に出力したときのものとIPv6のプリフィクスが変わっていた。これが噂に聞くリナンバ……！リナンバが発生するとVNE側にその情報が反映されるまでトンネルが張れなくなるんだったっけか。いや、トンネル自体は張れていたから、VNEからCEに戻すパケットの宛先が更新されずに余所に送られてたのかな。

というわけでその日のうちにヤマハが例示しているenablerの再設定エンドポイント叩くluaを仕込んだ(まぁそんなに起きないし……と思ってJPNEになってからン年単位で放置してた。そういうとこだぞ)。ちゃんと読んで今更気づいたんですが、今のヤマハルータってRTFS使わずに直接config内にファイル埋め込めるんですね。これならいちいちTFTPとか用意しなくて済むし仕込むのもだいぶ気が軽い。

ところでバックアップ機能組んでたつもりだったんだけど、なんか設定ミスってたかな……。

該当行だけ抜き出すとこんな感じ。なんかフィルタが付いてるのはVLANごとに使うトンネルが違うのでそれの制御用。

ip route default gateway tunnel 1 filter 500004 500000 keepalive 1 hide gateway tunnel 2 filter 500003 500000 keepalive 1 hide gateway pdp wan1 filter 500003 500000 weight 0
ip keepalive 1 icmp-echo 60 3 8.8.8.8 8.8.4.4 1.1.1.1 gateway-selection-rule=head

ダッシュボード上、keepalive 1のダウン自体は検知してたんだけど、WWANにフォールバックしなかったんだよなぁ……。光回線ぶち抜いてのテスト時はちゃんとフォールバックしてたけど、リナンバのテストはしたことなかったからな……。光回線ぶち抜いたテストでフォールバックできてたのは、光回線ぶち抜くとトンネル2本ともダウンするからkeepaliveじゃなくてhideが効いてたんだろうな。

うーん、keepaliveは1つめのgatewayにしか効かないのか、あるいは、gateway-selection-rule=headが2番目の経路に向かないせいでtunnel 2のダウンを検知しなかったのか、どっちだろう……。構文エラー吐いてないし、keepalive2つ使ってる例を見た感じ、後者かな。いやでも両方の可能性もあるよな……。

一旦gateway-selection-rule=normalだけ付けとくか……。lua埋め込んだので大丈夫なはずではあるが、もしかしたらクレカの更新忘れとかでトンネル止まるかも知れないし。