/

問題文

さて、突然ですが超有名大企業ICTSC Comに入社した新入社員のあなたのミッションは、SRv6を使ってHostAからHostBへの通信の際にIDS(Snort)をサービスチェインして通るようにするということを任されました。
しかし現在はSRv6でHostAからHostBへ通信はIDS Nodeを通らずに通信をしてしまっています。
これをIDS Nodeを通ってからHostBに通るようしてほしい。

HostA: 10.0.0.1/24から HostB: 10.0.1.1/24にPingが飛ばせています。
この状態ではIDS Nodeを通らずHostAからHostBへSRv6を使ってルーティングされています。

IDS Nodeではnetwork namespaceで切り分けられたLinuxとSnortが内部に存在します。残念ながらSnortはディフォルトではSRに対応できていないため注意してください。またSnort自身の設定は変えなくても問題ないように設定されています。
そしてちゃんとパケットが流れればSnortのコンソールを確認するとアラートが流れることが確かめることができます。

以下にトポロジーと認証情報を添付するので確認してみてください。

情報

全てのホストは以下情報で入れます
ユーザー: admin
パスワード: hello_5g

以下のIPアドレスはManagementのための接続アドレスです。

Host A

IPアドレス: 192.168.12.6

Router 1

IPアドレス: 192.168.12.1

Router 2

IPアドレス: 192.168.12.2

Router 3

IPアドレス: 192.168.12.3

Router 4

IPアドレス: 192.168.12.4

IDS

IPアドレス: 192.168.12.5

Host B

IPアドレス: 192.168.12.7

構成

問題スタート

HostAからHostBにPingが飛ばせる。この状態ではAからBへSRv6を使ってルーティングされてる

問題ゴール

HostAからIDSを通ってHostBにPingが飛ばせる様になる。
IDSではICMPを認識して検出ができる.

注意事項

  • 必ずSRv6の機能をつかうようにしてください。
  • トラブルはSRだけとは限りません。あらゆる事がありえます。
  • SnortはIDSが立ち上がっている中でnetwork namespace(veth)で区切られている。以下の方法で簡単に確認ができます。

下には便利なチートシートです。

# srextを使うときはこれを実行してからではないと動きません(公式ドキュメントから抜粋)
sudo depmod -a
sudo modprobe srext

# vethにpacketが通ってきているか見たいとき
ip netns exec Snort tcpdump -i veth0-Snort

# Snort側のnamespaceに移る
ip netns exec Snort bash

# Snortでのアラートが見たいとき(exec Snort bashをした後に使える)
Snort -c /etc/Snort/Snort.conf -A console

トラブルの概要

SFCをしたいができていない。

解説

この問題は、2つのIPv4対応ホスト(hostA and hostB)がSegment routing over IPv6 dataplane(SRv6)を介して通信できるようにして、サービスチェインを実装する問題でした。

トポロジーの細かい要素としては以下のようになります。

  • Router
    • R1,R3,R4: SRv6をサポートするルーター
    • R2: v6だけサポートするルーター
  • IDS: namespaceで区切られたSnortが動作しているサーバ

実際にパケットの動きを見ていきましょう。

まず今回の基本設定の状態はAからBへのトラヒックはR1,R2,R3,R4を通じてBへ渡されます。
実際のフローを少し細かく文章化すると以下のようになります。

IPv4のペイロードがHostAからHostBへ送信される

IPv4のペイロードがHostAから送信されます。
ここではSegment routing header(以下SRH)は付与されず、宛先がHostBになっているIPv4パケットとして送信されます。

パケット構成は以下のようになります。

  • Ethernetヘッダ
  • IPv4
    • 送信元アドレス: HostA
    • 送信先アドレス: HostB

HostAから送信されたパケットがR1に到着

R1では以下の作業が行われます。

  • IPv6カプセル化をする
  • 2つのノードを対象にするヘッダであるSegment Routing Header(SRH)を挿入しカプセル化をする

SRHの中にはロケーター情報として、R3,R4を経由するという順序情報と、Segments Left(SL)というSRに対応したルーターを残りいくつ通るかの情報が記載されています。

この作業が終わった後のパケット構成は次のようになります。

  • Ethernetヘッダ
  • IPv6ヘッダ
    • 送信元アドレス: R1::1
    • 宛先アドレス: R3::bb
  • SRH
    • ロケーター情報: R4::bb, R3::bb
    • Segments Left(SL): 1
  • IPv4
    • 送信元アドレス: HostA
    • 送信先アドレス: HostB

