ネットワーク構築の最近のブログ記事

このところ、ずっとぐだぐだ続きです。

nwの設計とかで、面白い部分っていかに合理的な設計をしたとか、どれだけ均整が取れた直交性の高い設計に出来た、とかであると思うのだけど。
言い換えるとイレギュラーがないこととか、一意のルールに則って居るとかがネットワークアドレス設計の必要性・・・だと思っているのですが・・・


ま、とりあえず割り当てればいいじゃん、とか、それって設計でも何でも無いし!

それで、設計したとか言われても・・・ねぇ。



ま、そんな感じで設計の意味判ってない人から、かなりリアルでかなり非道いコメント頂きました。



ぐだぐだな感じですけど、設計はしてねぇっす。


↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
WAN回線の遅延が、データ転送速度(実効速度)に影響を与える・・・というのは周知の話だと思っていましたが、意外と知られていないようなので。


まず、光の速度は1秒間に30万Km、導線を流れる電気も同等なのですが、
電線の遅延がそうなのであって、、、

伝送路の遅延は他にも要素が沢山ある。。。と言いたい。

まず、光学的あるいは電気的な減衰もあるので電線だけでデータを送れる訳もなく、途中で中継器等が入るはずですが、その時点で、間違いなくバッファリング、再送信が行われているわけですから、

そこで遅延が発生するのは当たり前な気がします。。



距離(あるいは中継拠点数の数)に比例して伝送路の遅延が発生するのですが、それは当たり前の事かと。で、帯域幅があっても遅延があればあるほど、帯域幅を使い切れない事態になるのはTCPの輻輳回避の仕組みから言って当たり前の事だと思うんですが、どうでしょ。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
WAN経由で遅いというのは、ごく当たり前のことだと思うのだけど。。。



帯域幅が広くても、RTTが悪い(=Ping の応答時間が遅い)ネットワークでは帯域幅を使い切れないことが普通に起こる。という至極一般的な話なんだけど、帯域幅にしか目が行かない人からすると
納得いかないようです。。。


なんだかなぁ。
↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
LinuxのBonding。
最近、触る機会が無いっていうか。。。
なんですが、ちょっとモードをまとめてみます。



Bondingとは。
Linux の kernel 2.4.12以降で実装された、NICをチーミング(Teaming)する機能。(ketnel 2.4.18以降で標準で組み込まれています)
複数のNICを論理的に1つのNICと見なして束ねることで、耐障害性を向上したり、送受信のパフォーマンスを(分散処理することによって)上げる技術。

NICを束ねたものとして仮想のデバイスを使用します。通常NICは/dev/eth0、/dev/eth1、/dev/eth2・・・というデバイス名を使用しますが、束ねたあとの仮想デバイスは/dev/bond0、/dev/bond1、/dev/bond2・・・というデバイス名を使用します。



↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
CISCOのFirewall。
PIXというか今はASAというか。。。

機能的には、別に普通だと思うのだけど、
微妙にIOS Firewallと違うのも判りにくいと思わせる一因なのかも。




ま、相変わらずマルチキャストルーティング(というか、マルチキャスト環境下のファイアウォール動作)に悩まされてる・・・。



もう、マルチキャストなんて、、、イヤだ!


