/
カテゴリー

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

参加者の皆さん、参加してくださり誠にありがとうございました。今回も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 &quot;FEX101&quot;
fex 102
description &quot;FEX102&quot;

ここまでの設定でお互いの親の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定義をまとめて流すと、再起動するというバグがあったみたいです。
少しづつ流せば再起動はしないようなので、そのようにして対処しました。

 /
カテゴリー

監視

はじめに

こんにちは、今回運営として主に監視の仕事をしていました源波です。

今回は、前回大会の電源トラブルからの反省を元に監視体制を強化しています。結果的には前回と同じ電源周りのトラブルで大会を一時中断せざるを得ない状況に陥りましたが、監視のおかげで原因の切り分けがスムーズに進み、早期の復旧につながったのではないかと考えています。

今大会では、大まかに上の図のような監視体制を取りました。

Grafana

Grafanaでは、PrometheusやZabbixで取得したデータをグラフ化して、値を視覚から感じ取ることができました。Grafanaの監視画面は以下のようになっていました。

監視項目については、それぞれの節で説明します。

Prometheus

前回大会までは監視ツールとしてすべてZabbixを使用していましたが、今大会からは部分的にPrometheusに移行しています。Prometheusでは、Node Exporterを用いて物理サーバーのホストOSやVMのゲストOSのステータス監視を行っていました。具体的には以下の値を取得し、可視化していました。

  • CPU使用率
  • メモリ使用率
  • ディスク容量
  • コンテストサイトのレスポンスタイム

前述した電源トラブルの際には、6台のIBM X3750 m4のうち、同系統の電源に接続していた3台のCPU使用率監視が途切れ、電源系統の異常に気づくことができました。
また、ディスク容量の監視によって、コンテストサイトのDBバックアップが正常に取れていないというトラブルに即座に気づくことができました。

Zabbix

Zabbixでは、Prometheusに移行することができなかったネットワーク機器と物理サーバーの各種センサ値の監視を行いました。また、先程の図にはありませんでしたが、VMゲストのPing,SSH監視、バックボーンのネットワーク機器、各チームに提供したネットワーク機器のPing,Telnet監視も行っていました。今回のバックボーン構成では、Home NOC Operators Group様より提供頂いたBGPフルルートを、Juniper様よりお借りしたSRX1500で受けていたので、SNMPでその経路数を取得するということも行いました。具体的には以下の値を取得していました。

  • 各ネットワーク機器のトラフィック量
  • 各ネットワーク機器のPing,Telenet疎通性
  • 各VMのPing,SSH疎通性
  • BGPルート数
  • 物理サーバーの消費電力
  • 物理サーバー内の温度

競技中は、各ネットワーク機器のトラフィックをスクリーンに移しつつ眺めていました。また、トラフィックの監視を行うことによって、「rs232c使ったことあります?」問題のAlaxalaのL2SWから流れる大量のトラフィックがバックボーン機材まで影響を与えているというトラブルを発見することができました。

2日目の昼間には、上流ISPの障害がありましたが、これもBGPのルート数が一気に5000経路ほどなくなっているのが、グラフから伝わってくるという面白い体験ができました。

graylog

graylogでは、ネットワーク機器やDNSサーバーのsyslog収集といったテキスト処理を行いました。これらは、競技中はあまり監視は行わなかったものの、競技終了後に眺めようということで記録をしてあります。

まとめ

今回監視サーバー群は、問題VMや他ライフサーバー群と同じく OpenStack上に構築してありました。電源トラブルが拡大した際には、監視サーバー群からの応答もなくなってしまうということもありました。たまたま最初に落ちたサーバーに監視サーバー群が乗っていなかったため早期の原因究明につながりましたが、次回は今回の失敗をもとに監視サーバー群は外部に設置するなどの対策を行いたいと考えています。

 /
カテゴリー

Juniper QFX5100

ictsc9トポロジ図

QFX5100を担当したnasuです。担当といってもQFXでやることはたくさんあり、一番バックボーンの中で手こずっていたのでバックボーン担当の3人全員で検証・構築をしていました。
ジュニパーネットワークス様からお借りさせていただいたQFX5100はデータセンター用ファブリックスイッチで一般的にはデータセンターのToR(Top of Rack)などで使われています。
この機材を今回はバックボーンのコアスイッチとして使わせていただきました。
ICTSC9のコアスイッチの要件はたくさんありますが大きく分けると以下があります。

  • Multi-chassis Link aggregation With VRRPを使っての冗長性
  • 15チーム分のRouting-instance(VRF)の展開及びルーティング
  • NAVTと対外へのルーティング

