Доброго времени, возникла странная проблема с сетью в виртуалках на базе KVM:
Долгое время всё работало без проблем, при этом сегодня никаких изменений ни на гипервизоре, ни в машинах не производилось.
Суть в том, что у 4 из 32-х аналогичных машин (ОС, настройки и т.д. всё аналогично), отпала сеть, при этом в таблице arp на гипервизоре маки у них сбросились на 00:07:b4:00:00:01 и 00:07:b4:00:00:02 (01 - это мак шлюза, куда всё уходит с гипервизора), а внутри самих машин таблица arp стала вообще пустой.Перезапуск интерфейса или виртуалки целиком не помогает, после старта всё равно на гипервизоре в arp почему то попадает мак шлюза, а не виртуалки.
Единственный способ поднять сеть, это через vnc из машины сделать какое-то исходящее соединение, при этом сеть начинает работать в обоих направлениях, а arp и в машине и на гипервизоре появляется правильный mac.
Куда копать?
[...]
> Единственный способ поднять сеть, это через vnc из машины сделать какое-то исходящее
> соединение, при этом сеть начинает работать в обоих направлениях, а arp
> и в машине и на гипервизоре появляется правильный mac.
> Куда копать?Похожая фигня с LXC (Docker) + pipework на ядре 3.14. Причём сеть подымается не сразу, а секунд через 90.
tcpdump показывает, что трафик с bridge наружу уходит без проблем, а внутрь попадает всё, кроме ответа от хоста, который ищешь. Причём если в сети проскочил чужой ARP запрос о том же хосте, то ARP ответ чужому проскакивает внутрь контейнера и всё мгновенно заводится.
Полез копать настройки ip, касающиеся bridging, но зарылся в старой документации.
Сегодня прошло сообщение про nftables 0.4 со ссылками на функционал ядер 3.18 и 3.19, возможно, там всё более ровно.
Кто-нибудь справился с этим?
Не совсем вникал в суть ваших проблем, просто расскажу что за проблема была у меня.Сеть примерно такая:
тырнет - роутер провайдера - коммутатор провайдера - сервер (сеть к ВМ через бриджи ) - виртуальная машина.
На роутере провайдера был статически забит мак-адрес, соответствующий IP VM.
При отсутствии трафика через некоторое время коммутатор терял привязку мак-адрес - физический порт.
Поступающие после этого извне пакеты к ВМ маршрутизировались роутером и тупо отправлялись в сторону коммутатора, без посылки ARP-запросов.
Коммутатор тупил и никуда не отправлял эти пакеты, т.к. привязки мак-порт не было.После получения пакета от ВМ, коммутатор заносил привязку в свою таблицу и всё запускалось.
Т.к. ВМ была абсолютно простаивающая, то лечилось костылем в виде "один ICMP раз в минуту" по крону.
Хотя, может и не в провайдерском коммутаторе дело было, а в linux-bridge, не помню точно, но вроде смотрел tcdpump и видел картинку именно так, как описал выше.
В общем причины так и не нашел, прописал arp статически и в стартовые скрипты tap'ов тоже добавил прописывание статически, проблема исчезла.А на днях попробовал сбросить, чтобы таблица опять создавалась динамически, и проблем больше нет, всё как раньше.
Наверное и правда что-то на шлюзе у провайдера было, не с проста же в arp для IP машинок попадал мак шлюза.