上記情報から、IPv6ヘッダの指し示す宛先がR3であるため、R1のルーティングテーブルを見てパケットはR2へと転送されます。

R1から転送されたパケットがR2に到着

R2ではSRv6に対応するための設定は投入していません。
しかし、IPv6の経路情報はR2にインストールされているため、IPv6ルーティングによりR3に転送することができます。

R2から転送されたパケットがR3に到着

R3ではSRv6に対応するための設定が投入されているため、R3::bbに対応する操作を実行し、次の処理を行えるようにするためにEnd動作をします。
End動作により、IPv6ヘッダの値とSRHのSegments leftの値が書き換わります。

  • Ethernetヘッダ
  • IPv6ヘッダ
    • 送信元アドレス: R1::1
    • 宛先アドレス: R4::bb
  • SRH
    • ロケーター情報: R4::bb, R3::bb
    • Segments Left(SL): 0

この情報から、次はR4へとパケットを転送します。

R3から転送されたパケットがR4に到着

R4がSRv6網の終端となります。
この先のネットワークはIPv4ネットワークで、SRv6とIPv6のカプセル化を解除する必要があるため、End.DX4動作をしてカプセル化の解除を行います。

その際、具体的には外部のIPv6ヘッターを除去し、R3でSRv6の設定(function)により決められたIPv4 Next hopへとパケットを転送します。

  • Ethernetヘッダ
  • IPv4
    • 送信元アドレス: HostA
    • 送信先アドレス: HostB

上記の手順により、HostBにPing Requestを送信することができました!

次はPing Replyパケットが送信されるまでのフローを見ていきましょう。

問題出題状態では、R3を通らずに R4 -> R3 -> R1 のようにパケットが転送されるようになっています。

IPv4のペイロードがHostBからHostAへ送信される

IPv4のペイロードがHostBから送信されます。

  • Ethernetヘッダ
  • IPv4
    • 送信元アドレス: HostB
    • 送信先アドレス: HostA

HostBから送信されたパケットがR4に到着

