/
カテゴリー

こんにちは、バックボーンなどインフラを担当した川原です。

参加者の皆さん、参加してくださり誠にありがとうございました。今回も30分のサーバの電源断、1日目のWi-Fiの不調など、皆さんにご不便をお掛けしてしまい申し訳ありませんでした。特にWi-Fiにつきましては、アンケートでも厳しい意見が多かったためバックボーン担当として重く受け止めています。ただ、Wi-Fiの調子は人数が増えてみないとわからないことも多いです。年々、改善を繰り返しながら取り組んでおりますので今後とも率直な意見をくださりながら参加して楽しんでいただければと思います。

また、機材提供・協力をはじめとした協賛企業の皆様、毎度のことながら我々学生の無茶な要望を受け入れてくださり誠にありがとうございます。今回も参加者へのインフラを提供する傍ら、運営学生も貴重な体験をすることができました。

さて、堅苦しい話はここまでとして今回も大規模なインフラを組んで皆さんに提供しました。LTなどでも話しましたが、改めてブログにまとめることで多くの人にネットワークやサーバに興味を持って欲しいと思っています。

今回のインフラは何人かで担当しているので、担当した各人がブログへ投稿することになっています。この記事では最初の記事として全体の総括をしていきたいと思います。

個別の解説は以下のとおりです.

バックボーンについて

我々ICTSC運営において、バックボーンとは全チームが問題を解くために使うインフラのことを言います。バックボーン担当は作問など大会開催に必要なタスクをこなす傍ら、興味のある人が思い思いのインフラを構築していくことになります。

バックボーンの目的は以下です。

  • 参加者が問題を快適に解ける環境を提供する
  • ICTSC運営が問題を提供しやすい環境を提供する

つまり、1に参加者、2に参加者、3くらいに問題作成者のことを考えて作るわけです。勘違いすると安定感に欠けた目的のわからないものになってしまうので、気をつけなくてはいけません。また、どんな問題でも出題できるように準備をしています。インフラ的に難しいからこの問題はボツで…ということは極力ないようにします。

問題作成は運営発足から行われるものなので、運営発足からHotstage(本番の大会会場で本番の機材を使いながら準備する期間)中のインフラもある程度安定させなければ、よい品質の問題を用意することができなくなってしまいます。そのあたりの差し引きをしながら本番環境を構築していくのもバックボーン構築の醍醐味です。

今回のバックボーンテーマについて

最近のICTSCのバックボーンはテーマを決めて構築を行っています。第7回は安定感、第8回は仮想化でした。

今回は… 冗長化!!

ということで構築されたバックボーンネットワークは以下のように、今回のテーマに則ってネットワーク機材をすべて冗長化しています。

各機材の冗長構成については各担当の者がそれぞれ本ブログに投稿することになっているので楽しみにしていてください。概要については当日の発表資料を以下に用意しました。

当日発生したトラブルについて

どれだけ準備しようがトラブルは起きてしまうものです。当日起きてしまったトラブルをまとめていきます。

1日目 11:30頃 サーバ電源断

1日目 11:30頃にサーバの全台が電源断するという障害が発生しました。昼食が早まったことで解答不可能になった時間は比較的少なくなりましたが、ご迷惑をお掛けしてしまい誠に申し訳ございませんでした。

原因

我々の不手際によって協賛の皆さんが半分のサーバを接続している電源系統でPCの充電をしてしまったことによる過負荷でおきたものであると考えられます。また、その後私が生きていたサーバのコンセントを抜くというミスオペを犯してしまいました。

改善策

改善策としては、サーバは冗長化が行えていなかったためサーバの電源をそのような危険性がある電源からではなくアクセスしにくい電源を選択するなどがあります。ネットワーク機器は最悪電源が落ちても2系統とっていましたし、再起動も比較的高速に行えます。何よりサーバの電源断はHDDなどが故障する可能性もあります。

ミスオペに関してはダブルチェックなどを行うなどがあります。ただ、復旧を一丸となって行えたのでとても良かったと思います。私を責めずに冷静に私の指示に従ってくれたみんなには感謝です。

1日目 懇親会

Wi-Fiの調子が悪いという話を多くの方から聞きました。懇親会後、原因の調査と修正を行いました。2日目の開始時にも軽くお伝えしましたが、ストレスを感じさせてしまい申し訳ありませんでした。

原因

2.4Ghz帯の電波が強すぎたことによって、多くのクライアントが2.4Ghz帯で接続し混線したものと考えられます。

