MENU

GNS3やDynamips上の機器を物理・仮想ネットワークに接続する方法

DynamipsやGNS3上の機器を実際の物理ネットワークやVMware Network Adapterと接続する方法です。

 

今回はGNS3上のルータのインターフェースfa0/0と
Windowsの「ローカルエリア接続3」を対応付けます。

 

もう1つ、GNS3上のルータのインターフェースfa0/1と
Windowsの「VMware Network Adapter VMnet1」を対応付けます。

 

※「VMware Network Adapter VMnet1」は、VMWareのネットワーク設定の
「ホストオンリー」と関連性が有ります。

 

 

「VMware Network Adapter VMnet1」とは

VMWarePlayerをインストールすると自動的に作成される仮想
ネットワークアダプターです。
VMWarePlayerのネットワーク設定で、「ホストオンリー」を指定すると
VMWarePlayer上のゲストOSのネットワークアダプターと、
ホストOS(Windows)の「VMware Network Adapter VMnet1」が疎通可能になります。

 

まず、GNS3フォルダの「Network device list」を実行します。

 

以下のエラーの対処方法

Unable to create lock file “c7200_i0_lock”.
VM default: unable to create instance!
C7200: unable to create instance!

 

c7200_i0_lockファイルを作成できないということなので
「Network device list」を格納しているフォルダ、
ここでは「GNS3」の権限を緩くします。
今回はてっとり早くeveryone フルコントロールにしました。
再度「Network device list」を実行するとエラーが出ないはずです。
1度正しく「Network device list」を実行できれば権限を元に戻しておきます。

 

 

正しく実行されると以下のように表示されます。

NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}
Name : VMware Network Adapter VMnet1
Desciption: VMware Virtual Ethernet Adapter

 

NIO_gen_eth:\Device\NPF_{BBBBBBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}
Name : ローカル エリア接続3
Desciption: Realtek PCI GBE Family Controller

 

以下の行をコピーしておきます。

 

NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}
NIO_gen_eth:\Device\NPF_{BBBBBBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}

 

GNS3を起動し、新規プロジェクトを作成します。
その中でC7200を1つだけ作成し、スロット0に「C7200-IO-2FE」を入れました。
ホスト名を変更する等して、コンフィグを少しデフォルトから変更します。
「ネットワークファイルに保存」アイコンをクリックしてから終了します。

 

projectフォルダに作成されたnetファイルを編集します。
以下の2行を追加します。

 

f0/0 = NIO_gen_eth:\Device\NPF_{BBBBBBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}
f0/1 = NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}

 

autostart = False
[127.0.0.1:7200]
workingdir = connection_working
udp = 10000
[[7200]]
image = E:\soft\Cisco\Cisco IOS\c7200-advipservicesk9-mz.124-6.T.bin
ghostios = True
[[ROUTER R1]]
console = 2000
cnfg = connection_configs\R1.cfg
slot0 = C7200-IO-2FE
f0/0 = NIO_gen_eth:\Device\NPF_{BBBBBBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}
f0/1 = NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}
x = -91.0
y = -68.0
[GNS3-DATA]

configs = connection_configs
workdir = connection_working

 

netファイルを起動すると、以下のように雲が2つ出来ていると思います。

 

 

fa0/0を「ローカル エリア接続3」と同一LAN内アドレス、
fa0/1を「VMware Network Adapter VMnet1」と同一LAN内アドレスにします。

 

それぞれのインターフェースで各々へpingし、疎通できれば終了です。

 

その後、以下の構成だった物理NICについて、

●GFE(オンボード)

 

192.168.0.2

 

255.255.255.0

 

ローカルエリア接続

 

●FE(増設LANカード)

 

172.16.0.2

 

255.255.0.0

 

172.16.0.1(gw)

 

ローカルエリア接続3

 

 

 

●FE(増設LANカード)

 

192.168.0.2

 

255.255.255.0

 

ローカルエリア接続

 

 

●GFE(オンボード)

 

