2018年11月30日(金) - 21:44 | カテゴリ:
ゲーム
本来は明日行くのでも良かったのだが、
先日改装したアキバソフマップも確認すべく、月末の日を楽しんできた。
改装したアキソフは4~6階が大人の階になっており、PCゲームは4~5階だった。
また、先日までは店頭でやっていた配布イベントなどは、
全て7階のイベントフロアに集結していた。
店頭でやらなくなってしまったのは、なんとも寂しい限りだが、
会計を済ませたらそのまま7階に直行出来たり、
イベント参加で必要となるレシートが風で飛ばされなくなったりと、
それなりのメリットはあると思う。
………

今月買って来たのは、活動休止したsprite/fairysのBOXと、きゃべつそふとのアメイジング・グレイス
しかし、sprite活動休止の報は衝撃だったが、もう5ヶ月たっていたのが早く感じる。
2018年11月25日(日) - 19:15 | カテゴリ:
Network
DHCPサーバの冗長化には色々な構築レシピが存在するが、
フェールオーバー機能で割り当てアドレスを同期しつつ、
プライマリが倒れたらセカンダリでDHCP機能を引き継ぐ構成が、経験上楽に冗長化を行えた。
ただ、IPv6で利用するDHCPサーバ(便宜上、DHCPv6と表記)は、
最近になってフェールオーバープロトコルが整備された為、
2018年11月現在・開発終了しているISC DHCPには機能が実装されていない。
現在開発中のKEA DHCPでもバックエンドにDBを用いた冗長化機能はあるのだが、
リースファイルを使う様な簡易な冗長化は出来ないのがネックだったりする。
………
話は変わり、筆者自宅のIPv6クライアントアクセス網は、
お金をケチる為にラズパイを用いたRA配布・DHCPv6サーバで構築してあるのだが、
このラズパイを最近になって2台に増やした為、DHCPv6サーバ冗長化問題が発生した。
当初、KEA DHCPで組み直す事を考えていたが、バックエンドにDB利用が前提となるのでやめた。
というのも、ラズパイの補助記憶装置(ストレージ)はSDカードとなる為、
DBみたいに読み書きが大量発生する用途には向かず、過去筆者も似たような事をやって壊した事があった。
という事で何か手が無いか色々と考えつつ、RFC・ドキュメント・ソースを漁っていた所、
EUI-64でインターフェースIDを配布する事で、
アドレス衝突無く任意のIPv6アドレスを使える事に気付いたのでやってみた。
※ 細かい事は、毎度のwikiに纏めたのでそちらをご確認ください
………
そもそもの話、IPv6アドレスの配布はRA(RouterAdvertisement)を使うのが大半だが、
中にはRA配布に対応せず、DHCPv6によるアドレス配布のみ対応した困ったOSがあったり、
ND-RDNSSに対応せず、こちらもDHCPv6によるDNS配布のみ対応したWindows7というOSが存在する。
これらのOS全てに対応するには、RAとDHCPv6のフル対応が必須となってしまい、
上記の様に自前でルータもどきを構築する必要が出てきてしまう。
ちなみに、昨今ではNECルータがND-RDNSSに対応したらしいが、
筆者は対応している物を所持していないので未テスト状態。そのうちテストせねば (`・ω・´)
………
上記の理由から、IPv6網(クライアントセグメント)でラズパイルータを自作して使っているのだが、
OSのセキュリティアップデートもそれなりの頻度でやっている都合上、
シングル構成ではラズパイ再起動時にNW停止が発生していたので、冗長化してみようと画策した。
RAを使っているならDHCPv6をIPv6アドレス配布に普通は使わないとしても、
上記の通り、DHCPv6でのアドレス配布にのみ対応している物がある為、出来る限り冗長化しておきたかった。
そんな事を思いつつ情報収集した結果、DHCPv6サーバを冗長化するには下記の手段がある事が判ってきた。
- DHCPv6で配布するアドレスレンジを細かくした、
DHCPv6サーバを複数構築する構成
- バックエンドにDBを利用しつつ、
フロントエンドをクラスタ化
- EUI-64でアドレス衝突を理論上排除しつつ、
フロントエンドをスタンドアロンで複数構築

当初はパターン1で構築していたのだが『それだったら普通のIPv4環境でも出来る』ので、
『ネタとして面白く無かろう』と方向性を何処かで間違えた結果、
IPv6だからこそ出来るパターン3(EUI-64)方式での冗長化にチャレンジしてみた。
結論だが、ISC DHCPでもIPv6アドレスの配布をEUI-64ルールで行う事が出来た。
やろうとしている事は皆同じらしくISCのメーリングリストを読んだり、
ドキュメントを読んでいたら似たような事が書いてあった。
ただ、設定を有効にするにはソースコード中のヘッダーを編集してソースリビルドが必須であった。
挙動面では稀(100再起動して1回程度)にアドレスプール内なのにアドレス払い出しが出来なかったり、
リンクローカルアドレスで払いだそうとしたりイマイチな挙動が出たりしたので、
エンタープライズで使うなら調整が必要に感じた。
ただ、前途の通りエンタープライズ用途ならKEA DHCPを使うべきだし、
Infoblox辺りならアプライアンス側で冗長化に対応しているので、
ISC DHCPを今更使う様とは稀だと思う。
だが、ラズパイみたいな非力サーバでもソフトウェア次第では十分使える物を作れるのが判った。
通信速度は頑張って10~30Mbps程度だが、そこまで速度を求める使い方をしていないので、
DHCPv6・RA辺りの仕様が枯れるか、興味のそそられる新しいNW機器が出るまで使ってみようと思う。
« 続きを隠す
2018年11月17日(土) - 21:45 | カテゴリ:
Network
ns-lab BBのバックボーンNWを支えるコアルータはCisco1812Jを使っていた。
外回線が100Mbpsだったりルータを階層化している事から、
Cisco1812Jでも問題無かったのだが、回線増強も予定しているのでコアルータも刷新した。
当初、RTX1210・IX2215・ISR891でどれにするか迷ったのだが、
某所でCisco892FSPを発見し、予定を変更してこちらを採用する事にした。


上段が今回購入した892FSP、下段が従来から使っているゲートウェイ用の891FJ
ns-lab BBはISPを2契約している都合上、ルーティング制御にPBRとtracking制御を多用している。
この制御を行っているのがコアルータなので、PBR・trackingを使えないと話にならなかった。
また、サブインターフェースでIPv4/v6への接続を行っているのでGigabitI/Fにしたかった。
普通の891FJだとFastEtherになるのだが、891FSPはGigabitEtherを2本備えているので、
今回の自宅NW要件にも合致したのでIYHした。
………
試しに100Mbpsを流し込んでみたが、色々と制御を盛り込んでいる中でCPU負荷は8%程。
ルータのポテンシャルとしては1Gbpsまでは行ける筈なので、
CPU負荷の計算上も問題無く1Gbpsを出せると思われる。
また、IPv4/v6網を分ける為にVRFでルーティングテーブルを分割した上でOSPF/BGPも喋らす事にしたのだが、
Cisco1812Jでは出来なかった、OSPFv3 VRF-Liteも出来るようになった。
片足を突っ込んでいる身としては、やはりコアルータはCisco・Juniperで組みたい所。
久々のNW弄りで徹夜した日も出たが、ルーティング最適化とかtrackingポリシーの変更も行えて楽しかった。