JApan Network Operators' Group

開催概要 プログラム チュートリアル ネットワーク 出席登録 アンケート ホスト・協賛 スタッフ English

JANOG Meeting本会議場ネットワークの作り方

2013年3月3日 JANOG31会場運営委員

■概要

img/janog31-topology.png

JANOG31では東京ミッドタウンホールという800人近くを収容できるホールで、1つの安定したネットワーク、5つの実験ネットワーク、1つのスタッフ用ネットワークを来場者に提供しました。このドキュメントでは提供した会場ネットワークの構想から構築方法について紹介したいと思います。一般的な注意点や方法論とJANOG31での構築の経験を紹介し、可能であれば倉敷芸文館で開催したJANOG30の時の例も紹介したいと思います。

■注意

このドキュメントに付属する資料およびコンフィグで使用しているIPアドレスは、ホストのグリー株式会社様よりJANOG31会場ネットワーク用に一時的に払いだされたもので、現在はJANOGでは使用しておりません。

■会場

img/janog31_mainhall.jpg

JANOG31の会場である東京ミッドタウンホールはビジネス向けの都市型多目的ホールで、電気・情報設備等の設備環境が非常によく整っていました。構築は楽でしたが、その分既存のインフラとの兼ね合いを考える必要がありました。

img/janog30_mainhall.jpg

JANOG30の会場である倉敷芸文館はオーケストラや劇団なども使用する一般的な劇場で、情報インフラを提供することが念頭に置かれていない設計の為、制約の多い中、苦労して一から敷設する必要がありました。

■構想

会場ネットワークとは言いますが、まずどのような会場ネットワークを提供するかを考えなくてはなりません。最終的に実験ネットワークを含めた6種類のネットワークを提供することになりましたが、当初の構想通り進んだわけではなく、プログラムとの関係や機材の関係などから臨機応変に計画を修正する必要がありました。

JANOGでは安定したネットワーク(協賛ブース向け有線含む)とスタッフ用のネットワークの2つを最低限の水準として提供します。それに加えて会場運営委員(LA)が好きなネットワークを構築しています。過去の例では、IPoE、5GHz帯の無線(802.11a)、1.0.0.0/8のネットワークなどが提供されました。JANOG30では、IPv4 over IPv6をテーマとして 4rdの3社相互接続実験ネットワークとLISP betaネットワークを提供しました。その結果として相互接続実験の結果をInternet-Draftとして発行したり、JANOG Softwire WG(Working Group)が発足するなどの成果をあげることができました。

JANOG31でのLAのミッションの１つとして、JANOGやインターネット業界に対して成果を還元できるネットワークを提供することがありました。これを具体的に3つの評価軸に落とし込みました。

  1. JANOGメンバーが会場まで足を運んでくれる価値のあるネットワーク
  2. プログラムと密接に関わったネットワーク
  3. フィードバックを得たり利用実績を積むなど、機材提供することでベンダー様にメリットがあるネットワーク

ここからは機材提供者と調整を行いながら具体的にどのようなネットワークを提供するのかを決めていきます。

最終的に「IPv4/IPv6移行・共存技術」というテーマでMAP-E、DS-Lite、464XLATの3つの新技術を用いたネットワークと、「新世代ネットワーク」というテーマでNICTとHANAを用いたネットワークを提供することに決定しました。

HANAはJANOG/IA研共催イベントをきっかけに先方から打診のあったテーマでした。またGeoIPに関係するネットワークという案も当初ありましたが、特定のIPアドレスの位置情報を恣意的に変更することの影響が懸念されるため断念しました。そこでIPv4/IPv6移行・共存技術としてMAP-Eと464XLATの提供が決まっていたことから、同種の技術であるDS-Liteを提供することにしました。

安定したネットワークについては、これまで janog30 と janog30-a など、2.4GHz(802.11bgn)をデフォルトにしていましたが、5GHz帯に対応している機器も普及してきた為、今回からは janog31, janog31-bg と 5GHz(802.11an)をデフォルトにするように変更することにしました。

以上からJANOG31は次の6種類のネットワークを作成することになり、8月から構想を練って、最終的に決定したのは11月の終わりでした。

janog31, janog31-bg 安定したネットワーク
janog31-map-e1, janog31-map-e2 MAP-Eを用いた実験ネットワーク
janog31-ds-lite DS-Liteを用いた実験ネットワーク
janog31-464xlat 464XLATを用いた実験ネットワーク
janog31-hana HANAを用いた実験ネットワーク
janog31-staff スタッフ用ネットワーク

■下見

会場の下見を行うことも重要で、この時に確認するのは特に以下のポイントです。下見に行く前に会場の図面をもらっておいてある程度設計を行なってから行くとスムーズです。

  • インターネット接続回線の提供方法
    • 回線種別
    • 設置場所
    • 設定変更・構成変更の可否
  • 機材の設置場所
    • 物理的な設置場所・設置可否
    • 設置方法(シートを敷くか等)
  • 電源容量
    • コンセント側だけではなく分電盤での容量を確認する
  • 配線経路
    • 配線経路の想定
    • 必要なケーブル本数・スイッチ数・線路長
    • バミや固定が可能か
  • 無線LANの電波状況
    • 既に利用されているチャネルと混雑状況
  • 夜間の電源投入可否
  • 人の立ち入り・常駐可否

上流回線の提供方法

インターネットに抜けるための上流回線が会場でどのように提供されているかを確認します。

JANOG31で使用した会場は、Bフレッツが3本既設で、すべてYAMAHAのルータで終端されていました。ただし、DHCPで50クライアント程度の払い出し設定との事だったので、既設ルータを切り離し、自前でルータを手配するという形をとりました。また、PPPoEの認証情報を公開できないとの事なので、別途、接続用のISPで手配する必要がありました。

JANOG30では会場に特にネットワークがなかったため、ホスト様が会場にダークファイバを引き込んで伝送装置でホスト様のデータセンターにまで光で飛ばしていました。これは地元ケーブルテレビ事業者だからこそできる、なかなか特殊な例です。

設置場所

設置場所に関しては、消防法などの関係から通路に無線APなどの機材を置いて良いのかなどもポイントです。テーブルの上に機材を置く場合は養生し、保護する必要があるか確認する必要があります。養生する際、気泡緩衝材や静電防止マット等を使用するのが手っ取り早いでしょう(確認の上、必要なくてもやったほうがいいです)。設置場所は電源容量や人の立ち入りにも左右されます。

JANOG31では2つの部屋が使用可能でした。1つは「調整室」と呼ばれる部屋で、上流回線と、各部屋へのパッチパネルが集約されていました。しかしこの部屋はホールスタッフの常駐部屋なのでJANOGスタッフの出入りは自由ではありませんでした。もう1つはスタッフ用の控え室の1つでフロアも異なり距離的にも離れている部屋でした。しかし、調整室からUTP配線が事前に行われていたということ、24時間稼働が可能でしたので「NOC」として使うことを決めました。各部屋は一般的な長机が置かれていたので養生して机の表面を保護する必要がありました。無線APは看板に使う建具にテープで固定できそうでした。

JANOG30では舞台袖が機材置き場になっていました。また協賛ブースや無線APの設置のために会場内の各所にL2スイッチを床に配置する必要がありました。舞台袖の機材置き場は長机２つで、その上にすべての機材を載せるため、長机の足の斜めの部分を縛って自重で机が畳まれないようにするなどの措置が必要でした。無線APは楽譜用の譜面台に置きました。

電源容量

電源容量は非常に重要で、どのコンセントからどの系統で何V、何Aが供給できるのかを確認します。機材の消費電力が電源容量をオーバーするとブレーカーが落ちてしまいますので、機材調達は会場の電源容量範囲に収まるように調整します。会場によっては電源の増設なども可能ですが費用発生してしまいます。よほどの事情がない限り、避けるべきだと考えています。 NOC部屋では15A回路2系統と壁コンセント15A回路1系統が使えました。そのため合計15A回路2系統使用することとし、30Aで収まるように機材の配置を調整しました。

JANOG30ではホスト様の手配の伝送装置を置く必要があったため、舞台袖に20Aの追加電源を敷設しました。

配線経路

配線経路の確認をしながら必要なスイッチの個数やケーブルの本数・長さを計算します。測定には赤外線で距離を測ることの出来る機械があるので、それを使うと非常に楽に速く計測ができます。事前に図面を入手していくつかの経路を想定しておくことが重要です。長さはUTPで100mを超えないように設計します。通路を跨ぐようなケースが出てくるので、そのような場合にバミテでの固定やマットの設置が可能かなどの確認が必要になります。

JANOG31では調整室のパッチパネル経由ですべての部屋に配線することが可能だったため、調整室では3m程度、長いところでも5m程度と比較的短いケーブルをたくさん用意すれば問題ありませんでした。ただしホール内中央への配線はPITを使う申請を行う必要がありました。