Multi-chassis Link aggregation With VRRP について

今回冗長性を確保するJuniperの技術としてMulti-chassis Link aggregation With VRRP(以下MC-LAG)というL2をスイッチまたぎのLAG(LACP)で冗長にし、L3をVRRPで冗長する技術を使いました。

MC-LAGは以下のメリットがあります。
– 別々のスイッチに繋ぐことにより冗長性の向上
– 帯域の向上
– LACPを使うので別ベンダーでも接続が出来る

またスイッチまたぎのLAGが組める技術はJuniperの中でMC-LAG以外にVirtual Chassis,Virtual Chassis Fabricがありますが以下の違いがあります。
– コントロールプレーンがActive-Active
– configの管理が2台別々
– L2だと1台だがL3だと2台に対向から見える
– マルチベンダーでのファブリック構成が可能

MC-LAG基本構成

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

MC-LAGを構成するにはスイッチの渡りにICL(Inter-Chassis Link)というICCP(Inter-Chassis Control Protocol
)
をやり取りする為の物理Linkを繋ぐ必要があります。今回この渡りの線にはQSFP(40G)を2本繋ぎました。
ICCP(Inter-Chassis Link)とはスイッチ間でリンクの情報やmacアドレスの共有をする為のプロトコルです。ICCPの設定はそこまで難しくなく、渡りのインターフェースにLACPの設定をし、対向のICCP用の管理アドレスを入れるだけで組めます。

  1. 渡りのLACPの設定

まず下記の設定を入れて、渡りのインターフェースにLACPの設定を入れていきます。
渡りにはICCP用のVLANとIPアドレスを設定し許可する必要があります。ICCPはpoint to pointなので/31で構いません。

  • Node01
set interfaces et-0/0/52 ether-options 802.3ad ae0
set interfaces et-0/0/53 ether-options 802.3ad ae0
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members ICCP-MNG

set interfaces irb unit 80 family inet address 172.30.10.252/31 //スイッチ毎に別のIPアドレス
set vlans ICCP-MNG vlan-id 80
set vlans ICCP-MNG l3-interface irb.80
  • Node02
set interfaces et-0/0/52 ether-options 802.3ad ae0
set interfaces et-0/0/53 ether-options 802.3ad ae0
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members ICCP-MNG

set interfaces irb unit 80 family inet address 172.30.10.253/31 //スイッチ毎に別のIPアドレス
set vlans ICCP-MNG vlan-id 80
set vlans ICCP-MNG l3-interface irb.80
  1. ICCPの設定
    次にICCPの設定を入れていきます。
    ここでは自分のICCP用のipアドレスと対向のipアドレスを設定し死活監視の時間設定などをしていきます
  • Node01
set protocols iccp local-ip-addr 172.30.10.252 //自分のIPアドレス
set protocols iccp peer 172.30.10.253 session-establishment-hold-time 50
set protocols iccp peer 172.30.10.253 redundancy-group-id-list 1
set protocols iccp peer 172.30.10.253 liveness-detection minimum-receive-interval 1000
set protocols iccp peer 172.30.10.253 liveness-detection transmit-interval minimum-interval 100
  • Node02
set protocols iccp local-ip-addr 172.30.10.253 //自分のIPアドレス
set protocols iccp peer 172.30.10.252 session-establishment-hold-time 50
set protocols iccp peer 172.30.10.252 redundancy-group-id-list 1
set protocols iccp peer 172.30.10.252 liveness-detection minimum-receive-interval 1000
set protocols iccp peer 172.30.10.252 liveness-detection transmit-interval minimum-interval 100

ここまでの設定でshow iccpで確認してみるとTCP ConnnectionがEstablishedとなってICCPが上がっていることが確認できます。

さてICCPの設定は出来ました。次はスイッチまたぎLAG(MC-AE)の設定をしていきます。

  1. MC-AEの設定

– Node01

