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ポリシーの変更も行えて楽しかった。
2018年10月21日(日) - 02:21 | カテゴリ:
Network
先日購入したCiscoASA 5506-Xだが、休みを使ってコンフィグを作り、
先週にASA5510からASA5506への刷新が完了した。
経過観察として1週間様子見していたのだが、
自宅で使う上での特性・注意点が判ってきたのでレポートしてみる。
今まではASA5510の上にJuniperSRX(GRE装置)・Fortigate60D(IPv6を上積みしていたが、
ASA5506に変えた事で1段に纏める事が出来た。
ただ、そのまま使ったら接地面が結構熱くなったので、木材を切って削って下駄を履かせた。
カタログスペックではASA5506の方が処理性能高いのだが、
CPUにAtomを使っている事もあり処理性能が気がかりだった。
という事で、VPN越しにCentOSのインストールISO(8.8GB)をダウンロードしてみた所、
VPN越しに90Mbpsの速度を出している時、CPU負荷は50%程になった。
※上位ルータがCisco1812Jなので100Mbps止まりになる(´・ω・｀)
他にもVPN越しに色々な処理を通しているので、100Mbps限界までは出なかった。
そうは言ってもIPsecで処理している中でこの負荷なのだから上出来な結果。
気になる所と言ったら、筐体底面が触れない程熱くなる事。
触った感じだと40度辺りまで行っていると思う。
その為、筆者環境ではホームセンターで買った木材(20mm×25mm)を切った後、
ヤスリがけ＆床ワックス(リンレイ all)を厚めに塗って耐熱処理を行い、筐体の底上げした。
コレをやっただけでも筐体内部温度が3度くらい下がっていた。
………
最終的に自宅環境のVPN装置一式が上手い具合に収まった。
消費電力・ファン騒音が下がったのは凄くありがたいが、
ファンレスであるが故に熱がこもりやすいのが懸念点。
ただ、この程度なら扇風機を外から当てれば解決出来るのでなんとかなる筈。
最近のNW機器は小型でファンレスが多いのでありがたい限りだが、
その分値段が中々下がらないのが少し困る(´・ω・｀)
仮想ルータなども台頭している中、ハードウェアで物を持つのは時代遅れになるのかもしれない。
« 続きを隠す