改善策

2.4Ghz帯の電波を弱める、5Ghz帯でクライアントが接続できているか監視するなどの対策を行いました。我々の感知している範囲では2日目は快適に使用できていたと聞いています。

しかし、競技時間の半分を不快な環境で回答していたことについては反省会でも話題になりました。次回以降はWi-Fiの調子などを早めに聞く機会を設け、早めに対策が行えるように努力します。みなさんもストレスを感じた場合は気軽に問い合わせ下さい。バックボーン側に原因がある場合は早急に対応いたします。

また、Wi-Fiの調子は当日の人数が入らないとわからないことも多いです。次回以降の運営からも当日アナウンスがあるとは思いますが、Wi−Fiが不調の場合は有線接続の使用をご検討ください。

2日目 13時頃

一部グローバルIP(Googleなど)への接続ができなくなるという障害が発生しました。障害は3分ほど継続した後、収束しました。

原因

以上の障害発生時のメトリクスを見ても、障害発生時間帯にルート数が5000経路ほど減少していました。また、こちらの設定ミスか上流からのトラフィックを受信しているのに、こちらからトラフィックが流れていませんでした。障害発生から5分以内にメトリクスを把握し上流であるHomeNOC様に確認したところ、一部障害が発生していたとお聞きしました。

しかし、このようなことが発生してもよいように上流は冗長化していましたが、うまく動作しませんでした。冗長化が動作しなかった原因としては、IPv4のフルルートを受け取っていた影響でルートの収束まで時間がかかってしまったようです。準備期間中や開催後に接続断テストを行った際には収束まで約10分の時間を要しました。

原因究明にはメトリクスによる可視化が重要であることを実感できた障害でもありました。

改善策

なぜ、収束までにここまでの時間が発生するのかは我々も理解しきれていません。勉強してきます。

フルルートの運用をしてみないとわからないことは多く存在します。このような貴重な機会をくださったHomeNOC様に感謝しております。

おまけ: ベンチマーク

今回、テンションがおかしくなってしまった運営学生は10Gbps NICをヤフオクで9本程度落札してしまいました。それをNAVTサーバに搭載し、バックボーンに組み込んでいました。大会終了後、バックボーンネットワークがどれほどの帯域を出せるのかベンチマークを取りました。

実験環境

18:13ごろから18:23ごろまでOpenstackのVM 10台から、別のVM 10台までiperf3を実行しました。以下のような経路を通り、通信を行いました。

その後、18:28以降に同様の経路でOpenstackのVM 15台から、別のVM 15台までiperf3を実行していました。

結果

わかりにくいですが、18:13ごろから18:23ごろまで 5 Gbps 、 18:28以降は 8 Gbps の流量が出ていることが右下のTraffic of servertransmit traffics of servers のグラフからわかります。このグラフは、Openstackのホストサーバの受信と送信の流量を示しています。

タイトルが消えてしまっていますが右上のグラフがNAVT 2台の流量合計です。このグラフからも 8 Gbps まで出ていることがわかります。

真ん中の Traffics between Nexus5548 and QFX5100 のグラフはNexus5548とQFX5100の間の4本の流量をそれぞれ示しており、上半分が送信、下半分が受信になっています。このグラフだけ単位が Bytes per sec になっていることに注意してください。

考察

楽しかった!!

LACPのハッシュアルゴリズムの偏りによって、 1 Gbps * 2 を出せるサーバが確率的に 1 Gbps しか出てないことがあり、15台のVM同士の通信では 8 Gbps までしか実験を行うことができませんでした。右下の Traffic of servertransmit traffics of servers のグラフからOpenstackのVM同士の合計トラフィックが 8 Gbps しか出てないことがわかります。今回のバックボーンのキャパシティは 20 Gbps であったため、今回のベンチマークはバックボーンのベンチマークというよりサーバのベンチマークになってしまいました。特に左下の CPU idle のグラフでは各ホストのcpu0の idle が大幅に下回っており、サーバで 10 Gbps を処理をする際割り込みが多く発生することが大変であるという意味がわかりました。

Traffics between Nexus5548 and QFX5100 のグラフから Nexus5548 <==> QFX5100 間の通信のロードバランスは非常に美しく4つのインターフェイスに対して等コストバランシングができていることがわかりました。 Nexus5548 ==> QFX5100Nexus5548 <== QFX5100 両方向で等コストバランシングされていることから両方の機種がよい性能を持っていることがわかりました。

