iTAC塾講義ノート
|
コース名
|
テクニカルエンジニア(ネットワーク)塾
Sコース8,9回目(大阪)
Aコース4,5回目(大阪・名古屋)
合同
|
講師
|
みずおか先生
|
日時
|
2000年6月24日、25日
10:00〜17:00
|
場所
|
1日目 さつきホールもりぐち
2日目 鉄鋼ビル大ホール
|
内容
|
ネットワーク機器実習 |
(概要)
〜 ネットワーク機器実習 〜
今回の講義は、ネットワーク技術者S君になって会社のネットワークを構築していく課程を
1995〜2000年の背景に合わせて体験していきました。
以下にその内容をまとめます。
常に全体を意識するのではなく、当方が属している名古屋A-1のPCから見た変遷を中心にまとめます。
(メインストーリー)実習ガイドより抜粋
☆☆☆ A社コリジョンセグメント分割記
☆☆☆
今回のiTACネットワーク実習においては、「企業ネットワークのコリジョンセグメン
ト分割の過程」を主眼としています。受講生のあなたは、中堅商社A社に1990年に入
社したパソコン好きな営業部員S君になります。そして、入社5年目の1995年のA社
のコンピューター導入以来、A社のコンピュータの世話をしているうちに、情報システ
ム部員としての道を歩んでいきます。そして、ネットワーク導入とともに実務経験を積ん
でいき、最終的には2000年に光ファイバ、L3ネットワークを構築する優秀な情報シ
ステム課長になるとともに、情報処理技術者試験のネットワークスペシャリスト試験に合
格し、名実ともに力をつけていくことになります。このシミュレーションを通じて、
1995年から2000年に至るまでのA社のネットワーク拡張を体験していただきます。
(社内ネットワークの拡張)-(トラフイックの増加)-(コリジョンセグメントの分割)
という流れを時間的な側面から追っていくことで、ネットワーク技術の推移を実機ととも
に実体験していただくのが今回の実習のメインテーマです。
今回の実習では、1995年から2000年までのA社ネットワーク拡張の時間的経緯と
ネットワーク技術発展の背景を説明するストーリーに沿っていく形で、2日間の実習を進
めていきます。
また、ピアツーピアからオールスイッチヘと至るネットワーク変遷や、ギガビットイーサネッ
トを実習します。そして、ハブの多段接続制限といった、情報処理試験のネットワークスペシャ
リスト塾で学習してきたことが、実務においても適用されていることを確かめます。
実習では、実機に触れることと、体で感じることを中心としております。皆様は、自分達で持
ってきたノートPCの電源を入れ、ネットワーク接続の設定をし、LANカードをインストール
します。そして、ケーブルを実際に接続し、ボートに差し込みます。通信が確立したら、実際に
データを転送してみます。その時間を計測するのは自分の時計です。体で感じていただきます。
このような実体験を組み重ねていくことによって、理解を深めていきます。
☆☆☆ シナリオの概略について
☆☆☆
1日日のトピック(予定)
・機器のマイクロバスからの持ち出し、搬入作業
・ハブによる各グループのLAN構築
・ハブによる各グループのファイル転送テストおよび報告、まとめ
・各グループのハブをカスケード接続してのファイル転送テスト
・各グループのハブのアップリンク先をスイッチにして転送テスト
・オールスイッチによるファイル転送テストおよび報告、まとめ
・WR11によるワイヤレス接続テスト
・アセット確認!・あとかたづけ・箱詰め・車搬入
2日日のトピック(予定)
・機器のマイクロバスからの持ち出し、搬入作業
・8312によるL3ネット構成での転送テストおよびまとめ
・「Physical View」などによるマネージメント実習
・光ファイバネットワーク構成によるファイル転送テスト
・G-NICによるファイル転送テストと実測値の計測
・8224XLおよび9006SXによるVLAN構築実習
・アセット確認!・あとかたづけ・箱詰め・車搬入
(実習 第一部 ハブによる各グループのLAN構築@1995)
☆☆☆ 背景 ☆☆☆
パソコン好きなS君はデータの共有のために自グループ内のPCをLAN接続し始めた。
☆☆☆ 目的/内容/確認事項 ☆☆☆
☆ ハブによる各グループのLAN構築
☆
・グループ内をLANで接続。
・各自のPCにIPアドレスを設定。
・接続をpingコマンドで確認。
・pingのオプション(-l:サイズ変更)でレスポンス時間を測定。
☆
ハブによる各グループのファイル転送テスト ☆
・30〜40MBのファイルを作成。
・「ネットワークコンピュータ」でグループ内のPCが見えることを確認。
・それぞれのPCにTemporary
フォルダ(\TEMP)を作り、1:1、n:nで作成したファイル転送。
転送時間の理論値、実測値を求め、その違いを考察。
☆☆☆ 結果 ☆☆☆
☆ ハブによる各グループのLAN構築
☆
名古屋A-1グループの設定:グループ名・・・koryouri
表1.1 初期段階でのkoryouriグループのIPアドレス割り当て |
PC名 |
IPアドレス |
kiki |
192.192.192.11 |
harry |
192.192.192.12 |
naokin |
192.192.192.13 |
taro |
192.192.192.14 |
・接続をpingコマンドで確認
「ping 192.192.192.13」 >>> 接続を確認。
・pingのオプション(-l:サイズ変更)でレスポンス時間を測定
「ping -l 64 192.192.192.13」 >>> 10ms以内で通信
64ビット、1500ビットでは差は無かったが、10000ビットでは遅くなった。
☆
ハブによる各グループのファイル転送テスト ☆
・30〜40MBのファイルを作成 → 作成ファイル容量:40,673,334バイト
・それぞれのPCにTemporary
フォルダ(\TEMP)を作り、1:1、n:nでファイル転送
HUB転送速度: 10Mbps
理論転送時間: 40,673,334 × 8 / ( 10× 10^6 ) = 32.5秒
実測値(1:1)
表1.2a 初期段階でのkoryouriグループファイル転送時間(1:1) |
転送方向 |
転送時間 |
1.taro → kiki |
3分 17秒 (197秒) |
2.kiki → harry |
1分 24秒 ( 84秒) |
1'.taro → kiki |
2分 51秒 (171秒) |
3. taro → harry |
4分 (240秒) |
3'. taro → harry |
5分 6秒 (306秒) |
taroから送信するデータの通信時間が他に比べて遅すぎる。
原因として
・40MBのデータを作成した際の「ペイントブラシ」が立ち上がっていたため
・コリジョンを頻発させたためにBack Off時間が長くなった
ことが考えられたため、全PCを再起動しやり直してみることにした。
表1.2b 初期段階でのkoryouriグループファイル転送時間(1:1) |
転送方向 |
転送時間 |
4.taro → naokin |
4分 37秒 (277秒) |
5.kiki → naokin |
43秒 ( 43秒) |
6.kiki → taro |
1分 10秒 ( 70秒) |
平均:173.5秒 (PC"taro”の送信を除くと 65.7秒)
実効速度 4.95Mbps
実測値(3:3)
表1.3 初期段階でのkoryouriグループファイル転送時間(3:3) |
転送方向 |
転送時間 |
|
harry → kiki |
3分 22秒 (212秒) |
この3つを同時通信
(本当は4つのPCで同時通信がしたかったが、
PC”taro”の通信状態がよくないようなので3つにした) |
harry → naokin |
2分 24秒 (144秒) |
naokin → harry |
3分 25秒 (205秒) |
平均:187秒 実効速度 1.74Mbps
☆☆☆ 考察、まとめ ☆☆☆
HUBによるデータ転送
理論転送時間は32.5秒なのに対して実際の転送時間は1:1で平均65.7秒(taro除く)であった。
原因としては、
IPパケットの構成として、パケット長を64バイトと考えると、
プリアンブル8バイト、IPパケット64バイト、IBG12バイトであり、
その中で、実際のデータは46バイトである。
これを考慮すると 46/(8+64+12)= 0.55であり、転送時間の比 32.5/65.7=0.5とほぼ一致する。
3:3の転送では平均187秒と1:1の時と比較してコリジョンによるスループットの悪化が体験できた。
また、PC(taro)が送信するファイルの転送時間が著しく遅かったのは、当初
・大ファイル作成によるメモリ消費
・コリジョンによるBack off時間の増大
が原因と考え、再起動したが現象は変わらず、
またケーブル、NICも問題が無い事から PC→NIC間に問題があると考える。
(実習 第二部 各グループのハブをカスケード接続@1996)
☆☆☆ 背景 ☆☆☆
グループ内のPCをHUB接続してデータの共有をしていたS君。
周りを見渡すと他のグループも同じようなことをしていた。
S君は各グループのHUB同士を接続することにした。
☆☆☆ 目的/内容/確認事項 ☆☆☆
☆
各グループのハブをカスケード接続してのファイル転送テスト
☆
・他グループと同じコリジョンセグメントになることによる、IPアドレスの再設定。
・HUBの段数は4段までという規定があるが、それを超えるとどうなるかを確認
・段数を4段以下にして、ファイル転送テストを実行。
☆☆☆ 結果 ☆☆☆
・IPアドレスの再設定
全体のネットワーク番号を 192.168.1
、サブネットマスクを 255.255.255.0 とした。
名古屋A-1(koryouri) は 192.168.1.40番台
が割り振られたので、
表2.1 全グループをHUBで接続した後のkoryouriグループのIPアドレス再設定て |
PC名 |
IPアドレス |
kiki |
192.168.1.41 |
harry |
192.168.1.42 |
naokin |
192.168.1.43 |
taro |
192.168.1.44 |
に変更した。
他のグループのネットワークは?
表2.2
全グループをHUBで接続した後の他グループのIPアドレス一覧 |
地区 |
IPアドレス
192.168.1.** |
大阪S-1 |
10番台 |
大阪S-2 |
20番台 |
大阪S-3 |
30番台 |
名古屋A-1(koryouri) |
40番台 |
大阪S-4 |
50番台 |
名古屋A-3(AO) |
60番台 |
名古屋A-2(trouble) |
70番台 |
大阪A-1 |
80番台 |
大阪A-2 |
90番台 |
大阪A-3 |
100番台 |
・ネットワークの接続状態
(大阪S-1 |
10番台) |
-- |
(大阪S-2 |
20番台) |
-- |
(大阪S-3 |
30番台) |
|
| |
|
|
|
|
| |
|
(名古屋A-1 |
40番台) |
|
☆情報システム部☆ |
|
(大阪S-4 |
50番台) |
|
|
\ |
|
|
|
| |
|
(名古屋A-2 |
60番台) |
|
\ |
|
|
(名古屋A-3 |
70番台) |
|
| |
|
| |
|
|
| |
|
(大阪A-3 |
100番台) |
-- |
(大阪A-1 |
80番台) |
|
(大阪A-2 |
90番台) |
図2.1 全グループのネットワーク接続状態 |
・HUBの段数は4段までという規定があるが、それを超えるとどうなるか?
この状態で、名古屋A-2 → 大阪A-2 (HUB段数
10段)をpingで接続確認をしたところ、レスポンスが返ってきた。
・HUBのカスケード接続によるファイル転送テスト
----------- |
-- |
------- ( HUB ) ------- |
-- |
--------- |
| |
|
| |
|
| |
< 名古屋A-1(koryouri) >
( HUB )
|
|
< 名古屋A-2(trouble) >
( HUB ) |
|
< 名古屋A-3( AO) >
( HUB ) |
|
| | |
|
|
| | |
|
|
| | |
taro kiki |
|
kenichi |
|
ao2 |
図2.2 名古屋地区のHUB接続状態 |
各グループ1台から一斉に転送する。
表2.3 HUBをカスケード接続し、一斉転送した時のファイル転送時間
(データ容量34.8MB) |
1回目 |
kenichi → taro |
286秒 |
taro → ao2 |
314秒 |
ao2 → kenichi |
114秒 |
2回目 |
kenichi → kiki |
140秒 |
kiki → ao2 |
127秒 |
ao2 → kenichi |
168秒 |
3回目 |
kenichi → kiki |
136秒 |
kiki → ao2 |
133秒 |
ao2 → kenichi |
155秒 |
平均:174.8秒 実効速度 1.59Mbps
☆☆☆ 考察、まとめ ☆☆☆
HUBを4段以上接続した時の接続確認テストでは10段でも接続が確認できた。
これは、
・ケーブル長が最大長に比べて短い。
・HUBの性能向上による遅延時間の減少
により、相手側PCへの到達時間が短かったためだと思われる。
(実習 第三部 スイッチによるLAN構築@1997)
☆☆☆ 背景 ☆☆☆
HUB同士を接続してネットワークを拡大したS君。
今度はコリジョンによるスループットの悪化が問題になってきた。
街中ではスイッチングHUBの価格も安くなりだし、S君は導入することにした。
☆☆☆ 目的/内容/確認事項 ☆☆☆
☆
各グループのハブのアップリンク先をスイッチにして転送テスト
☆
・リピータHUB から
スイッチングHUBに交換することによって、どのくらいスループットが良くなるか、
または悪くなるかを確認
・コリジョンランプの点き方に注目。(同時につくか、どこかとペアでつくか)
・転送テストを行う前に、スイッチングHUBの電源を一度OFFにして、ON後すぐにテストを開始する。
それと、OFFにしない方法との差を確認。
☆
オールスイッチによるファイル転送テストおよび報告、まとめ
☆
・全てのPCをリピータHUBから切り離し、スイッチングHUBに接続する(オールスイッチ)。
・アップリンク先にスイッチを置いていた方法との差を検討。
☆☆☆ 結果 ☆☆☆
・各グループのハブのアップリンク先をスイッチにして転送テスト
----------- |
-- |
--- ( Switching HUB ) --- |
-- |
--------- |
| |
|
| |
|
| |
< 名古屋A-1(koryouri) >
( HUB )
|
|
< 名古屋A-2(trouble) >
( HUB ) |
|
< 名古屋A-3( AO) >
( HUB ) |
|
| | |
|
|
| | |
|
|
| | |
kiki |
|
kenichi |
|
ao2 |
図3.1 名古屋地区のHUB接続状態 |
各グループ1台から一斉に転送する。
表3.1 HUBをカスケード接続し、アップリンク先にスイッチングHUBを置く
構成での一斉転送した時のファイル転送時間
(テスト直前にスイッチの電源OFF)(データ容量34.8MB) |
|
kiki → ao2 |
123秒 |
kenichi → ao2 |
135秒 |
ao2 → kenichi |
187秒 |
kenichi → kiki のつもりが、kenichi →
ao2になっていたため、再テスト |
再テスト |
kiki → ao2 |
123秒 |
kenichi → kiki |
187秒 |
ao2 → kenichi |
143秒 |
平均:151秒 実効速度:1.84Mbps
表3.2 HUBをカスケード接続し、アップリンク先にスイッチングHUBを置く
構成での一斉転送した時のファイル転送時間
(テスト直前にスイッチの電源OFFせず)(データ容量34.8MB) |
|
1回目 |
2回目 |
3回目 |
kiki → ao2 |
123秒 |
120秒 |
121秒 |
kenichi → kiki |
143秒 |
138秒 |
138秒 |
ao2 → kenichi |
186秒 |
173秒 |
179秒 |
平均:147秒 実効速度:1.89Mbps
2日目、アップリンク先にスイッチを置く方法とオールスイッチの方法での転送時間
の違いを調べるため次のテストを実施した。
@アップリンク先にスイッチを置く方法
--- |
-- |
--- ( Switching HUB ) --- |
----- |
-- |
| |
| |
| |
| |
| |
| |
naokin |
kiki |
thomas |
kenichi |
ao1 |
ao2 |
図3.2 名古屋地区のHUB接続状態
(アップリンク先にスイッチを置く方法) |
スイッチに接続された3台のみ使用して一斉に転送しあう。
naokin , thomas , ao2 の組合せと
kiki , kenichi , ao1 の2ケースについてテスト
表3.3
スイッチに接続された3台のみ使用して一斉に転送時間
case1(naokin , thomas , ao2の組合せ)(データ容量34.8MB) |
|
1回目 |
2回目 |
3回目 |
naokin → ao2 |
122秒 |
116秒 |
115秒 |
ao2 → thomas |
122秒 |
108秒 |
113秒 |
thomas → naokin |
85秒 |
90秒 |
68秒 |
表3.4
スイッチに接続された3台のみ使用して一斉に転送時間
case2 (kiki , kenichi , ao1の組合せ)(データ容量34.8MB) |
|
1回目 |
2回目 |
3回目 |
kiki → ao1 |
100秒 |
94秒 |
106秒 |
ao1 → kenichi |
113秒 |
112秒 |
110秒 |
kenichi → kiki |
72秒 |
72秒 |
74秒 |
2回の平均:100秒 実効速度:2.78Mbps
Aオールスイッチ
--- |
---- |
---- ( Switching HUB ) ------- |
----- |
----- |
-- |
| |
| |
| |
| |
| |
| |
| |
| |
| |
naokin |
kiki |
thomas |
kenichi |
toshirou |
hiyoko |
ao1 |
ao2 |
ao3 |
図3.3 名古屋地区のHUB接続状態
(オールスイッチ) |
表3.5
スイッチに接続された全てのPCが適当な相手に
ファイルを一斉転送した時間 (データ容量34.8MB) |
naokin → ao2 |
124秒 |
kiki → thomas |
180秒 |
kenichi → thomas |
23秒 |
thomas → toshirou |
88秒 |
toshirou → hiyoko |
70秒 |
hiyoko → ao3 |
180秒 |
ao1 → kiki |
380秒 |
ao2 → kenichi |
120秒 |
ao3 → ao2 |
153秒 |
平均:146秒 実効速度:1.91Mbps
☆☆☆ 考察、まとめ ☆☆☆
スイッチングHUBを導入することにより、スループットの改善がはかれると思ったが、
結果は、HUBによる接続(実効速度1.59Mbps)と比較して1.84Mbpsと1.15倍の改善にとどまった結果となった。
原因としては、スイッチングHUBが効力を発するのは、A→BとC→Dのような同時通信ができる時
であり、今回のテストのような3台では同時通信が不可能なのであまり改善されなかったと考える。
次に、転送直前に電源を切る場合と切らない場合にてテストを行った。
スイッチは電源を切るとアドレステーブルはクリアされ、テーブルに登録されるまでは
ブロードキャストで流れるためスループットは悪化するはずである。
テスト結果では、電源を切る(テーブルをクリアする)・・・ 実効速度1.84Mbps
電源を切らない(テーブル情報を持ったまま)・・・ 1.89Mbps
となり、予想通りの傾向が出た。
しかし、大きく取り上げるほどの差が出なかったのは、ブリッジのラーニングが早いからだと推測する。
先ほどの3台でのスイッチのテストでは、スループットがほとんど改善しなかった。
では、全て(12台)のPCをブリッジに直接接続すると同時通信が出来、スループットが大幅に改善すると予想する。
結果は
アップリンクでのスイッチ接続・・・実効速度 2.78Mbps
オールスイッチ接続・・・実効速度 1.91Mbps
で、まったく逆の結果になった。
原因を推測すると、表3.5におけるオールスイッチの結果を見ると、転送時間が23秒、380秒と、
10Mbpsと100Mbpsが混在してるように思える。考察しにくいデータである。
他のグループの結果(ヒロチェンコさん提供)を見ると
平均 2.2Mbps → 3.7Mbps
という結果になっており、改善されているのが分かる。
(実習 第四部 L(レイヤ)3スイッチによるLAN構築@1998)
☆☆☆ 背景 ☆☆☆
スイッチングHUBの導入でスループットは改善した。
今度は他地区のネットワークとの接続を検討して、自由テキストを導入することにした。
☆☆☆ 目的/内容/確認事項 ☆☆☆
☆ 8312によるL3ネット構成での転送テストおよびまとめ
☆
・スイッチングHUBを各グループ2台設置。
・各スイッチを自由テキスト(8312)と接続。
・IPアドレスの再設定
・これによりデフォルトゲートウェイにつながるかを確認。
・他地域のPCとpingで接続確認
・自由テキストで確立されるVLANの特長を理解。
・tracert によるルーティング経路の確認
・ダイナミックルーティングのリルートの確認。
8312ではディスタンスベクター方式のRIP2を使用している。
つまり、30秒間隔でルータから情報を交換し、4回情報が来なかったら
そのルートは無かったことにして迂回路を設定する。
☆☆☆ 結果 ☆☆☆
|
--------
|
--- ( 8312 L3 Switch ) --- |
--------- |
|
| |
|
| |
|
(Switching HUB ) |
|
(Switching HUB ) |
|
| |
・・・ | |
|
| | ・・・
| |
|
|
|
|
図4.1 名古屋地区の自由テキストとの接続状態 |
|
|
SH |
大阪A
10.100.2 |
SH |
|
|
|
|
+- |
----------- |
-+ |
|
|
|
|
|
| |
|
|
|
|
10.1.2 |
|
<自由テキスト> |
|
10.1.1 |
|
|
|
/ |
|
\ |
|
|
|
<自由テキスト> |
-- |
----------- |
-- |
<自由テキスト> |
|
|
| |
|
10.1.3 |
|
| |
|
+- |
----------- |
-+ |
|
+- |
----------- |
-+ |
SH
|
名古屋A
10.100.3 |
SH
|
|
SH
|
大阪S
10.100.1 |
SH
|
図4.2 全社構成のネットワーク |
☆ この構成ではネットワークが6つあることを確認
☆
☆ IPアドレスの再設定 ☆
バックボーンネットワークに接続するに当たり、IPアドレスおよびデフォルトゲートウェイの再設定を行う。
名古屋Aの割り振り・・・10.100.3/24
表4.1 バックボーンネットワーク接続後
のkoryouriグループのIPアドレス割り当て |
PC名 |
IPアドレス |
kiki |
10.100.3.41 |
harry |
10.100.3.42 |
naokin |
10.100.3.43 |
taro |
10.100.3.44 |
デフォルトゲートウェイ・・・ 10.100.3.254
☆ 自由テキストについて ☆
ポート番号 |
1 |
2 |
3 |
4 |
5 |
・・・ |
n |
ポート |
・ |
・ |
・ |
・ |
・ |
・・・ |
・ |
図4.3 自由テキストポート部概略図 |
”ルータを超えれば違うネットワーク”なので、ルータでは、各ポートは違うネットワークになります。
しかし、自由テキストのVLAN機能を使用すると、ポート2と3は同じネットワークと言うふうに、
複数のポートを1つのネットワークにすることが出来ます。
今回も、自由テキストには名古屋Aから2つのスイッチから接続しに行きましたが、
同じネットワークとして設定されています。
☆ ネットワークへのpingによる接続確認 ☆
ping 10.100.1.52(大阪S任意)
を行ったところ、接続を確認。
引き続き arp -a でarpテーブルの中身を確認する。
自ネットワークでは、テーブルはpingで確認しあったPCのIPアドレス、MACアドレスが確認できた。
(たとえば、PC(harry)とpingすれば、10.100.3.42
[MACアドレス] )
しかし、他ネットワークの場合は、デフォルトゲートウェイのアドレスが表示されることに注目する。
☆ tracert によるルーティング経路の確認 ☆
tracert(とれーするーとと発音)・・・ルーティング経路を表示させる(日経ネットワーク7月号
P.86)
他ネットワークの任意のPC(大阪S・・・10.100.1.52、大阪A・・・10.100.2.21)へのtraceを確認する。
表4.2 tracert 10.100.2.21 で表示される画面 |
1 |
1ms 1ms 1ms |
10.100.3.254 |
2 |
4ms 2ms 1ms |
10.1.2.1 |
3 |
5ms 1ms 1ms |
PC04[10.100.2.21] |
表示されるIPアドレスは、それぞれのデータリンクの終点になる。
kiki → 大阪S(10.100.1.52) ・・・ 10.100.3.41 →
10.100.3.254 → 10.1.3.254 → 10.1.3.52
kiki → 大阪A(10.100.2.21) ・・・ 10.100.3.41 →
10.100.3.254 → 10.1.2.1 → 10.100.21
|
|
SH
|
大阪A
10.100.2 |
SH |
|
|
|
|
+- |
----------- |
-+ |
|
|
|
|
|
|
10.100.2.254 |
|
|
|
|
10.1.2 |
|
<自由テキスト> |
|
10.1.1 |
|
|
|
10.1.2.1
/
10.1.2.254 |
|
10.1.1.254
\
10.1.1.1 |
|
|
|
<自由テキスト> |
10.1.3.1--- |
----------- |
--10.1.3.254 |
<自由テキスト> |
|
|
10.100.3.254
| |
|
10.1.3 |
|
10.100.1.254
| |
|
+- |
----------- |
-+ |
|
+- |
----------- |
-+ |
SH
|
名古屋A
10.100.3 |
SH
|
|
SH
|
大阪S
10.100.1 |
SH
|
図4.3 全社構成のネットワーク |
☆
ネットワーク切断によるダイナミックルーティングのリルート機能の確認 ☆
大阪A、名古屋A間のネットワークを切断する。
|
|
大阪A |
|
|
|
10.1.2.1
切断×
10.1.2.254 |
|
10.1.1.254
\
10.1.1.1 |
|
名古屋A |
10.1.3.1--- |
----- |
--10.1.3.254 |
大阪S |
図4.4 大阪A名古屋A間を切断
|
名古屋A→大阪A(10.100.2.21)のtracert
10.100.3.254 → 10.1.3.254 → 10.1.1.254 → 10.100.2.21
<< 切断した線を元に戻す >>
10.100.3.254 → 10.1.2.1 → 10.100.2.21
ダイナミックルートによってリルートが出来ることを確認した。
☆☆☆ 考察、まとめ ☆☆☆
結果の中で確認、考察しているので省略する。
(実習 第五部 光ファイバのLAN構築@2000)
☆☆☆ 背景 ☆☆☆
光ファイバーの価格低下に伴い、S君は導入を検討することにした。
☆☆☆ 目的/内容/確認事項 ☆☆☆
・ブリッジ同士ではループは不可。
しかしスパニングツリーを有効にすることにより可。
スパニングツリーを有効にして接続確認
・逆にスパニングを無効にして接続確認
・光ファイバネットワーク構成によるファイル転送テスト
・G-NICによるファイル転送テストと実測値の計測
・8224XLおよぴ9006SXによるVLAN構築実習
☆☆☆ 結果 ☆☆☆
[Giga-SW]----- |
--- |
光ファイバ |
--- |
[Giga-SW] |
|光ファイバ |
|
|
|
|光ファイバ |
[8224XL SW-HUB] |
--- |
ツイストペア |
--- |
[8224XL SW-HUB] |
| | | |
|
|
|
| | | |
PC PC PC |
|
|
|
PC PC PC |
図5.1 ループ構成図 |
[Giga-SW]----- |
--- |
× 切断 × |
--- |
[Giga-SW] |
|光ファイバ |
|
|
|
|光ファイバ |
[8224XL SW-HUB] |
--- |
ツイストペア |
--- |
[8224XL SW-HUB] |
| | | |
|
|
|
| | | |
PC PC PC |
|
|
|
PC PC PC |
図5.2 切断時の迂回路 |
ブリッジのループ試験
全体をブリッジにて接続しているのでネットワークは一つである。
ブリッジにはループを作ってはいけないという決まりがあった。
しかしそれはスパニングツリー機能を使用することにより回避できる。
図5.1のようにループ状態でping命令を出すと接続確認が出来た。
また、ループの一部を切断(図5.2)してみてもスパニングツリーによる
迂回も確認できた。
逆にスパニングツリーを無効にしたらどうなるか。
マスタリングTCP/IP p.103にはメルトダウンを発生すると記してある。
実際そのループを通るファイルと転送してみるとコリジョンランプの点灯回数、
ループ内のパケット数は時間と共に増加し、最初はpingにて接続確認できていた通信も
タイムアウトが頻発し、通信不可能になった。
・光ファイバネットワーク構成によるファイル転送テスト
・G-NICによるファイル転送テストと実測値の計測
・8224XLおよぴ9006SXによるVLAN構築実習
については時間がなくてテストが出来なかった。
☆☆☆ 考察、まとめ ☆☆☆
結果の中で確認、考察しているので省略する。
☆☆☆ 【補習1】光ファイバのデータリンクについて 〜 NSP掲示板にて 〜 ☆☆☆
実習の中で使用した光ファイバーケーブルについての疑問点をNSP掲示板にて
いおさん、Y.Kさんの協力により解決しましたので、紹介します。
第5部で使用した光ファイバについて
今回、8224XLとGiga-SW、Giga-SW同士をSCケーブルで接続した。
これのデータリンクの確立方法は?特長は?
☆☆☆ ケーブルコネクタ形状について ☆☆☆
☆ SCケーブル
・「SC」というのはコネクタ形状のことで、他に、ST,FC,SMA-906などいろある。
・SC形コネクタは、ギガビットEthernet教科書 P90〜P91を見ると国際規格に採用された(IEC 60874-14規格)世界標準と記述される。
・SCコネクタはNTTが開発した光コネクタで、PUSH/PULL着脱、2連化(デュプレックスタイプ)が容易などの利点が受け入れられギガビットイーサネット(GbE)やATMに広く用いられている。
・IECを中心に統一作業が進められてきたが、1992年6月にSC形が推奨形光コネクタとして採用された。
・かりに正式標準でなくてもGbE、ATM用途での事実上の世界標準であることは確か。
・ST、FC形コネクタについてもGbE、ATM以外の用途にはよく用いられており、SC形コネクタと同じく世界標準になっていると思われる。
☆SC以外のコネクタ
・ST:AT&T開発 バネヨット方式の着脱 100BASE-FXなどにによく用いられている。
・FC:NTT開発 ねじ込み方式の着脱 光計測器類などによく用いられる。
・SMA:米軍など使用されているねじ方式の着脱 ロスが多いと言う欠点あり。
・どれも、接続にひねりを伴うため2個のコネクタを一体にして2連化出来ない。
☆これからの、コネクタ
・高密度実装に向けた更なる小型化→SFF(Small Form Factor)用光コネクタ
・MT-RJ:タイコ社開発 MT部はNTT開発のMTコネクタ使用、これにRJ-45のようなピンロック付きカバーを付ける
2芯一括型 RJ-45とほぼ同じサイズ
・MU:NTT開発
・LC:ルーセント・テクノロージー社(AT&T系)
・すべてPUSH/PULL着脱ができ、極めて小型。
参考:BLACK BOX CABLE CATALOG 2000年6月号など
☆☆☆ 光ファイバーの選択 ☆☆☆
光ファイバ自体の種類もいろいろ
・マルチモード/シングルモード
・ケーブル径
などあるので、製品にあったものを選択する必要がある。
☆☆☆ 本実験でのデータリンク、物理層仕様 ☆☆☆
・データリンクはイーサネットやFDDIとの並びで考えると、「ギガビットイーサネット(IEEE802.3z)」。
・物理層仕様は、1000BASE-SX。
☆ 機器間を光ファイバー2本使用して接続していたことについて
・単方向通信なので、行きと帰りで2本必要。
・これはギガビットイーサネットだからではない。
・光だろうが銅線だろうが、1本の線に仮に両方から同時に送れるとするならば、絶対衝突する。
・ツイストペアケーブルなら1本と考えてしまうが、内部的には行き帰りで別の銅線を使ってる。
☆ ギガビットイーサネットの接続方法
|
フレームフォーマット |
接続方法 |
Ethernet |
Ethernet |
CSMA/CD |
GbE(ギガビットイーサネット) |
Ethernet |
POINT-POINT |
GbEはフレームフォーマットがEthernetなので、"イーサネット"の名を継承するが、接続方法はCSMA/CDではなくPOINT-POINT(全2重通信)。
(日経NETWORK 5月号 特集「LANスイッチの完全理解」のP.79)
☆☆☆ 【補習2】スイッチングHUBのワイヤスピードについて ☆☆☆
過去問対策2(iTAC テクニカルエンジニア(ネットワーク)塾 Sコース 10回目 講義ノート)
で補習
☆☆☆ 【補習3】tracertのしくみについて ☆☆☆
過去問演習1-TCP iTAC テクニカルエンジニア(ネットワーク)塾 Aコース 6回目 講義ノート)で補習
|