キャンパスネットワークにおける上流ネットワークの冗長化
葭葉 純子 1), 中村 直毅 1), 長田 典久 1) , 秋山 英明 2) ,小松 雄一 2) , 大泉 洋貴 2) , 阿部 陽介 2) , 中山 雅晴 1)
1) 東北大学医学系研究科 情報基盤室
2) 東日本電信電話株式会社
yoshiba@med.tohoku.ac.jp

Upstream Redundancy in Campus Networks Using Server Functions
Junko Yoshiba 1), Naoki Nakamura 1), Norihisa Osada 1), Hideaki Akiyama 2),
Yuichi Komatsu 2), Hiroki Oizumi 2), Yosuke Abe 2), Masaharu Nakayama 1)
1) Tohoku University Graduate School of Medicine Information Inf
2) NIPPON TELEGRAPH AND TELEPHONE EAST CORPORATION

概要COVID-19 の蔓延に伴ってオンライン授業や Web 会議が頻繁に使われるようになり、教育・研究環境で安定したインターネット通信環境を提供することがますます重要なものとなっている。そこで、東北大学医学系研究科は、キャンパスネットワークの上位で障害が発生した際にも、オンライン授業や Web 会議に支障を与えないように、上位ネットワークの冗長化を行った。現状のキャンパスネットワークでは、上位の学内ネットワーク、SINETを経由してインターネットに接続しているが、上位の学内ネットワークや SINET で障害が発生した場合にはインターネット通信を継続できないため、バックアップ回線として学内ネットワークや SINET とは独立している商用プロバイダ回線を用意し、ネットワークを冗長化することにした。冗長化には一般的にルーティングプロトコル BGP[1] [2]などを用いた仕組みが必要であるが、技術的、運用的な敷居が非常に高い。そこで、ネットワーク機器やサーバを効果的に組み合わせて簡単な仕組みで実現することにした。この仕組みによって障害時には、バックアップ回線を利用してインターネット向けの通信を維持し、学外からキャンパスネットワークの DMZ で稼働しているメールやウェブサービスの通信も維持できるようになった。本稿ではネットワークの冗長化の概要および評価について報告する。

1

クで障害が発生した際にもインターネット通信がはじめに継続できるようにするため、SINET と独立してい昨年度以降、COVID-19 対応のためにオンライる商用プロバイダ回線を用いてネットワークを冗ン授業や Web 会議が一斉に行われるようになり、長化することにした。障害時には、このバックア安定したインターネット環境がますます重要なもップ回線を利用してインターネット向けの通信をのとなっている。医学系研究科のキャンパスネッ維持できるようにするとともに、キャンパスネッ

トワークは、大学本部で管轄しているネットワー

トワークの DMZ で稼働しているメールやウェブク機器を経由して、SINET に接続している。そのサービスの通信も合わせて維持できるようにした。

ため、大学本部管轄のネットワーク機器、回線、本稿では、これらのネットワークの冗長化の概要

SINET 等に障害が発生するとインターネット向けおよび評価について報告する。の通信が不通になってしまう懸念がある。実際、昨年度にはキャンパス間の通信で利用する光ファイバーケーブルが小動物に切断され長時間通信が停止したことで、授業や会議を突然中断せざる得ない状況が発生した。そこで、上位のネットワー

242

2 上位ネットワークの障害を考慮したネットワークの冗長化
2.1 ネットワークの冗長化の概要
学内の端末は、平常時は帯域が広く高速な上位の学内ネットワーク（以降、上位学内回線と記載念されるため、手動で切り替えることにした。

する）をメイン回線として利用しインターネットインターネット向けの通信を行う。上位学内回線では、SINET が使われており、SINET に依存しない商用プロバイデフォル
トルート
優先2

ダをバックアップ回線として準備することで、学内ネットワークに障害が発生した際にもインターネット通信が維持できるようにする。以下にネッ

バックアップ回線（商用回線）

上位学内回線
Link0
デフォルトルート
優先１

Link1

バックアップ回線用FW

外部接続スイッチ

トワークの冗長化の概要について説明する。
2.2 キャンパス内の端末からインターネット向け
通信