172.16.0.2

 

255.255.0.0

 

172.16.0.1(gw)

 

ローカルエリア接続3

へ変更したのですが、
netファイルについては再編集を行うこと無く疎通が可能でした。
「Network device list」の実行結果についても、以前と変化は
有りませんでした。しかしながら、やはり何度が再起動を繰り返して
いると疎通断が発生しました。なので再度「Network device list」を
実行すると、以前は以下のような感じだったのが

 

NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}
Name : VMware Network Adapter VMnet1
Desciption: VMware Virtual Ethernet Adapter

 

 

 

NIO_gen_eth:\Device\NPF_{BBBBBBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}
Name : ローカル エリア接続3
Desciption: Realtek PCI GBE Family Controller

 

 

今回は以下のようにNICの付け替えが反映された状態となっていました。

NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}
Name : VMware Network Adapter VMnet1
Desciption: VMware Virtual Ethernet Adapter

 

NIO_gen_eth:\Device\NPF_{CCCCCCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC}
Name : ローカル エリア接続3
Desciption: Realtek PCI GBE Family Controller

 

ですので、

 

NIO_gen_eth:\Device\NPF_{CCCCCCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC}
をコピーした後で、projectフォルダの該当ファイルnetファイルを編集し
以下のようにしました。

 

autostart = False
[127.0.0.1:7200]
workingdir = connection_working
udp = 10000
[[7200]]
image = E:\soft\Cisco\Cisco IOS\c7200-advipservicesk9-mz.124-6.T.bin
ghostios = True
[[ROUTER R1]]
console = 2000
cnfg = connection_configs\R1.cfg
slot0 = C7200-IO-2FE
f0/0 = NIO_gen_eth:\Device\NPF_{CCCCCCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC}
f0/1 = NIO_gen_eth:\Device\NPF_{AAAAAAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}
x = -91.0
y = -68.0
[GNS3-DATA]

configs = connection_configs
workdir = connection_working

 

その後にnetファイルを起動すると、新たな雲「C3」が出来ています。
まず「C1」の雲を削除し、「C3」の名前を「C1」にリネームして終了です。
172.16.0.1⇔172.16.0.3間の、疎通断も改善しました。

 

 

しかしながら、172.16.0.2⇔172.16.0.3間の疎通断は改善されなかったため
GNS上の「C1」=ローカルエリア接続3=オンボードGBE と、
「R1」=Cisco7200 fa0/0 間のパケットキャプチャを行ってみました。

 

172.16.0.3→172.16.0.2へのping時のパケットで、header checksumに
エラーが出ていたため、デバイスマネージャからオンボードGBEの詳細設定を開き
「IPv4チェックサムオフロード」の値を「受信と伝送有効」から「無効」へ変更し再起動しました。
※再起動を行わないと設定が反映されません。

 

その後は疎通可能に戻りました。
参考に以前問題無く使用していた増設ボードFEの詳細設定を確認してみたところ、
チェックサムオフロードを設定する項目自体が有りませんでした。
外部のWEBブラウザでhttpアクセスしても、問題なく
BHR-4RV → GNS上のCisco7200 → VMWare上のBIG-IP VE 
→ IISのWEBサーバー
まで到達し、index.htmlが表示できました。

 

 

・・・しかしながら応答まで2秒程度かかっていました。
なので再度WireSharkでパケットを見てみるとGETリクエストを3回再送
しているようでした。
そこで、再度デバイスマネージャからオンボードGBEの詳細設定を開き
「TCPチェックサムオフロード(IPv4)」の値を「受信と伝送有効」から「無効」へ
変更し再起動しました。
※今回の事象には関係無いですが、ついでに「UDPチェックサムオフロード
(IPv4)」も「受信と伝送有効」から「無効」へ変更しておきました。
その後はレスポンス良く返してくれるようになりました。

 

参照サイト
http://d.hatena.ne.jp/torutk/20070616/p1
http://blogs.yahoo.co.jp/motleycrue_megadeth/48832137.html