NAVTは 10 Gbps * 2 のNICを刺したサーバの2台構成で 8 Gbps は余裕であることがわかりました。 :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)に対しての通信で以下の現象が発生した。
– ラボのPCからwebサーバ(192.168.14.200)に向かってpingを打つと返ってくる
– Webページを見ることが出来ない

担当者「192.168.14.200に対してpingが返ってくるんだからwebページが見れないのはサーバ屋の問題だ!」

諸君にはRouter2と、webサーバに接続してトラブルシュートをし原因を突き止めてwebページが見れるようにして欲しい。
今回動いているwebサーバは公開用のipアドレスとは別にマネージメントのipアドレスがあるのでそこからsshすることができる。

制約

  • 設定を変更できるのはwebサーバとRouter2(1841)のみである
  • Router2(1841)のデフォルトルートを変えてはいけない

スタート

webサーバ(natip 192.168.14.200)に対してpingは通るのにwebページが見れない。

ゴール

webサーバ(natip 192.168.14.200)にpingも通り、またapacheのテストページを見ることが出来る。

情報

  • webサーバマネージメントssh情報
  • 192.168.14.200はweb公開用なのでicmpとhttpしか許可をしていない
  • 手元のPCは2960-Bの4番ポートに接続してください。dhcpが振ってきます。
  • Router2のアクセス情報
  • Router1は ip nat outside source static 192.168.14.70 192.168.14.200の設定が入っている。
  • Router3は ip nat inside source static 192.168.14.70 192.168.30.130の設定が入っている
  • インターフェースのinside,outsideは図に書いています。
  • 問題文に プロバイダーサービスのl2vpnを利用して とありますが今回は直接結線をしています。
  • この問題にvrfは関係ありません

トラブルの概要

pingが通るのにwebが見れないということは一見サーバ側の問題かなと思うかもしれませんが、その割には手元機材の情報があったり、webサーバは特に問題が無いように見えます。
この問題実はpingを返しているのはWebサーバではなく、NATルータです。

解説

この問題ではサーバ側の不備は一切なくRouter2が原因です。
cisco機器で内部と外部を同セグに見せるようなNATをする場合にありがちな設定ミスです。
NATの設定に不備があるため、NATされたアドレスがルーティングテーブルに乗らずRouter2がNATのアドレスを持ってしまいRouter2がpingの応答をしてしまっています。
なのでNATのルーティングを正しく書けば解決します。

解答例

Router2

- ip route 192.168.14.130 255.255.255.255 FastEthernet0/1.1647
+ ip nat outside source static 192.168.14.130 192.168.14.70 add-route
+ ip route 192.168.14.130 255.255.255.255 192.168.14.131

採点基準

NATに問題があることの指摘、及び設定変更してwebが見れる→満点

講評

この問題が解放されたのが遅かった為解答したチームはありませんでした。
pingが届くのにwebが見れないと聞いたらみなさんはとりあえずサーバに問題があるのでは?と考え問題の無いサーバ側を調べていたかと思われます。
複雑にNATを使用した場合(例えば同セグに見せるようなNAT)ping返答しても設定ミスでルータが返してあることがたまにあるのでみなさん気を付けてください。

 /

問題文

我が社では事業拡大に向けて、これまで別々に活躍していた2つの会社を統合することにした。

事務所を新たに開設したのだが、ネットワーク設計がまだ途中のため、
暫くの間は本社で余ったルーター1台を間に挟んで通信をすることにした。

しかし、エンジニアは既に設計の方に出払ってしまっているため本社にいる手の空いている人間に構築をさせた。

本人から完成しましたと連絡を受けネットワークを使ってみたのだが2つの事務所から疎通が全く取れず、困っている状況である。

早急に担当したエンジニアに設計をやり直せといったのだが本人は「めとりっく?の値とかワケワカンナイ…無理っしょ」なんてブツブツつぶやき

「ユ○バで彼女とデートがあるんで。」

と言い残して帰ってしまった。

こちらでは君たちだけが頼りである。すまないが早急に対応をお願いしたい。
帰った部下にはきついお灸を据えたいので原因の報告も合わせて頼みたい。

それからエンジニアの数人には連絡が取れるので、もし何か必要なことがあれば彼らに聞いてくれ。

本社から持ち込んだルーターは892jである。

