Архів мітки: ethernet

Міграція гостьових Debian у VirtualBox та проблеми з мережею NAT

Нещодавно я скопіював усі свої гостьові операційні системи з одного комп’ютера на інший. Через OVL формат – це тривіальні задача. Хоча, якщо назви у віртуальних машин однакові (а саме назви файлів для дисків), то це не виходить зробити за один раз. Доводиться кожну таку машину окремо.

Так от, всі машини запустились без проблем, а старенька Debian 4.0 – ні. Точніше вона начебто працювала нормально, але без мережевого інтерфейсу eth0:

$ /sbin/ifconfig
lo        Link encap:Local Loopback  
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:8 errors:0 dropped:0 overruns:0 frame:0
 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0 
 RX bytes:560 (560.0 b)  TX bytes:560 (560.0 b)

Спроба запустити його вручну закінчилась нічим:

# ifup eth0
Internet Systems Consortium DHCP Client V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device
Bind socket to interface: No such device
Failed to bring up eth0.

Файл /etc/network/interfaces післе переносу не редагувався і містив стандартні рядки:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

Трохи погугливши вияснив, що проблема в udev. А ще точніше – у файлі /etc/udev/rules.d/z25_persistent-net.rules. На різних версіях Debian-оподібних операційних систем він може мати інші префікси, але persistent-net.rules буде присутнє. Файл мав такий зміст:

# This file was automatically generated by the
# /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules
# file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.

# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="08:00:27:a5:c0:ff",
 NAME="eth0"

# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="08:00:27:97:b2:6b",
 NAME="eth1"

Як я зрозумів, при міграції гостьової Debian, було змінено MAC адресу мережевого адаптеру. І система udev чомусь подумала, що це новий адаптер. Мені залишилось лише видалити інформацію про eth0 (перший рядок) та змінити в другому eth1 на eth0:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="08:00:27:97:b2:6b",
 NAME="eth0"

Після перезапуску віртуальної машини – мережа піднялась автоматично.

Ping та завантаженість каналу мережі

Коли локальна мережа та підключення до інтернету поєднані через некеровані комутатори (свічі), то досить важко визначити на якому саме напрямку проблеми.

Корисна утиліта ping дає, на перший погляд, тільки приблизну оцінку того, як саме пакети йдуть мережею і який відсоток втрат. Але якщо уважно придивитися до її виводу, то можна побачити одну характерну ознаку, яка може свідчити про проблеми у пропускній здатності каналу чи мережевої карти: істотне коливання часу відповіді echo reply на запит echo request.

Поясню на прикладі:

$ ping 192.168.0.26
PING 192.168.0.26 (192.168.0.26) from 192.168.0.22 : 56(84) bytes
 of data.
64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=0.890 ms
64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=0.503 ms
64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=0.485 ms
64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=0.492 ms
64 bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=0.495 ms
64 bytes from 192.168.0.26: icmp_seq=6 ttl=64 time=0.502 ms
64 bytes from 192.168.0.26: icmp_seq=7 ttl=64 time=0.476 ms
64 bytes from 192.168.0.26: icmp_seq=8 ttl=64 time=0.490 ms
64 bytes from 192.168.0.26: icmp_seq=9 ttl=64 time=0.499 ms
64 bytes from 192.168.0.26: icmp_seq=10 ttl=64 time=0.492 ms
64 bytes from 192.168.0.26: icmp_seq=11 ttl=64 time=0.496 ms
64 bytes from 192.168.0.26: icmp_seq=12 ttl=64 time=0.476 ms
64 bytes from 192.168.0.26: icmp_seq=13 ttl=64 time=0.487 ms
64 bytes from 192.168.0.26: icmp_seq=14 ttl=64 time=0.487 ms
64 bytes from 192.168.0.26: icmp_seq=15 ttl=64 time=0.480 ms
64 bytes from 192.168.0.26: icmp_seq=16 ttl=64 time=0.500 ms
64 bytes from 192.168.0.26: icmp_seq=17 ttl=64 time=0.485 ms
64 bytes from 192.168.0.26: icmp_seq=18 ttl=64 time=0.477 ms

--- 192.168.0.26 ping statistics ---
18 packets transmitted, 18 received, 0% loss, time 17017ms
rtt min/avg/max/mdev = 0.476/0.511/0.890/0.096 ms

Тут все гаразд, відхилення звичайно є, але в середньому (0.096 ms) вони не істотні. І зовсім інша картина у наступному прикладі:

$ ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10) from 192.168.10.1 : 56(84) bytes
 of data.
64 bytes from 192.168.10.10: icmp_seq=1 ttl=128 time=4.41 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=128 time=0.730 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=128 time=0.804 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=128 time=0.724 ms
64 bytes from 192.168.10.10: icmp_seq=5 ttl=128 time=0.740 ms
64 bytes from 192.168.10.10: icmp_seq=6 ttl=128 time=0.734 ms
64 bytes from 192.168.10.10: icmp_seq=7 ttl=128 time=3.03 ms
64 bytes from 192.168.10.10: icmp_seq=8 ttl=128 time=2.61 ms
64 bytes from 192.168.10.10: icmp_seq=9 ttl=128 time=0.730 ms
64 bytes from 192.168.10.10: icmp_seq=10 ttl=128 time=0.746 ms
64 bytes from 192.168.10.10: icmp_seq=11 ttl=128 time=0.720 ms
64 bytes from 192.168.10.10: icmp_seq=12 ttl=128 time=0.721 ms
64 bytes from 192.168.10.10: icmp_seq=13 ttl=128 time=0.911 ms
64 bytes from 192.168.10.10: icmp_seq=14 ttl=128 time=0.741 ms
64 bytes from 192.168.10.10: icmp_seq=15 ttl=128 time=0.754 ms
64 bytes from 192.168.10.10: icmp_seq=16 ttl=128 time=2.54 ms
64 bytes from 192.168.10.10: icmp_seq=17 ttl=128 time=0.731 ms
64 bytes from 192.168.10.10: icmp_seq=18 ttl=128 time=2.04 ms
64 bytes from 192.168.10.10: icmp_seq=19 ttl=128 time=0.739 ms
64 bytes from 192.168.10.10: icmp_seq=20 ttl=128 time=0.730 ms
64 bytes from 192.168.10.10: icmp_seq=21 ttl=128 time=0.728 ms

--- 192.168.10.10 ping statistics ---
21 packets transmitted, 21 received, 0% loss, time 20205ms
rtt min/avg/max/mdev = 0.720/1.268/4.419/1.011 ms

На час першого відгуку (4.41 ms) не звертаємо увагу, але я спеціально позначив аномальний час 7, 8, 16 та 18 запитів. Це саме ті моменти, коли час відповіді істотно відрізняється. В обох прикладах відсоток втрати пакетів нульовий, але у другому можна стверджувати, що мережевий канал чи пристрій істотно завантажені.