Странный ping

мб, что-то с ARP?

А вы достаточно ждали, перед тем как поставить диагноз что не пингуется? Просто если в таблице свича нет мака с портом, то при попытке обратиться к этому хосту может быть задержка, пока свич выясняет на каком порту у него сидит этот мак.

И да, это все если оба хоста в одном бродкаст домене. Иначе тут может быть трабл на L3.

А как устроена сеть? По пути от А до Б: Железные свитчи, виртуальные сущности (мосты в линуксе, например) и так далее. Как это всё настроено? Есть ли файрволлы (на основе iptables или чего-то ещё).

Есть ли другие машины в похожих сетевых условиях? На них всё работает как ожидается или нет?

У меня внезапно скрипт ansible перестал отрабатывать, выяснилось что пинга нет, и если пингануть вручную в обратную сторону, то скрипт отрабатывает, но зачем мне такая автоматизация? А ждать больше 5 минут смысла все равно нет, я считаю. Про таблицу и логику свича при отсутствующем маке - спасибо, буду знать.

Не, задержка там не 5 мин конечно)) максимум 0,5-1 сек

Как устроена сеть я уже не скажу - у нас реорганизация и сейчас сетевая инфраструктура приводится к стандартам головной организации. Местный админ по факту эникейщик и знает еще меньше чем я. Буду выходить на новых админов тогда и с ними разбираться.

у нас реорганизация и сейчас сетевая инфраструктура приводится к стандартам головной организации

Тогда ещё один вопрос: когда именно появилась проблема? То есть, вы принесли две новые машины (А и Б), впервые подключили их к сети и тут же поняли, что сеть работает неправильно? Или же эти две машины стоят уже давно, но раньше на них проблема не наблюдалась?

Одна машина реальная железка, вторая - виртуалка, создаваемая скриптом ansible. Скрипт пересоздает инфраструктуру местную и запускается редко. Раньше отрабатывал без проблем, а сегодня вот перестал.

А доступ к хосту с виртуалками есть? Известно как виртуалки там попадают в реальную сеть? Обычный мост или что-то хитрое?

была похожая тема. но, там у человека kaspersky * систему «от сети защищал». в вашем случае фильтров/фаерволов нет же?

Доступ к хосту с виртуалками есть. В сеть попадают через обычный мост.

Не, касперского слава богу нет. Я искренне не понимаю смысл в антивирусах для линукса.

Можете подсказать куда копать?

В изучение вывода tcpdump (или wireshark, без разницы). И смотреть, что улетело, куда долетело (и с MAC-адресами). То есть, на обоих хостах запустить и наблюдать. А дальше вывод сам собой получится.

Ещё свич управляемый помогает. Особенно если графики отрисовываются по трафику на портах. Можно создать поток посредством ping -f и тоже посмотреть, что куда полетело.

пока свич выясняет на каком порту у него сидит этот мак

И как же по-вашему это происходит?

Внезапно, как понос… если нет в табличке мака, то бродкастит на все порты. Учись щегол)

И как же это повлияет на задержку?

Ключевые слова: Таблица mac + поиск. Ты щегол сообразительный как я погляжу. Поэтому догадаешься сам.

Быстровато ты слился...

В каком смысле? Тебя что то не устроило?

Да. Я рассчитывал поразвлекаться подольше. «О сколько нам открытий чудных...» вот это вот всё.

Это понятно, а по делу то есть что сказать?

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

(Это потенциально более забавно, чем ковырять тему «выяснения» путём такой рассылки.)

Может тебе лучше орнитологией заняться?

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

Вполне по делу я намекнул тебе в каком направлении нужно самому подумать. Но ты почему то думать не захотел.

Может тебе лучше орнитологией заняться?

Давай твой внутренний шаблонный господин пафос не будет вещать кому и чем заниматься.

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

Попытка не засчитана)) не внушает, выглядит по детски и опять же пафос течет по экрану.

Копайте в сторону заполнения таблиц маршрутизации вцелом и особенностей протоколов маршутизации в частности. Возможно еще в сторону ARP протокола.

Копайте в сторону

Какие по-вашему проблемы «заполнения таблиц маршрутизации вцелом и особенности протоколов маршрутизации в частности» будут проявлять себя так, как описано ТСом?

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

Пересоздаваемая виртуалка — машина А?

Виртуалка это машина Б.