制約

  • 禁止事項
    • 892jを除くルーターへのアクセス全般(設定変更、コンフィグ参照など)
    • ルーティングプロトコルの変更
    • IPアドレス、サブネットマスクの変更

スタート

  • 各拠点のルーターから892jに疎通が取れない
  • 892jを超えて拠点間で通信ができない

ゴール

  • 892jと隣接が結べていること
  • 892jを超えて各拠点で通信ができること
    • 対向拠点ルーターに192.168.12.1/26が存在します。疎通確認に使用してください。
  • 報告事項
    • 疎通が出来なかった原因(複数ある場合は全て)
    • 上記にともない追加、削除、変更を行ったコマンド全て
    • 892jのshow run結果 ## 情報 (任意)

トラブルの概要

この問題は、これまで別々に活躍していた支社を統合し新たな事務所への移行作業を行っている最中を想定しました。

ネットワークのトポロジは次のようになっています。

トポ図

問題の初期状態では参加者の手元PCからLoopBackに疎通がとれません。

解説 (必須)

まずはshow run の結果を見てみます。
するとと下記のようになっているはずです。

!
router ospf 721 vrf vrf12
    router-id 2.2.2.2
    network 192.168.12.0 0.0.0.3 area 12
    exit
!
!
router eigrp 406
    address-family ipv4 vrf vrf12 autonomous-system 406
      eigrp router-id 2.2.2.2
      network 192.168.12.0 0.0.0.3
      exit

ちなみですが、参加者から設定できるルータ間ではEIGRPが動作しています。
ですのでまずは、EIGRPのルーティングの設定部分を見てみます

892j#show run | begin eigrp
router eigrp 406
    address-family ipv4 vrf vrf12 autonomous-system 406
      eigrp router-id 2.2.2.2
      network 192.168.12.0 0.0.0.3
~(後略)~

次にインターフェイスのIPを見てみます

892J#show run | begin interface

interface FastEthernet8.0.{$team_id}39
 encapsulation dot1Q 0.{$team_id}39
 ip vrf forwarding vrf12
 ip address 192.168.12.65 255.255.255.192
!
interface GigabitEthernet0
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0.0.{$team_id}40
 encapsulation dot1Q 0.{$team_id}40
 ip vrf forwarding vrf12
 ip address 192.168.12.129 255.255.255.192

2つを抜き出して比較します

 network 192.168.12.0 0.0.0.3
 ip address 192.168.12.129 255.255.255.192

ネットワークアドレスとサブネット(ワイルドカードマスク)が一致していません。

動的においてはマスク値が一致していないと経路情報の交換が出来ず、
互いに隣接を結ぶことは出来ません。

まずはこの部分から書き換えます。
問題文の制約としてIPアドレス、サブネットマスクの変更を設けてあるので
変更するのはEIGRPの設定部分になります。

892j#conf t
892J(config)#router eigrp 406
892J(config-router)#no network 192.168.12.0 0.0.0.3 
892J(config-router)network 192.168.12.128 0.0.0.63

これでEIGRPの隣接問題が解消します。

しかし、まだこの状態ではLoopBackの経路情報が来ていません。

今回、この問題ではトポロジ図上ではこのようになっています。

BlackBoxは今回参加者の皆さんが触ることの出来ない装置になっています。
中ではVRFが稼働しています。このVRFを問題に関係する部分だけ抜き出してみると
下記のようなトポロジに変化します

LoopBackと892jの間はOSPFが動作しているのです。
今回参加者の一部から「二種類のルーティングプロトコルが動作しているがどちらが正しいのか?」
という質問を受けたことがありますがこの問題においてはどちらも動作するのが正常な動きとしています。

892jに入っているOSPFのコンフィグを見てみます。
(この問題に関係する部分だけを抜き出します)

892j#show run | begin ospf

router ospf 721 vrf vrf12
 router-id 2.2.2.2
 network 192.168.12.0 0.0.0.3 area 12

先程と同じくインターフェイスも見てみます。

892j#show run | begin interface 

interface FastEthernet8.0.{$team_id}39
 encapsulation dot1Q 0.{$team_id}39
 ip vrf forwarding vrf12
 ip address 192.168.12.65 255.255.255.192

比較します。

network 192.168.12.0 0.0.0.3 area 12
ip address 192.168.12.65 255.255.255.192

ここでも値が一致していません。
同じように修正を行います。

892j#conf t
892J(config)#router ospf 721 vrf vrf12
892J(config-router)#no network 192.168.12.0 0.0.0.3 area 12
892J(config-router)#network 192.168.12.64 0.0.0.63 area 12

