初参加で初運営委員をしております。参加したかと言うと、実はネットワーク関係を勉強したのは去年の8月くらいから勉強を初め、学校の方では主にCiscoルーター・スイッチを触りその関係で今回のコンテストに運営として志願しました。ICTSCではL2,L3のネットワーク設計を担当しています。L1もちょっと触ってます。実際の会場で(おそらく)お会いするとは思います、よろしくお願いします。この記事ではネットワーク設計とは何をするのか!?ってな感じで、後から“””デキる”””方々からお叱りをおことばを受けることを覚悟しつつ、書いてきます。聞いたことのある、OSI参照モデルのお話です。L1は物理層、L2はデータリンク層、L3はネットワーク層...と勉強した記憶があります(汗また下位層で決めた内容を基に上位層に引き継いでいくってのもありますよね、ネットワーク設計においても同じ事が言えます。L2設計まず基となる下位層から、今回作ろうとするネットワークを考えます。1,2,3と下からで、L1設計(物理配線)からじゃないの?と思われる方が居ると思いますが(僕も思ってた)、先に物理配線、機材や光ファイバー、LANケーブルを決めてしまうと途中で変更できなくなるのと、実際の論理的な設計の時に仕様変更で必要な機材やケーブルが増えるかもしれません。論理から物理に落とし込んでいきます。L2設計から始めます。今回必要なネットワークは何があるのかを考える。ルーターを超えない範囲のネットワークをたくさん、ふわふわしてるようなイメージを想像する。そのネットワークが何の役割をするのかも考える。言ったイメージでL2ネットワークを作成していきます。IPアドレスやVLANIDを考える必要はありません。L3設計時に割り振りやすいような配置固めは考えます。目指せふわふわネットワーク。L3設計ここでルーターを超える通信について考えてみます、L2設計で作成したネットワークを繋げる作業です。L3設計では、IPアドレスやVLANIDの割り振りルーティングフィルタリングの作業を行います。ルーティングはRIPやOSPFがよく知られていますよね。実際の企業ネットワークはもっと難しいこと(他の企業ネットワークとお金が絡む)をしているそうですがここでは割愛します。フィルタリングについても拡張ACLでCiscoだとanyですべて切ったり、ipやtcpだけを使う(ipやtcpの層から上の層すべて)プロトコルを切ることもできます。L2ネットワーク同士の接続要件もフィルタリングの仕事です。体外接続に置いてもグローバルIPアドレスで引っ張るか、1つのグローバルIPアドレスにNAPTする方法もあります。バックボーンはどういう構成にするのか?考えることは大量にあります。L1設計L3設計まで行くと最低限必要な機材スペックや光ファイバーの本数、LANケーブルが何本いるか、なんとなく分かっていくはずです。あとは設置する場所の大きさを測り、長さも測ればなお良しです。おわりに如何だったでしょうか、ICTSCでは企業ネットワークのようなネットワークを想定しています。本物の企業ネットワークには当たり前ではあるのですが、ポリシーが定められており、ポリシーを基に考えていきます。今回の大会でもポリシーがあったような気がしましたが...我々運営もそろそろ修羅場を迎えそうな雰囲気があります。/カテゴリーサーバー関連こんにちは!電気通信大学の吉村と申します。ICTトラブルシューティングコンテストは今回で2回目の参加となります。前回のICTSC4ではネットワーク寄り、今回はサーバ・インフラ寄りで担当しており、まだまだわからないことも多いのですがどうぞよろしくお願いいたします。今回はDNSサーバについての話をします。DNSサーバと聞いてまず最初に思い浮かぶのはBINDかと思います。今回は”NSD”というDNSサーバを紹介します。/カテゴリーネットワーク関連はじめまして。こと田中京介と申します。携わるのは初めてで、今回が初参加かつ初運営委員です。インフラには以前から興味があり、ICTSC5を通して様々なことを吸収していきたいと思っています。お手柔らかによろしくお願いします。いうことで、監視に関するふわっとした話をします。いう疑問がまず存在するのですが、僕は以下の様な理由で監視が必要だと考えています。(死活監視)多くのサービスが監視を導入する理由がこれだと思います。リクエストを行ったりすることで、サービスがダウンしていないか確認するものです。使って死活監視を行っています。サービスを提供するインフラを改善するためこれは、サービスの継続提供の先にあるものです。提供しているサービスの一部に負荷が掛かりサービス全体が重くなっている、なんてことがあったとします。いうことを知ることで、そこから改善の糸口をつかむことができるのではないかと考えています。そこで今回は上記の目標を達成するため、以下のとおり監視ツールの選定を行いました。新しいサービスですが、各所で使われているのをブログなんかで目にします。ホストに紐付いた通常のメトリック(監視項目)とは別に、サービスメトリックというホストに依存しないメトリックも設定できます。設定が最小限で済むことが大きいです。格好いいというのも個人的には好きなところです。並んで有名なものです。豊富なテンプレートにより、監視対象を容易に設定できることや、多彩な設定ができることが強みです。こちらは直接サーバにインストールして使う形になります。これら2つを併用してみる形となりました。あるため、外部へ疏通ができるサーバーしか監視することができません。内部のネットワークに負荷が掛かっていたり、外部への接続に問題があるというときには、当たり前ですが監視ができません。不足している部分を補うというユースケースを考えており、現在検証を進めているところです。ここまで書いておきながら、私は今までこういったツールをほとんど使ったことがありません。(お恥ずかしながら......)まだまだ検証途中であり、サービスの中身に踏み込んだ内容が書けていないのはこういった事情があります。そのうち、検証も進んできたところで再度記事を書きたいなと思います。ところで今回の大会、募集要項が去年と少しだけ変わっているのには気付かれたでしょうか?私としては、そんなところにも目を向けて頂けたらと思っています。皆さんの参加応募をお待ちしております。以上で私の記事は終わりです。