set interfaces xe-0/0/0 ether-options 802.3ad ae1
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 aggregated-ether-options lacp system-id 00:01:02:03:04:05
set interfaces ae1 aggregated-ether-options lacp admin-key 3 //LAG毎に別
set interfaces ae1 aggregated-ether-options mc-ae mc-ae-id 3 //LAG毎に別
set interfaces ae1 aggregated-ether-options mc-ae chassis-id 0 //スイッチ毎に別
set interfaces ae1 aggregated-ether-options mc-ae mode active-active
set interfaces ae1 aggregated-ether-options mc-ae status-control active //2台目には standby
set interfaces ae1 aggregated-ether-options mc-ae init-delay-time 240
  • Node02
set interfaces xe-0/0/0 ether-options 802.3ad ae1
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 aggregated-ether-options lacp system-id 00:01:02:03:04:05
set interfaces ae1 aggregated-ether-options lacp admin-key 3 //LAG毎に別
set interfaces ae1 aggregated-ether-options mc-ae mc-ae-id 3 //LAG毎に別
set interfaces ae1 aggregated-ether-options mc-ae chassis-id 1 //スイッチ毎に別
set interfaces ae1 aggregated-ether-options mc-ae mode active-active
set interfaces ae1 aggregated-ether-options mc-ae status-control standby //2台目には standby
set interfaces ae1 aggregated-ether-options mc-ae init-delay-time 240

MC-AEにしたいae1インターフェイスに、これらの設定をお互いに入れるとMC-AEの設定は完了です。
トラコン本番ではNexusとのつなぎのMC-AEはSFP+4本(10G * 4)で構築しました。
あとはMC-AEで使いたいVLANを定義しae1に設定していくだけです。また使いたいVLANは渡りのae0でも通信を許可しておきます。

  • Node01 & Node02
set vlans VLAN10 vlan-id 10
set vlans VLAN20 vlan-id 20

set interfaces ae1 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae1 unit 0 family ethernet-switching vlan members VLAN10
set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN10

ここまででL2の冗長化は完了しました。
次はL3の冗長化であるVRRPの設定を入れていきます。

  1. VRRPの設定
    vlanにipアドレスを当てる場合はirbインターフェイスにipアドレスを設定してそれをvlansのl3-interfaceで紐づける必要があります。
  • Node01
set interfaces irb unit 10 family inet address 192.168.1.252/24 vrrp-group 1 virtual-address 192.168.1.254
set interfaces irb unit 10 family inet address 192.168.1.252/24 vrrp-group 1 priority 200
set interfaces irb unit 10 family inet address 192.168.1.252/24 vrrp-group 1 accept-data
set vlans VLAN10 l3-interface irb.10
  • Node02
set interfaces irb unit 10 family inet address 192.168.1.253/24 vrrp-group 1 virtual-address 192.168.1.254
set interfaces irb unit 10 family inet address 192.168.1.253/24 vrrp-group 1 priority 100
set interfaces irb unit 10 family inet address 192.168.1.253/24 vrrp-group 1 accept-data
set vlans VLAN10 l3-interface irb.10

以上で基本的なMC-LAGの構築は完了しました。
今回のトラコン本番ではl3が必要なセグメント数は、運営用6個と参加者1チームにつき12個なので、16チーム(参加者15 + 予備1) x 12セグメント + 6 = 198セグメントのセグメントを定義してvrrpを回しました。

MC-LAGホットステージ中の出来事

さてここまで淡々と構築手順を書いていきましたが、ホットステージ中はなかなかMC-LAGがなかなか構築できず余裕がありませんでした。:fire:
その余裕が無かった要因として

  • ホットステージ序盤は問題vmの作成の為にopenstackへの疎通を早急にしなくてはいけないため片系しか動かさなかった
  • 問題vm作成中はopenstackへの疎通を切らすような大きな作業は出来ないため本番用構築がホットステージ後半になってしまった
  • vlan周りの設定が上手くいかずトラシュー時間が長くなってしまった
  • お借りしたQFXの片方がメジャーバージョン2つ違うということに気づくがとても遅かった。

Junos OSのvlan周りの設定は色々あってどれがどういうのかを理解がちゃんと出来ていませんでしたね
第8回でもジュニパーさんの機材を使ったのでその時configを参考にして、vlanの設定をしたら動かないという・・・
以下はMC-LAGで上手くいかないvlan設定

set interfaces ae1 unit 10 vlan-id 10
set vlans VLAN10 vlan-id 10
set vlans VLAN10 interface ae1.10

