ICTSC, イベント, コラム, ネットワーク

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました!

今回は、私が担当した問題の内一つを紹介していきます。

タイトル:調子が悪いんでしょうか?

問題文

ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。

見れないページ : URL

ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****

FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】:****


** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1

 *1  どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。

 

問題解説

この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。

 

キーポイント

  • AWSのデフォルトMTU値が9001である
  • FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
  • 経路上のルータ(vyosB)のMTU値が800になっている
  • 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう

  *2 実際には約600byte〜700byteくらい

 

解説

この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。

まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。

また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。

今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。

 

解法

上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。

問題文からヒントを探す

この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか?と考えると解きやすかったかもしれません。

 

手元にある情報から探す

では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)

# curl -v http://hogehoge/
* About to connect() to hogehoge port 80 (#0)
*      Trying hogehoge ... connected
* Connected to hogehoge ( hogehoge ) port 80 (#0)
> GET / HTTP/1.1
> User-Agent : curl/~~~
> Host :  ipaddress
> Accept :  */*
>

上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
(これはWebServerへsshしifconfigする事でもわかります。)
そして、ssh時に帰ってきているパケットを見ると

「ネクストホップのmtuは800だよ」

というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか?

 

原因を特定する

さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか?
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。

・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番

つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。

このようになりますね。
それでは、これによってどのような事が起きるのでしょうか?
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。

PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP(type3 code4)パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。

詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして

 

では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。

Webページを参照する時の流れ

1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない

通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね!

対処する

そうなると、対処方法としては以下の二つが挙げられます。

・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる

このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。

尚、変更するのはサーバのみでお願い致します。

ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが

今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。

これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。

以上で、対応完了となります。

尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。

 

 

まとめ

「PathMTUDiscovery問題」如何だったでしょうか?
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います!

ICTSC, イベント, 雑談

8月末に大阪で行なわれた、第6回ICT トラブルシューティングコンテストに今回もお邪魔してきました。

ICTSC – ICTトラブルシューティングコンテスト
http://icttoracon.net/

2日間の戦いの後は、運営側の採点が行なわれるのですが、その採点時間の間、参加者の学生達にイイ話をして場を繋がなければいけません。
学生も大変ですが、大人も意外と大変です。
前回のICTSC5のときは、大人っぽくお金の話をしたのですが、2回続けてお金の話はヤらしいよなあ、と思って数学の話をしてみましたよ。

発表前に、数学好きな人ー?、と聴衆の学生さんに聞いたところ、挙手は皆無。
お金の話のほうが聞きたかった人ー?、と聞いたら、挙手がちらほら。
ありゃあ、はずしちゃったかあ、と思ったけど、発表後に、数学を勉強してみたいと思った人ー?、にちらほらと手が挙がったので、まあ喋って良かったかのなあ。
でも最近の若者は気を使ってくれるんだよねえ。ありがとう。
前回のICTSC5のときに喋った資料もついでに吊っておきます。出すのを忘れてました。

イベント, インフォメーション

来年1月に開催されるJANOG39 ミーティングのホスト企業をDMM.comラボが務めさせていただきます!
少しずつですが、準備を進めていますよー!

さてさて、9月7日よりJANOG運営スタッフの募集が始まっていますが、本日はツチノコNOC(仮)と称した会場ネットワークを構築する部隊のメンバーを募集します!

JANOG39 ミーティングについて

名称 JANOG39ミーティング
日時 2017年1月18日(水)~20日(金)
※1月19日(木)の本会議終了後に、懇親会が開催されます。
会場 本会議:金沢市文化ホール (http://www.bunka-h.gr.jp/)
懇親会:ホテル金沢 (http://www.hotelkanazawa.co.jp/)
主催 日本ネットワーク・オペレーターズ・グループ
ホスト 株式会社DMM.comラボ (http://labo.dmm.com/)
参加費 本会議:無料
懇親会:有料 (金額未定)

来年1月18日から3日間に亘り、日本中のネットワークオペレータが一堂に集い、情報交換や議論を行うことを目的とした会です。

JANOG39の詳細や、スタッフ・プログラム募集については下記のページをご覧ください!
https://www.janog.gr.jp/meeting/janog39/

ツチノコNOC(仮)について

ツチノコNOC(仮)は、JANOG39本会議中に使用する会場ネットワークを構築するチームです。
JANOG39 ミーティングの運営スタッフとは異なりますのでご留意ください。

求める人材像と具体的な作業内容について

求める人材像

– イベントネットワーク構築に興味がある
– 大規模WiFi環境を作ってみたい
– イベント運営の裏側が見たい

具体的な作業内容(すべてを1人で行っていただくことはありません)

– 会場下見・ネットワーク回線の手配
– ネットワーク設計・当日作業手順所作成
– 監視(設計・設定・セキュリティ含む)
– 無線AP、無線コントローラ・L2/L3スイッチ設定
– ケーブルアサイン・タグ作り

構築経験は問いません!
学生の方、面白い事をしたいエンジニアの方など大歓迎です!
なお、応募多数の場合はバランスを考慮し選考させていただく場合がございます。

大まかなスケジュールについて

9月 メンバー募集→メンバー確定
10月 キックオフミーティング、チーム分け、アイディア出し、機材手配
11月 システム設計、機材準備
12月 東京にてホットステージ、システム仮組み、動作テスト
1月 金沢にて本番環境構築
2月 クローズミーティング

応募方法

応募は、以下のフォームよりお願いいたします。
締め切り:10月3日(月)10:00まで

https://goo.gl/forms/vbA5MeDEFI35ExBa2

 

最後に

ご質問、ご要望、疑問などございましたら、お気軽にご連絡ください!
冬の金沢で一緒に会場ネットワークを構築しましょう!皆さまからのご応募お待ちしております!!

ICTSC, イベント

お久しぶりです。 2年間の学生延長オプションを申請したツチノコ、@whywaitaです。

1年ぶりにツチノコブログにお邪魔させて頂きますが、今回もICTトラブルシューティングコンテスト(以下、トラコン)のお話をさせて頂きたいと思います。 トラコンそのものにつきましては、過去に何名かが記事を投稿しておりますので、そちらも確認頂ければと思います。

第4回、第5回と運営側として参加してきた私ですが、今回は”運営OB枠”、チーム「traITors」として、参加者側で大会に加わりました。 今回は先日行われた”NTT西日本杯 第6回 ICTトラブルシューティングコンテスト”の 参加 レポートとなります。

到着まで

前日(8/26)の朝、私とメンバーの1人は東京を発ちました。学生にはお金はありませんが体力があります。 ここまで言えば分かる方には分かるかもしれません。青春18きっぷを使った12時間の旅が始まったのです。 我々が通ったルートを地図に書き出してみるとこのようになります。

12時間旅行

道中は浜松で鰻を食べました。特急を乗らずに浮いたお金で美味しい鰻を食べるライフハックとなります。

そんな楽しい(厳しい)旅を乗り越え、我々は大阪に到着し、トラコンに参加しました。

訪れた危機

大会の1日目(8/27)の朝に、チームメンバーが集まりました。チームメンバーが大阪と東京に居た関係で顔を合わせるのは前回大会ぶりでした。運営委員も疲れているだろうという事で、翼を授けるドリンクを差し入れ用に購入しました。

Redbull15本

会場に到着すると慌ただしく最後の詰めの作業をしている運営委員や、昨日遅くまで作業していたのかゆっくりと体を休めながら会場に到着する運営委員が居ました。前々回や前回の我々はあのように見えていたのか、という話をチームメイトとしていると、開場時間になったので我々も会場入り。そんな我々に用意されたテーブルには、他のチームのテーブルには置いてあるLANケーブルが無く、あったのはLANケーブルを作る為の工具類でした。

工具

するとにやけた顔の運営委員がやってきて、「皆さんはL1からお願いしますww」と言って去って行きました。ちくしょう。

まあ仕方が無いとメンバーでLANケーブルを作成します。こういう時に限って大人達は楽しそう写真を撮りにくるのです。ちくしょう。

さて、ようやくLANケーブルが出来上がってルータやスイッチに結線したら、ようやく競技を開始出来ます。

まず、スコアサーバにユーザ登録します。前回まで問題の出題や質問の窓口としてRedmineを用いていたのですが、今回は運営陣が開発したスコアサーバを用いて行いました。

kyontan/ictsc-score-server

個人アカウントの登録には「自分の名前」「自分で決めたパスワード」「運営から渡された登録コード」を用いるようです。登録コードは8文字程とのこと。 じゃあユーザー登録、を…

登録コード

運営委員によると128文字あるとのことでした。

な…何を言っているのかわからねーと思うが、俺も何をされたのかわからなかった…
ジャン=ピエール・ポルナレフ


運営委員からの愛のプレゼント(単に嫌がらせとも呼びます)は問題にも現れます。

各チームにはそれぞれIP Phoneを渡されていました。 Cisco社から提供されたモデルはPoEによって運用されており、LANケーブル1本で電力とデータを供給出来ます。 しかし我々のチームのIP Phoneはそもそも色々な情報が来ていないようでした。 色々試してみたのですが問題が解決出来ず、ふと使われていた(これは運営陣が用意したLANケーブルです)ものを見てみると…

データ線無しLANケーブル

上が正常なLANケーブル、下がIP Phoneに刺さっていたLANケーブルです。 少し見づらいですが、下のLANケーブルには中の線が少し足りない事にお気づきでしょうか?

なんと運営委員は、PoEの中で電源給電部のみを残したLANケーブルを専用で作成していたのです。 ここまで手の込んだ悪戯をする為には、少なくない労力が必要でしょう。我々は逆に少し感心してしまいました。

さて、結果は…?

多くの運営委員からの嫌がらせ愛を感じながら、競技は終了しました。

結果としては2位相当(我々は招聘チームのため、表彰対象外となっています)で、あと8点足りず1位にはなれなかったようです。 うーん、残念。

前回のDMM.com Laboさんの言葉をお借りして、

『まあ結果はいいじゃないか』

という事で。


大会の翌日(8/29)、我々チームメンバーは会場に再度訪れていました。

大会は2日間で終わりですが、最後に会場からの撤収作業が必要となります。 お借りしたルータ、スイッチ、サーバ、ラックを1つ1つ梱包しながら片付けていきます。 勿論会場もお借りした時の状態に戻します。大会で利用したホワイトボードや机なども元の形に戻します。

東京へ送る荷物全ての発送が終われば、現地での作業は終了です。

まとめ

4日間の参加レポートをお届けしました。

参加者側からの視点で見るトラコンはまた運営側から見る物とは別の物です。 今までもそれは若干感じていたのですが、実際に運営側と参加者側両方を経験してみると、また色々な物が見えて興味深い感想を持ちました。 どういうような感想を抱いたのかなどは、今回の運営委員にフィードバックしていき、よりよい大会運営に役立てていきたいと考えています。

一緒に大会に参加してくださった参加者の皆様、この大会の為に尽力してくださった社会人の皆様、 そしてなにより、今回のトラコン開催にこぎつけた運営委員に感謝申し上げます。

次回大会をお楽しみに。

どのような形で関わるかは、この記事を読んでくださった貴方次第です。

PAGE TOP