/
カテゴリー

監視

はじめに

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

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

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

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 参加者の方は復習に、次回以降参加するつもりの方は予習に役立ててください!

続きを読む