4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue

    link/ether 00:0c:29:89:80:c2 brd ff:ff:ff:ff:ff:ff

# brctl show

bridge name     bridge id               STP enabled     interfaces

eth0            8000.000c298980c2       no              hweth0

# ping -c 1 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=29.9 ms

--- 192.168.0.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 29.959/29.959/29.959/0.000 ms

Разберем описанное в протоколе. Во-первых, в точке, выделенной ремаркой, произошел автоматический перевод физического интерфейса в режим прослушивания. Эмулятор это «поймал» и выдал запрос оператору (см. рис. 2).

Рисунок 2. Запрос на перевод интерфейса в режим прослушивания

Во-вторых, несмотря на предупреждение о невозможности данной операции, тем не менее все работает, как следовало. Из чего можно сделать вывод, что реальный интерфейс компьютера, в котором запущен эмулятор VMWare, и так уже работает в состоянии promiscuous (кстати, это не отображается системными флагами), что подтверждает тезис о неизбежности перехода к виртуализованным сетевым интерфейсам в перспективе. В-третьих, сетевой мост получает канальный адрес, такой же как адрес первого присоединенного интерфейса. Ну и, наконец, трафик – пошел! Обратите внимание на задержки. Они велики. Но это лишь следствие инерционности работы сетевого моста. И немного спустя все приходит в норму. Например, так выглядит «пингование» с удаленного хоста спустя некоторое время:

server:~ # ping -c 1 192.168.0.111

PING 192.168.0.111 (192.168.0.111) 56(84) bytes of data.

64 bytes from 192.168.0.111: icmp_seq=1 ttl=64 time=0.498 ms