узел назначения, недостижимый к адресам локальной сети после 6 месяцев

У меня есть сервер LTS Ubuntu 14, который работал в течение приблизительно 6 месяцев.

Сегодня я делал стандартную тонкую настройку к конфигурации сети, и все ушло в сторону. У меня есть 4 сетевых интерфейса VLAN, которые внезапно не направят трафик. Я ничего не могу проверить с помощью ping-запросов ни на одном из тех сетевых интерфейсов.

Я перезагружал сервер несколько раз и даже восстанавливал к резервному копированию с прошлой ночи, прежде чем я внес любые изменения, но ничто не получит их работа.

Сначала я думал, что проблема, возможно, была создана сетевыми инженерами центра обработки данных, но я добавил пару полей Windows к одному из VLAN, и они связываются друг между другом прекрасным, но не могут проверить с помощью ping-запросов freeswitch на VLAN. UFW отключен.

У меня есть eth0, который имеет два IP-адреса и который продолжает хорошо работать:

auto eth0
iface eth0 inet static
address 192.168.1.13
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.12 192.168.1.11 10.1.0.10
hwaddress ether 00:50:56:b1:23:b0

auto eth0:0
iface eth0:0 inet static
address 192.168.1.14
netmask 255.255.255.0

У меня есть 3 VLAN, которые являются схемами точка-точка, входящими в специализированных интерфейсах (я запутал общедоступные IP-адреса):

auto eth2
iface eth2 inet static
address 10.2.0.12
netmask 255.255.255.0
hwaddress ether 00:50:56:b1:71:7a
post-up route add -net 192.168.211.32 netmask 255.255.255.224 gw 10.2.0.1

auto eth3
iface eth3 inet static
address 10.3.0.13
netmask 255.255.255.0
hwaddress ether 00:50:56:b1:1c:cd
post-up route add -net 192.168.211.64 netmask 255.255.255.224 gw 10.3.0.1

auto eth4
iface eth4 inet static
address 144.?.?.206
netmask 255.255.255.252
hwaddress ether 00:50:56:b1:3d:10
post-up route add -net 199.?.?.67 netmask 255.255.255.255 gw 144.?.?.205

Существует 4-й VLAN, который является тем, который мы пытались поднять сегодня, я удалил "пост, маршрут добавляет", потому что, когда я пытался добавить его, именно тогда вещи ушли в сторону:

auto eth1
iface eth1 inet static
address 10.100.0.11
netmask 255.255.255.0
hwaddress ether 00:50:56:b1:82:59

Вот таблица маршрутизации (я запутал общедоступный IP-адрес):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.2.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth2
10.3.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth3
144.?.?.204     0.0.0.0         255.255.255.252 U     0      0        0 eth4
172.16.43.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.211.32  10.2.0.1        255.255.255.224 UG    0      0        0 eth2
192.168.211.64  10.3.0.1        255.255.255.224 UG    0      0        0 eth3
199.?.?.67      144.?.?.205     255.255.255.255 UGH   0      0        0 eth4

eth3 (10.3.0.13) работал самое длинное. Я добавил два компьютера Windows к тому VLAN для поиска и устранения неисправностей целей как 10.3.0.99 и 10.3.0.98, и они могут проверить с помощью ping-запросов друг друга, но ни один не может проверить с помощью ping-запросов 10.3.0.13, и сервер человечности просто получает это при попытке проверить с помощью ping-запросов одного из них:

itas@FreeSWITCH2:~$ ping 10.3.0.99
PING 10.3.0.99 (10.3.0.99) 56(84) bytes of data.
From 10.3.0.13 icmp_seq=1 Destination Host Unreachable
From 10.3.0.13 icmp_seq=2 Destination Host Unreachable
From 10.3.0.13 icmp_seq=3 Destination Host Unreachable

На основе того вывода ping это, кажется, выбирает правильный интерфейс, потому что 10.3.0.13 IP в том интерфейсе, однако "sudo tcpdump-i eth3" никогда не показывает, что единственный пакет в или и "sudo tcpdump-i любой icmp" показывает это:

20:10:52.378575 IP 10.3.0.13 > 10.3.0.13: ICMP host 10.3.0.99 unreachable, length 92

Это похоже на icmp отклонение, никогда не касается "провода" (это - среда VMware). Wireshark на полях окон никогда не видит icmp эхо-запросы, и я настроил VMware для разрешения неразборчивый. Одно из полей Windows находится на том же хосте и другом тесте, каждый находится на другом хосте.

От всего я читал, это похоже на него, должна быть проблема с таблицей маршрутизации, но я, может казаться, не нахожу проблему с таблицей маршрутизации, и я, может казаться, не убеждаю это поле отсылать пакет на eth3 или любом из интерфейсов VLAN.

Я в полной растерянности относительно что случилось со всеми этими сетевыми интерфейсами.