これで値が一致します。
ですが、まだ隣接を結びません。

OSPFが隣接を結ぶ条件として大まかですが

  • IP、ワイルドカードマスクの一致。
  • hello-time,hold-timeの一致

となります。
BlackBoxの一部を抜き出すと設定には以下が投入されています。

!
!
interface fa 0/1.{$team_id}9
    ip vrf forwarding vrf12-ospf
    encapsulation dot1Q {$team_id}9
    ip address 192.168.12.126 255.255.255.192
    no shut
    ip ospf hello-interval 15
    exit
!
!

OSPFのHello-intervalはデフォルト設定で10秒になっています。
しかし今回の設定では15秒に設定しているのでこのままでは対向と設定が合いません。
設定を15秒に合わせなければなりませんがそもそもBlackBoxは設定も参照もできません。
では、15秒感覚で送信されていることを突き止めるのか。

892jで下記のコマンドを叩けば何秒で送信されているのか確認することが出来ます。

892j# debug ip ospf hello

これを叩いて数秒待つと対向からHelloパケットが送信されている様子を確認する事ができます。
今回は15秒ですのでおおよそ15秒感覚で受信をします。

確認したら設定を変更します。

892j#no debug all
892j#conf t
892j(config)#interface fa 8.139
892j(config-if)#ip ospf hello-interval 15
892j(config-if)#exit

これでやっとOSPFとEIGRP両方の設定が完了し隣接を結ぶことが出来ます。
ですが、この状態で疎通確認をしても疎通はできません。

今回、参加者側とLoopBack側ではルーティングプロトコルが使用されているため
境目となる892jでは特殊な設定が必要になってきます。

ここで使われるのがルート再配送と呼ばれるものです。

ルート再配送とは
http://www.infraexpert.com/study/routecontrol01.html

こちらを参考にするとわかりやすいかと思われます。

まずはOSPFから設定を加えます。

892j#conf t
892J(config)#router ospf 721 vrf vrf12 
892J(config-router)#Redistribute eigrp 406 subnets
892J(config-router)#exit

今回のOSPF再配送設定ではサブネット化されたネットワークをEIGRPにも含む形になるので
subnetsコマンドが必要になってきます。

上記を加えるとOSPFの設定は完了です。

同様にEIGRP側の設定も行います。

892j#conf t
892J(config)#router eigrp 406
892J(config-router)#Redistribute ospf 721 
892J(config-router)#default-metric 100000 100 255 1 1500
892J(config-router)#exit

先程とは違いコマンドが一行増えています。
EIGRPでは、OSPFで再配布されたネットワークはメトリック値がデフォルトで
∞(無限大)に設定されているので、メトリック値の値を適切にしなければ
到達不能のネットワークになってしまいます。
そのため、default-metricコマンドで値を詳細に設定する事により
値を適切なものに変更し、到達性のあるネットワークにします。

サブコマンドの意味は次の通りになっています。

892J(config-router)#default-metric &lt;bandwidth&gt; &lt;delay&gt; &lt;reliability&gt; &lt;load&gt; &lt;MTU&gt;

以上ですべての設定が完了です。

解答例

ちなみにですが、最後のに記載されてあるdefault-metric 100000 100 255 1 1500については
数値全指定なので運営へ質問をしなければ満点を獲得することが出来ない状況でした。

router ospf 721 vrf vrf12

    router-id 2.2.2.2
    network 192.168.12.64 0.0.0.63 area 12
    Redistribute eigrp 406 subnets
    default-metric 64 ←(なくてもOK。)
    exit
!
!
interface fa 8.{$team_id}9
    ip ospf hello-interval 15
    exit

!
!

router eigrp 406
  address-family ipv4 vrf vrf12 autonomous-system 406
    eigrp router-id 2.2.2.2
    network 192.168.12.128 0.0.0.63
    Redistribute ospf 721 
    default-metric 100000 100 255 1 1500 
    exit
  exit

採点基準(任意)

  • EIGRPのワイルドカードマスクが間違っているのを指摘&修正
  • OSPFのワイルドカードマスクが間違っていることを指摘&修正
  • OSPFのHELLOタイマーが隣接と一致していない事の指摘&修正
  • ルート再配送EIGRPにデフォルトメトリックの設定が入っている(運営側指定の値以外)
    • 指定の値以外を指定した場合は満点を与えない
  • ルート再配送EIGRPにデフォルトメトリックの設定が入っている(運営側指定の値)
    • 指定の値は運営に質問が来た場合に答えるものとする

