https://www.opennet.ru/openforum/vsluhforumID1/95898.html Доброго времени, возникла странная проблема с сетью в виртуалках на базе KVM:<br>Долгое время всё работало без проблем, при этом сегодня никаких изменений ни на гипервизоре, ни в машинах не производилось.<br>Суть в том, что у 4 из 32-х аналогичных машин (ОС, настройки и т.д. всё аналогично), отпала сеть, при этом в таблице arp на гипервизоре маки у них сбросились на 00:07:b4:00:00:01 и 00:07:b4:00:00:02 (01 - это мак шлюза, куда всё уходит с гипервизора), а внутри самих машин таблица arp стала вообще пустой.<br><br>Перезапуск интерфейса или виртуалки целиком не помогает, после старта всё равно на гипервизоре в arp почему то попадает мак шлюза, а не виртуалки.<br><br>Единственный способ поднять сеть, это через vnc из машины сделать какое-то исходящее соединение, при этом сеть начинает работать в обоих направлениях, а arp и в машине и на гипервизоре появляется правильный mac.<br><br>Куда копать?<br> https://www.opennet.ru/openforum/vsluhforumID1/95898.html#3 Sun, 21 Dec 2014 04:38:25 GMT В общем причины так и не нашел, прописал arp статически и в стартовые скрипты tap'ов тоже добавил прописывание статически, проблема исчезла.<br><br>А на днях попробовал сбросить, чтобы таблица опять создавалась динамически, и проблем больше нет, всё как раньше.<br><br>Наверное и правда что-то на шлюзе у провайдера было, не с проста же в arp для IP машинок попадал мак шлюза.<br> https://www.opennet.ru/openforum/vsluhforumID1/95898.html#2 Wed, 17 Dec 2014 06:17:18 GMT <br>Не совсем вникал в суть ваших проблем, просто расскажу что за проблема была у меня.<br><br>Сеть примерно такая:<br><br>тырнет - роутер провайдера - коммутатор провайдера - сервер (сеть к ВМ через бриджи ) - виртуальная машина.<br><br><br>На роутере провайдера был статически забит мак-адрес, соответствующий IP VM.<br>При отсутствии трафика через некоторое время коммутатор терял привязку мак-адрес - физический порт.<br>Поступающие после этого извне пакеты к ВМ маршрутизировались роутером и тупо отправлялись в сторону коммутатора, без посылки ARP-запросов. <br>Коммутатор тупил и никуда не отправлял эти пакеты, т.к. привязки мак-порт не было.<br><br>После получения пакета от ВМ, коммутатор заносил привязку в свою таблицу и всё запускалось.<br>Т.к. ВМ была абсолютно простаивающая, то лечилось костылем в виде "один ICMP раз в минуту" по крону.<br><br><br>Хотя, может и не в провайдерском коммутаторе дело было, а в linux-bridge, не помню точно, но вроде смотрел tcdpump и видел картинку именно так, как описал выше.<br> https://www.opennet.ru/openforum/vsluhforumID1/95898.html#1 Tue, 16 Dec 2014 21:48:18 GMT [...]<br>&gt; Единственный способ поднять сеть, это через vnc из машины сделать какое-то исходящее <br>&gt; соединение, при этом сеть начинает работать в обоих направлениях, а arp <br>&gt; и в машине и на гипервизоре появляется правильный mac.<br>&gt; Куда копать?<br><br>Похожая фигня с LXC (Docker) + pipework на ядре 3.14. Причём сеть подымается не сразу, а секунд через 90.<br><br>tcpdump показывает, что трафик с bridge наружу уходит без проблем, а внутрь попадает всё, кроме ответа от хоста, который ищешь. Причём если в сети проскочил чужой ARP запрос о том же хосте, то ARP ответ чужому проскакивает внутрь контейнера и всё мгновенно заводится.<br><br>Полез копать настройки ip, касающиеся bridging, но зарылся в старой документации.<br><br>Сегодня прошло сообщение про nftables 0.4 со ссылками на функционал ядер 3.18 и 3.19, возможно, там всё более ровно.<br><br>Кто-нибудь справился с этим?<br>