JANOG30ではホール内外ともに有線を敷設する必要があったため非常に大変でした。また、木材部分のバミ不可や通路を跨ぐ配線や、2階への縦配線、最長90mの区間など、非常に気を使う箇所がありました。そのため何度かの配線経路の変更や、通路敷設用のマットの手配などが必要になりました。有線区間が長いと、撤収に時間がかかります。

img/janog30-haisen8.png

無線の混雑状況

無線LANの利用状況の確認は安定した無線の提供に欠かせません。最近のカンファレンスホールでは公衆無線LANサービスが提供されていることが多く、無線のチャネルはほとんど埋まっています。しかし、利用率が低ければそれほど問題になりません。inSSIDerなどのソフトウェアで可視化したり、Macではairportなどのコマンドを使って確認を行いました。高価なアナライザを使えばトラフィック量も分かります。

JANOG31では会場で公衆無線LANサービスが提供されていたため2.4GHzから5GHzまですべてのチャネルが埋まっていましたが、トラフィックはほとんど流れておらず、過去にも数百人を収容する規模の無線ネットワークの構築実績があるとのことだったので、問題ないと判断しました。

JANOG30では会場付近にほとんど無線が出ておらず、電波は非常にクリーンでした。

■機材調達

ネットワークのデザインと下見による物理設計を元に機材を選定して、調達します。

機材借用で気をつけること

機材を借用するにあたっては以下のことを気をつける必要があります。

  • 借用の責任者・責任範囲・免責事項
  • 費用負担の範囲
  • 借用書の作成
  • 運搬保険の要不要
  • 同梱物の確認、一覧の作成

運搬中や使用中に装置が故障・紛失した場合の責任問題があるので責任の範囲は予め合意を行う必要があります。また機材をベンダー→ホットステージ会場→本会議場→ベンダーと運搬するので、運搬方法と費用の負担、運搬責任についても、予め決めておかなければなりません。借用書は借用責任者と各ベンダー様との間でやりとりを行います。

コアネットワークの機材調達

まず最低限のネットワーク提供に必要なのは以下の機材です。

  • 無線AP
    ※ 無線LANコントローラ(WLC)があると、便利
  • L2スイッチ
  • インターネット接続用ルータ

無線APは会場の規模によりますが12～15個で、それに応じてL2スイッチのポート数なども決めていきます。L2スイッチは可能であればPoE対応のものが理想です。理由としては、無線APにUTP経由で電源供給が出来、電源を取ることが難しい場所であっても、比較的容易に解決することが出来ますし、撤収の際、工数の削減が可能です。また、JANOGでは数百クライアントが同時に接続するため、特にNAPTのセッション数において、ルータには高い性能が必要になります。

ここからはオプションです。会場で監視計測のサーバを立てたり、他のネットワークを引っ張ってきたり、実験ネットワークを組む際に必要な機材です。

  • サーバ(DNS, 計測, 監視, ログ収集)
  • 実験用機材
  • VPNルータ

構想・設計から必要な機材を選定したのち、機材提供に協力していただけるベンダー様を探します。ここが非常に難所で、スポンサー様などに声をかけさせて頂いたり、スタッフで持ち寄ったりさせていただいています。

実験用機材の調達

実験ネットワークの機材は各ベンダーの方と直接交渉してお願いします。お願いするにあたっては次のことに気をつける必要があります。

  • 機密事項にあたるか
  • 情報の公開が可能か
    • 参加状態・機種・コンフィグ・バージョン
  • 免責

開発・検証中の最新の技術を使っている場合は、ビジネス上情報を出せない場合がありますので、情報の公開についてはベンダーの意向に従って実施します。万が一実験ネットワークが失敗した場合に、ベンダーに対して間違った評判とならないように表現には最大限配慮します。またベンダーの意向によっては、初めから社名などをださないといった配慮も必要になってきます。

■ホットステージ

当日ぶっつけ本番ですべてのネットワーク機器の設定を行うことは不可能に近いので、予め機器の設定を作り、動作を確認しておいて、当日は電源を入れて組み立てれば使えるようにしておく必要があります。これを行うのがホットステージと呼ばれる作業です。ホットステージの目標は「組み立てれば使える状態」です。

ホットステージの時期と期間

ホットステージを行う時期は早すぎず遅すぎずです。早すぎると機材借用期間が長くなってしまうし、遅すぎるとトラブルが発生してしまった時にリカバーできません。JANOGでは1.5週間前ぐらいから開始します。

期間はネットワークの規模によります。短すぎると作業が終わらない可能性がありますし、長すぎると無駄に稼働をとられる可能性があります。JANOG30では無線の設定でハマって時間を食ってしまいサーバの設定が一部間に合わなかったという経験があります。スタッフの稼働度合いを考慮した規模でネットワークを構築することも必要です。

JANOG31の場合は1月23日の前日準備に向けて1月15日から1月19日の期間で行いました。予備日として1月21日と22日を設定していました。4日のうち初日を開梱とコアネットワークの構築、残り3日を実験ネットワーク構築にあてました。

ホットステージまでにやること

  • 機材の手配
  • 会場の確保
  • おおまかな設計
  • 機材管理の準備
  • 資料の印刷

まずホットステージ会場の手配が必要です。JANOG30ではLAスタッフのさくらインターネット様、JANOG31ではホストのグリー様に会議室を提供して頂きました。

会場を選ぶ時には電源容量に気をつける必要があります。万が一、大量の実験機材を持ち込んで一般の会議室のブレーカーを落としてしまったら大変です。他には出入りのしやすさや、対外接続環境なども考慮するポイントです。本番と同じ環境を作ることができるのが望ましいのですが、それができる環境はほとんどありません。

ホットステージが始まった時に、手が止まっている人が出来ないように、後で述べるネットワークの設計とそのタスクの割り振りを予め行なっておいたほうが良いです。かならず指揮官を１人決めて作業の進捗確認と割り当てを行います。

JANOGでは機材管理に Post-itのラベルシール(12シートと24シートのもの) を使っています。これに通し箱番号、機材名、借用先を記入して、箱や機材や付属品(電源ケーブルやLANケーブルに至る)に貼っていきます。このシールの作成を済ませておきます。

L2図やL3図、アドレスリスト、ポートアサイン表などは印刷して持ってきておきます。紙の資料のほうが圧倒的に理解しやすいです。

ホットステージ中にやること

目標である「組み立てれば使える状態」に向かって突っ走ります。ただし間に合わない可能性もあるので、優先度をつけて取り組むことが大切です。JANOGではコアネットワークを作ることが実験ネットワークよりも優先です。

ホットステージ中にL2やL3の設計はどんどん変更が加えられていきます。そのためドキュメントには必ず日時を記入してバージョン管理し、Webなどから最新版を取れるようにする必要があります。

■グランドデザイン

img/janog31_network_grand-design.png

JANOGではまず来場者や出展者、スタッフや発表者によるデモンストレーション、さらには来場者が急な仕事を要した場合など、必要に応じて安定したインターネット接続が出来るよう、ネットワーク(コアネットワーク)を提供するという目的を持っています。それに付け加えて、いつ使えなくなっても問題のない実験ネットワークも提供するという位置づけになっています。

JANOG31のコアネットワークはそうしたポリシーに則って設計してあります。調整室とNOCと２つの部屋がありますが、コアネットワークはすべて調整室の中で閉じて動作するようにして、実験ネットワークはすべてNOCに設置しました。万が一調整室とNOCの間の配線が途切れたりNOCに置く実験用スイッチがトラブルに見舞われても、コアネットワークが動作できるようにするためです。また、ルータからトンネルを張ってホスト様のネットワークから抜ける設計にしていますが、万が一うまく行かなかった場合、会場のBフレッツ提供ルータに直収できるようにもしました。

■L0/L1設計

会場ネットワークを支える物理配線。配線ルートや実際に敷設する際に気をつけるポイントを紹介します。本項目の最大なポイントは、「会場へ来ていただく方と関係者への安全確保」です。

配線ルート設計時のポイント

  • 1本のUTPの長さは100mを超えないよう (実際は、90m以内に収まるように) 設計します。どうしても長くなりそうな場合は、一度SW-HUBなどを経由するようにします。もしくは、光ファイバー(インドア)を使用します。
  • ドアを経由する場合は、(1)ドアを開けっ放しにする、(2)ドアの隙間(下や横等)を通す、(3)ドアを半開き状態にする、の3種類から選択することになります。会場の構造によっては、消防法の観点から開けっ放しにできない場合がありますので、注意が必要です。ドアを半開き状態にする場合は、ドアの開閉時の衝撃でケーブルへの損傷を防ぐ為、PF管等でケーブル自体を防護する必要があります。
  • 会場内で使用するUTPは可能な限り目立たない色で、会場の雰囲気に合わせた方が無 難です(黒がオススメ)。
  • ケーブル長を測定する場合、出来れば実際のルートで計測を行います。計測には、ウォーキングメジャーや、レーザー距離計等を用途に応じて選定すると良いです。レーザー距離計を使用する場合は、正確な距離に囚われることは不要で、ある程度の“目安”として考えます。3回程測定し平均値でその区間のおおよその距離と考えれば良いでしょう(実際に敷設するケーブルはそれ以上の長さが必要となる)。

