JANOG44 Meeting

本記事は、JANOG44 Meetingで発表した内容を記事として書き起こし、加筆修正したものです。

DHCP開発経緯

あるキャリアでDHCPv6が必要となった。

• 当時、キャリア向けに使用できるDHCPv6サーバーがCNRしかなかった(らしい)。
• DHCPv6サーバー作ってよ！

　　　⇒作った！

• せっかく作ったから他キャリアにも売りたくなった。
• 「DHCPv4が欲しいんだけど」といわれる。

　　　⇒作った！

　（誤） 御社製品はDHCPv6に対応しているでしょうか？

　（正） 弊社製品はDHCPv4にも対応しています！

• 「DOCSISはTFTPも扱えないと」といわれる。

　　　⇒作った！

キャリアの要件

冗長

• 3台以上で冗長したい。
  • IPの払い出しが止まると全サービスが止まるといって過言でない。
  • 数が並んでるだけでも安心できる。

　　　　⇒何台構成でもOK！

• DRサイト、別局舎で冗長したい。
  • 東京が壊れても大阪では動いてほしい。
  • でもIPアドレスは有限。

　　　⇒別局舎でも同期可能 (遅延はあるけれど)

　　　⇒リアルタイムにホットスタンバイで同期するよりは、

　　　　バックグラウンドでコールドスタンバイの方が結局はおすすめ

サーバー集約

---

多段リレー

開発で困ったこと

ディスクI/O問題

• DHCPはリース情報を(ディスクなどに)永続的に保持することがプロトコルとして前提となっている
• OSSのDHCPサーバーはこの辺がボトルネックになって性能が出ないことがある
• Linuxでは、極短時間に同一ファイルに多数ランダム書き込みをするとI/Oが停止する

　　⇒仕方ないのでいい感じの独自のファイルDBを作成する羽目に

ICMP Echo問題

リトライ問題

---

ポート番号問題

---

振り返ると

• ネットワークの負荷で苦しめられたことが多かった様子
  • FWのセッションテーブル、ブロードキャスト/マルチキャストの輻輳
  • これが顕在化するにはトラフィックが大きく起因するはず
  • いくつかのキャリアのトラフィックを比較してみました

【トラフィックモデル】

比較の考察

• 移動系と固定系はモデルが全く違う
  • DISCOVER/REQUEST比、リース時間
  • REQUESTにACKが返らないのはAPを移動している　(違うサブネットに移動している)から
• FTTHとCATVは似ている様子
• CATVは端末数少なめ
  • この規模だと十分耐えられる負荷に収まるのでは
  • バースト時はモデルが違うのでもしかしたら……
  • 広域停電からの復旧
  • 端末アップデートやスリープ復帰など特定時刻イベント

XACK DHCP製品ページ

XACKトップページ