- PR -

DHCPレンジ枯渇状態への対応方法

1
投稿者投稿内容
newbie
会議室デビュー日: 2005/10/19
投稿数: 12
投稿日時: 2006-02-13 13:22
こんにちは。

DHCPレンジ枯渇状態への対応方法として以下のような状況に対して対応を
考えているのですが果たして実現できるかどうかアドバイスを頂けないでしょうか。

以下のようなネットワークがあります。
（デザインの良し悪しは別として）
私の考えに問題がないかどうか、もし問題があるとしたらどこにあるか教えて頂けないでしょうか。

現在Catalyst3550-12の各インターフェースにVLANを設定し、
そのインターフェースそれぞれにCatalyst2950が接続されています。
各2950のポートには直接クライアント群、サーバー群が接続されています。
一応各VLANはサーバー用、クライアントセグメント用と分かれてはいます。
3550にぶら下がっている各2950は特に何も設定されておらずただのハブ状態になっています。
特にクライアント用のセグメントについてはポート数を稼ぐため各2950に3rdパーティのスイッチングハブをカスケードしています。

ルーティングは全て3550によって行われています。

オフィスが拡大するたびに3550のインターフェースに対して2950を
増やして来ていますが、最近、クライアントセグメントのDHCPレンジが一杯になりかけています。
今までのパターンだともうひとつ2950を購入して別セグメントを作るところなのですが
3550のインターフェースはすでに一杯で増設することはできません。
よってアイディアとして、一杯になっているセグメントのひとつの2950のポートにVLAN1を作成し、
そこに3rdパーティのスイッチングハブを接続し、新たなセグメント用のポート数を稼ぎます。
DHCPサーバーは上位の2950上に接続されているため、2950の設定でVLAN1にリレーをさせます。
今まで直接2950にぶら下がっていたクライアントの一部はVLAN1である3rdパーティのハブにつなぎかえられます。
つなぎかえる前はDHCPの期限を極力短くして新しいVLANでのIPを取得できるようにします。

上記のアイディアで当面のDHCPの問題は解決できるものでしょうか？
長期的にはデザイン全てを変える予定です。
アドバイスをお願いいたします。

Newbie
Desmo
大ベテラン
会議室デビュー日: 2004/03/24
投稿数: 149
投稿日時: 2006-02-13 13:53
Catalyst3550-12自体の事はよく知りませんが・・・
配下のセグメントはどのようなネットワークアドレスになっているのですか？
例えば、
・セグメント１ 129.168.1.0/24
・セグメント２ 129.168.2.0/24
・セグメント３ 129.168.3.0/24
・セグメント４ 129.168.4.0/24
・・・・・
といった具合に増えていって、その内の１つのセグメントのアドレスが不足しそうだということなのでしょうか？
ならば（例えば）現行の"セグメント１"の代わりに
　129.168.128.0/22
のようなセグメントを作ればよいと思いますが・・・
上の例なら、クライアントに対して 129.168.128.1から始まって 最大で1000個以上のIPを割り当てることが可能です。


> 一応各VLANはサーバー用、クライアントセグメント用と分かれてはいます。

それって何の意味があるのでしょう？
セキュリティ面でもレスポンス面でも特にメリットが無いように思えますが・・・
newbie
会議室デビュー日: 2005/10/19
投稿数: 12
投稿日時: 2006-02-13 15:10
Desmoさん、ありがとうございます。
はい、ご指摘の通り
・セグメント1 192.168.1.0/24(サーバー)
・セグメント2 192.168.2.0/24(クライアント)
のように現在分かれています。
セグメント2のIPが足りなくなってきています。
ちなみにセグメント2は3550から5つ程足が出ていて、それぞれ同じVLANになっています。
仰るとおり新しいセグメントを作れればよいのですが新たにVLANを作るための
ポートが3550上に空いていないためこれ以上足を出す事ができません。
また現在の192.168.2.0/24を/22に変えることもクライアントに与える影響を
考えるとやりたくないのです。
できる事なら既存の2950の下に足を出して別セグメントを作り、そこに少しずつ
クライアントを動かして動作確認を行いたいと思っています。
Desmo
大ベテラン
会議室デビュー日: 2004/03/24
投稿数: 149
投稿日時: 2006-02-13 19:11
> できる事なら既存の2950の下に足を出して別セグメントを作り、そこに少しずつ
> クライアントを動かして動作確認を行いたいと思っています。

特に問題は無いと思います。
Wind
ベテラン
会議室デビュー日: 2004/11/10
投稿数: 73
投稿日時: 2006-02-14 10:07
ちょっとしたツッコミです（釈迦に説法かもしれませんが）。

> 各2950は特に何も設定されておらずただのハブ状態になっています。
箱を開けただけのCat2950でもVLAN1（Native VLAN）は存在しますので、

> 一杯になっているセグメントのひとつの2950のポートにVLAN1を作成し、
という手法はNGです。

上層のCat3550-12T（12G？）にはVLAN1の他にVLAN Interface（SVI）が2つ切られているはずです（もしかすると、Native VLANを含めて2つかも）。
ですので、Core SwitchたるCat3550側で新規VLANを作成し、同じVLAN IDのVLANをCat2950で作成し、Cat3550とCat2950間で802.1qにてTaggingしてあげないと、通信できないかとおもいます（Cat2950、ISLしゃべれないし）。
で、DHCPがセグメント越えになる場合、SVIでHelper Addressの設定をしないとDHCPは取れないのでご注意を。
また、現在のVLANの数が判らないのでアレですが、Cat3550-12ではSVI数の上限はDefaultの仕様だと16なので、それを越えないように注意してください（越えても動きますが、制約事項あり）。

今回の要件だと、Cat3550まで手を入れる必要がありますねー。

>> 一応各VLANはサーバー用、クライアントセグメント用と分かれてはいます。
>
> それって何の意味があるのでしょう？
パフォーマンス然り、セキュリティー然り、色々とメリットはあると思います。
ServerとClientがL2で会話されると通信制御が非常に面倒ですし、いざという時のトラブルシューティングが面倒じゃないですか？
ServerとClientを同一のセグメントに並べるのは、自分的に非常に気持ち悪いです。
newbie
会議室デビュー日: 2005/10/19
投稿数: 12
投稿日時: 2006-02-14 14:43
Windさん、
ありがとうございます！
求めていた答えです。これをヒント（というかそのもの）に解決策を
考えていきたいと思います。
ありがとうございました。
1

スキルアップ／キャリアアップ（JOB@IT）