大阪大学ネットワークの再構築：
ATMからギガビットイーサネットへ
野川 裕記
大阪大学サイバーメディアセンター
応用情報システム研究部門
nogawa@cmc.
概要
大阪大学では、キャンパスネットワークを、ATM中心のネットワークからギガビットイーサネット中心のネットワークへ再構築を行った。本稿では、キャンパスネットワーク再構築にあたっての背景、設計、構築および運用について述べる。１．はじめに
本稿は4 節からなり、第2節では、大阪大学キャンパスネットワークの歴史と問題点について述べた後に、次世代キャンパスネットワークが備えるべき条件について考察する。第3節では、大阪大学キャンパスネットワーク第4機整備の設計について述べる。第4節では、大阪大学キャンパスネットワーク第4期整備の構築および運用について述べ、第5節で、まとめを行う。２．背景
２．１ 大阪大学キャンパスネットワークの歴史
大阪大学のキャンパスネットワークは、大阪大学総合情報通信システム（Osaka Daigaku Information Network System）と呼ばれており、英語の頭文字をとってODINSと略されている。ODINSは整備年代の別に4期に分類されており、その整備年代と特徴を表1に示す。ODINS1は1993年に構築され、幹線はATM、支線はFDDIで構築された。ODINS2は1996年、幹線のATMを増速し、支線までATM化したものである。ODINS3は、1998年に構築したシステムであり、ODINS2の上で動作するマルチメディア会議システムである。そして、2001年に、ATM中心のネットワークをギガビットイーサネット中心のネットワークに再構築したのがODINS4である。
２．２ ODINS2の問題
ODINS2は、1996年に構築してから2001年にODINS4が構築されるまで、さまざまな問題を抱えていた。その問題は、政治的問題と技術的問題の2つに分類することができる。2.2.1 ODINS2 の政治的問題
ODINS2の政治的問題を述べる前に、ODINSを運用する主体について説明する必要がある。ODINSを全学的に運用する主体は、ODINS3期まではODINS整備本部と呼ばれ、ODINS4からはODINS運用本部と呼ばれている。すなわち、ODINS整備本部あるいは運用本部が、ODINSの全学的運用において責任をもつことになっている。
ODINS2の政治的問題としては、2点あった。第1点は、ODINS2構築時において各部局のネットワークの設計・構築・運用は、各部局でのボランティアに大きく依存しており、ODINS整備本部全体としてもボランティアの集合体の域を出なかったことである。このことにより、ODINS2においては、ネットワーク管理者は大学内における計算機管理の正式な権限を持つことができなかった。一方、インターネットが急速に普及した結果、学外からの不正アクセスが急増してきた。そのため、ODINSにファイアウオールを設置し、学外の不正アクセスからODINSを守る必要性が急激に高まっていた。一方、ファイアウオールを設置し運用するためには、正式な権限が必要である。正式権限に基づいたファイアウオールの設置・運用がこのように必要であるにもかかわらず、ネットワーク管理者が正式権限を持っておらず、ファイアウオールを設置し運用することができない、という状況がODINS2では続いていた。
第2点は、部局における接続形態・対外サービスはさまざまであり、しかも各部局のボランティアに運営が任されていたため、ODINS整備本部は全学的な接続形態・対外サービスについての把握ができなかったことである。これは、ファイアウオールを設置するにあたり、設定に必要な情報をODINS整備本部が把握していないことを意味しており、ファイアウオール導入に際し、大きな障害となっていた。
| 整備年 | 特徴 | |
| ODINS1 ODINS2 ODINS3 ODINS4 |
1993年 1996年 1998年 2001年 |
ATM（幹線）+FDDI ATM（幹線+支線） ATM上のマルチメディア講義システム ギガビットイーサネット |
2.2.2 ODINS2の技術的問題
ODINS2の技術的問題としては、2点ある:ルータが古く能力不足であること、とルータが分散していることである。第1は、ルータが古く能力不足であることであり、具体的には、パケットフィルタリング能力が低いことである。これには2種類あり、1つはフィルタを設定したときのパケット処理能力が低いこと、もう１つは、フィルターの設定項目が少ないことである。フィルター設定項目については、送信アドレス、発信アドレスしか設定できず、ポート番号によるフィルターができないことが問題である。この問題のために、ある特定の通信（WWWトラヒックなど）を選択的に遮断することが不可能であった。
第2は、ルータが分散しているために、セキュリティを確保するためには多くのルータにフィルターを適用しなければならないことである。ルータの信頼性が低かったときには、ルータを分散させシステム全体を安定稼動させることには意味があった。しかしながら、ルータの信頼性が向上しセキュリティが問題となっている状況においては、ルータを分散させることは、フィルター適用の手間が増え、かえってセキュリティ上の問題となる。
２．３ 次世代キャンパスネットワークの条件
ここでは、次世代のキャンパスネットワークが備えなければならない条件について考察する。この条件は4点あり、セキュリティ、広帯域化、管理コストの削減、IPv6への対応 である。2.3.1 セキュリティ
最近、インターネット経由の不正アクセスは急激に増加しており、大学においても不正アクセスに対する対処が求められている。そのためには、インターネットとキャンパスネットワークの間にファイアウオールを設置して、キャンパスネットワークを不正アクセスから防御する必要がある。このとき、大阪大学の規模でアプリケーションレベルのファイアウオールを導入すると破綻するのは明らかである。その理由は3点あり、
- アプリケーションレベルのファイアウオールは、ギガビットクラスのトラヒックを処理できない。
- 設定に関する管理コストが非常に高い。特に、DNSサーバをファイアウオールの内部と外部で分離する場合（split-brain DNS）はそうである。
- Unixを基本としたシステムであるために、停止する場合はシャットダウンの手順を踏まなければならない。もしシャットダウンの手順を踏まずに機器を停止した場合、次回の立ち上げ時にファイルシステムの検査に長時間かかり、外部との通信を早期に回復することが困難になる。
また、NAT （Network Address Translation）は採用しないことに決定した。これは、管理コストを低減させるとともに、IPv6への移行を促進させるためである。以上のことから、ODINS4では、高速なルータを導入し、ルータでパケットフィルタリングを行うことにより、ファイアウオールとすることとした。
2.3.2 広帯域化
広帯域化を考える際には、2つの要因がある： IP上の会議システムとSuperSINETである。IP上の会議システムとして、WIDEプロジェクト1が開発したDVTS（Digital VideoTransport System）が用いられつつある。このDVTSは、IEEE1394フレーム、すなわちデジタルビデオをインターネット上で伝送するシステムであり、送信側でIEEE1394のフレームをIPパケットにカプセル化し、受信側でIPパケットからIEEE1394のフレームを再構成する。このとき片方向で最大40Mbpsの帯域を消費する。すなわち、双方向の会議を行うためには、エンドーエンド間で約100Mbpsの帯域が必要になる。そして、DVTSにおいて画質を確保するために、パケットロスの少ないルータあるいはスイッチを用いる必要がある。また、大学間・学部間の共同研究がますます盛んになっており、共同研究に参加している教室に閉じたVLANの要求が増加していることを考慮すると、スイッチを中心とするネットワークが望ましい。
一方、SuperSINETは、文部省が構築した実験用ネットワークであり、最大10Gbpsのバックボーンを持つ3。つまり、この10Gbpsのバックボーンからのトラヒックを処理できる能力のあるキャンパスネットワークを設計する必要がある。
2.3.3 管理コストの削減
管理コストを削減するためには、次の3点を考慮しなければならない：ATM-LANEの管理、ルータの管理、データリンクの統一である。
ODINS2で用いていたATM-LANEは管理コストが大きいものであった。その理由は、ATMは基本的にpointto-pointあるいはpoint-to-multipointの技術であり、この上でbroadcastをエミュレーションするためには複雑な機構が必要であったからである。
ODINS2では、35台のATMルータを設置したが、このように多数のルータを配置するとフィルターの設定が煩雑になり、結果として管理コストが上昇することがわかった。
ODINS2では、データリンク層としてFDDI、ATM、イーサネットの3種類が混在しており、煩雑であった。特にUTP上のATMを使用している個所があり、UTP上のイーサネットと区別がつき難く、運用上の問題となっていた。そのため、ODINS4ではデータリンクを統一することとした。
2.3.4 IPv6 への移行
IPv4アドレスの枯渇や経路表爆発の問題から、IPv6の早急な利用が望まれている。そのため、ODINS4はIPv4で設計するにしても、近いうちにIPv6への移行することを想定した設計を行う必要がある。
IPv6への移行を考慮すると、ルータの数を少なくすることが必要である。なぜならば、ODINSをIPv6対応にするためにはすべてのルータをIPv6対応にする必要があるため、ルータが多いとIPv6移行にかかる各種の手間やコストが増大するからである。
３．ODINS4の設計
ODINS4設計の原則は以下の2点である。- ルータを集中させる
- ルータの数は最低限にする
- ルータの周りにスイッチを配置する。
- 設計が容易になり、2.3.3で述べた管理コストを低下させることができる。
- ルータで集中的にパケットフィルタリングを行うことで、2.3.1で述べたセキュリティ問題に対処することができる
- 2.3.4で述べたように、IPv6 への移行が容易である。
４．ODINS4の構築および運用
第3節における設計を行い、入札を行ったところ、表2の構成となった。図1に、ODINS4におけるルータおよびスイッチの配置を示す。
ルータの数については、ODINS４では4台のルータしか導入していない。しかも、これらはVRRPによって冗長化しているので実際には同時に2台しか稼動していないことになる。すなわち、ODINS2での35台のルータに比べ、大幅に減少している。これが可能になったのは、ルー
タの機能が向上した（VLAN routingなど）とともに信頼性が向上したためである。ただし、各部局のコアスイッチはL3スイッチとしており、ネットワーク不調時にはルーティングを行える設計にしてある。
ODINS2からODINS4への移行を円滑に進めるものと
して、ATM-LANEのVLANとギガビットイーサネットのVLANの間でプリッジングを行っている。このために、IPアドレスを変更することなしにODINS2からODINS4への移行を行うことができ、2002年7月23日現在、ほとんどの部局がODINS4への移行を終了している。
表2: ODINS4 で導入したルータとスイッチ
| ベンダー名 | 型名 | 台数 | |
| ルータ | Juniper Networks | M20 | 4台 |
| スイッチ スイッチ スイッチ |
Extreme Networks Extreme Networks Extreme Networks |
BlackDiamond Alpine summit |
11台 79台 631台 |
４.１ セキュリティインシデント
なお、ODINS4を構築し、運用する過程で、セキュリティについての新たな問題が判明した。それは、広帯域ネットワークであるがゆえに生じた問題であり、具体的には２つの事例からなる：１つは、ウイルスに感染した計算機による大量のUDPであり、もう1つは、大量のSNMPパケットによるルーティング不安定である。4.1.1 大量のUDPの事例
2002年4月13日にODINSは、SINET管理者からある警告を受けた。その警告の内容は、大阪大学から米国ISPのある特定のIPアドレスに対して大量の（150Mbps以上）UDPパケットが送られており、SINET側でフィルタリングを実施した、ということである。大阪大学が調査したところ、その原因は、ある計算機がウイルスに感染しており、そのために大量のUDPパケットを送信していたからであった。この計算機については、即座にネットワークから分離し、ウイルス駆除を行った。
この事例から、ODINS4およびSuperSINETのような広帯域ネットワークにおいては、小さなセキュリティインシデント（この場合は、ウイルス感染）でも外部ネットワークに多大な迷惑を及ぼすことを経験した150Mbps以上のトラヒックを処理できるサイトは限られており、サイトによっては大阪大学からのDoS攻撃と見なされてもおかしくはない事例であった。この事例は、セキュリティ対策の重要性・緊急性について考えさせられた事例であるとともに、緊急時における行動を明記しておく必要性も明らかにした。
4.1.2 大量のSNMPパケットによるルーティング不安定
ODINS4の運用中にルーティングが不安定になることがあり、調査すると大量（数１０Mbps以上）のSNMPパケットがルータに対して送信されているのが判明した。SNMPアクセスリストを設定したが、ルーティングの不安定は続き、パケットフィルターでSNMPパケットを遮断することで安定になった。
この事例から、広帯域ネットワークでは、ルータも１つの計算機と見なしてネットワーク経由での攻撃から如何に防御するのかを考慮しなければいけないことを学習した。今回の事例では、SNMPアクセスリストを設定してもルータCPU負荷は減少せず、ルーティングの不安定は続いたままであった。そこで、パケットフィルターでSNMPパケットを遮断することによりルーティングを安定させた。SNMPパケットはネットワークインターフェイスからルータCPUに到達しそこで処理されるのであるが、効率的にSNMPパケットを遮断するためには、パケットがルータCPUに到達する手前でパケットフィルターが有効になっている必要がある。すなわち、このような設定を行うことのできるアーキテクチュアをルータが持っていなければならない。よって、広帯域ネットワークを安定に運用するためには、ルータの機種選定において、ルータCPUの手前でパケットフィルタリングを行うことのできるアーキテクチュアかどうかを確認する必要があることがわかる。