星陵キャンパス

図 2. 障害発生時の回線切り替え

通常、キャンパス内の端末は、Link0 を経由して上位学内回線から Web 会議やオンライン授業、ウェブ閲覧、GSuite 等のサービスを利用している

2.3 メール・ウェブメールサービス公開のための学（図 1）。上位学内回線で障害が発生した際には、外からキャンパス向けの通信Link1 を経由してバックアップ回線から通信するメール・ウェブサービスを提供するため、キャように制御する。内部からインターネット向けのンパス内の DMZ にメールおよびウェブサーバを通信は、NAPT（Network Address Port Translation）配置している。これらのサーバ宛の通信は、平常によって通信が維持される。

時には上位学内回線から Link0 を経由して通信し、平常時
インターネット
上位学内回線

バックアップ回線（商用回線）ではなく、Link2 を用いるのは、メール・ウェブサ

Link0

Link0
バックアップ回線用FW

Smtp
サーバ

Mail
サーバ

ービスを平常時もバックアップ回線を利用できる

Link1

Link1
外部接続スイッチ

キャンパスFWて通信されるようにする（図 3）。ここで、Link1

インターネット

バックアップ回線（商用回線）

上位学内回線

障害時にはバックアップ回線から Link2 を経由し障害時

Webサーバ

診療用-FW 研究・教育用-FW

星陵キャンパス

バックアップ回線用FW外部接続スイッチように設定しておくためである。バックアップ回線向けの Link1 は平常時には無効化され、この経キャンパス
FW
Smtp
サーバ

Mailサーバ

Web
サーバ

路を使って通信できないため、外部接続スイッチとバックアップ回線用 Firewall（以降、バックアッ診療用-FW 研究・教育用-FW

プ回線用 FW と記載する）間に Link2 を追加し、星陵キャンパス

図 1. キャンパス内の端末から外部へのインター平常時においてバックアップ回線経由でのメール・ウェブサービスが通信できるようにする。

ネットアクセス

バックアップ回線では、固定のグローバル IP ア
上位学内回線とバックアップ回線を簡単に切りドレスを１つ取得し、外部からこの IP アドレス宛替えるため、外部接続スイッチで、上位学内回線に通信が届くと Port Forwarding により、DMZ に設およびバックアップ回線向けのデフォルトルート置されている指定されたサーバに通信を転送し、を 2 つ設定する。バックアップ回線向けのデフォメールやウェブサービスを提供する。

ルトルートの優先度を上位学内回線向けよりも高平常時く設定し、平常時には、バックアップ回線向けの障害時

インターネット

Link1 を無効化し、Link0 を経由して帯域の広い上化し、Link1 を経由してバックアップ回線から通信が行われるように制御する（図 2）

上位学内回線

Link1
外部接続スイッチ

バックアップ回線（商用回線）

Link0

Link0

位学内回線を経由して通信する。上位学内回線において障害が発生した際には、Link1 を手動で有効

インターネット

バックアップ回線（商用回線）

上位学内回線

Link2

バックアップ回線
用FW

キャンパス
FW

DMZ
Smtp
サーバ

Mail
サーバ

障害時

Link1

Webサーバ

外部接続スイッチ

キャンパス
FW

Link2

バックアップ回線
用FW

DMZ
Smtp
サーバ

Mail
サーバ

Webサーバ

なお、インターネット上の特定のサーバを ping
監視し、応答がない場合にデフォルトルートを自診療用-FW 研究・教育用-FW

星陵キャンパス

診療用-FW 研究・教育用-FW

星陵キャンパス

動切り替えることも技術的には可能であるが、意図しない回線切り替えが頻繁に発生することが懸243

図 3. 学外からのメール・ウェブサービス利用

するため、メール・ウェブサービスを提供するサ3 実装
2 章で述べた仕組みを実環境に適用した。なお、外部接続スイッチは、Cisco 社製 Catalyst 3850、バックアップ回線用 FW は、Fortinet 社製 FortiGate
200E、キャンパスネットワークの Firewall（以降、キ ャ ン パ ス FW と 記 載 す る ） は 、 Cisco 社 製
Firepower 4110 を利用しており、各サーバの OS は、CentOS 7 もしくは CentOS8 を利用している。

