無線IP電話導入で再認識したDHCPの“癖”
いまでは枯れているはずのDHCP。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070424/269286/?ST=network&P=1
しかし、無線IP電話の導入で、そうではないことを再認識した。 DHCPサーバーを冗長化したら端末に割り当てるIPアドレスが枯渇したり、少しの間、無線LANの圏外状態になると圏内に戻ってもIPアドレスが変わり通話が切れてしまったりとまだまだ難しいことが残されていた。その癖は、DHCPサーバーや無線LAN端末によって、さまざまである。
無線IP電話を利用する場合、端末のIPアドレスの割り当て／管理にDHCP（Dynamic Host Configuration Protocol）サーバーを用いることが多い。DHCPは、IPアドレスなどのネットワーク設定情報をサーバーで一元管理し、運用管理を効率化するための技術である。サーバーが端末の要求によって、IPアドレスを割り当てる（リース）してくれるので、ネットワーク・セグメントを移動しても端末の設定を手動で変更しなくて済む。IPネットワークが標準になり、安定した技術、製品だと思われている。
ところが、無線IP電話を利用するうえで、これまで隠れてた問題が表面化した。無線IP電話「FOMA N900iL」をユーザー企業に導入したときに、IPアドレスが浪費され枯渇したり通話が切れたりするトラブルが発生した。調査を進めると、DHCPサーバーの構成や機種によっては異なる不具合が生じることがわかった。
DHCPサーバーの冗長化が必須要件
NTTドコモのFOMA/無線LANデュアル端末「N900iL」の導入を進めていたユーザー企業では、DHCPサーバーの冗長化を必須要件に挙げていた。通常、拠点ごとにDHCPサーバーを設置して個別に運用する。WANでの障害発生に備えてのことである。しかし、このユーザーの場合、DHCP サーバーでIPアドレスを配布する対象が「FOMA N900iL」のみであり、拠点ごとにDHCPサーバーを配置、管理したくないという。このため、データセンターにDHCPサーバーを冗長化して配置することにした。
そこで、冗長化の機能があり、比較的安価に構築できるRed Hat Linuxに白羽の矢が立った。このLinuxに標準搭載されているDHCPサーバーを冗長化して使用することにした（図1）。１台で運用し、障害などの問題が発生したら、もう１台のほうが代わりに処理を受け持つ。いわゆるアクティブ/スタンバイの構成である。
図1●LinuxのDHCPサーバー冗長化機能 図1●LinuxのDHCPサーバー冗長化機能
[画像のクリックで拡大表示]
冗長化試験時にアドレスが枯渇？
LinuxのDHCPサーバーを冗長化して導入することは初めてであった。このため運用前に、そのユーザーの拠点で試験することにした。実際に N900iLを100台準備し、DHCPサーバーを冗長化して試験を実施した。一通り試したところ、DHCPサーバーを冗長化させた状態で特に問題なく動作していた。
しかし、次の段階の試験で問題が発生した。１台のDHCPサーバーに故意に障害を発生させた状態で、端末を何度か再接続させると、数台が圏外のまま接続できなくなってしまった。端末の再接続とは、電源を入れ直したり、ニューロ・ボタン（中央のボタン）を長押したりすることで、無線LANに接続し直すことである。
端末の再接続をさらに繰り返すと、最終的にはすべての端末が圏外状態となり接続できなくなった。DHCPサーバーのログを見ると、端末からのIP アドレス割り当て要求に対して、サーバーは無応答になっていた。どういうわけか、DHCPサーバーからIPアドレスが払い出されなくなってしまったようだ。アクティブ、スタンバイのどちらか１台をダウンさせるとこの問題が発生する。
この現象は不思議なことに、冗長化の設定をした状態で、１台のDHCPサーバーをダウンさせた場合のみ発生する。調査のためWindowsのノートPCを無線LAN端末として使用してみたが、この現象は発生しない。パケットのやりとりを調べてみた結果、どうやらN900iLがIPアドレスを再取得する際に、「DHCP Release」パケットを送出することが関係しているようだ。
DHCP Releaseというのは、端末がそれまで使っていたIPアドレスが不要になったときにその旨をサーバーに伝えるメッセージである。本来ならばサーバーは、Releaseパケットを受け取れば、その端末が使っていたIPアドレスを再割り当てするはずである。しかし、そのアドレスを保持してしまうようだ（図2）。つまり、端末の再接続を繰り返すたびに、新しいIPアドレスが払い出されていき、最終的にIPアドレスが枯渇してしまっていることがわかった。
図2●DHCPサーバー冗長構成で1台がダウンすると･･･
図2●DHCPサーバー冗長構成で1台がダウンすると･･･
端末からのDHCP Release（IPアドレス解放）を受け取ると、そのIPアドレスが使用不可になっていった。
冗長化状態では、2台のサーバーで端末に割り当てたIPアドレスのテーブルの同期を取っている。ところが、１台がダウンして同期が取れなくなると、DHCP Releaseを受け取ると、そのアドレスを“寝かせる”ような動作をしているようである。これは、ダウンさせていたサーバーを復帰させて同期が取れるようになると、正常にアドレスを割り当てられるようになることから確認できた。
どうやらLinuxに標準装備されているDHCPサーバーの冗長化機能は、FOMA N900iLとの組み合わせでは使えそうにない。
しかし、いまさらDHCPサーバーの機種変更をするわけにもいかない。そこで、DHCPサーバー2台を独立して動作させるようにした。端末に割り当てるためのプール・アドレスを分割してそれぞれのDHCPサーバーに設定し、端末のIPアドレスの割り当て、管理を独立して実行する（図3）。この場合、端末からのアドレス要求があると２台のDHCPサーバーが応答し、先に受信したほうのIPアドレスが端末に割り振られることになる。
図3●DHCPサーバーの冗長化 図3●DHCPサーバーの冗長化
両方のDHCPサーバーが応答し、端末が早く 受け取ったIPアドレスを受け入れる。
[画像のクリックで拡大表示]
ただし、この運用方法には問題がある。端末の台数に対し、約2倍のプール・アドレス数が必要となってしまうことである。２台のDHCPサーバーを独立して動作させると、１台のDHCPサーバーがある端末にIPアドレスを割り当てても、その端末が再接続した際にもう１台のDHCPサーバーがIPアドレスを割り振る可能性がある。そうすると、リース（アドレス貸し出し）期間が終了するまで１台の端末に2つのIPアドレスが割り当てられた状態になる。
このユーザー企業では、幸運にもIPアドレス空間を、端末の台数に対し十分な数を確保できた。この2台のDHCPサーバーを独立して運用する方式で本稼働にこぎつけることができた。
こんどは通話断が発生
しばらくトラブルなく運用できていたものの、新規拠点を増設する際に新たな問題が発生した。非常にまれなケースではあるものの、通話しながらフロア内を移動し続けると、通話が切れてしまう端末が現れたのだ。接続する無線LANのアクセス・ポイントを切り替えるハンドオーバーがうまく動作しないという問題である。
初めは無線LAN機器とFOMA N900iLが原因で生じるハンドオーバー処理の不具合ではないかと考えた。ところが、何度かこの現象を根気強く再現させると、何らかの原因でハンドオーバーに失敗し、端末が一度圏外になった場合にこの現象が発生していることがわかった。
FOMA N900iLの場合、通常ハンドオーバーでは取得済みのIPアドレスを使い続けるが、一度圏外状態に移行し圏内に戻った場合は、DHCPサーバーからIPアドレスを再取得する。どうやらこのIPアドレスの再取得で、別のIPアドレスが割り振られているようだ。
N900iLは通話中に圏外に移動しても、すぐには通話断とはしない。音声パケット（RTPパケット）を受信できない状態が20秒間続くと、通話断と判断する。したがって、20秒以内に圏内に戻れば通話はそのまま継続される。ただし、通話を継続するには、圏内に戻った際、同じIPアドレスが割り当てられる必要がある。
しかし、DHCPサーバーを2台独立稼働する構成（図3）では、同じIPアドレスが割り当てられるとは限らない。圏内に戻ったときにIPアドレスをDHCPサーバーに要求し、2台のDHCPサーバーのうち先に応答が返ってきたIPアドレスを取得するからだ。つまり、2分の1の確率で IPアドレスが変わることになる。これが通話断の原因であることがわかった（図4）。
図4●N900iL通話断の原因
図4●N900iL通話断の原因
いったん端末が圏外状態になると、IPアドレスの再割り当てを受ける。その際、以前とは別のDHCPサーバーからアドレスを受け取ると通話断となる。
この問題が新規拠点の増設時に判明したのは、これまでの拠点よりフロアが格段に広く、ハンドオーバーが頻繁に発生する環境であったためと思われる。
独自にDHCPサーバー冗長化機能を作りこむ
通話断の原因はわかったものの、解決策はなかなか見つからない。発生頻度は低いものの、通話断となる場合があることがわかった以上、現状のままでは運用できない。とりあえず、暫定対策として、2台のDHCPサーバーのうち、1台のみを起動させ、問題が発生した場合は手動で切り替えることにした。
当時、OKIでは数種類のDHCPサーバーとN900iLの組み合わせで検証をしていた。しかし、冗長化機能があり、なおかつN900iLのIPアドレス再取得時に、割り当てるIPアドレスが変わらないDHCPサーバーは見つからなかった。
もはやLinuxのDHCPサーバー冗長化の動作部分を、N900iLに合わせて独自に作りこむしかない。すでに導入済みDHCPサーバーを入れ替えること自体も困難であること、ほかのユーザー案件でもDHCPサーバーの冗長化が要件として挙がっていたことがこの判断を後押しした。
図5●DHCP冗長化機能を独自に作りこみ
図5●DHCP冗長化機能を独自に作りこみ
そこで、社内のLinux有識者の力を借りて独自開発に始めた。仕様を検討した結果、図5に示すようなDHCPサーバー冗長化の動作を、シェル・スクリプトを用いて実現することにした。Linuxでは、シェル・スクリプトと呼ばれるスクリプト言語が使える。コマンドの実行や条件分岐などをテキストで記述することで、複雑な処理を自動化できる。早速このシェル・スクリプトを社内で作成し、動作確認を実施した。その後、このユーザー環境のDHCPサーバーへ、このシェル・スクリプトを導入し、N900iLの動作環境で、無事DHCPサーバーの冗長化を実現することができた。
それにしても、DHCPの冗長化でこれだけ苦労することになるとは夢にも思わなかった。無線IP電話導入の難しさをあらためて実感させられることになった。現在OKIでは、「FOMA N900iL」導入にあたり、DHCPサーバーの冗長化が要件となる場合、この独自機能を組み込んだLinuxサーバーで対応している。
DHCPサーバーや無線IP電話端末の種類によって動作が異なる
実は、こういった問題はWindows Serverに標準装備されているDHCPサーバーを用いた場合にも発生することがわかっている。N900iLで通話中に一度圏外になったあとに圏内に戻るとIPアドレスが変わってしまうという問題である。
N900iLはIPアドレスを再取得する際に、DHCP Releaseを送出する。DHCP Releaseを受け取ったDHCPサーバーは、そのアドレスの履歴をクリアする。Windows Serverの場合、空いているIPアドレスの若番から、端末にIPアドレスを割り当てるため、別のIPアドレスが割り当てられる可能性が高い（図6）。一方、Linuxに標準搭載されているDHCPサーバーは、DHCP Releaseを受け取っても、以前と同じIPアドレスを割り当てる。IPアドレスは変わらないため通話が継続できる。
図6●WindowsとLinuxのDHCPサーバーの動作 図6●WindowsとLinuxのDHCPサーバーの動作
[画像のクリックで拡大表示]
また、あるアプライアンス型のDHCPサーバーでは、単独で動作している場合は常時同じIPアドレスを在り当てる。しかし、冗長化機能を使用した途端、別のIPアドレスを割り当てるような機器もあった。
無線IP電話端末の種類によっても動作が異なる。たとえば、ハンドオーバー時に、DHCPサーバーからIPアドレスを再取得する端末もあれば、実施しない端末もある。
また、ハンドオーバー時に、デフォルト・ゲートウエイにARP（Address Resolution Protocol）要求を出し、応答がない場合のみ、ネットワークが変わったと判断し、DHCPのアドレス要求を出す端末もある。無線IP電話の場合、通話中のIPアドレス変更はそのまま通話断につながってしまう。
無線IP電話端末の導入では、その機器の仕様を十分に把握し、ネットワーク設計やDHCPサーバーの機種選定に、十分注意を払う必要がありそうだ。
井上 伸也
2000年、沖電気工業へ入社。交換機のハード設計部門へ配属された後、IPネットワークの普及に伴い SE部門へ異動。現在は、主にモバイル・セントレックス案件の提案、構築業務を担当。N900iLリリース当初から、モバイル・セントレックス案件に携わり、無線LANの現地調査やトラブル対応など、様々な現地作業を経験する。業務のかたわら無線LANならではの付加価値を持った新規ソリューションを発掘できないか日々模索中。
[2007/05/08]