MC-LAGではaeに論理インターフェースを増やして定義するのではなく、ただunit 0にvlanのmemberに追加するだけでよかったようです。

Routing-instance(VRF)の展開

トラコンのバックボーンでは参加者1チームに当てられるアドレス帯は全チーム共通なものを当てています。どういうことかというと上の図のように192.168.0.1/24といっても15チーム分の192.168.0.1が存在します。
どうしてこのような全チーム同じアドレス帯で設計をしているかというとこれはトラコンならではの理由があります。

例えば全チーム別々のアドレス設計を行なったとします。そうすると参加者が解く問題vmのipアドレスを15チーム別々にしなくてはいけません。
もちろんopenstackを使っているので同じイメージでインスタンスごとに別々のipアドレスにするだけならopenstack server createの時に変更が出来ます。
しかしipアドレスが変わると問題内容に関わってしまうvmの場合に対処が複雑になります。
例を挙げるとあるパッケージのconfファイルにipアドレスが書かれていて、これもチームによって変更したい場合にopenstack server createではできません。
となるとipアドレスが別々のvmイメージを作成しなくてはならず、管理が複雑になります。
またチーム間での通信は不可にするACLの設定も複雑になりconfigの量が長くなるというものもあります。

これらを簡単にするべくVRFによって15チーム同じアドレス帯にする設計をしています。
メリットとして
– 問題vmは1個だけで15チーム分そのままコピー展開するだけで済む
→チーム別々のイメージを作成しなくてすみ、管理がとても簡単。ipアドレスに気にする必要がなくなる。
– 通信させたくないセグメントには一括でnullルートが書ける

もちろんこのような設計にするとすると外部から192.168.0.1といってもが15チーム分あるので、どのチームのアドレスかを識別することができません。
これを解決するものとしてトラコンの独自技術のNAVTというものがあります。NAVTの説明は別項があるのでそちらをご覧ください。

さてここからはどのようにして同じアドレス帯のセグメントを展開したのかを説明をしていきたいと思います。
これはVRF(Virtual Routing and Fowarding)という機能を使って実装しています。
VRF(Virtual Routing and Fowarding)というのは1個の物理ルータの中に仮想のルータを作成してルータごとに独立したルーティングテーブルを保持できる機能です。
つまりルータ1台で複数の仮想ルータを作ることができる機能です。

ここでは本番で実際に使ったQFX5100のconfigを一部抜粋(ipアドレスやvlanidを一部変えています)して簡単に紹介していきたいと思います。

  1. vlanとipアドレスの定義
    まずはvlanとipアドレスの定義を行っていきます。またvrrpを組んでいるのでそれらの設定もいれていきます。
set interfaces irb unit 100 family inet address 192.168.0.252/24 vrrp-group 100 virtual-address 192.168.0.254
set interfaces irb unit 100 family inet address 192.168.0.252/24 vrrp-group 100 priority 200
set interfaces irb unit 110 family inet address 192.168.1.252/24 vrrp-group 100 virtual-address 192.168.1.254
set interfaces irb unit 110 family inet address 192.168.1.252/24 vrrp-group 100 priority 200

set interfaces irb unit 200 family inet address 192.168.0.252/24 vrrp-group 100 virtual-address 192.168.0.254
set interfaces irb unit 200 family inet address 192.168.0.252/24 vrrp-group 100 priority 200
set interfaces irb unit 210 family inet address 192.168.1.252/24 vrrp-group 100 virtual-address 192.168.1.254
set interfaces irb unit 210 family inet address 192.168.1.252/24 vrrp-group 100 priority 200

set vlans team01-VLAN100 vlan-id 100
set vlans team01-VLAN100 l3-interface irb.100
set vlans team01-VLAN110 vlan-id 110
set vlans team01-VLAN110 l3-interface irb.110

set vlans team02-VLAN200 vlan-id 200
set vlans team02-VLAN200 l3-interface irb.200
set vlans team02-VLAN210 vlan-id 210
set vlans team02-VLAN210 l3-interface irb.210

ここまではGlobalのルーティングテーブルにvlan,ipアドレス定義しています。
では次にチームごとにインターフェースをvrfに紐づけていきます。

  1. チームごとのRoutig-instancesの定義
    vrfの設定はrouting-instanceで設定していき、チームで使うirbインターフェースを紐づけていきます。