ーバに対して、既存の IP アドレスと同じネットワークアドレスの IP アドレスを新規で割り当てた（図 6 の①、②、③）。外部接続スイッチでは、新規で割り当てた IP アドレスから発信される通信がバックアップ回線用 FW の常時接続用インタフェース(192.168.z.10)宛にルーティングするようにソースルーティングの設定をした（図 7）。また、インターネットからバックアップ回線用 FW の WAN

3.1 接続構成およびルーティング制御
既存の外部スイッチおよびバックアップ回線用 FW に対してそれぞれ、Link1 の障害時用インタフェースおよび Link2 の常時接続用インタフェー
スを新規作成し、図 4 に示すように接続し、外部接続スイッチ側の障害時用インタフェースをshutdown とした。に 設 定 さ れ て い る グ ロ ー バ ル IP ア ド レ ス（160.x.y.100）に着信する通信が、キャンパス FWの DMZ 上に配置されているサーバに転送されるようにするため、バックアップ回線用 FW において表 1 示す Port Forwarding の設定を行った。

インターネット

上位学内回線
192.168.x.1

Link0
Link1

バックアップ回線（商用回線）

外部接続スイッチ

Link0
障害時用インタフェース（192.168.y.10）

障害時用インタフェース⇒ shutdown

インターネット

上位学内回線

192.168.x.1

キャンパスFW

Link2
常時接続用インタフェース

星陵キャンパス

バックアップ回線用FW
常時接続用インタフェース（192.168.ｚ.10）

障害時用インタフェース（192.168.y.10）
160.x.y.100（ＷＡＮ側）

バックアップ回線用FW

Link2
常時接続用インタフェース（192.168.ｚ.10）
DMZ

Smtp
サーバ

Mail
サーバ

Web
サーバ

130.34.x.10

130.34.x.11

130.34.x.12

Link1
外部接続
スイッチ

バックアップ回線（商用回線）

130.34.x.20①

星陵キャンパス130.34.x.21

②

既存設定

130.34.x.22③

バックアップ回線からの接続用に新規に割り当て

図 6. サーバの IP アドレス冗長化設定
図 4. バックアップ回線用 FW への接続
外部接続スイッチでは、図 5 の赤枠内に示すよ
うに、バックアップ回線向けのデフォルトルートの優先順位が上位学内回線向けのデフォルトルートの優先順位よりも高くなるようにするため、上位学内回線向けは 40 を指定し、バックアップ回線向けを未指定(0)とした。

図 7. 外部接続スイッチにおけるソースルーティ

バックアップ回線向（優先１）ング設定
表 1. バックアップ回線用 FW の Port Forwarding
設定
Port Forwarding設定
160.x.y.100(TCP/25) → 130.34.x.20(TCP/25)

上位学内回線向（優先２）①Smtpサーバ

160.x.y.100(TCP/587) → 130.34.x.20(TCP/587) ①Smtpサーバ
160.x.y.100(TCP/465) → 130.34.x.20(TCP/465) ①Smtpサーバ

図 5. 外部接続スイッチのデフォルトルート設定

160.x.y.100(TCP/110) → 130.34.x.21(TCP/110) ②Mailサーバ
160.x.y.100(TCP/143) → 130.34.x.21(TCP/143) ②Mailサーバ

3.2 メール・ウェブサーバのマルチホーミング設定

160.x.y.100(TCP/993) → 130.34.x.21(TCP/993) ②Mailサーバ
160.x.y.100(TCP/995) → 130.34.x.21(TCP/995) ②Mailサーバ
160.x.y.100(TCP/80) → 130.34.x.22(TCP/80)

インターネットからバックアップ回線を経由してメールおよびウェブサーバに接続できるように

244③Webサーバ

160.x.y.100(TCP/443) → 130.34.x.22(TCP/443) ③Webサーバ
160.x.y.100(TCP/53) → 130.34.x.2(TCP/53)