講評(任意)

最後の方に出題されるライスボス問題でした。
2日目の午後付近で回答可能になった問題だった&問題が複雑過ぎた為か
回答できたチームはいませんでした。
個人的には意外と解いてくれるチームが出るのかな。と思っていたので少し残念な気分です。
とはいえ、私が参加者でもこの問題は意地悪すぎる部分が多いと感じるところもありますので
その辺は反省してます…。

この問題解説で参加者の皆さんが少しでも理解をしていただけたら
出題者としても嬉しい限りです。

 /
カテゴリー

どうも無線LAN担当をしたnasuです。
コンテストやカンファレンスで提供する無線LANというのは本当に難しい、目に見えないのでまた難しい(まあLANケーブルに流れるパケットも目に見えませんが・・・)ものです。
家庭用みたいに置いてつなぐだけでは使えないし、クライアント数がいるからといってAPの数を増やせばいいわけではないし、会場によっては電波状況がーなど色々あり、有線とは全く違う知識が必要になってきます。
さて今回はシスコシステムズ合同会社様から以下の機材をお借りさせていただきました。
– AIR-CT2504-15(WLC) * 2台
– AIR-CAP3702E(AP) * 5台
テーマが冗長なんでもちろんWLCも冗長するよね(笑)と言われて今回はWLCまで2台で運用しました。

無線LANのいろは

さて無線LANのお話をするわけですが、知らない方も多いと思いますので提供した無線LANの話に関わる技術だけを抜粋して簡単に説明します。
無線LANについて詳しく知りたい方は以下のサイトなどを参考にしてください。
https://www.allied-telesis.co.jp/products/list/wireless/knowl.html
http://www.infraexpert.com/study/study11.html

2.4Ghzと5Ghzとは

  • 2.4Ghzの特徴
    • 壁や床などの障害物に強い
    • チャンネル数が少ない(被らずに使えるチャンネル数は3個)
    • bluetoothや電子レンジなどとチャンネルが被り干渉する
    • 速度は遅め
  • 5Ghzの特徴
    • 壁や床などの障害物に弱い
    • チャンネル数が多い(使えるチャンネル数は19個)
    • 干渉するものは少ない
    • 速度は早い
    • DFSによるチャンネル変更がある

DFS(Dynamic Frequency Selection)とは

5Ghz帯は2.4Ghzと比べて干渉するものは少ないですが、既に使われているものがあります。
それは気象レーダーや軍事レーダーといったものです。
5Ghzで使えるチャンネル数は19個ありますが、レーダーがいるのはW53,W56と呼ばれる計15個のチャンネルです。なので確実に干渉されないのは4個のチャンネルしかありません。
無線LANはレーダーを妨害してはいけないため、レーダーがいたら自動的にチャンネルを切り替えるという機能の実装が義務付けられています。このチャンネルを変更する機能をDFS(Dynamic Frequency Selection)といいます。
チャンネル変更が起きるとユーザー側は接続が途切れ不安定になります。

会場について

今回会場を提供してくださったさくらインターネット様からは自社で使っているチャンネル以外で無線LANを提供してほしいという要望がありました。
したがってホットステージ序盤はさくらインターネット様が使っていないチャンネルでの運用をしていたわけですが、レーダーが地理に的に近くある為かDFSが頻繁に来てしまいました。

DFSの対策をするには以下があります
– W52というのレーダーが使われていないチャンネルで運用する
→W52は既にさくら様で使用しておりましたので、混線を避けるためにW52は使いませんでした。

  • 会場付近でレーダーがいないチャンネルを探す
    これはDFSを確認したらログを見て、DFSを受けたチャンネルの使用を設定からオフにしていき、会場付近でレーダーが使われていないチャンネルに絞っていく感じです。
    ホットステージは約2週間あったのでその期間でDFSを受けたらオフにしていくを繰り返したら、ホットステージ後半ではDFSをあまり受けないチャンネルに絞れたと思います。
    最終的に6個チャンネルで提供しました。

CiscoのWireless LAN Controller(以下WLC)とAccess Point(以下AP)について

WLC集中管理型について

さて無線LAN設計はまず大きく分けて2つあります。
– 分散管理型(自律型)
– 集中管理型