施工時のポイント

  • ケーブルの余長はある程度は自由に動かされる程度のあれば十分で、10m単位での余長は取らないようにします。
  • 会場内やホール内等人の目に触れるところは、なるべく綺麗にしかつ目立たないように配線するように心がけます(特に壇上はかなり目立つので机の前から配線はなるべく避け、ケーブルもごちゃごちゃさせない)。
  • 設計や施工時に、撤去時のことも考慮します。準備よりも撤去時間が短い事が大半なので、効率よく撤去出来るようにしておくことが望まれます。その為、撤去時に時間を要する施工方法等は極力取り入れないようにします。例えば、JANOG31では会場内をPIT内配線すれば見栄えはスッキリして綺麗ですが、撤去時に時間を要することから採用しませんでした。
  • 撤去時のことを考慮し、工具類(ニッパーとか)を必要としない方法でなるべく施工します。構築時のスタッフ以外でもスムーズな撤去を可能とし、また工具を持っている人でなければ作業できないというのはなるべく避けるようにします。
  • 会場内では数多くのケーブルを接続します。その為、このケーブルの行き先はどこなのかと、ある程度わかるようにします(ただし、あくまでも可能な範囲で)。
  • 使用するUTPは、単線ケーブル、Cat5e以上を使用します。撚り線は使用しません(現在は、1Gbpsまでの通信の為、Cat5e以上としています。2013年1月現在)。
  • 爪が折れているRJ45コネクタは使用せず、作り直しや交換します(知らない間に外れていたりして、無用なトラシューを強いられます)。
  • 余長処理は、そのままケーブルを放り投げす輪を作った状態でベルクロ等で固定すると綺麗に見えます。

設計時・施工時共通のポイント

  • 人や台車等が多く出入りや通過しない所を極力選ぶ。どうしても人が多く通る場所は、参加者などそこを通る人への安全対策をとる必要があります。具体的には、ケーブルにつまづかないように養生テープなどで固定したりマットで覆ったり、またケーブル自体踏まれても大丈夫なようにソフトモールを使う必要があります。
  • バックヤード側は、手押し台車やカゴ台車での往来が多いところもあるので、会期中の配線トラブル(断線等)を防ぐことが重要になります。会期中に断線トラブルが発生する場合は、復旧に時間を要し限りある人的リソースも消費します。また、断線箇所によっては会場内へのネットワーク提供も不可となってしまう可能性もあります。

全体を通して、参加者やその他のスタッフや関係者に対して「安全」を確保することが 【最優先項目】 です。効率化や綺麗にみせる化技術をそれぞれ天秤にかけそれらを実現する場合には、「安全性が担保できるか?」「どうやったら安全になるか?」を考える必要があります。 ※JANOGの本会議に出席したら会場内で怪我をしたといわれることは、最も避けなければいけません!

アドバイス

  • どうしても多く人の通りが多いドア付近をケーブルを這わせる必要がある。
    • 可能であればルート変更を推奨。それでも変更できない場合は、まずケーブル自体を床に固定し、その上で養生マットを被せる。
    • それができない場合は養生テープでケーブル部分をなるべく広範囲で養生する。少ないと人が通る際にケーブルに引っかかり、養生テープが剥がれ余計につまづきやすくなります。
  • ケーブルが宙ぶらりんになってしまい、固定したい
    • ネジリッコや、ベルクロ(マジックテープ)、養生テープ等で固定します。
    • インシュロック等は取り付け時は簡単だが、撤去時はニッパー等の工具が無いと外せれないのでなるべく使用しないようにします。
  • 無線APや、SW類を机等に固定したい
    • ベルクロ(マジックテープ)もしくは養生テープ(なるべく白色)で固定します。
  • ケーブルを敷設する区間に、養生テープ等の使用ができず固定できないところがある
    • ケーブル自体をマットで覆うか、ソフトモールに床用滑り止めテープを貼った状態で床置する。
    • 床と固定されていないが、滑り止めテープによってモール自体が滑りにくい。

■無線設計

AP配置設計

img/janog31_network_ap-distribution.png

無線APの配置は電波範囲と電源供給箇所とUTP配線との兼ね合いになります。まず設置可能なポイントを探ります。JANOG31の場合はPoEによる電源が供給が可能な構成だった為、電源を考慮する必要は余りありませんでした。しかし、LAN配線については、パッチを経由し、壁の情報コンセントから接続する為、情報コンセント近所が設置可能なポイントになります。

そこから3種類の色の半径10m程度の円をなるべく同色が重ならないように、会場の必要部分が覆えるように配置していきます。色は2.4GHzでいう1ch, 6ch, 11chにそれぞれ当たりますが、どのチャネルをどの色にしているかは下見の時に電波状況を確認して決めます。

電波強度設計

無線の電波強度は実際に会場に設置してから確認を行います。同じチャネルの他のAPと干渉しない程度の強さに調整していきます。ただし人間が入ると電波が吸収されることを考慮して少しだけ強めにします。本来であれば天井などの高所に設置しますが、JANOGでは難しいので譜面台などで人と同じ程度の高さに設置します。金属やコンクリートは激しく電波を吸収してしまうので、金属の扉やコンクリートの壁を隔てれば電波は届かないと考えると良いでしょう。

JANOG30では電波がクリーンだったため細かくチューニングをして快適な電波環境にすることができました。JANOG31では自動で調整をしてみましたが、特定の場所・特定の機器で接続ができないなど、あまり良くなかったようです。

無線チャネル設定

2.4GHz帯は1ch, 6ch, 11chの３つのチャネルについて、どのAPにどのチャネルを割り当てるのかを決めます。 5.0GHz帯はもっと多くのチャネルを使うことができます。36ch,40ch, 44ch, 48chはW52、52chからはW53と呼ばれますが、W53は気象レーダーなどと周波数帯がかぶっているのでDFS(Dynamic Frequency Selection)が有効になっていると時々チャネルが変わって他のAPと干渉することがあります。

下の例では通常のAPとW53のチャネルに設定されたAPのクライアント数のグラフを掲載しています。 W53のチャネルに設定されたAPでは5GHz帯のクライアントが2.4GHz帯に移動させられているのがわかります。これを許すかどうかはポリシー次第です。

img/wireless-clients_ap05_day1.png

正常なAP

img/wireless-clients_ap13_day1.png

W53のチャネルのAP

無線機材

無線機材は今回もCisco Systems様から提供して頂きました。Ciscoの無線AP(Aironet)はスタンドアロンで動作するautonomousモードと、WLCで集中管理されるLightweightがあり、それぞれファームウェア(IOS)が異なります。WLCを使うことによって複数台のアクセスポイントの設定や管理をネットワークを通して一括して行うことができます。WLC自体は高価ですが、多くの台数のアクセスポイントの設定と管理が必要な場合に利用することで運用コストを削減することができます。

JANOG31ではAPの数が13台以上と非常に多いのでWLC(Wireless LAN Controller)を使ってアクセスポイントを集中管理することにします。

img/janog31_core_wlc.jpg

Cisco WLC 2504

img/janog31_core_cisco-aironet1262.jpg

Cisco Aironet 1262

今回はWLCにCisco WLC 2504、APにCisco Aironet 1262とCisco Aironet 3502を提供して頂きました。この2つは外見はそっくりですが、3502の方が新しくて高機能です。見分け方は中央部のロゴが銀色のものが3502、濃い灰色のものが1262です。それぞれ6本のアンテナがついていますが、3本が2.4GHz(丸形アンテナ)で3本が5GHz(平べったいアンテナ)のものです。

WLCを使うLightweightモードではWLCとAP間でLWAPP(1262)やCAPWAP(3502)というプロトコルでトンネルを使って通信を行い、WLCにAPを接続すると自動的に認識されます。以前のコンフィグが残っているとうまくWLCと接続できないため、APは起動時にIOS以外のすべてのファイルを削除して、IOSのバージョンも揃えておくと良いです。WLCにはWebブラウザ経由でアクセス可能で、GUIで設定を行なっていきます。WLCとAPのアドレスはmanagementセグメントのアドレスを設定していきます。このアドレスでトンネルが張られます。

無線セキュリティ

セキュリティー対策として、以前まではWEPを使用していましたが、WLCを使用することもあり、APへの負荷が軽減出来ること、WEPしか対応しないクライアントは非常に少なくなったことから、今回は、WPA2+PSKを使用することとしました。平均して300台程度のクライアントが会場ネットワークに接続していましたが、WPA2での運用に問題はありませんでした。

そのほか、DHCP Spoof対策、プライバシーセパレータによるクライアント間の通信の拒否などの実施を行っています。

無線通信速度

また、JANOG28 feedback meeting で説明させて頂いた対応として、遅いレートを使用しないよう、54Mbps優先で、24Mbps, 36Mbps, 48Mbpsをサポート、1Mbps～9Mbps,12Mbps～18Mbpsをサポート外としました。今回、11bを対応外に出来なかったのは、先行して802.11abg対応と書いてしまったために、11bを外せなかったという失敗もありました。