DNSサーバ160.x.y.100(UDP/53) → 130.34.x.2(UDP/53)

DNSサーバ以上によって、バックアップ回線側からのメーとルーティング設定を行う。これによって、平常

ル・ウェブサービスへの通信が、DMZ に設置され時には、DNS2 は参照されず、メール、ウェブサているメール・ウェブサーバへ転送され、サーバービスへのアクセスは、DNS1 で設定した名前解からの戻りの通信もバックアップ回線を経由して決が行われ、上位学内回線経由で通信が行われる送信元のクライアントに応答する構成とした（図（図 11）。反対に障害時は、DNS2 のみが参照され、8）。

DNS2 で設定した名前解決が行われ、バックアップ回線経由でメール、ウェブサービスへアクセス

インターネット

上位学内回線

バックアップ回線（商用回線）

Link0
Link1
外部接続スイッチする（図 12）。なお、MX レコードについては、学

160.x.y.100（ＷＡＮ側）
バックアップ回線用FW

Link2

内回線およびバックアップ回線経由からメールを受信できるように設定した（図 9 緑枠）。

常時接続用インタフェース（192.168.ｚ.10）

キャンパス
FW

DMZ

Smtp
サーバ

Mail
サーバ

Web
サーバ

130.34.x.10

130.34.x.11

130.34.x.12

130.34.x.20

130.34.x.21

130.34.x.22①②

平常時(DNS1)

障害時（DNS2）

既存設定③

星陵キャンパス

バックアップ回線からの接続用に新規に割り当て

図 8. バックアップ回線経由のメール・ウェブの通信
なお、クライアントがアクセスするサーバの指図 9. DNS 設定

定は、以降で記載する DNS を用いて制御する。
名前

送信先

宛先

サービス

アクション

★outsideから障害時用インタフェース(Link1)へ

3.3 DNS 設定

dnsalldns2-server

利用者はメールやウェブサービスを利用するた

DNS

許可

外部からLink1への通信はDNSを許可

め、ホスト名を指定して接続する。ホスト名が上★outsideから常時接続用インタフェース(Link2)へ

位学内回線用の IP アドレスで名前解決される場合

IMAP

は、上位学内回線経由の通信となり、バックアッmailall

mail-server

プ回線用 FW の WAN のグローバル IP アドレス

IMAPS

許可

POP3
POP3S（160.x.y.100）で名前解決される場合は、バック

SMTPS
smtpアップ回線経由の通信となる。平常時と障害時にall

smtp-server

SMTP

許可

Submission

DNS の登録情報を修正することなくサービスを継HTTP

weballweb-server

DNS1 と障害時用のゾーン情報を保持する DNS2

all_denyall

allの 2 つ用意し、平常時には DNS1 のゾーン情報の外部からLink2への通信はメールとウェブを許可、その他拒否続するため、平常時用のゾーン情報を保持する

み参照でき、障害時には DNS2 のゾーン情報のみ
平常時と障害時の DNS 設定を図 9 に示す。障ALL拒否

図 10. バックアップ回線用 FW のポリシー設定参照できるように設定した。
害時用 DNS（DNS2）設定では、メール・ウェブ

許可

HTTPS

①DNS参照上位学内回線②メール・ウェブ利用

インターネット①

サーバのホスト名は、バックップ回線のグローバ
ル IP アドレス（160.x.y.100）を設定する（図 9 赤外部接続スイッチ枠）。平常時用（DNS1）と障害時用（DNS2）ともに、NS レコードは DNS1 および DNS2 の両方を指定する（図 9 黄枠）。また、平常時に DNS2 のゾー

うにバックアップ回線用 FW でポリシー（図 10）

245

Link1