トラコンでは集中管理型を採用しています。
WLC1台に設定を入れるだけで、全てのAPの設定が変更でき管理がとても簡単です。
また集中管理型を採用していますが、通信パケットはWLCを経由させてはいません。
これはFlexConnectと呼ばれるものを使用しております。
FlexConnectを利用する利点はWLCに障害が起きてもダウンタイム無しで運用することが可能です。

RF Profile

APは設置する場所によって出力などを調整する必要があります。
例えば教室や部屋といった狭い場所に置くAPの場合は端末とAPの物理的な間が近いので早いデータ・レートが保証されます。
逆に今回の競技エリアのような広い場所に置くAPの場合は端末とAPが近い人もいれば遠い人もいるので遅いデータ・レートの端末もいます。
無線LANは同時に複数の端末が通信してるように見えますが、瞬間的には必ず1対1の通信が行われていて他の端末は待機状態になっています。
なのでデータ・レートが遅い端末が1台でもいると他の端末の待機時間が増えてしまい全体の端末の通信が遅くなる原因となります。
これを防ぐために遅いデータ・レートの端末は通信させないという設定を入れる必要がありますが、置く場所のAPによっては遅い端末もいるので設定の調整をする必要があります。
グローバルの設定に入れると全てのAPに設定が反映されてしまい個々のAPの設定ができなくなってしまうので、RF Profileという機能を使います。
狭い部屋に置く用データ・レートが早いものしか許可しないProfile、広い場所に置く用の遅いデータ・レートも許可するProfileといったものを用意してAP Groupに紐付けをします。

802.1X認証とRadiusサーバについて

さて今回参加者のみなさんはictsc9というssidに繋いでもらいました。
全チーム同じssidなのにちゃんと自分のチームのネットワークにつながっているけどどうやってこれをやっているのだろう:thinking_face:と思う方がいたかもしれません。
まあ恐らくはidとpwを使ってるからこれで識別しているのだろうなと想像がついたと思います。
簡単にどんなことをしてるかというとAAA Overrideという機能を利用してradiusサーバから返されるradius属性に基づいて、個々のチームのvlanを変えました。
つまりradiussサーバにこのユーザはこのvlanという情報を記載して、WLCが認証の際にユーザ情報を元に個々にvlanを分けています
Radiusサーバにはfreeradiusというパッケージを使用しました。
RadiusサーバにはRADIUS Access AcceptメッセージでWLCにVLAN情報を送信する機能があります。
VLAN情報を送信するには、Radiusポリシーに必要な3つのRadius属性を設定します。
(Radius属性についての詳細はRFC2868をお読みください)

  • Tunnel-TypeはVLANの13を当てます
  • Tunnel-Medium-Typeには802.1xの6を当てます
  • Tunnel-Private-Group-Idにこのユーザに割り当てたいvlanを指定します

/etc/freeradius/users

team01 Cleartext-Password := &quot;team01password&quot;
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = 割り当てたいvlanid

WLCの冗長について

今回のテーマが冗長化ということもありCisco様よりWLCを2台お借りし運用しておりました。ただ、今回Juniper様よりお借りしたSRXやQFXで構成した両方がアクティブの状態で動作する訳ではなく、それぞれPrimaryとSecondaryの状態で使用しました。この構成はPrimaryとなっているWLCが常にワイヤレスクライアントの認証等を行います。しかし、それがなんらかのトラブルで動作しなくなった時に、SecondaryとなっているWLCがアクティブに遷移して動作する特徴を持ちます。
簡単にどんな設定をしたかを以下に箇条書きでまとめます。

  1. WLCのMobility Groupを同じにする
  2. お互いのIPアドレスとMACアドレスを登録
  3. 使用する全てのAPにSecondary WLCを設定
  4. Primaryのダウン検知を1秒に変更

具体的に説明し始めるとものすごく長くなってしまうので冗長化の設定をするときに参考になったサイトのURLを記載しますのでご確認ください。

Cisco Wireless LAN – High Availability
http://www.infraexpert.com/study/wireless41.html

まとめ

Radius認証の周知が不足していて、一部端末が繋がらないというトラブルがあり申し訳ありません。
競技中の運用は基本的に安定した通信が出来ていたと思いますが、突発的に通信が良い悪いなどがありトラブルシュートに大変でした。
2.4Ghzは不安定な要素が多いので提供をやめてしまいたいというのがありましたが、古い端末で2.4Ghzしか対応してないものなどがあるので提供しました。
このような場だと5Ghzに対応してない端末はほぼいない、居ても有線LANでの対応ができるので安定を求めるのであれば2.4Ghzはやめたほうがいいかもしれません。

 /