■L2設計

ネットワークのグランドデザインと下見で得られた物理的制約に基づいてL2の設計を行います。

img/janog31_network_L2-topology.png

JANOG31 L2図

やること

  • 機材の収容構成を決める
  • L2スイッチのポートのVLANの設定を決める
  • L2スイッチのポートのdescriptionを決めておく
  • L2図を描く

ポイント

  • 多ポートのL2スイッチに全部収容してVLANでセグメントを分ける
  • セグメントには名前(description)をつけておく
  • ポートアサインは会場での機材配置を想像して行う
  • SNMPで情報を取得する場合、VLANトランクをすると、合計値となってしまうため、なるべくシンプルに。

L2の設計ではスイッチの構成、ポートのアサイン、VLANのアサインなどの作業を行います。L2設計は物理的な制約に縛られることが多く、スイッチの配置場所や借用できる機材のスペックや数に依存します。ネットワークをコンパクトにするために、L2スイッチにほとんどの機器を接続してVLANでセグメントを区切ることが多いです。尚、VLANやセグメントの切り方はL3の設計に依存します。

まず物理的な制約から調整室に48ポートのL2 PoEスイッチ、NOCに48ポートのL3スイッチを設置することを決めました(結果としてどちらも担えるハイスペックなL3 PoEスイッチを提供して頂きました)。ポート数は接続される機器の数から判断します。また、アクセスポイントを接続するスイッチはPoE対応のものが手配できると非常に構成がシンプルになり、運用も楽になります。

スイッチのポートを各機器にアサインしていきます。ルータのような機器には基本的に対外接続用とLAN用で２ポートアサインします。場合によってはマネージメントポートとしてもう１ポートアサインします。アサイン順序は、論理的な設定内容に依存せずに、本会議場に設置した時の物理的な機材の設置を想像して決めるとわかりやすいと思います。

VLANのアサインはなるべく規則性があって、L3のアドレスとも関係があるものが好ましいです。具体的なアサインは次のL3図を参照してください。ポートに対するアサインはL2図の赤字のもので行なっています。ここで()で書かれた数字はuntaggedのVLANです。JANOG30では10台程度のスイッチを会場全体に配置する必要があったため、各スイッチにポートのVLANアサインを書いた紙を貼り付けていましたが、では２台のスイッチに集約できたのでL2図を参照するようにしました。

安価なスマートスイッチや、古い製品などを併用する場合、1005を超えるVLANは、拡張範囲 VLAN と呼ばれ、使えない機器がありますので、注意が必要です。特にたくさんのVLANを必要としないのであれば、1～1001の間にしておくと、無難でしょう。また、VLAN1(Default VLAN)の取扱については、機器によって違いますのでそのあたりの注意も必要ですし、Cisco製の場合だと、VLAN ID 1002～1005は、トークンリングおよび FDDIのVLAN 専用となっていたりしますので注意が必要です。

VLANで多重化できる場合でもポート数の制約がない限りは分けておいたほうが良いです。理由は各実験ネットワークのトラフィック量をSNMPなどで取得する場合に、各機器のSNMPの設定、必要に応じてOIDの情報を調べる必要が有りますが、スイッチのポートを参照すればトラフィックが正確に分かります。

今回はSoftwire WGの発表セッションでMAP-EのBR切り替え実験を行うためにBRのポートをRouted Portに設定してあります(VLANに所属するポートが１つであればSVIでも実現可能です)。DS-Lite/464XLATのAFTR/PLATの上流ポートも揃えてroutedで設定しました。またL3の設計上vlan interfaceを設定してルータとして動作するようにしてあります。

■L3設計

img/janog31_network_L3-topology.png

JANOG31 L3図

やること

  • セグメントの作成
  • セグメントのdescriptionの決定
  • セグメントに対するprefixの割り当て
  • セグメント内の機器のホストアドレスの割り当て
  • ルーティングの設計
  • NAPTの設計
  • DHCPの設計
  • L3図を描く
  • ルーティング図を描く

ポイント

  • 機器管理用セグメント(management)を作る
  • IPv4アドレス、IPv6アドレス、VLAN番号に規則性をもたせる
  • セグメントの上流機器は若番アドレス、下流機器は老番アドレスなど規則性をもたせる
  • 実験ネットワークはL1でもL2でもL3でも分離
  • ルーティングをstaticで行うときはping-pongに注意
  • 未使用のアドレスブロックは、nullへ
  • NAPTのセッション溢れに注意

L3の設計ではIPアドレスのアサイン、ルーティングの設計などを行います。会場で利用可能なアドレスが限られているので、最大限に活用できるような割り当て方を行います。JANOG31のネットワークではコアネットワークの安定性を要件にしていたので、安定無線ユーザのトラフィックは直接ゲートウェイルータに収容する一方、実験ネットワークをL3スイッチにすべて収容して分離しました。

IPv4は/23、IPv6は/48を提供して頂きました。実験ネットワークの都合上IPv4/24ではギリギリだったので、念のため/23を提供して頂きました。このうち上流のpoint-to-pointのセグメントとコアネットワークでアドレスの半分を利用し、もう半分を実験ネットワークに使いました。

IPアドレスは在庫の許す限り規則性をもつようにしてアサインを行なっていきます(今回のネットワークは事情があってあまり良くない例になってます)。アドレスの多いIPv6ではPrefixにVLAN番号をそのまま入れるようなこともあります。ネットワークの順番とアドレスの大小を揃えたり、セグメントの上流機器は若番アドレス、下流機器は老番アドレスなどの規則性をもたせたりします。覚えやすいアドレス設計は設定時やトラブルシュート時に無用な混乱を招かなくて済みます。ちなみに、JANOG31では、IPv6のアドレスは、GREE様の文字を取った仕込みなど、ちょっとした遊び心も取り入れています。

このような小規模のネットワークではstaticでルーティングを行います。この時気をつける必要があるのがping-pongです。上流ルータから192.0.2.0/24というアドレスがstaticでルーティングされているルータで、192.0.2.128/25など一部のセグメントしか使用しなかった場合、デフォルトゲートウェイを上流ルータに向けていると192.0.2.1宛のパケットは上流ルータと下流ルータの間でTTLが無くなるまで往復してしまいます。これを防ぐために自分に委譲されたプレフィックスは最低優先度(Administrative Distance:254)でNullインターフェースに落としておく必要があります。

#上流ルータ
ip route 192.0.2.0 255.255.255.0 203.0.113.2

#下流ルータ
ip route 0.0.0.0 0.0.0.0 203.0.113.1
ip route 192.0.2.0 255.255.255.0 Null 0 254   ←これ大事

NAPTの設計も行います。多数のユーザが接続するネットワークのNAPTではセッション溢れが起こることがあります。JANOG31でも前日設営時に20人程度のスタッフだけであふれたことがありました。この場合は外部アドレスを増やす方法と、ip nat translation *-timeoutなどのコンフィグでNAPTのセッション保持時間を短くする方法で対応します。

■対外接続

img/janog31_network_uplink.png

JANOG31 対外接続部ネットワーク図

config gree-vpn コンフィグ

JANOG31では会場ネットワークをホストのグリー様のネットワークから提供するために、会場側ゲートウェイ(janog-gw)とグリー様のDC内に設置されたルータ(gree-vpn)との間でトンネルを張りました。これによりグリー様のグローバルアドレスを使用して多種多様な実験ネットワークの構築が可能になりました。

会場ではBフレッツのアクセス回線が敷設されていました。インターネットアクセスにはスタッフからのドネーションで、OCNの固定IPのアカウントを払いだして頂きました。固定IPにしたのはトンネルの終端アドレスが途中で変更にならないようにするためです。janog-gwでIPv4のPPPoE接続を行い、インターネットを経由してグリー様のネットワークまでトンネルを張ります。

トンネルには当初L2TPを使う予定でしたが、janog-gwでNAPTを行った時の相性が悪くうまく動作できなかったため、GREトンネルを利用することにしました。デフォルトルートのnext-hopをトンネルのセグメントの対向のアドレスに向けるだけでルーティングできるので、あまり悩まされずに構築することができます。

グリー様のネットワーク内では、バックアップ系のBGPルータにトンネル終端のルータ(gree-vpn)を接続しています。BGPルータとの間は物理的には１つの線ですが、ip address … secondaryで論理的に２つのセグメントを作成して、上流、下流を使い分けています。

■コアルータ

img/janog31_core_janog-gw.jpg

Cisco 3900

config janog-gw コンフィグ

JANOG会場の対外接続部とコアネットワークのルーティングを担当するコアルータ(janog-gw)にはCisco 3900を採用しました。数百人規模のユーザに対してNAPTを行うための性能を持つルータとして選定しています。このルータでは、対外接続、安定した通信が必要とされるセグメントの収容とそれに対するNAPTやDHCP等のサービス、実験ネットワークへのルーティングを行なっています。

インターネット接続設定

対外接続はPPPoEで行います。今回はBフレッツがアクセス回線なのでMTUは1454 byteです。通常の家庭で設定するものと変わりありません。