って言って、投げてしまいたいんだけど(^^;




↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
ARPingの問題は片付いていないのだけれど、、、
それよりも、ちょっと気になる事があって。

実際、例えば24ビットマスクのネットワークとかだったら、スキャンするのに最低でも254回はARPを投げて、しばらくモニタして・・・を繰り返す事になる。仮にARPを投げるのに0.1秒、モニタ時間を1秒としても、1.1秒×254=280秒・・・おおよそ5分弱掛かる事に。
それでも良いけど、あまりにもアホな方法なんで、もちっと早く出来ないのかと。


↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
ネットワークから重複したIPアドレスを探し出す方法は無いかと探してみたのだけれど。


↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
Dynagenで何をやっているかというと・・・・

実はマルチキャスト・ルーティングだったりします。。。

恥ずかしながら今までマルチキャスト・ルーティングって経験無かったりするのです。
ですので、マルチキャスト・ルーティングの構築・テストその他の方法を調べていたのですが、、、手元にある実機というか、使えそうなヤツってCiscoの3745と2611、Catalyst2950、2960程度だったので色々検証すら出来ずにいたのです。。。




↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
CISCOルータのエミュレータです。
Windows、MacOS X、Linuxのバイナリが提供されています。


よくCISCOルータの勉強用(というかCCNAの勉強用)にヤフオクなんかで実機を買うのも良く聞く話なのですが、なかなか良くできたエミュレータなので、、、これで実機不要かな・・・と思います。
ホンモノのIOSが必要なのでその部分グレイだねという点と、ホンモノのIOSを使うので他のシミュレータと違って動作が実機そのままという点と、ちょっとメモリ食いなので・・・というか基本7200のエミュレータなので、ルータ1台あたり160Mbytesのメモリを消費する・・・大量のルータを起動しようとするとそれなりのメモリリソースが必要になる、実LANインターフェースを割り当て可能なのでその気になればPC(とかMac)をCISCOルータ化できる・・・という特徴が。イメージさえあれば、マルチプロトコル環境でも、BGPでも、EIGRPでも好き放題に環境構築できるので、かなり面白い。。
運良く手元に実機ごと3745がありましたので、ルータ6台の環境をエミュレーションさせてみようとしましたが、2Gbytesのメモリではスワップ多発で使い物になりませんでした。
ま、それほど大規模の検証が必要になる事もそれほど無いと思いますが。

あと欲を言えばCatalystのエミュレーションも出来ればステキなんですがね。

使い方については
Dynamips/Dynagen 設定マニュアル
とか参考になります。。。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
IPアドレス(レンジ表記)をサブネット表記に置き換えるスクリプトですが、副産物と言うべきか、できたものがこれ。
ip.zip

使い方ですが
D:\src>ip.pl -s 10.1.0.0 -e 10.11.200.255
10.1.0.0/16
10.2.0.0/15
10.4.0.0/14
10.8.0.0/15
10.10.0.0/16
10.11.0.0/17
10.11.128.0/18
10.11.192.0/21
10.11.200.0/24

D:\src>ip.pl -s 192.1.0.0 -e 192.20.255.199
192.1.0.0/16
192.2.0.0/15
192.4.0.0/14
192.8.0.0/13
192.16.0.0/14
192.20.0.0/17
192.20.128.0/18
192.20.192.0/19
192.20.224.0/20
192.20.240.0/21
192.20.248.0/22
192.20.252.0/23
192.20.254.0/24
192.20.255.0/25
192.20.255.128/26
192.20.255.192/29
こんな感じで、10.1.0.0から10.11.200.255をサブネット表記するにはこうしたらいいというリストを出してくれます(2つ目は192.1.0.0から192.20.255.199の例)。ネットワークなんて触ってると、ルーティングテーブルとかACLとかで、オーバーヘッド(ペナルティ)を減らしたいという意図からできる限り行数を短くしたい事も多いし、この機会に作っておこうとか、そんな感じですが。
ま、そもそもIPアドレス設計の段階で考慮されていればこんな涙ぐましい努力は必要無いんですけど、現実問題としては既に存在するネットワークをどうこうするという話が多いわけで、過渡期的にぐちゃぐちゃなネットワークになってしまう事なんて良くある話で。ま、そんな意味では必要悪というか仕方ないというか。。。

↓ にほんブログ村に登録してます (^^ ↓
ブログランキング・にほんブログ村へ にほんブログ村 IT技術ブログへ にほんブログ村 音楽ブログへ にほんブログ村 音楽ブログ DTM・MIDIへ
1ページ

このアーカイブについて

このページには、過去に書かれたブログ記事のうちネットワーク構築カテゴリに属しているものが含まれています。

前のカテゴリはスマートフォンです。

次のカテゴリはネット/コンピュータです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

2010年9月

      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

ブログペット

アーカイブ

その他のリンク

アクセラナビ

ブログ全体を検索
1x4x9.netを検索


タグクラウド

最近のコメント

QRコード

QR_Code.jpg