Cisco Nexus 5548,2248

どうもCisco Nexus5548,2248を担当したnasuです。

今回サイバーエージェント様からお借りさせていただいたCisco Nexus 5548はデータセンター用スイッチです。
またCisco Nexus 2248はFabric ExtenderといってNexus7000や5000の親がいないと動作しないスイッチとなります。
これらの機材を今回バックボーンのL2スイッチとして使用させていただきました。
L2でしか運用しなかったので、バックボーンの中では一番楽に構築が出来ました。

Enhanced vPCについて

L2でしか使わなかったと言っても、テーマである冗長性を確保しないといけないので、Enhanced vPC(拡張vPC)という技術を使いました。
vPC(virtual PortChannel)というのはJuniperのMC-LAGと似てスイッチまたぎのLAGを構成が出来る技術です。
また拡張vPCを使うとFexであるNexus2248を親であるNexus5548のペアにデュアルホーム接続され、それと同時FEX配下のホストにもvPCを使用してFEXのペアにデュアルホームに接続ができます。

ここからは本番で実際使用したconfigの抜粋(一部IPアドレスやVLAN IDを変更しています)を出しながら簡単に説明していきたいと思います。

まずvPCを組むにはvPCを組むスイッチの渡りの線にvpc peer-linkと言われる10GEのポートチャネルを繋ぐ必要があります。

  1. vPCの設定
    ではvPCの設定を入れていきます。
    最初にマネジメント用インターフェースにIPアドレスを設定してお互いが疎通できる状態にしておきます。
    そしてN5kの渡りのインターフェイスにchannnel-group(LACP)とvpc peer-linkの設定をいれます。
  • N5k01
interface mgmt0
ip address 192.168.0.1/24

vpc domain 1
peer-keepalive destination 192.168.0.2
  • N5k02
interface mgmt0
ip address 192.168.0.2/24

vpc domain 1
peer-keepalive destination 192.168.0.1
  • N5k01 & N5k02
interface Ethernet2/15
switchport mode trunk
channel-group 1 mode active

interface Ethernet2/16
switchport mode trunk
channel-group 1 mode active

interface port-channel1
switchport mode trunk
spanning-tree port type network
speed 10000
vpc peer-link

以上でvpcの接続は完了です。

  1. FEXの設定
interface Ethernet1/1
switchport mode fex-fabric
fex associate 101
channel-group 101

interface Ethernet1/2
switchport mode fex-fabric
fex associate 102
channel-group 102

interface port-channel101
switchport mode fex-fabric
fex associate 101
vpc 101

interface port-channel102
switchport mode fex-fabric
fex associate 102
vpc 102

fex 101
description "FEX101"
fex 102
description "FEX102"

ここまでの設定でお互いの親の5kが2kを2台とも認識ができます。
最後にサーバにつなぐLAGの設定です

  1. MC-Linkの設定
  • N5k01 & N5k02
interface Ethernet101/1/1
switchport mode trunk
channel-group 11 mode active

interface Ethernet102/1/1
switchport mode trunk
channel-group 11 mode active

interface port-channel11
switchport mode trunk
spanning-tree port type edge trunk

Nexus5548,2248 まとめ

データセンタースイッチをL2でしか使わなかったのでconfigも短いものでした。
それでもvlan定義はたくさんあるのでそこだけが長くなりましたね。
今回Nexus5kと2kを繋ぐために使ったモジュールはFET-10Gといって普通のSFP+モジュールとは違うものを使いました。
見た目はほぼSPF+と同じなのですが、FET-10GはNexus同士を繋ぐ専用のモジュールで、それ以外の用途では使うことはできないようです。

今回も踏んだバグ

トラコンでは毎回何かしらのバグを踏みます。今回も変なバグを見つけました。
〜〜夜中ホテルでリモート作業してる時〜〜
インフラリーダ「突如Nexusが再起動しだしたんだけどwwだれか今入ってる?ww」
nasu「いや誰もリーダー以外は入ってないですね」
某K氏「NX-OS bug url これじゃない?」
インフラリーダ「私たちはまたバグを踏んでしまったのか」

どうやら今回使ってたNX-OSのバージョンではVLAN定義をまとめて流すと、再起動するというバグがあったみたいです。
少しづつ流せば再起動はしないようなので、そのようにして対処しました。