set routing-instances team01 instance-type vrf
set routing-instances team01 interface irb.100
set routing-instances team01 interface irb.110

set routing-instances team02 instance-type vrf
set routing-instances team02 interface irb.200
set routing-instances team02 interface irb.210
  1. ルーティング設定
    次にvrfのルーティング設定をしていきます。
    juniperではpolicy-options policy-statementでルート情報の設定をします。
    そして作ったポリシーをvrfに紐づけて、最後にstatic routeをnavtに向けます。
set policy-options policy-statement team01_export term direct from protocol direct
set policy-options policy-statement team01_export term direct then community add team01_comm
set policy-options policy-statement team01_export term direct then accept
set policy-options policy-statement team01_export term reject then reject
set policy-options policy-statement team01_import term direct from community team01_comm
set policy-options policy-statement team01_import term direct then accept

set policy-options policy-statement team02_export term direct from protocol direct
set policy-options policy-statement team02_export term direct then community add team02_comm
set policy-options policy-statement team02_export term direct then accept
set policy-options policy-statement team02_export term reject then reject
set policy-options policy-statement team02_import term direct from community team02_comm
set policy-options policy-statement team02_import term direct then accept

set routing-instances team01 vrf-import team01_import
set routing-instances team01 vrf-export team01_export
set routing-instances team01 routing-options static route 0.0.0.0/0 next-hop
172.26.0.254 //NAVT

set routing-instances team02 vrf-import team02_import
set routing-instances team02 vrf-export team02_export
set routing-instances team02 routing-options static route 0.0.0.0/0 next-hop 172.26.0.254 //NAVT

ここまでが簡単なvrfのconfigとなります。
実際本番では上記のconfigに
null routeの設定
– 問題が増えるごとにvlanの定義
– NAVT用のstatic arp

が加えられ最後に15チーム分複製してvrfを展開しています。
さすがにこのような長いconfigを15チーム分手打ちはできないので、スクリプトを使って生成して流しました。
最終的なconfigの長さはdisplay set | no-moreで1919行になりました。
2000行近くのconfigを2つ作ってお互いに整合性がちゃんと取れているかのチェックは本当に大変でした。
スクリプトに不備があってある行がおかしいとか頻繁に起きていたので、本番直前は3人でトリプルチェックしていました。

 /

執筆担当: 新留

新留です。
HomeNOCと今回のコンテスト会場を接続する機材として、Juniper Networks(以下Juniper)様からお貸出しいただいたSRX1500を利用しました。
この機材では、Chassis Clusterでのクラスタ構成による冗長化やフルルートの受信と経路制御を行い、コンテスト参加者や運営、協賛とインターネットとの橋渡しを行っていました。

トポロジー図

ご満悦の表情でトラフィックを裁くSRX1500

Chassis Cluster

下流との接続と設定の簡略化、何よりロマンを求めて、今回はこの2台でChassis Clusterを構築し、Active-Activeとなるような構成にしました。
この構成のおかげで2つの機材の設定を1つのコンソール接続で管理でき、またルーティングテーブル・NAPTテーブルが同期されるため、とても便利でした。
Chassis Clusterを生かしてSRX1500と下流のQFX5100との接続をLAGで構築する予定もあったのですが、時間の都合で今回は達成することが叶いませんでした。

余談で、この設定はホットステージ開始前に行ったのですが、再起動必須なことを失念してリモートで設定投入 -> 再起動 -> 接続断 -> DCダッシュ ということをしてしまったのを今でも覚えています。

ルーティング

HomeNOCの説明でも軽く紹介した、大阪側から広告されたフルルートと東京側から広告されたデフォルトルートは、このSRX1500で受信していました。

HomeNOCから受けたIPv4 約69万経路 + IPv6 約5万経路をこの機材で収容し、ルーティングを行なっていました。
フルルートを受けている時の show bgp summary

受信経路の説明の図

また、SRX1500とその下流のQFX5100間ではOSPFで経路を広告していました。

内部経路の広報の図

SRX1500からはデフォルトルートを広告し、下流のQFX5100からはライフサーバー群、NAVT変換後のネットワーク、デバッグ用のチーム16(実際には存在しないチーム番号)を広告していました。OSPFでの経路数はトータルで30程度でした。

