После обновления до Ubuntu 16.04 с 14.04 я не могу пинговать шлюз, сначала интерфейс eth0 не запускался, и я прочитал, что обновление нового MAC-адреса исправит это, поэтому я решил удалить сетевой интерфейс из виртуальной машины и добавил новый one, то оказалось, что для запуска интерфейса eth0 нужно было переименовать во что-то другое (ens ###), как показано в "ifconfig -a". Но теперь не могу пинговать шлюз, с маршрутами все в порядке.
root@Hostname:~# arp -a
? (192.168.1.1) at <incomplete> on ens192
? (192.168.1.82) at 00:5:56:ab:bb:cc [ether] on ens192
Мог ли старый MAC-адрес где-то застрять? Или почему написано «неполное»? когда я пингую шлюз, его пункт назначения недоступен, он работал нормально до обновления.
Вы можете увидеть, как он запрашивает MAC-адрес шлюза в tcpdump
Обновление: решено
Хорошо, разобрался, похоже, когда я добавил сетевой адаптер, я выбрал vmxnet3, но старый адаптер был E1000. Я просто снова удалил интерфейс, добавил адаптер E1000, снова переименовал имя интерфейса в файле / etc / network / interface и перезапустил. Теперь он работает нормально. Спасибо Даниэле, еще раз проверил гиперсивсор и вм помог
Небольшое резюме
Недавно Ubuntu приняла systemd, которая обрабатывает имена сетевых интерфейсов при загрузке системы. Именование будет связано с чем-то физический в аппаратном обеспечении (например, в слот, в который вставлена карта), поэтому вы можете добавлять / удалять / заменять сетевое оборудование, и имена не меняются внезапно (как это было раньше, с ethX схема).
Теперь вы выполнили обновление, и сетевой интерфейс был переименован, поэтому ваша конфигурация в /etc/network/interfaces нужно было исправить. Но, запутавшись, вы сначала попытались удалить виртуальную сетевую карту, а затем добавили новую. Это дало вам другой MAC-адрес И не решило вашу проблему с подключением. Затем вы поняли, что произошло переименование, вы исправили конфигурацию, и связь снова была восстановлена.
Проблема (предстоит решить):
Теперь ваша виртуальная машина может разговаривать с другой машиной (192.168.1.82) в той же локальной сети, но больше не может разговаривать со шлюзом.
Тот факт, что виртуальная машина не может получить arp reply от шлюза означает, что они не могут даже общаться на уровне Ethernet.
Возможные причины (необходимо проверить):
iptables или что-то, что добавляет правила iptables, вероятно, на гипервизоре, а не на самой виртуальной машине), применяемые к сетевому адаптеру шлюза или сетевому адаптеру виртуальной машины, что может разрешить трафик со старым MAC-адресом, но не с новым.