R4では以下の作業が行われます。

  • IPv6カプセル化をする
  • 2つのノードを対象にするヘッダであるSegment Routing Header(SRH)を挿入しカプセル化をする
  • その後のパケットは以下のようになります

    • Ethernetヘッダ
    • IPv6ヘッダ
      • 送信元アドレス: R4::dd
      • 宛先アドレス: R1::1
    • SRH
      • ロケーター情報: R1::1
      • Segments Left(SL): 0
    • IPv4
      • 送信元アドレス: HostB
      • 送信先アドレス: HostA

    上記情報から、IPv6ヘッダの指し示す宛先がR3であるため、R1のルーティングテーブルを見てパケットはR2へと転送されます。

    R4から転送されたパケットがR2に到着

    R2ではSRv6に対応するための設定は投入していません。
    しかし、IPv6の経路情報はR2にインストールされているため、IPv6ルーティングによりR1に転送することができます。

    R2から転送されたパケットがR1に到着

    R1がSRv6網の終端となります。
    この先のネットワークはIPv4ネットワークで、SRv6とIPv6のカプセル化を解除する必要があるため、End.DX4動作をしてカプセル化の解除を行います。

    その際、具体的には外部のIPv6ヘッターを除去し、R3でSRv6の設定(function)により決められたIPv4 Next hopへとパケットを転送します。

    • Ethernetヘッダ
    • IPv4
      • 送信元アドレス: HostB
      • 送信先アドレス: HostA

    ここまでが基本的な状態の設定として問題環境に設定していた状態でした。
    SRv6について理解するためのきっかけになったと思います。

    では実際の問題を解くフェーズに入っていきます。

    今回の問題で行う方策をまとめると、

    • Snortがあるホスト(IDS)を通ってパケットを動かす必要がある
      • しかしSnortはSRv6に対応していない

    ということになります。

    (ちなみに 普通Snortは別ホストじゃないんですか? という質問については、この問題で使用するVMのリソースがコンテストで使用している物理サーバーのうち一台のサーバーをおおむね専有するほど多く、メモリを節約するためにしょうがなく行った苦肉の策でした。
    ですが出題としては全く問題ないのでこのまま出題しました。)

    今回のトポロジーから、Snortがあるホストにパケットを転送させるにはR1で付与するSRHのロケーター情報にR5を追加することで、R5を経由することができるようになります。

    しかし、SnortはSRv6に対応していません。そのため、一度SRv6のカプセリングを外してIPv4のパケットだけに変換する必要があります。

    「SRv6はデータプレーンにロケーション情報等が付与されているだけなので一旦外す」という方法が考えれると思います。
    ちょっと意地悪に見えるかなぁと思い、出題的には # srextを使うときはこれを実行してからではないと動きません(公式ドキュメントから抜粋) と書いておいたコードがありました。
    このコードについてインターネットで調べると、例えば

    いhttps://github.com/netgroup/SRv6-net-prog

    というリンクが見つかり、以下のようなそれっぽいfunctionを見つけることができます。

    • End.AD4: Endpoint to IPv4 SR-unaware APP via dynamic proxy
    • End.EAD4: Extended End.AD4 behavior that allow SR-unaware VNFS to be the last SF in SFC

    このことから、bbの定義を

    srconf localsid add fc00:5::bb end.ad4 ip 192.168.1.2 veth0 veth1

    このようにすることで、無事Snortまで通信が転送されます。Snortから戻ってきたパケットは正常にR4に流れていきます。
    別解としてEnd.EAD4を利用する方法もありますが、こちらでも問題はありません

    具体的な挙動としては、veth0に対して流れてきたパケットのSRHを外して、 IPv4 Payload オンリーにして流してあげるだけです。veth1に戻ってきたら、先程外したSRHを再度付与します。
    これで無事通信をIDSを通じてhostBへ行くことができました!

    問題作成の狙いとお気持ち

    この問題は次世代ネットワークについての知識をつけてほしいということから作りました。そもそもほぼ全員がSRv6ってなんやねんというところからで辛いかなと思ってたんですが、まずは存在を知ってもらって、その上でおもしろいところや有用性を理解してもらえたら嬉しいなと思って作った問題でした。また、狙いとしてSRv6はほぼmininet以外で遊べる環境というものは公開されていないため直接OSに対して書き込むconfigとかがあまり見ることができないというのがあります。なので今回は公開をすることでトラコン参加者以外も幸せになるおもしろい問題になったんじゃないかと思います。

    ちなみにですが実は自動起動の設定にsystemctlを使用したため、問題参加者はそのへんをガサゴソするとconfigがでてきて参考になったかも知れません。
    なおホントはもう少し難しい問題にする予定だったんですが、、、これではあまりにも解けなそうではと言われて変更して、変更したやつも、ちょっとむずかしいのでは?と言われてSRのコマンドだけの修正で解ける問に変更されたので Baby とつけていました。ちょっとpwn系のCTF問題みたいなネームみたいですね。
    それでも難しいと言われたので誰も挑戦してくれないかなとヒヤヒヤしていましたが、いくつかのチームは挑戦してくれたのでホッとしました笑

    回答例

    R1のSegment ID table(SID, つまり通るべき経路の指定)をR3,R5,R4の順番でオーダーする
    ip route add 10.0.1.0/24 encap seg6 mode encap segs fc00:3::bb,fc00:5::bb,fc00:4::bb dev eth1
    IDS NodeのSnortはSRHを処理することができません。よってIPv6 headerを取り外してあげる必要があります。よってサービスチェインのダイナミックプロキシを行う必要があります
    srconf localsid add fc00:5::bb end.ad4 ip 192.168.1.2 veth0 veth1
    ちなみにR1でR3,R4で指定してR3でR5に行くようにoverSRv6を更にしたらいいのではと思うかもしれないですが、拡張カーネルが必要で今回は対応していないため困難です

    これは今回出題したSRv6についての問題を体験できるVagrantFileです。もしよかったらぜひ遊んでみてください!!
    https://github.com/takehaya/SRv6_SFC_Example

    採点基準

    点数となるのはIDSNodeまでの中継するべきノードをSRv6でオーダーされていて50%+その後にダイナミックプロキシされるで満点を与える方針
    そもそもオーダーがない場合などは部分点をつけることはしません

 /
カテゴリー

問題文

仮想機密伝送路課の検証環境ラボ(以下、ラボという)の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返答しても設定ミスでルータが返してあることがたまにあるのでみなさん気を付けてください。

 /
カテゴリー

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

 /