個人的に一番驚いたのが、ルーティングプロトコルでデフォルトルートを広告してくれるコマンドが存在しないことでした。
そのため、Juniperの公式HPにある情報などを頼りに以下の設定でデフォルトルートを広告しています。

set routing-options static route 0.0.0.0/0 discard
set routing-options static route 0.0.0.0/0 no-install
set routing-options static route 0.0.0.0/0 preference 200

set policy-options policy-statement bgp-redistribute term default from route-filter 0.0.0.0/0 exact
set policy-options policy-statement bgp-redistribute term default then accept

set protocols ospf export bgp-redistribute

この設定で、RIBに乗らない経路を作成し、その経路を広告するように設定しています。
Policy Statementの名前が bgp-redistribute なのは、BGPで流れてきたデフォルトルートを再広告する設定の名残です。
ちゃんと直さないとなあと思いながら本番が来てしまい、直せず仕舞いでした。

構築途中で「BGPで流れてきたデフォルトルートを再広告する設定」のミスにより、HomeNOCから来たフルルートをQFX5100にOSPFで再広告するという設定をしていました。
その結果、60万を超える経路を受信しようとしたQFX5100がハングアップし、その設定を行なった私は「うわあ・・・やっちまった・・・」とうなだれていました。

その直後にHomeNOCの山口様がこんなツイートを残していて、胸が痛くなりました。


十分勉強になりました、ありがとうございました。

ハングアップした原因としては、経路広告先であるQFX5100のIPv4の最大経路数が208,000経路であるにもかかわらず、69万もの経路を流してしまったため性能的に無理だったというものでした。
フルルートをOSPFで流した時の概要の図

また、事前の連絡ではデフォルトルートを大阪・東京双方から受信するという話で、そのため横着をしてBGPの経路をOSPFに広告する設定でデフォルトルートだけが広告されると想定し設定していました。
その設定途中でSRX1500にフルルートを流してみよう!ということになり、と同時にその時に再広告の設定を失念していた人的ミスのせいでQFX5100が一時応答不能になるというトラブルに発展しました。

やはり横着はよくない、eBGPで受けた経路をIGPに再広告するのではなく、きちんとDefault Gatewayを生成することが必要だとしっかり理解した瞬間でした。

このトラブル以外SRX1500でのトラブルはなく、とても安定して稼働してくれました。

コンテストを終えて

今回のコンテストでは、SRX1500で見た最大フロー数は7500程度、最大帯域は150Mbpsでした。
今回利用したネットワーク機材の中では通信量はそこまでないことがわかっていたのですが、フルルートが乗っているということもあり、私はCPU負荷やメモリ負荷といった部分を比較的注視して見ていました。
しかし、実際にコンテストが始まってからも多少の増減はありましたが特に詰まることなくパケットを処理している様子で、心配することはなかったなと思いながら見てました。
個人的な感想になりますが、Juniper機材を触ったことのなかった自分にとって新しい体験ができ、とても楽しく触らせていただきました。
機材提供をしていただいたJuniper Networks様、ありがとうございました。

 /

執筆担当: 新留

前回から引き続き、Home NOC Operators Group(以下HomeNOC)様よりインターネットへの接続をご提供いただきました。
その中で、トラコン初となる10G回線と対外接続2経路、フルルートをご提供いただき、大阪・東京の2拠点と接続して冗長化しました。

HomeNOC - SRX1500のトポロジー図

10G回線

本戦会場であるさくらインターネット株式会社様のDWDM装置を利用し、実際にHomeNOCの大阪DCと会場の間をダークファイバーを利用し、10GBase-LRにて直接接続しました。

光ファイバーを通る通信について、HomeNOCの山口様が記事にしているので、こちらにリンクを掲載させていただきます。

DWDM装置は知識のない人が触れるものではないため、HomeNOCの方に実際に現地で設定・調整を行っていただきました。

10GでHomeNOCと接続していますが、ホットステージ中は当初の想像よりもパフォーマンスが出ないことに気づきました。

その理由として、インターネット上でのルーティングが関わっています。
インターネットの世界は非常に大量のルーターが相互接続されており、また自組織のルーターから見たベストパスが他組織においてもベストパスとは限りません。

一般的な経路制御の方法として、ホットポテトルーティングというものがあります。
これは、経路が最も近い場所から広告されているピアに向かってパケットを投げる制御です。