interface Dialer1
 mtu 1454
 ip address negotiated
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname ******
 ppp chap password 7 ******

トンネル設定

トンネルはGREトンネルで設定します。IPv4とIPv6で分けてあります。

interface Tunnel0
 no ip address
 ipv6 address 2400:8700:31:FFFE::1/126
 ipv6 enable
 tunnel source Dialer1
 tunnel mode ipv6ip
 tunnel destination 157.112.199.253
 tunnel path-mtu-discovery
!
interface Tunnel1
 ip address 157.112.199.245 255.255.255.252
 ip nat outside
 no ip virtual-reassembly in
 tunnel source Dialer1
 tunnel destination 157.112.199.253
 tunnel path-mtu-discovery

ip route 0.0.0.0 0.0.0.0 Tunnel1 157.112.199.246
ipv6 route ::/0 Tunnel0 2400:8700:31:FFFE::2

GREトンネルを使う場合はMTUに気をつける必要があります。会場はBフレッツが敷設されているのでルータでのMTUは1454 byteになります。そこからIPv4トランスポートのGREトンネルで24 byte(IPv4ヘッダ20 byte+GREヘッダ4 byte)を引いた1430 byteから、IPv4は20 byte、IPv6は40 byteのヘッダ分を引いた、IPv4 1410 byte、ipv6 1390 byteがルータの下流に設定したほうが良いMTUになります。IPv4のTCP MSSはさらに20 byte引いた1390 byteになります。今回はPath MTU discoveryを期待して細かく設定はしていません(動作確認は行なっています)。

NAPTの設定

NAPTのセッションが枯渇しないようにタイムアウトの間隔を短くし、かつ外部アドレスのレンジを増やしています。

ip nat translation tcp-timeout 300
ip nat translation udp-timeout 120
ip nat translation dns-timeout 10
ip nat translation icmp-timeout 5
ip nat pool general-NW 157.112.199.32 157.112.199.63 net mask 255.255.255.224
ip nat pool staff-NW 157.112.199.64 157.112.199.95 net mask 255.255.255.224

来場者収容I/Fの設定

janog-gwに直収する各セグメントは一旦core-swに送られるため、1つの物理インターフェイスでtag VLANで多重化されます。

interface GigabitEthernet0/1.155
 description ### Stable Network ###
 encapsulation dot1Q 155
 ip address 172.16.0.1 255.255.0.0
 ip flow ingress
 ip nat inside
 no ip virtual-reassembly in
 ip tcp adjust-mss 1390
 ipv6 address 2400:8700:31:91EE::1/64
 ipv6 enable
 ipv6 nd other-config-flag
 ipv6 dhcp server Stable-VLAN155-v6

■コアスイッチ

config core-sw コンフィグ

core-swは調整室に設置され、会場APや協賛ブース、スタッフ席のネットワークを収容しています。また、調整室～NOC間は会場既設のパッチを使用した配線ということ、また長距離のパッチケーブルを準備しなくても良いと言うことから、リンクの冗長の為、47-48の2portによるリンクアグリゲーション(EtherChannel)接続しています。今回のネットワーク構成においてnoc-swやjanog-gwはルーティングを行っておりますが、core-swはルーティングしていません。なのでL3構成図にもcore-swは現れませんし、ip routingのconfigもありません。

無線AP向けスイッチポートの設定

interface GigabitEthernet0/1
 description AP01
 switchport access vlan 153
!
interface GigabitEthernet0/2
 description AP02
 switchport access vlan 153
!
…
!
interface GigabitEthernet0/18
 description AP18
 switchport access vlan 153

協賛ブース向けスイッチポートの設定

interface GigabitEthernet0/21
 description STABLE
 switchport access vlan 155
!

WLC向けスイッチポートの設定

interface GigabitEthernet0/43
 description WLC
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 153
 switchport trunk allowed clan 111,112,121,131,141,151,153,155
 switchport mode trunk

janog-gw向けスイッチポートの設定

interface GigabitEthernet0/45
 description JANOG-GW
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 101,151-153,155
 switchport mode trunk

noc-sw向けスイッチポートとリンクアグリゲーションの設定

interface GigabitEthernet0/47
 description TO-NOC-SW-1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 101,111,112,121,131,141,151-153,155
 switchport mode trunk
 channel-group 1 mode active
!
interface GigabitEthernet0/48
 description TO-NOC-SW-2
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 101,111,112,121,131,141,151-153,155
 switchport mode trunk
 channel-group 1 mode active

interface Port-channel1
 description TO-NOC-SW
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 101,111,112,121,131,141,151-153,155
 switchport mode trunk

■実験用ルータ

config noc-sw コンフィグ

noc-swでは、MAP-E、DS-Lite、464XLAT、HANAなどのIPv4/IPv6移行技術用実験ルータを収容するルータであり、各実験ルータ用のVLAN設定やstaticルートを設定しています。特徴的な設定として、BRルータの切り替えのためのfloating static routeの設定と、CE切り替えのためのdummy VLANの設定が入っています。

BRルータの切り替え

Softwire WGの発表内でMAP-EのBRの切り替え実験を行うための設定を行いました。IPI-BRと接続しているポートのケーブルを抜去した直後にFNSC-BRに切り替わるようにするために、floating static routeの設定の設定を行なっています。

ipv6 route 2400:8700:31:610::/64 GigabitEthernet0/1 2400:8700:31:611::2 200
ipv6 route 2400:8700:31:610::/64 GigabitEthernet0/3 2400:8700:31:612::2

floating static routeは同一の宛先に対してインターフェイスとネクストホップが異なる経路を設定する時にadministrative distance値を変更することで実現しています。administrative distance値は数字が小さいほうが優先されるため、これによってGigabitEthernet0/3がリンクアップしている間はNext-hopを2400:8700:31:612::2とし、GigabitEthernet0/3がリンクダウンした時にはNext-hopがGigabitEthernet0/1の先の2400:8700:31:611::2に切り替わるようになります。

S 2400:8700:31:610::/64 [1/0]
     via 2400:8700:31:612::2, GigabitEthernet0/3
↓
S 2400:8700:31:610::/64 [200/0]
     via 2400:8700:31:611::2, GigabitEthernet0/1

S 157.112.198.105/32 [1/0] via 157.112.198.102, GigabitEthernet0/3
S 157.112.198.104/32 [1/0] via 157.112.198.102, GigabitEthernet0/3
↓
S 157.112.198.105/32 [200/0] via 157.112.198.98, GigabitEthernet0/1
S 157.112.198.104/32 [200/0] via 157.112.198.98, GigabitEthernet0/1

CEルータ切り替え

MAP-Eネットワーク(janog31-map-e1)では時間によってCEの機器を切り替えていました。すべての機器をあらかじめ接続しておき、論理的なコンフィグの変更のみで切り替えを行えるようにしています。接続対象ではないCEのダウンリンク側インターフェイスをダミーVLAN(162～165)に所属させておき、接続対象であるCEのダウンリンク側インターフェイスだけをjanog31-map-e1のVLAN111に所属させることにしています。

interface GigabitEthernet0/10
 description F60-DOWN
 switchport access vlan 163　←ダミー
!
interface GigabitEthernet0/12
 description SEIL-MAP-E-DOWN
 switchport access vlan 111　←接続
!
interface GigabitEthernet0/14
 description RTX1200-DOWN
 switchport access vlan 164　←ダミー
!
interface GigabitEthernet0/15
 description ASAMAP

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 161

　↓下流VLAN設定を入れていない

 switchport mode trunk

MAP-E BR向けrouted portの設定

interface GigabitEthernet0/1
 description FX5000
 no switchport
 ip address 157.112.198.97 255.255.255.252
 ipv6 address 2400:8700:31:611::1/64
!

サーバ向けスイッチポートの設定

VM内でVLANをほどくのでtrunkで設定します。

interface GigabitEthernet0/45
 switchport trunk encapsulation dot1q
 switchport trunk allowed clan 152,153
 switchport mode trunk
!
interface GigabitEthernet0/46
 switchport trunk encapsulation dot1q
 switchport trunk allowed clan 152,153
 switchport mode trunk
!

janog-gw向けVLANインターフェイスの設定

実験ネットワークのゲートウェイルータとして使うため、VLANインターフェイスを作成してアドレスを設定します。

interface Vlan101
 ip address 157.112.199.125 255.255.255.252
 ipv6 address 2400:8700:31:CFFF::2/64

ルーティング設定

default route, 各実験ネットワーク向けのルーティング(floating static route)、ping-pong対策のルーティング設定を行なっています。