Я запускаю сценарий ansible на своем рабочем месте (машина А). Он на сервере создает виртуалку (машина Б) и потом не может на нее зайти чтобы продолжить выполнение. Я могу зайти на сервер отдельной ssh сессией, оттуда зайти на эту виртуалку и пингануть свое рабочее место, после этого сценарий ansible продолжает выполнение. Единственно, что я не упомянул, мое рабочее место в другой подсети, чем сервера и виртуалки. У АРМ - 10.xxx.2.xxx, у серверов и ВМ - 10.xxx.1.xxx, если это важно. У меня маска 10.ххх.2.ххх/24, на виртуалке 10.xxx.1.xxx/23. Но раньше ведь работало с этими же настройками, значит причина в чем-то другом.

Виртуалка это машина Б.

А вот тут тогда вопрос. Хост-система должна как-то обеспечить либо проброс ARP-таблицы из виртуалки, либо добавить статическую запись для виртуалки в свою таблицу ARP. Или что-то около этого. В зависимости от способа проброса канала до виртуалки, конечно - вдруг там у тебя физический интерфейс пробрасывается, как есть, или vlan там.

.1/23 и .2/24 не пересекаются, да и вообще, если бы были проблемы с IP, то после пинга ничего бы не «чинилось».

Виртуалка Б поднимается клонированием и прибивается (каждый раз поднимается одинаковая) или поднимается/прибивается как есть (в следующий раз поднимается то, что прибили)?
Воспроизводится ли проблема сейчас, если прибить/поднять виртуалку?

ВМ поднимается клонированием и прибивается. В следующий раз создается точно такая же. Хмм, вручную воспроизвел шаги только что, все работает как раньше, проблема не воспроизводится. Даже не знаю что и делать.

А вот это уже смахивает на «неудачное стечение обстоятельств».
Есть уверенность, что именно в тот момент, когда А не пинговало Б на самом деле сеть была в порядке? И запинговалось от Б к А и обратно, потому что сеть починили? =)

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

Отлично, отлично... я считаю...

Какой протокол маршрутизации заполняет таблицы узлов при прохождении какого-либо сетевого пакета?

Или вот ещё...
Описываемая ситуация также наблюдалась бы, если хост/гипервизор почему-то считал, что MAC, с которым поднялась виртуалка Б находится где-то ещё, а виртуалка Б не пыталась вообще ничего отправить в сеть.

А нет ли в хозяйстве других виртуалок (не запускаемых одновременно с Б) использующих такой же IP как у виртуалки Б?

Думаю, воспроизвести можно попробовать так:
- прибить виртуалку Б
- поднять виртуалку Ц с таким же IP, но другим MAC-ом
- пингануть с виртуалки Ц default gateway
- прибить виртуалку Ц, поднять виртуалку Б

Или вот ещё...

Вполне возможно, что виртуалка перезапускается со случайным MAC — обычное дело, а на хосте-мониторилки надо ждать очистки либо руками кеша arp. Я так понял, что у ТСа почему-то оно всё время перезапускается, не?

Чистить кэш возможно надо на роутере. Но хотелось бы верить, что ВМка или ейный хост умеют gratuitous ARP.

Чистить кэш возможно надо на роутере.

Ну да, как частность.

Но хотелось бы верить, что ВМка или ейный хост умеют gratuitous ARP.

Надо бы дождаться ответа ТСа, а то получается уже мистика. Ведь если две вируалки с одним ARP, то это бы при возвратном пинге спасало бы не на долго.

Уверенность есть, такая ситуация также повторялась на другой машине, которую я редко использовал, поэтому не напрягало. А здесь ситуация возникла на активно используемой машине, поэтому пришлось озадачиться.

Есть другие ВМ с таким же IP, но не запускаемые одновременно. Сценарий ансибл работает так - запускает виртуалку с заранее заданным адресом, заходит на нее, настраивает ее в том числе меняя сетевые настройки после чего ее перезагружает, а сам запускает следующую виртуалку которая опять имеет тот же фиксированный адрес и т.д. Все виртуалки поднимаются с новым mac адресом. Попробую попозже поднять виртуалку Ц и посмотреть.

ipsec туннель?

оторая опять имеет тот же фиксированный адрес и т.д. Все виртуалки поднимаются с новым mac адресом.

Ну вот она скорее всего и причина. Одно дело, если с большими промежутками, когда записи MAC устаревают. Но если часто, то лучше уж привязать IP-MAC.

Вряд ли. Сценарий пересоздает инфраструктуру, поэтому запускается очень редко. Тем более что до этого работало.

поэтому запускается очень редко.

Имелось в виду, что мало времени проходит от остановки предыдущей и старта новой vm.

Так до следующей ВМ не доходит. Первая же ВМ уже не доступна.