HomeNOC 大阪DCからインターネットに出る通信は、HomeNOCのルーティングポリシーに従い、MEDやAS_PATHなどを見た上でベストパスを選択しルーティングします。
しかし、戻り経路はどこから来るのかは相手組織のルーティングポリシー次第であり、また相手組織から見たベストパス次第となります。

例えば東京のとあるサーバーに大阪からパケットを飛ばしたとします。
そのパケットがもし大阪から出たとして、帰って来るパケットは相手から見て最も近い場所から吸い込まれます。
非対称パスでの通信速度の解説の図
その結果、行きは早くても戻りパケットが回線速度の遅い場所を通り、そこがボトルネックとなり通信が遅くなります。

これを知らずにパフォーマンスの確認メールを送り、詳細を理解することができました。ありがとうございました。
その後、会期期間中はバックボーンが計11Gbpsの場所と接続されている大阪からできるだけパケットが流入するよう制御していただきました。
おかげでバックボーンネットワークに関してはとても快適に通信できていました。

後から聞いた話なのですが、eBGPでは大抵のASが/24より細かい経路を無視するように設定されているということで、ICTSCが利用するネットワーク(103.202.216.16/28)よりもずっと大きいネットワーク(103.202.216.0/24)を大阪優先になるよう経路広告を変更していただいていました。
本当にありがとうございました。

対外接続2経路・フルルート

今回のテーマである「冗長化」を達成するため、ダークファイバー回線が切断された場合のバックアップとしてHomeNOCの東京DCとEtherIPトンネルを利用した接続を行い、大阪との通信が途絶えた際に利用されるよう設定していました。
対外接続2経路化に伴い、HomeNOCからSRX1500へ到達するパケットの経路制御が必要になるため、SRX1500でBGPを利用した経路広告を行い、MED値を制御することで出来るだけ大阪から通信を吸い込むような制御を行いました。
その際の設定として、大阪からの経路広告はMED値100、東京からの経路広告はMED値200で広告していました。
MED値は低い方が優先されるので、この広告を行なった結果、トラフィックはMED値の小さい大阪の方から流れてくることが確認できました。

HomeNOC側からの経路広告としては大阪からフルルートを、東京からデフォルトルートの広告をいただきました。
実は当初はデフォルトルートのみを広告してもらう予定だったのですが、会場で設定中に100万経路を処理可能なSRX1500にフルルートを流してみよう!ということになり、実際に流したら安定して動作できたため、この設定をそのまま利用することになりました。
東京からフルルートを受け取ることについては、PPPoEの回線品質から見送りました。

その結果、こちらからのパケット送出についてはフルルートが受信できている(HomeNOCの大阪データセンターが生きている)場合は大阪からパケットが送出され、もし大阪DCとの回線がダウンした場合はバックアップとして利用することができるようになりました。

コンテストを終えて

コンテスト二日目の午前中にHomeNOCよりも上流の回線で障害が発生し、5000経路くらいが消失、さらに一時的に下り通信が東京から来ていた現場を目の当たりにするというとてもレアな経験ができました。
この原因は、HomeNOCがバックボーンとの接続で使用しているフレッツ網で発生した障害の影響だったそうです。

5000経路も消えた図

(しかしこの時にICTSC側で通信障害が起きていました・・・設定不足・・・:innocent:ご迷惑をおかけしました)

また、ホットステージ期間中に10G回線でエラーカウンタが回り続けている連絡を受け、光ファイバー清掃で対応するなども行いました。
他にもNTT東日本とNTT西日本のフレッツ回線における閉域網は直接接続できない等、大阪ということも相まって面白い体験ができました。

 /
カテゴリー

こんにちは、ICTSC9 問題リーダーの金澤です。参加者の皆さん、コンテストお疲れ様でした。

ICTSC9 で出題された各問題の解答と解説記事を公開しました。ここに、各問題の記事へのリンクをまとめます。コンテスト本番から1ヶ月ほどと、大変遅くなってしまって申し訳ありません。

※ 2018/04/02 現在、解説が未公開の問題があります。申し訳ありませんが、今しばらくお待ちください。

ICTSC9 参加者の方は復習に、次回以降参加するつもりの方は予習に役立ててください!

続きを読む

最近のコメント