ip route 0.0.0.0 0.0.0.0 157.112.199.126
ip route 157.112.198.0 255.255.255.192 157.112.198.253
ip route 157.112.198.64 255.255.255.240 157.112.198.66
ip route 157.112.198.80 255.255.255.240 157.112.198.66
ip route 157.112.198.96 255.255.255.240 Null0
ip route 157.112.198.104 255.255.255.255 GigabitEthernet0/3 157.112.198.102
ip route 157.112.198.104 255.255.255.255 GigabitEthernet0/1 157.112.198.98 200
ip route 157.112.198.105 255.255.255.255 GigabitEthernet0/3 157.112.198.102
ip route 157.112.198.105 255.255.255.255 GigabitEthernet0/1 157.112.198.98 200
ipv6 route 2400:8700:31::/56 2400:8700:31:FFF::253
ipv6 route 2400:8700:31:200::/55 2400:8700:31:333::2
ipv6 route 2400:8700:31:400::/55 2400:8700:31:333::2
ipv6 route 2400:8700:31:600::/64 2400:8700:31:601::12
ipv6 route 2400:8700:31:610::/64 GigabitEthernet0/1 2400:8700:31:611::2 200
ipv6 route 2400:8700:31:610::/64 GigabitEthernet0/3 2400:8700:31:612::2
ipv6 route 2400:8700:31:600::/56 Null0
ipv6 route 2400:8700:31:800::/64 2400:8700:31:801::15
ipv6 route 2400:8700:31:800::/56 Null0
ipv6 route ::/0 2400:8700:31:CFFF::1

■サーバ

DNS

会場では、インターネット上の宛先の名前解決ができるDNSキャッシュサーバを用意する必要があります。また、数百人規模での利用が想定されるため、多くの問合せ要求が発生します。そのために、多くの問合せを処理できるようにする必要があります。

DNSのキャッシュサーバの実装としては、BINDやunbound,dnscache等があります。 NAT64のための、DNS64などの実装が必要であればBINDを選ぶことになりますが、JANOG31のネットワークでは通常の名前解決のみで他の機能は必要がなかったため、unboundを利用しました。

実際にunboundを運用するために、標準から変更している設定が幾つかあります。まず、libeventを利用するようにコンパイルを行いました。また、毒入れの防止のためにDNSSECの検証を有効にしました。さらに、応答を素早く返すために、レコードのTTLが0になる前に再度キャッシュを行うプリフェッチ機能を設定で有効にしました。多くの接続が予測される環境での利用のため、通常では無効になっているラウンドロビンを有効にして運用をしていました。

DNSキャッシュサーバを構築した後は、多くの要求に答えられるか実際に性能テストを行う必要があります。その際に、BINDに含まれるqueryperfを利用して性能テストを行いました。問合せをするドメインとしては、namebenchに含まれるTOP100サイトを元に測定を行いました。結果、4万qps程度の性能があったので、パフォーマンス上、十分だと判断しました。

今回は測定をしていないが、munin-node用のスクリプトも存在しているので、キャッシュヒット率や問い合わせレコードの種別等の統計を取るとパラメータの調整等が行い易くなるかもしれません。

監視

会場ネットワークで起きた障害を検知するためにnagiosなどの監視ツールを利用します。JANOG31では人手＆時間不足のため監視の設定は行いませんでした。

他にはsyslogd, snmptrapdを立ち上げ、機器からのログを取得を行っています。異常の連絡などがあった場合、このログが問題解決の手がかりになる可能性があります。

計測

最近のJANOGでは、設計・構築・運用ノウハウがたまっており、ネットワークの性能が生かせているか、また、偏った負荷が無いか、常時計測をしています。また、公開できる範囲で、より多くの方に快適に使ってもらうため、全体のトラフィック量、無線LANのアクセスポイントへの接続数、実験ネットワークへの接続数などを公開し、協力を頂いたベンダー様へ、どの程度のノードの接続があったかを実績として情報共有を行っています。

とはいえ、ぎりぎりの人数のスタッフで行っているため、多くの時間を割くことが出来ませんので、使用実績の有るCactiを使用し情報の取得をしています。Cactiでデータを取るには、SNMPで情報が取得できる機器である必要があるため、設計段階から対応している機器をなるべく使用するようにしています。(といっても、ホスト様、協賛社様からお借りすることが多いため、一概には言えませんが)。

たとえば、今回はCisco製のWLCを使用しましたが、WLCから無線関係の情報を取るには、次のOIDをたたけば、AP毎の2.4GHz, 5GHz共に接続数や、SSID毎の接続数などの情報を取得することが出来ます。WLCに接続されたAPは、Base Radio MAC Address (AP MACAddressではない)を10進数に変換したもので管理されていて、赤字の中の6つの数字がそれに該当します。

WLCの無線関係MIB

2.4GHzのクライアント数 .1.3.6.1.4.1.14179.2.2.2.1.15.32.55.6.68.244.224.0
5GHzのクライアント数 .1.3.6.1.4.1.14179.2.2.2.1.15.32.55.6.68.244.224.1
SSIDごとの接続数
.1.3.6.1.4.1.14179.2.1.1.1.38.1
.1.3.6.1.4.1.14179.2.1.1.1.38.2

自律モードの時の無線関係のMIB

2.4GHzのクライアント数 .1.3.6.1.4.1.9.9.273.1.1.2.1.1.1
5GHzのクライアント数 .1.3.6.1.4.1.9.9.273.1.1.2.1.1.2

■MAP-E 実験ネットワーク

MAP-Eの実験ネットワークを構築するにあたって5社のベンダー様から7種の機材を提供して頂きました。

MAP-Eはステートレスなトンネリング方式によりIPv4 over IPv6を実現します [1] 。MAP-E試験ネットワークを構築していく上で、得られたノウハウを記します。

JANOG31の準備として会場ネットワークを事前に構築し、試験を行うホットステージを行いました。MAP-Eは2012秋に新潟で各ベンダが参加した相互接続試験を行っています [2] 。ホットステージでは相互接続試験で見られた問題 [3] はほとんど解決されていました。ホットステージ中、新たにフラグメントに関する問題が見つかりました。フラグメント時、IPフラグメント・パケットが同じIDを持つ必要がありますが、IPフラグメント・パケット毎に異なるIDがついていました。そのため、オリジナルのIPパケットが再構成できない問題がありました。MAP-E とは直接関係ありませんが、Windows8 の DHCPv6 クライアント動作が他 OS とは異なり、DNS アドレスが配布されないという問題が見つかりました [4] 。この問題は MAP-E では利用可能なポート数が限られるため、 DNS query のproxy の際に IPv6 を用いたことから見つかりました。

JANOG31本会議では、1CEに割り当てられるポート数が制限されることから、ポート割当て数の異なる2つのネットワークを用意しました。ポート割当て数の多いネットワークは特に問題なく運用できていました。ポート割当て数の少ないネットワークも NAPT のテーブルで宛先ポートを IPv4 宛先アドレスと合わせて一意になるように割り当てる工夫により、大きな問題はなく動作していました。

以下に各ベンダー様のコンフィグを掲載します。コンフィグから見える実装の違いや設計の思想の違いを感じ取ってもらえると楽しめると思います。

IP Infusion (BR)

img/janog31_map-e_ipinfusion.jpg

IP Infusion (map-e BR)

IP Infusion様から提供頂いたBRは、機器ベンダー向けのルーティングソフトウェアであるため、Linuxカーネルに実装されています。ipコマンドでMAP-Eの制御を行なっています。ここではコンフィグを分かりやすくするため/etc/rc.local に全て記載しています。

ip -f inet6 tunnel add map1 map_mode map-e \
fmr 1 \
mss auto \
wan_if_name lo \
encap_src_check 0 \
ttl_propagation 1 \
allow_private 1 \
rule_ipv6_prefix 2400:8700:31::/48

ip -f inet6 tunnel register map1 rule_ipv4_prefix 157.112.198.104/32 2400:8700:31:600::/56 8 0
ip -f inet6 tunnel register map1 rule_ipv4_prefix 157.112.198.105/32 2400:8700:31:800::/53 8 0

ifconfig map1 up
sysctl -w net.xrd.delegated_prefix=2400:8700:31:610::1/128
route add -host 157.112.198.104 map1
route add -host 157.112.198.105 map1

FNSC FX5000 (BR)

img/janog31_map-e_fnsc-fx5000.jpg

古河ネットワークソリューション FX5000(map-e BR)

古河ネットワークソリューション様のFX5000はキャリア向けのルータです。直流電源が必要なためAC/DCコンバータを併せて設置しています。MAP-E部分のコンフィグを抜き出して掲載します。

config FX5000 コンフィグ

…
ip route 157.112.198.104 255.255.255.255 tunnel 1
ip route 157.112.198.105 255.255.255.255 tunnel 2
…
interface tunnel 1
 description mape-rule1
 tunnel mode ipinip ipv4 ipv6-tunnel-profile 1
exit
!
interface tunnel 2
 description mape-rule2
 tunnel mode ipinip ipv4 ipv6-tunnel-profile 2
exit
!
!
ipv4 ipv6-tunnel-profile 1
 profile-mode map-encap
 rule-ipv4-prefix 157.112.198.104/32
 rule-ipv6-prefix 2400:8700:31:600::/56
 user-len 8
 source-address 2400:8700:31:610::1
 ipinip fragment pre