(160.x.y.100向）Link2

バックアップ回線用FW②（130.34.x.10,11,12向）
DNS2

①
DNS１

130.34.x.2 130.34.x.1

Smtp
サーバ

Mail
サーバ

Web
サーバ

①Link1のDNS
通信は平常時×130.34.x.10 130.34.x.11 130.34.x.12
130.34.x.20 130.34.x.21 130.34.x.22

ン情報を参照できなくするため、バックアップ回線側から DNS2 へは Link1 を経由して通信するよ

バックアップ回線（商用回線）

星陵キャンパス

図 11. 平常時の DNS 参照とサーバへのアクセス

用しているウェブ、メールサービス以外の各研究①DNS参照上位学内回線②メール・ウェブ利用

インターネット

バックアップ回線（商用回線）①

Link1

外部接続スイッチ

ウェブサーバでリバースプロキシを使い、研究室(160.x.y.100向）Link2②（130.34.x.20,21,22向）①
DNS2

室管理のサーバは、冗長化の対象外としていたが、DNS１

130.34.x.2 130.34.x.1

Smtp
サーバ

Mail
サーバ

バックアップ
回線用FW管理のサーバも対象にすることを検討している。

Web
サーバ

130.34.x.10 130.34.x.11 130.34.x.12
130.34.x.20 130.34.x.21 130.34.x.22①Port Forwarding設定（表１）でDNSは130.34.x.2へ

星陵キャンパス

図 12. 障害時の DNS 参照とサーバへのアクセス

4 評価と考察図 13. バックアップ回線切り替え時の利用帯域構築したバックアップ通信回線が正常に動作するか切り替え試験を休日の 9 月 11 日（土）に実施した。
・9/11 15:37

外部接続スイッチの link1 のインタフェースを有効化（no shutdown）

・9/11 15:52

外部接続スイッチの link1 のインタフェースを無効化（shutdown）

15:37 の切り替えでは、内部から外部向けの通信においては ping 落ちが生じることなく、バックアップ回線用 FW 側へ通信が切り替わり、ウェブサイトの閲覧を継続できることを確認した。外部向けに公開しているウェブサービスでは、20 秒程度で表示できるようになることが確認でき、メールサービスについても、バックアップ回線への切り替え後も学内・学外からともに送受信することが可能であった。
以上より、当初想定していた以下の 3 点が実現できていることが確認できた。
1.

キャンパス内からインターネット上のサーバにアクセス可能

2.

学外からキャンパス内の DMZ で運用しているメール・ウェブサービスを利用可能

3.

東日本大震災（2011 年 3 月）の際には、上位学内回線が不通になり、メール・ウェブ通信が一切できない状況が長時間続いた。今回構築した仕組みにより、これらの課題が解決することが見込まれる。一方、バックアップ回線への切り替えは、手動で行う必要があるため、職員自身が切り替え作業を行えるようにするため、回線を切り替えるための訓練を定期的に行い、災害や障害に備えたい。

5 おわりにオンライン授業や Web 会議が頻繁に使われるようになり、安定したインターネット通信環境を提供するため上位ネットワークの冗長化を検討した。一般に上位ネットワークを冗長化するには、ルーティングプロトコル BGP[1] [2]等を用いて実現することが一般的であるが、技術的、運用的な敷居が非常に高い。そこで、ネットワーク機器、サーバを効果的に組み合わせた簡単な仕組みによって、ネットワークを冗長化する仕組みを検討し、実際のネットワーク上で動作することを確認した。
現時点では、提供できる帯域は限られているため、障害発生時に簡単な操作で切り替え可能

アナウンス方法やサービスの提供範囲などの運用バックアップ回線へ切り替えた際に、バックアについて検討を進めていきたい。

ップ回線用 FW のステータス画面で利用帯域などを確認した（図 13）。バックアップ回線は、最大

参考文献

速度 1Gbps の IPoE を用いたプロバイダ回線であるが、利用帯域は最大 400Mbps 程度、内向きの利用帯域は、100Mbps 程度を推移し、帯域的な問題は発生しなかった。平日に利用した場合の通信状況の確認については、今後の課題である。また、今回のバックアップ通信回線の整備では、基幹で運246[1] 学術情報ネットワーク(SINET)BGP サービス:
https://www.sinet.ad.jp/connect_service/service/bgp．
[2] 伊藤智博 他、災害時に備えた分散キャンパスによる情報基盤の整備、学術情報処理研究 15
巻、1 号、p.5-11、2011 年．