Ubuntu仮想マシンをGNS3シミュレーションネットワークに接続する方法

Ubuntu仮想マシンをGNS3シミュレーションネットワークに接続する方法

Ubuntu VMにインストールされている監視ソフトウェアを使用して、Ubuntu VMにもインストールされているGNS3でシミュレートされたネットワークを管理したいと思います。

私の仮想マシンのインターフェイスは次のとおりです。

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:01:73:bd:8e  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.221.143  netmask 255.255.255.0  broadcast 192.168.221.255
        inet6 fe80::5f6a:96d3:65b9:4fe0  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:96:7f:80  txqueuelen 1000  (Ethernet)
        RX packets 408  bytes 440051 (440.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 303  bytes 35261 (35.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 166  bytes 16050 (16.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 166  bytes 16050 (16.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:f8:73:7f  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

GNS3のネットワークには、次のトポロジを持つ2つのルータがあります。

ここに画像の説明を入力してください。

仮想ブリッジインターフェイスvirbr0:192.168.122.1を使用して、2つのルータR1とR2をVM Ubuntuに関連付けました。トポロジのクラウドは、Ubuntu VMホストへの接続を表します。

R1とR2でOSPFルーティングプロトコルを使用しています。

R1のルーティングテーブル:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.122.1 to network 0.0.0.0

C    192.168.122.0/24 is directly connected, GigabitEthernet0/0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O       10.0.0.2/32 [110/2] via 10.1.1.2, 00:11:04, GigabitEthernet1/0
C       10.1.1.0/24 is directly connected, GigabitEthernet1/0
C       10.0.0.1/32 is directly connected, Loopback0
S*   0.0.0.0/0 [1/0] via 192.168.122.1

R2ルーティングテーブル:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.1.1.1 to network 0.0.0.0

S    192.168.122.0/24 [1/0] via 10.1.1.1
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C       10.0.0.2/32 is directly connected, Loopback0
C       10.1.1.0/24 is directly connected, GigabitEthernet0/0
O       10.0.0.1/32 [110/2] via 10.1.1.1, 00:32:36, GigabitEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 10.1.1.1, 00:32:36, GigabitEthernet0/0

R1とR2の間の通信は正常です。たとえば、互いのループバックインターフェイスをpingできます。

R1はvirbr0インターフェイス192.168.122.1でPINGを行うことができます。 R2はR1のg0 / 0(IP 192.168.122.2)でPINGできますが、virbr0 IP 192.168.122.1ではPINGできません。

Ubuntu VMホストでは、パスは次のとおりです。

$ ip route
default via 192.168.221.2 dev ens33 proto dhcp metric 100 
169.254.0.0/16 dev ens33 scope link metric 1000 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 
192.168.221.0/24 dev ens33 proto kernel scope link src 192.168.221.143 metric 100

Ubuntu VMでR1とR2のループバックインターフェイスをpingできますが、出力インターフェイスを設定した場合にのみ可能です。

$ ping -I virbr0 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 192.168.122.1 virbr0: 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=254 time=50.6 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=254 time=29.2 ms

Ubuntu VMはルータR2(Lo:10.0.0.2)からPING要求を受信して​​いるように見えますが、PING応答を返すために使用するインターフェイスを知りません。

また、Ubuntu VMのPINGリクエストにも同じ問題があります。 PING要求に使用されるインターフェースを表示する必要があります。

virbr0を介して静的パスを追加できます。

IP route add 10.0.0.0/24 via 192.168.122.1 dev virbr0

ただし、これは特定のネットワークでのみ機能するソリューションであり、IP割り当てが他の一般的なシナリオでは機能しません。さらに、この特定のネットワークでこのソリューションを使用すると、ソースIP 10.0.0.2を表すR2でPINGを実行する必要がありますが、これは望ましくありません。

VMがR1のインターフェイスg0/0に直接接続できるように、最高のUbuntu VMをGNS3ネットワークに統合したいと思います。

Ubuntu VMでOSPFルーティングプロトコルを使用することが可能で、VMとルーター間の通信の問題を解決できるかどうか疑問に思います。

答え1

あなたが言及したように、これは次のとおりです。

Ubuntu VMでR1とR2のループバックインターフェイスをpingできますが、出力インターフェイスを設定した場合にのみ可能です。

次の理由で本当です。

VM(VM)は、PING応答を返すために使用するインターフェイスを知りません。

仮想マシンには10.xxx IPへの特定のパスがないため、これらのパケットを「defaultデフォルトで192.168.221.2 dev ens33経由」ゲートウェイに送信します。

10.xxx へのパケットの送信先を知るには、仮想マシンにパスが必要です。これがすぐに次を追加すると、すべてが正しく機能する理由です。

IP route add 10.0.0.0/24 via 192.168.122.1 dev virbr0

10.0.0.0/16たとえば、前述の「特定のネットワーク」問題を克服するのに役立つ場合(そして10.xxxネットワーク全体が他の場所では使用されていないと仮定した場合)、このパスに「より広い」範囲を追加することもできます。

手動でパスを追加するのを防ぐために、2つの考えられる解決策を考えてみましょう。 (どちらも行っていないので、詳細を提供することはできませんが、役に立つ場合は言及します。)

  • 前述のように、Linux VMでOSPFを有効にすることができます(Quaggaを使用することもできます)。これに関するいくつかの情報は次のとおりです。ここ

  • 有効なDHCPサービスに次のものを追加できますg0/0R1オプション(33または121)DHCPクライアントにパスを送信する(DHCPサーバーがこの機能を提供している場合)

関連情報