exit
!
ipv4 ipv6-tunnel-profile 2
 profile-mode map-encap
 rule-ipv4-prefix 157.112.198.105/32
 rule-ipv6-prefix 2400:8700:31:800::/53
 user-len 11
 source-address 2400:8700:31:610::1
 ipinip fragment pre
exit
…

FNSC F60 (CE)

img/janog31_map-e_fnsc-f60-f200.jpg

古河ネットワークソリューション FITELnet F60(map-e1 CE) (上段)

古河ネットワークソリューション様のFITELnet F60は小型のアクセスルータです。ポート割当数の多いjanog31-map-e1のCEを担当していました。MAP-E部分のコンフィグを抜き出して掲載します。MAP用のプロファイルを作成して、トンネルのモードの設定の特にMAPを選んで、パラメータとして渡す実装になっているようです。

config F60 コンフィグ

ip route 0.0.0.0 0.0.0.0 tunnel 1
ip nat max-sessions 20000
…
ip nat ap_pool POOL1
 ipv6-mape-profile 1
exit
ip ipv6-mape-profile 1
 user-len 8
 br-address 2400:8700:31:610::1
 rule-ipv6-prefix reference-interface lag 1
 rule-ipv6-prefix-len 56
 rule-ipv4-prefix 157.112.198.104 255.255.255.255
exit
!
…
interface lan 1
 ip address 192.168.11.1 255.255.255.0
 ipv6 address address-pool POOL1 prefix-length 64 interface-id mape-rule
ipv6-mape-profile 1
 ipv6 nd other-config-flag
 ipv6 nd sender
 ipv6 dhcp server serv1
exit
interface tunnel 1
 tunnel mode ipip ipv6-mape-profile 1
 tunnel source reference-interface ipv6 lan 1
 ip mtu 1460
 ip nat inside source list 1 ap_pool POOL1
exit
…

FNSC F200 (CE)

img/janog31_map-e_fnsc-f60-f200.jpg

古河ネットワークソリューション FITELnet F200(map-e2 CE) (下段)

古河ネットワークソリューション様のFITELnet F200は中型の企業向けルータです。ポート割当数の少ないjanog31-map-e2のCEを担当していました。MAP-E部分のコンフィグを抜き出して掲載します。

config F200 コンフィグ

ip route 0.0.0.0 0.0.0.0 tunnel 1
ip nat max-sessions 20000
…
ip nat ap_pool POOL1
 ipv6-mape-profile 1
exit
ip ipv6-mape-profile 1
 user-len 11
 br-address 2400:8700:31:610::1
 rule-ipv6-prefix reference-interface lag 1
 rule-ipv6-prefix-len 53
 rule-ipv4-prefix 157.112.198.105 255.255.255.255
exit
!
…
interface lan 1
 ip address 192.168.12.1 255.255.255.0
 ipv6 address address-pool POOL1 prefix-length 64 interface-id mape-rule
ipv6-mape-profile 1
 ipv6 nd other-config-flag
 ipv6 nd sender
 ipv6 dhcp server serv1
exit
interface tunnel 1
 tunnel mode ipip ipv6-mape-profile 1
 tunnel source reference-interface ipv6 lan 1
 ip mtu 1460
 ip nat inside source list 1 ap_pool POOL1
exit
…

銀座堂 ASAMAP (CE)

img/janog31_map-e_ginzado-asamap.jpg

銀座堂 ASAMAP (map-e1 CE)

銀座堂様から提供頂いたASAMAPはVyattaに実装されたMAP−Eです。今回はMacMiniに載せての登場でした。map用のインターフェイスにルールを記述してそこにルーティングを向ける実装になっているようです。

config ASAMAP コンフィグ

…
interfaces {
    …
    ethernet eth1 {
        address 192.168.11.1/24
        address 2400:8700:31:600::1/64
        …
        ipv6 {
            …
        }
        …
    }
    …
    map map0 {
        br-address 2400:8700:31:610::1/64
        default-forwarding-mode encapsulation
        ipv6-fragment-size 1500
        rôle ce
        rule 1 {
            ea-length 8
            ipv4-prefix 157.112.198.104/32
            ipv6-prefix 2400:8700:31:600::/56
        }
        tunnel-source eth1
    }
}
protocols {
    static {
        interface-route 0.0.0.0/0 {
            next-hop-interface map0 {
            }
        }
        …
    }
}

YAMAHA RTX1200(CE)

img/janog31_map-e_yamaha-rtx1200.jpg

YAMAHA RTX1200 (map-e1 CE)

YAMAHA様からは名ルータRTX1200を提供して頂きました。コンフィグは非常に簡単に見えます。トンネルの方式としてMAPを設定し、引数でパラメータをすべて設定できる実装のようです。

config RTX1200 コンフィグ

ip route default gateway tunnel 1
…
tunnel select 1
 tunnel encapsulation ipip
 tunnel endpoint address 2400:8700:31:600:9d:70c6:6800:0 2400:8700:31:610::1
 tunnel map-e 157.112.198.104/32 2400:8700:31:600::/56 8 4
 ip tunnel mtu 1460
 ip tunnel tcp mss limit 1360
 ip tunnel nat descriptor 1000
 tunnel enable 1
…
nat descriptor address outer 1000 map-e
…

IIJ SEIL/X1 (CE)

img/janog31_map-e_iij-seilx1.jpg

IIJ SEIL/X1 (map-e1 CE)

config SEIL/X1(MAP-E) コンフィグ

IIJ様から提供頂いたSEIL/X1は小型のアクセスルータです。MAP-Eのコンフィグは4rdの名残になっています。BRかCEか動作モードを決めて、BR/CEのアドレスを決めて、MAPのルールを設定します。MAP-E用のインターフェイスにルーティングを向けるとMAP-Eとして動作する実装になっているようです。なおJANOG31 で利用したものは MAPの評価のための特別版ファームウェアであり正式リリース版ではありません。

interface frd0 mtu 1460
interface frd0 tcp-mss 1420
route add default frd0
…
nat napt add private 192.168.11.0-192.168.11.255 interface frd0
…
frd mode ce
frd ce-address 2400:8700:31:600::1
frd br-address 2400:8700:31:610::1
frd rule add Rule1 external-ipv4-prefix 157.112.198.104/32 internal-ipv6-prefix 2400:8700:31:600::/56 index-length 8 psid-offset 4

■DS-Lite 実験ネットワーク

DS-Liteの実験ネットワークを構築するにあたり、3社の協力を賜りました。プロバイダ側の機器のAFTRにはA10ネットワークス様からAX2500を、カスタマ側の機器のB4には、本会議初日はNECアクセステクニカ様のRG-A54i、二日目はIIJ様のSEIL/X1を提供していただき、それぞれ動作することを確認しました。各ベンダー様から頂いた、設定に関するこぼれ話や、実際機器に設定したコンフィグを紹介いたします。

NECアクセステクニカ RG-A54i (B4)

img/janog31_ds-lite-464xlat_necat.jpg

NECアクセステクニカ RG-A54i(DS-Lite B4) (左側)

設定を行う上でのノウハウ
AFTRアドレスを手動設定するだけでしたのでノウハウは特にありませんでした。本来、ユーザはこのような設定を意識しないことが望ましいので、本来あるべき姿だと思います。
気を付けた点
使用した装置はコンシューマ向けでしたので、通常 10台程度の接続を目安としていますが(設定上は最大32台まで接続可)、今回は JANOG 参加者向けということで、DHCPv4 での IPアドレス付与を例外的に50 に変更しました。でもこれでもIPアドレスリースが追い付かないケースがあったようです。100に設定しておけばよかったかもしれません。また、前述の通り、本来の使用環境とは大きく異なった為、装置負荷を軽減する為にDNS Proxyを使用しない(直接外部DNSを参照させる)、DHCPv6サーバを稼働しないなどの対処を行い、DS-LiteでのPacket 転送に専念させました。
感じたこと
より現実のエンドユーザの環境に近い環境を体感していただくためにDHCPv6 OptionによるAFTR FQDN情報の取得などを含めた動作検証も行った方がよりよかったと思います。しかし、そうすると、参加可能ベンダ数がぐっと減ってしまう懸念もあります。また、Staffの皆さまや参加者の皆さまに設定画面を見ていただけるようにWeb-GUIの公開をすればよかったと思っています。

IIJ SEIL/X1 (B4)

img/janog31_map-e_iij-seilx1.jpg

IIJ SEIL/X1(DS-Lite B4)

config SEIL/X1(DS-Lite) コンフィグ

感じたこと
今回はじめて、DS-Lite B4の設定をしましたが、B4ではほとんど何もしなくて良いのだな、という印象を抱きました。

DS-Lite B4部分のコンフィグ

interface lan1 add 2400:8700:31:500::cafe/64
interface tunnel0 tunnel 2400:8700:31:500::cafe 2400:8700:31:500::1
interface tunnel0 mtu 1460
interface tunnel0 tcp-mss auto
route add default tunnel0
route6 add default 2400:8700:31:500::1

A10ネットワークス AX2500 (AFTR)