カテゴリー

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人でトリプルチェックしていました。

 /
カテゴリー

問題文

スイッチの問題を解決した後、ドワーフに話しかけられた。

ドワーフ「いや~まさか本当にトラブルを解決するとはビックリしたぜ。ついでにもう一つ頼まれてくれないか?」

ドワーフ「実は魔法陣の構成を 892j から 1941 に変更して、同じ呪文を書き込んだんだがNAT-PTが動作しないんだ。頼む……この通りだ」

エイト「コンフィグを使いまわしたってこと? そんなことするから動かないのよ。悪いけど、あんたたちやってあげてくれない?」

起こっていたトラブル

NAT-PTが機能していないため、v4の宛先にpingが飛ばない。

トラブルの概要

Cisco Express Forwardingと呼ばれるスイッチング技術がCiscoの機器ではデフォルトで有効になっているのですが、
この技術がNAT-PTに対応していないことで、pingが飛ばない状況になっていました。

採点基準

  • NAT-PTを機能させること
  • IPv6アドレスのみを持つPCからIPv4のホストに対してpingが通ること

解法


no ip cef
no ipv6 cef

上記のコマンドでcefを無効化する。

講評

この問題を解放した時期の差はありますが、全てのチームが解放しているにもかかわらず、
8チームからしか解答が来ていない問題となっていました。
解答をしてくれたチームで見ると、8チーム中7チームが満点となっていました。
NAT-PTはIPv4/IPv6の共存技術の中でもあまり知られていない技術だと個人的に思っているので、
皆さんの調べる力を試す問題として出題しました。

最終的に7チームが解答未提出となり、チーム間での調べる力の差なのかなと感じました。

 /
カテゴリー

こんにちは,ぱろっくです.

妖精の国 第二のトラブルに関する解説を書かせていただきます.

問題文

国から国への船旅の途中、激しい嵐に遭った。荒れ狂う海の中で波に流され、気がつけば小さな島に漂着していた。

エイト「何とか元の航路に戻りたいけど……船の修理が終わるまでこの島で過ごすことになりそうね」

探索していると、島の中央に神殿があることに気づいた。神殿の柱には見知らぬ文字と美しい模様が刻まれていたが、何を表しているのかはわからなかった。そして、祭壇には大きな黒い箱が安置されていた。

エイト「何だろうこの箱……ってサーバじゃない」

詳しく調べてみると、そのサーバは強大な力を持っていることがわかった。そして、その中には先人の訪れた形跡があった。

エイト「どうやらこのサーバの力を試してみようとしたけど、途中で力尽きてしまったようね。この強大な力を使えれば、魔法の研究や応用が爆発的に発展するに違いないわ! よくわからないけど、私たちで動かしてみましょう」

採点基準

  1. CUDAのシンボリックリンクがcuda-8.0ではなくcuda-7.5にはられているのに気づき,修正してmakeが通るようになっている.
  2. GPUのスレッド数をTitanXの上限まで落としてsuccessと出力できている.

解説

この問題では,近年流行しているGPUプログラミングに関するものでした.普段触ったことのない方には新鮮に感じたと思います.これをきっかけにGPUプログラミングに興味を持ってもらえたら嬉しいです.

今回起きていたトラブルは,まずCUDAを新しいバージョンに入れ替えた際にシンボリックリンクが張り替えられていない問題が発生していました.

makeファイル内で記述されていたコンパイル時の-arch及び-codeコンパイラオプションをTitanX(pascal)に合わせていたのですが,古いバージョンの方にシンボリックリンクがはられたままであったためコンパイルが通りませんでした.

そのため,まずシンボリックリンクを張り替えれば,このトラブルは解決し,コンパイルが通るようになります.

次に,実行ファイルの出力がfailedになってしまうトラブルが起きます.

これは,ファイル内でGPUの1ブロックあたりのスレッド上限数である1024を超えてしまい,処理が正常に行われていないため起こるトラブルです.

そのため,ソースコード内のスレッド数の指定を1024以下に変更するなどの対策をすればトラブルが解決しsuccessと出力されるようになります.

まとめ

以上が本問題の解説となります.

この問題は,さくらインターネット株式会社様の「高火力コンピューティング」サービスから機材提供をしていただきました.ご提供していただき本当にありがとうございました.問題提供していた環境を普段も使いたいという方はこちらをご参照ください.