松崎さん:国内の通信は、遅延が増えていた。ってことは通信が出きていた。日頃とは違った挙動が見えたと。 #janog
2017-09-01 17:47:27松崎さん:OCNと国内 遅延がぐぐっと増えた。 遅延が増えたが通信はできた。疎通性はあったが、日頃とは違う挙動が見えたかもしれない #janog
2017-09-01 17:47:27松崎さん: v6のノードは遅延は見えてない、パケットロスは共通部分のパケロス もう1つのノードではパケットロスなく遅延のみで生き延びられた、v6は何もなし #janog
2017-09-01 17:48:07松崎さん:海外との通信。IPv4で遅延。またパケットロスが発生していた様子。IPv6の方は直接の影響はなさそう。 #janog
2017-09-01 17:48:26松崎さん:なので、宛先に依ってはパケットロスなしで通信できていた様子。701の輻輳の影響は不明です。 #janog
2017-09-01 17:48:53松崎さん: IPv4は影響があった。宛先によってはなし。 v6はほとんど影響なし。 701向けの輻輳は不明 #janog
2017-09-01 17:48:54松崎さん:ここからは僕の予想です。最初の事象では、Google は既存のピアで経路ポリシーを変え、最後は Shutdownしたのではないかと。 #janog
2017-09-01 17:49:36松崎さん: ここから想定すると。。。 最初の実装はGoogleは既存のPeerで設定変更をして経路を漏らし、おそらくPeerのシャットダウンをしたように観測される #janog
2017-09-01 17:49:37松崎さん:こういうような影響があったときに何を? ・ちゃんとフィルター →701がフィルタリングしていたら… ・AS15169が多段の安全策を持っていたら? →ボタン一発なシステムだと安全とも言えないかも… #janog
2017-09-01 17:50:19松崎さん:この場合なにをやるべきか: フィルタしとけと。 701がフィルタしてればなんとかなったかも。OutBoundの何かしてれば大丈夫かも、 本当に安全かは? SecureBGPではうまくいかない。隣接関係は正しいので判別できない。 #janog
2017-09-01 17:50:38松崎さん:Secure BGP? ・隣接関係は正しい →そこで漏れるはずのないものが漏れた ・Origin Validation →そもそもトラフィックエンジニアリング目的で受け取ってもらわないとならないのでこれも辛い #janog
2017-09-01 17:51:07松崎さん:Origin Validationで厳密に設定して検証すれば経路をふせげたかも、難しいかも。 特定の経路だけでなく全経路に流せば?>ルータのメモリが増えてルータベンダーが喜んだ? #janog
2017-09-01 17:51:29松崎さん:経路制御ポリシー: ・細かい経路? →メモリがたくさん必要で… ・/25 にしちゃえば? →/24よりも長くして #janog
2017-09-01 17:51:37松崎さん:/25だったら影響は極小化できたかも。 JANOGで見たMax-Prefixをやれば? 加藤さんもいってたが厳しい。 どんとShutdownされるので落としていいのか? 701とのピア切るのと思うとしびれる #janog
2017-09-01 17:52:12松崎さん:Max-Prefix をもうちょっとちゃんと? ・なかなか厳しい →超えちゃうと、最初はWarninngだが、その後は落とされちゃう →ドキドキ →良い落とし所にしないと… #janog
2017-09-01 17:52:13松崎さん:こんな話できるよ、っていう方います?もしくは、ここをもうちょっと聞いてみたいとか。俺こうだったぜ、とか。 #janog
2017-09-01 17:52:37ししおさん: /25をくばれば大丈夫だった? そうだったかもしれないが、受ける方は大変なので ルータベンダーがよろこぶ #janog
2017-09-01 17:53:28ししおさん:/25 を配っておけば、どっちにしろフィルターに引っかかるから 松崎さん:隣接に配っておけば。でも受ける側は大変で、ベンダーが喜ぶことに。 #janog
2017-09-01 17:53:29