img/janog31_ds-lite_a10-ax2500.jpg

A10ネットワークス AX2500(DS-Lite AFTR)

感じたこと

DS-Lite, 464XLATではセンター側でStatefulのNAT44を行い、CPE側はStatelessで動作させます。CPE側をStatelessにするメリットとして、CPE側の機能実装の簡略化、処理負荷の軽減させる点があります。もしCPE側にStatefulのNAT44を行わせる実装にすると、例えば、ALG(FTP,TFTP,SIP,RTSP,PPTP,ESG)、EIM/EIF、Hairpinning、Port Overloading、session logging(警察対応ログ)などの機能対応が必要となり、セッション管理によるCPU負荷の増大、より多くのメモリリソースの確保、ソフトウェアの継続した機能開発など、CPE側のソフトウェア開発負担やハードウェアコスト増が懸念されます。

これらの理由から、今回A10ネットワークスでは、IPv4 over IPv6技術としてミドルクラスのBOX製品であるAX2500を利用したDS-Lite, 464XLATをご提供させていただきました。DS-Lite, 464XLAT以外にもDNS64/NAT64, 6RDにも対応し、同一筐体でこれら全ての機能を同時動作させることも可能です。また、今後もソフトウェアアップデートにより新たなIPv6移行技術を実装していく予定です。

気をつけた点

CPE側のfragment設定を確認した上で、AXでfragmentが必要な場合に以下動作になるよう設定しました。(細かな設定が可能となります。)

  • ds-lite(tunnel outer header含めたsizeでのfragment)
    • ipv6->ipv4(outbound): ipv4 fragment(v4 df-bit packetはtunnel先にicmpv4 fragment needed送信)
    • ipv4->ipv6(inbound): ipv6 fragment(v4 df-bit packetはicmpv4 fragment needed送信)
    • mss-clamp無効化(CPE側で有効のため)
  • xlat464- ipv6->ipv4(outbound): ipv4 fragment(icmpv6 packet too bigは送信しない)- ipv4->ipv6(inbound): ipv6 fragment(v4 df-bit packetはicmpv4 fragment needed送信)- CPE(clat)からのempty ipv6 fragmentation header packet対応- mss-clamp無効化(通信エラーは発生しなかったので今回は無効にしました)

また、ALGへの対応や、

  • nat64 alg (ftp/sip/rtsp)
  • ds-lite alg (ftp/sip/rtsp/pptp)

hairppining, EIF/EIM, session capacity(必要v4 nat pool数の確保), icmp v6→4変換対応(XLATのみ)を行いました。

DS-Lite AFTR部分のコンフィグ

config AX2500コンフィグ

class-list dslite (ds-liteのB4のIPv6アドレス)
2400:8700:31:400::/64 lsn-lid 1 (prefixとlsn-lid idとのマッピング)
2400:8700:31:500::/64 lsn-lid 1
!
class-list dslite_client-permit 192.168.0.0 /16
 (ds-liteで通信を許可するB4配下のPrivate IPv4アドレス)
!
interface ve 100
ip address 157.112.198.66 255.255.255.252
ipv6 address 2400:8700:31:333::2/64
ip nat outside
!
interface ve 104
ipv6 address 2400:8700:31:500::1/64
ipv6 nat inside
!
ip route 0.0.0.0 /0 157.122.198.254
!
ipv6 route 2400:8700:31:400::/64 2400:8700:31:500::cafe
ipv6 route 2400:8700:31:200::/64 2400:8700:31:300::cafe
!
ip nat lsn endpoint-independent-mapping enable (EIMの有効化)
ip nat lsn endpoint-independent-filtering enable (EIFの有効化)
ds-lite alg rtsp enable (ds-liteのALG有効化)
ds-lite alg tftp enable
ds-lite alg sip enable
!
ds-lite inside source class-list dslite
 (ds-liteのB4アドレスとしてclass-list dsliteのアドレスを適用)
ip nat pool dslite 157.112.198.81 157.112.198.82 netmask /28 lsn
 (ds-lite用IPv4アドレス)
!
lsn-lid 1
 (class-listで参照されるnat IPとのマッピング)
source-nat-pool dslite
ds-lite inside-src-permit-list dslite_client-permit

■464XLAT 実験ネットワーク

464XLATの実験ネットワークを構築するにあたり、2社の協力を賜りました。プロバイダ側の機器のPLATにはDS-Liteと同様のA10ネットワークス様からAX2500を提供して頂きました。カスタマ側の機器ののCLATには、本会議初日はNECアクセステクニカ様のCL-AT1000Pを提供して頂きました。

464XLAT は、クライアントサイドでIPv4宛の通信をIPv4/IPv6変換を行います。 IPv6宛の通信は変換を行わないため、クライアントサイドの機器ではIPv4/IPv6変換を行うプレフィックスを指定する必要があります。 IPv4ヘッダからIPv6ヘッダへ変換する際にフラグメントが必要であれば、フラグメント処理が必要です。フラグメント処理の為にMTUの設定等が必要になる場合もあります。

プロバイダサイドに到達するパケットは、通常のIPv6通信とNAT64を行わなければいけない通信が混じっています。そのため、NAT64を行う対象プレフィックスを指定する必要があります。また、NAT64を行うために設定が必要です。

NECアクセステクニカ CL-AT1000P (CLAT)

img/janog31_ds-lite-464xlat_necat.jpg

NECアクセステクニカ CL-AT1000P(464XLAT CLAT) (右側)

CL-AT1000Pは家庭用のルータであるため10クライアント程度の接続を想定しており、最大でも30〜50クライアントの処理能力しか持ちあわせていませんでした。JANOGでは数十人からのアクセスが見込まれたためDHCPで振られるアドレスの数を制限するなどの工夫を行いました。

A10ネットワークス AX2500 (PLAT)

img/janog31_ds-lite_a10-ax2500.jpg

A10ネットワークス AX2500(464XLAT PLAT)

DS-Liteと同じ筐体で464XLATを提供しました。

464XLAT PLAT部分のコンフィグ

config AX2500コンフィグ(DS-Liteと同じ)

class-list NAT64
 2400:8700:31:200::/64 lsn-lid 2 <-- NAT64側のソースプレフィックスを指定
 2400:8700:31:300::/64 lsn-lid 2 <-- 同上
!
interface ve 100
 ip address 157.112.198.66 255.255.255.252
 ipv6 address 2400:8700:31:333::2/64
 ip nat outside <-- NAT64を行ったパケットの出口を指定
!
interface ve 103
 ipv6 address 2400:8700:31:300::1/64
 ipv6 nat inside <-- NAT64対象のソースインタフェイスを指定
!
ip nat lsn endpoint-independent-mapping enable <-- EIMを有効化
ip nat lsn endpoint-independent-filtering enable <-- EIFを有効化
!
nat64 fragmentation df-bit-transparency enable <-- CLATでフラグメント処理をされたパケットに対応
nat64 alg rtsp enable <-- ALG有効化
#ALG設定が続く…
!
nat64 inside source class-list NAT64 <-- NAT64のアドレスとしてclass-listのNAT64のアドレスを適用
!
ip nat pool nat64 157.112.198.83 157.112.198.84 netmask /28 lsn <-- NAT64に利用するIPv4アドレスのプールの指定
!
nat64 prefix 2400:8700:31:380::/96 <-- 464XLATのNAT64対象アドレスを指定
!
lsn-lid 2
 source-nat-pool nat64 <-- class-listで参照されるnat IPとのマッピング
!

■HANA 実験ネットワーク

HANAの内容については ネットワークのページ で記載したので、ここでは研究ネットワークを会場ネットワークとして提供するに至って頑張った点を紹介したいと思います。

NICT様から提供頂いた新世代ネットワークのHANAは、当初、バックボーン区間でアドレスの自動割り振りを行うというだけの実験でした。オペレータの多いJANOG来場者にとって見て分かりやすく、そして楽しんでもらえるよう、障害迂回のデモンストレーションや発表を行うなど、打ち合わせの中で様々な提案をさせて頂き、また、それに応えて頂きました。

元々が広域ネットワークを対象にした技術であり、通常は大量のアドレス空間を消費するので、アドレスの制約が大きいJANOGの会場ネットワークで、いかに消費するアドレスを減らすかにチャレンジして頂きました。

更には会場の電源容量の都合から元々は複数台であった実験機材を、１つの物理サーバに仮想マシンとして収容することをお願いしました。こちらも見事に応えて頂きました。

お陰様で双方にとって非常にメリットの大きい実験ネットワークに仕上げることができたと感じています。運用者と研究者が協力して実験ネットワークを構築したという点でも非常に大きな役割を果たせたと思います。

今後、研究分野のネットワークを実験ネットワークとして提供するという提案があれば歓迎します。

■ソーシャルボタン

ソーシャルボタンを読み込み中か、 お使いのブラウザではソーシャルボタンをご利用いただけません。

(最終更新日: 2013.03.03)

JANOG31 Meeting
JANOG31はグリー株式会社のホストにより開催しました。
footer Sitemap Contact to JANOG