/カテゴリーICTSC9こんにちは、バックボーンなどインフラを担当した川原です。参加者の皆さん、参加してくださり誠にありがとうございました。今回も30分のサーバの電源断、1日目のWi-Fiの不調など、皆さんにご不便をお掛けしてしまい申し訳ありませんでした。Wi-Fiにつきましては、アンケートでも厳しい意見が多かったためバックボーン担当として重く受け止めています。Wi-Fiの調子は人数が増えてみないとわからないことも多いです。年々、改善を繰り返しながら取り組んでおりますので今後とも率直な意見をくださりながら参加して楽しんでいただければと思います。機材提供・協力をはじめとした協賛企業の皆様、毎度のことながら我々学生の無茶な要望を受け入れてくださり誠にありがとうございます。今回も参加者へのインフラを提供する傍ら、運営学生も貴重な体験をすることができました。堅苦しい話はここまでとして今回も大規模なインフラを組んで皆さんに提供しました。LTなどでも話しましたが、改めてブログにまとめることで多くの人にネットワークやサーバに興味を持って欲しいと思っています。今回のインフラは何人かで担当しているので、担当した各人がブログへ投稿することになっています。この記事では最初の記事として全体の総括をしていきたいと思います。監視編OpenStack編バックボーンについて我々ICTSC運営において、バックボーンとは全チームが問題を解くために使うインフラのことを言います。バックボーン担当は作問など大会開催に必要なタスクをこなす傍ら、興味のある人が思い思いのインフラを構築していくことになります。バックボーンの目的は以下です。参加者が問題を快適に解ける環境を提供するICTSC運営が問題を提供しやすい環境を提供するつまり、1に参加者、2に参加者、3くらいに問題作成者のことを考えて作るわけです。勘違いすると安定感に欠けた目的のわからないものになってしまうので、気をつけなくてはいけません。どんな問題でも出題できるように準備をしています。インフラ的に難しいからこの問題はボツで...ということは極力ないようにします。問題作成は運営発足から行われるものなので、運営発足からHotstage(本番の大会会場で本番の機材を使いながら準備する期間)中のインフラもある程度安定させなければ、よい品質の問題を用意することができなくなってしまいます。そのあたりの差し引きをしながら本番環境を構築していくのもバックボーン構築の醍醐味です。今回のバックボーンテーマについて最近のICTSCのバックボーンはテーマを決めて構築を行っています。第7回は安定感、第8回は仮想化でした。冗長化!!ということで構築されたバックボーンネットワークは以下のように、今回のテーマに則ってネットワーク機材をすべて冗長化しています。各機材の冗長構成については各担当の者がそれぞれ本ブログに投稿することになっているので楽しみにしていてください。概要については当日の発表資料を以下に用意しました。当日発生したトラブルについてどれだけ準備しようがトラブルは起きてしまうものです。当日起きてしまったトラブルをまとめていきます。11:30頃にサーバの全台が電源断するという障害が発生しました。昼食が早まったことで解答不可能になった時間は比較的少なくなりましたが、ご迷惑をお掛けしてしまい誠に申し訳ございませんでした。我々の不手際によって協賛の皆さんが半分のサーバを接続している電源系統でPCの充電をしてしまったことによる過負荷でおきたものであると考えられます。その後私が生きていたサーバのコンセントを抜くというミスオペを犯してしまいました。改善策としては、サーバは冗長化が行えていなかったためサーバの電源をそのような危険性がある電源からではなくアクセスしにくい電源を選択するなどがあります。ネットワーク機器は最悪電源が落ちても2系統とっていましたし、再起動も比較的高速に行えます。何よりサーバの電源断はHDDなどが故障する可能性もあります。ミスオペに関してはダブルチェックなどを行うなどがあります。復旧を一丸となって行えたのでとても良かったと思います。私を責めずに冷静に私の指示に従ってくれたみんなには感謝です。懇親会Wi-Fiの調子が悪いという話を多くの方から聞きました。懇親会後、原因の調査と修正を行いました。2日目の開始時にも軽くお伝えしましたが、ストレスを感じさせてしまい申し訳ありませんでした。原因2.4Ghz帯の電波が強すぎたことによって、多くのクライアントが2.4Ghz帯で接続し混線したものと考えられます。改善策2.4Ghz帯の電波を弱める、5Ghz帯でクライアントが接続できているか監視するなどの対策を行いました。我々の感知している範囲では2日目は快適に使用できていたと聞いています。競技時間の半分を不快な環境で回答していたことについては反省会でも話題になりました。次回以降はWi-Fiの調子などを早めに聞く機会を設け、早めに対策が行えるように努力します。みなさんもストレスを感じた場合は気軽に問い合わせ下さい。バックボーン側に原因がある場合は早急に対応いたします。Wi-Fiの調子は当日の人数が入らないとわからないことも多いです。次回以降の運営からも当日アナウンスがあるとは思いますが、Wi−Fiが不調の場合は有線接続の使用をご検討ください。一部グローバルIP(Googleなど)への接続ができなくなるという障害が発生しました。障害は3分ほど継続した後、収束しました。以上の障害発生時のメトリクスを見ても、障害発生時間帯にルート数が5000経路ほど減少していました。こちらの設定ミスか上流からのトラフィックを受信しているのに、こちらからトラフィックが流れていませんでした。障害発生から5分以内にメトリクスを把握し上流であるHomeNOC様に確認したところ、一部障害が発生していたとお聞きしました。このようなことが発生してもよいように上流は冗長化していましたが、うまく動作しませんでした。冗長化が動作しなかった原因としては、IPv4のフルルートを受け取っていた影響でルートの収束まで時間がかかってしまったようです。準備期間中や開催後に接続断テストを行った際には収束まで約10分の時間を要しました。原因究明にはメトリクスによる可視化が重要であることを実感できた障害でもありました。改善策なぜ、収束までにここまでの時間が発生するのかは我々も理解しきれていません。フルルートの運用をしてみないとわからないことは多く存在します。このような貴重な機会をくださったHomeNOC様に感謝しております。NICをヤフオクで9本程度落札してしまいました。それをNAVTサーバに搭載し、バックボーンに組み込んでいました。大会終了後、バックボーンネットワークがどれほどの帯域を出せるのかベンチマークを取りました。10台までiperf3を実行しました。以下のような経路を通り、通信を行いました。15台までiperf3を実行していました。グラフからわかります。このグラフは、Openstackのホストサーバの受信と送信の流量を示しています。まで出ていることがわかります。グラフはNexus5548とQFX5100の間の4本の流量をそれぞれ示しており、上半分が送信、下半分が受信になっています。なっていることに注意してください。実験を行うことができませんでした。出てないことがわかります。あったため、今回のベンチマークはバックボーンのベンチマークというよりサーバのベンチマークになってしまいました。処理をする際割り込みが多く発生することが大変であるという意味がわかりました。間の通信のロードバランスは非常に美しく4つのインターフェイスに対して等コストバランシングができていることがわかりました。両方向で等コストバランシングされていることから両方の機種がよい性能を持っていることがわかりました。余裕であることがわかりました。:clap:まとめバックボーン担当は以上の通り様々な技術的挑戦をしながら参加者に快適に問題を解いてもらうことを目標にバックボーンを構築しています。興味を持った方は是非これから続く記事も読んでいただき、わからないところを自分で調べることで知識を深めていただければと思います。機材提供をしていただける皆様!!面白い機材、お待ちしております!!改めて、参加者・関係者の皆様ありがとうございました。検証環境ラボ(以下、ラボという)のWANルータ(Router1)をリプレースすることになった。今回新たな要件として本番環境で動いているwebサーバにラボから接続出来るようにしてほしい言われた。本番環境とラボは同じセグメントを使用しており、そして擬似的にwebサーバをラボにあるように見せる様に複数回NATをして対処してくれと要望があった。ラボのクライアントからwebに繋げるipアドレスはRouter1のNATで192.168.14.200のアドレスを利用してwebページを見れるようにしてくれとも言われている。そのためラボにおいてある別のルータ(Router2)から本番環境のWANルータ(Router3)にプロバイダーサービスのl2vpnを利用してRouter2とRouter3を繋げ、3段階NATをすることによってwebサーバを見れるようにNATの設定を仮想機密伝送路課の担当者が行った。NATの設定後、ラボのPCからWebサーバ(192.168.14.200)に対しての通信で以下の現象が発生した。諸君にはRouter2と、webサーバに接続してトラブルシュートをし原因を突き止めてwebページが見れるようにして欲しい。今回動いているwebサーバは公開用のipアドレスとは別にマネージメントのipアドレスがあるのでそこからsshすることができる。192.168.14.200)に対してpingは通るのにwebページが見れない。192.168.14.200)にpingも通り、またapacheのテストページを見ることが出来る。情報webサーバマネージメントssh情報192.168.14.200はweb公開用なのでicmpとhttpしか許可をしていない手元のPCは2960-Bの4番ポートに接続してください。dhcpが振ってきます。192.168.14.200の設定が入っている。192.168.30.130の設定が入っているインターフェースのinside,outsideは図に書いています。ありますが今回は直接結線をしています。この問題にvrfは関係ありませんトラブルの概要pingが通るのにwebが見れないということは一見サーバ側の問題かなと思うかもしれませんが、その割には手元機材の情報があったり、webサーバは特に問題が無いように見えます。この問題実はpingを返しているのはWebサーバではなく、NATルータです。解説この問題ではサーバ側の不備は一切なくRouter2が原因です。cisco機器で内部と外部を同セグに見せるようなNATをする場合にありがちな設定ミスです。NATの設定に不備があるため、NATされたアドレスがルーティングテーブルに乗らずRouter2がNATのアドレスを持ってしまいRouter2がpingの応答をしてしまっています。NATのルーティングを正しく書けば解決します。講評この問題が解放されたのが遅かった為解答したチームはありませんでした。pingが届くのにwebが見れないと聞いたらみなさんはとりあえずサーバに問題があるのでは?と考え問題の無いサーバ側を調べていたかと思われます。複雑にNATを使用した場合(例えば同セグに見せるようなNAT)ping返答しても設定ミスでルータが返してあることがたまにあるのでみなさん気を付けてください。が社では事業拡大に向けて、これまで別々に活躍していた2つの会社を統合することにした。間は本社で余ったルーター1台を間に挟んで通信をすることにした。エンジニアは既に設計の方に出払ってしまっているため本社にいる手の空いている人間に構築をさせた。本人から完成しましたと連絡を受けネットワークを使ってみたのだが2つの事務所から疎通が全く取れず、困っている状況である。早急に担当したエンジニアに設計をやり直せといったのだが本人は「めとりっく?の値とかワケワカンナイ...無理っしょ」なんてブツブツつぶやき「ユ○バで彼女とデートがあるんで。」と言い残して帰ってしまった。こちらでは君たちだけが頼りである。すまないが早急に対応をお願いしたい。帰った部下にはきついお灸を据えたいので原因の報告も合わせて頼みたい。それからエンジニアの数人には連絡が取れるので、もし何か必要なことがあれば彼らに聞いてくれ。本社から持ち込んだルーターは892jである。禁止事項892jを除くルーターへのアクセス全般(設定変更、コンフィグ参照など)ルーティングプロトコルの変更IPアドレス、サブネットマスクの変更スタート各拠点のルーターから892jに疎通が取れない892jを超えて拠点間で通信ができないゴール892jと隣接が結べていること892jを超えて各拠点で通信ができること対向拠点ルーターに192.168.12.1/26が存在します。疎通確認に使用してください。(任意)トラブルの概要この問題は、これまで別々に活躍していた支社を統合し新たな事務所への移行作業を行っている最中を想定しました。ネットワークのトポロジは次のようになっています。問題の初期状態では参加者の手元PCからLoopBackに疎通がとれません。するとと下記のようになっているはずです。exitちなみですが、参加者から設定できるルータ間ではEIGRPが動作しています。255.255.255.192ネットワークアドレスとサブネット(ワイルドカードマスク)が一致していません。互いに隣接を結ぶことは出来ません。この部分から書き換えます。問題文の制約としてIPアドレス、サブネットマスクの変更を設けてあるので変更するのはEIGRPの設定部分になります。0.0.0.63これでEIGRPの隣接問題が解消します。この状態ではLoopBackの経路情報が来ていません。今回、この問題ではトポロジ図上ではこのようになっています。BlackBoxは今回参加者の皆さんが触ることの出来ない装置になっています。中ではVRFが稼働しています。このVRFを問題に関係する部分だけ抜き出してみると下記のようなトポロジに変化しますLoopBackと892jの間はOSPFが動作しているのです。今回参加者の一部から「二種類のルーティングプロトコルが動作しているがどちらが正しいのか?」という質問を受けたことがありますがこの問題においてはどちらも動作するのが正常な動きとしています。892jに入っているOSPFのコンフィグを見てみます。12先程と同じくインターフェイスも見てみます。255.255.255.192比較します。255.255.255.192ここでも値が一致していません。同じように修正を行います。12これで値が一致します。OSPFが隣接を結ぶ条件として大まかですがIP、ワイルドカードマスクの一致。hello-time,hold-timeの一致となります。BlackBoxの一部を抜き出すと設定には以下が投入されています。exit!!OSPFのHello-intervalはデフォルト設定で10秒になっています。今回の設定では15秒に設定しているのでこのままでは対向と設定が合いません。設定を15秒に合わせなければなりませんがそもそもBlackBoxは設定も参照もできません。15秒感覚で送信されていることを突き止めるのか。892jで下記のコマンドを叩けば何秒で送信されているのか確認することが出来ます。helloこれを叩いて数秒待つと対向からHelloパケットが送信されている様子を確認する事ができます。今回は15秒ですのでおおよそ15秒感覚で受信をします。確認したら設定を変更します。15892j(config-if)#exitこれでやっとOSPFとEIGRP両方の設定が完了し隣接を結ぶことが出来ます。この状態で疎通確認をしても疎通はできません。今回、参加者側とLoopBack側ではルーティングプロトコルが使用されているため境目となる892jでは特殊な設定が必要になってきます。ここで使われるのがルート再配送と呼ばれるものです。ルート再配送とはhttp://www.infraexpert.com/study/routecontrol01.htmlこちらを参考にするとわかりやすいかと思われます。OSPFから設定を加えます。subnets892J(config-router)#exit今回のOSPF再配送設定ではサブネット化されたネットワークをEIGRPにも含む形になるのでsubnetsコマンドが必要になってきます。上記を加えるとOSPFの設定は完了です。同様にEIGRP側の設定も行います。1500892J(config-router)#exit先程とは違いコマンドが一行増えています。EIGRPでは、OSPFで再配布されたネットワークはメトリック値がデフォルトで∞(無限大)に設定されているので、メトリック値の値を適切にしなければ到達不能のネットワークになってしまいます。そのため、default-metricコマンドで値を詳細に設定する事により値を適切なものに変更し、到達性のあるネットワークにします。サブコマンドの意味は次の通りになっています。&lt;MTU&gt;以上ですべての設定が完了です。1500については数値全指定なので運営へ質問をしなければ満点を獲得することが出来ない状況でした。exit採点基準(任意)EIGRPのワイルドカードマスクが間違っているのを指摘&修正OSPFのワイルドカードマスクが間違っていることを指摘&修正OSPFのHELLOタイマーが隣接と一致していない事の指摘&修正ルート再配送EIGRPにデフォルトメトリックの設定が入っている(運営側指定の値以外)指定の値以外を指定した場合は満点を与えないルート再配送EIGRPにデフォルトメトリックの設定が入っている(運営側指定の値)指定の値は運営に質問が来た場合に答えるものとする講評(任意)最後の方に出題されるライスボス問題でした。2日目の午後付近で回答可能になった問題だった&問題が複雑過ぎた為か回答できたチームはいませんでした。個人的には意外と解いてくれるチームが出るのかな。思っていたので少し残念な気分です。いえ、私が参加者でもこの問題は意地悪すぎる部分が多いと感じるところもありますのでその辺は反省してます...。この問題解説で参加者の皆さんが少しでも理解をしていただけたら出題者としても嬉しい限りです。/カテゴリーICTSC9どうも無線LAN担当をしたnasuです。コンテストやカンファレンスで提供する無線LANというのは本当に難しい、目に見えないのでまた難しい(まあLANケーブルに流れるパケットも目に見えませんが・・・)ものです。家庭用みたいに置いてつなぐだけでは使えないし、クライアント数がいるからといってAPの数を増やせばいいわけではないし、会場によっては電波状況がーなど色々あり、有線とは全く違う知識が必要になってきます。今回はシスコシステムズ合同会社様から以下の機材をお借りさせていただきました。5台テーマが冗長なんでもちろんWLCも冗長するよね(笑)と言われて今回はWLCまで2台で運用しました。無線LANのいろはさて無線LANのお話をするわけですが、知らない方も多いと思いますので提供した無線LANの話に関わる技術だけを抜粋して簡単に説明します。無線LANについて詳しく知りたい方は以下のサイトなどを参考にしてください。Selection)とは5Ghz帯は2.4Ghzと比べて干渉するものは少ないですが、既に使われているものがあります。それは気象レーダーや軍事レーダーといったものです。5Ghzで使えるチャンネル数は19個ありますが、レーダーがいるのはW53,W56と呼ばれる計15個のチャンネルです。確実に干渉されないのは4個のチャンネルしかありません。無線LANはレーダーを妨害してはいけないため、レーダーがいたら自動的にチャンネルを切り替えるという機能の実装が義務付けられています。Selection)といいます。チャンネル変更が起きるとユーザー側は接続が途切れ不安定になります。会場について今回会場を提供してくださったさくらインターネット様からは自社で使っているチャンネル以外で無線LANを提供してほしいという要望がありました。したがってホットステージ序盤はさくらインターネット様が使っていないチャンネルでの運用をしていたわけですが、レーダーが地理に的に近くある為かDFSが頻繁に来てしまいました。W52というのレーダーが使われていないチャンネルで運用する→W52は既にさくら様で使用しておりましたので、混線を避けるためにW52は使いませんでした。会場付近でレーダーがいないチャンネルを探すこれはDFSを確認したらログを見て、DFSを受けたチャンネルの使用を設定からオフにしていき、会場付近でレーダーが使われていないチャンネルに絞っていく感じです。ホットステージは約2週間あったのでその期間でDFSを受けたらオフにしていくを繰り返したら、ホットステージ後半ではDFSをあまり受けないチャンネルに絞れたと思います。最終的に6個チャンネルで提供しました。Point(以下AP)についてWLC集中管理型についてさて無線LAN設計はまず大きく分けて2つあります。集中管理型トラコンでは集中管理型を採用しています。WLC1台に設定を入れるだけで、全てのAPの設定が変更でき管理がとても簡単です。集中管理型を採用していますが、通信パケットはWLCを経由させてはいません。これはFlexConnectと呼ばれるものを使用しております。FlexConnectを利用する利点はWLCに障害が起きてもダウンタイム無しで運用することが可能です。ProfileAPは設置する場所によって出力などを調整する必要があります。教室や部屋といった狭い場所に置くAPの場合は端末とAPの物理的な間が近いので早いデータ・レートが保証されます。逆に今回の競技エリアのような広い場所に置くAPの場合は端末とAPが近い人もいれば遠い人もいるので遅いデータ・レートの端末もいます。無線LANは同時に複数の端末が通信してるように見えますが、瞬間的には必ず1対1の通信が行われていて他の端末は待機状態になっています。データ・レートが遅い端末が1台でもいると他の端末の待機時間が増えてしまい全体の端末の通信が遅くなる原因となります。これを防ぐために遅いデータ・レートの端末は通信させないという設定を入れる必要がありますが、置く場所のAPによっては遅い端末もいるので設定の調整をする必要があります。Profileという機能を使います。Groupに紐付けをします。802.1X認証とRadiusサーバについてさて今回参加者のみなさんはictsc9というssidに繋いでもらいました。全チーム同じssidなのにちゃんと自分のチームのネットワークにつながっているけどどうやってこれをやっているのだろう:thinking_face:と思う方がいたかもしれません。idとpwを使ってるからこれで識別しているのだろうなと想像がついたと思います。Overrideという機能を利用してradiusサーバから返されるradius属性に基づいて、個々のチームのvlanを変えました。radiussサーバにこのユーザはこのvlanという情報を記載して、WLCが認証の際にユーザ情報を元に個々にvlanを分けていますRadiusサーバにはfreeradiusというパッケージを使用しました。AcceptメッセージでWLCにVLAN情報を送信する機能があります。VLAN情報を送信するには、Radiusポリシーに必要な3つのRadius属性を設定します。割り当てたいvlanidWLCの冗長について今回のテーマが冗長化ということもありCisco様よりWLCを2台お借りし運用しておりました。今回Juniper様よりお借りしたSRXやQFXで構成した両方がアクティブの状態で動作する訳ではなく、それぞれPrimaryとSecondaryの状態で使用しました。この構成はPrimaryとなっているWLCが常にワイヤレスクライアントの認証等を行います。それがなんらかのトラブルで動作しなくなった時に、SecondaryとなっているWLCがアクティブに遷移して動作する特徴を持ちます。簡単にどんな設定をしたかを以下に箇条書きでまとめます。具体的に説明し始めるとものすごく長くなってしまうので冗長化の設定をするときに参考になったサイトのURLを記載しますのでご確認ください。Availabilityhttp://www.infraexpert.com/study/wireless41.htmlまとめRadius認証の周知が不足していて、一部端末が繋がらないというトラブルがあり申し訳ありません。競技中の運用は基本的に安定した通信が出来ていたと思いますが、突発的に通信が良い悪いなどがありトラブルシュートに大変でした。2.4Ghzは不安定な要素が多いので提供をやめてしまいたいというのがありましたが、古い端末で2.4Ghzしか対応してないものなどがあるので提供しました。このような場だと5Ghzに対応してない端末はほぼいない、居ても有線LANでの対応ができるので安定を求めるのであれば2.4Ghzはやめたほうがいいかもしれません。Nexus5548,2248を担当したnasuです。5548はデータセンター用スイッチです。ExtenderといってNexus7000や5000の親がいないと動作しないスイッチとなります。これらの機材を今回バックボーンのL2スイッチとして使用させていただきました。L2でしか運用しなかったので、バックボーンの中では一番楽に構築が出来ました。vPC(拡張vPC)という技術を使いました。PortChannel)というのはJuniperのMC-LAGと似てスイッチまたぎのLAGを構成が出来る技術です。拡張vPCを使うとFexであるNexus2248を親であるNexus5548のペアにデュアルホーム接続され、それと同時FEX配下のホストにもvPCを使用してFEXのペアにデュアルホームに接続ができます。IDを変更しています)を出しながら簡単に説明していきたいと思います。peer-linkと言われる10GEのポートチャネルを繋ぐ必要があります。vPCの設定ではvPCの設定を入れていきます。最初にマネジメント用インターフェースにIPアドレスを設定してお互いが疎通できる状態にしておきます。peer-linkの設定をいれます。peer-link以上でvpcの接続は完了です。"FEX102"ここまでの設定でお互いの親の5kが2kを2台とも認識ができます。まとめデータセンタースイッチをL2でしか使わなかったのでconfigも短いものでした。それでもvlan定義はたくさんあるのでそこだけが長くなりましたね。今回Nexus5kと2kを繋ぐために使ったモジュールはFET-10Gといって普通のSFP+モジュールとは違うものを使いました。見た目はほぼSPF+と同じなのですが、FET-10GはNexus同士を繋ぐ専用のモジュールで、それ以外の用途では使うことはできないようです。今回も踏んだバグトラコンでは毎回何かしらのバグを踏みます。今回も変なバグを見つけました。これじゃない?」インフラリーダ「私たちはまたバグを踏んでしまったのか」どうやら今回使ってたNX-OSのバージョンではVLAN定義をまとめて流すと、再起動するというバグがあったみたいです。流せば再起動はしないようなので、そのようにして対処しました。