Juniper

[Proxy]

Доброго времени суток.

Попросили помочь разобраться с проблемами в одной сети.

Топология не сильно сложная: несколько сетей (отдельная для IP телефонии, отдельная для ПЭВМ, отдельная для ещё кое-каких устройств), один маршрутизатор (Juniper EX3300). Маршрутизатор направляет пакеты в указанные сети, маршрут по умолчанию на шлюз с доступом к WAN (для обновления софта и не только). Всем устройствам DHCP соответствующей сети сообщает шлюзом тот самый маршрутизатор.

Имеется потеря пакетов в любых направлениях, но при этом потеря пакетов довольно странная:
Отправляем пакеты узлу, с которым не взаимодействовали в течение n-го времени, первые 3-4 пакета стабильно теряются, затем остальные стабильно доходят. Но стоит только в течение n-го времени (скажем 10 минут) снова ничего не отправить — всё заново.
Повторяется стабильно.

Касается и узлов WAN (ping ya.ru с любого узла любой сети не обнаружит ответы на первые 3-4 запроса, например, затем 100% последующих запросов завершатся успешно).

Нагрузка на всех интерфейсах минимальная. Использование памяти: 15-30%, ЦП: 0.23%
Конфигурация Juniper-а примитивная: несколько записей в таблице маршрутизации, никаких QOS, ничего необычного.

Выявить проблему сильно мешает использование всего этого добра в режиме 24/7 (нельзя допустить, чтобы АТС потеряла доступ к WAN, например).

Может быть это что-то сильно простое и банальное? Переполнение какого-нибудь кэша?

[alibek]

Простое и банальное — логические петли.

[Proxy]

Простое и банальное — логические петли.

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

Притом удалось раздобыть у поставщика ещё один маршрутизатор аналогичный, его уже я настраивал (по-сути и не ориентировался на настройки первого). Пока не удалось толком потестировать (нельзя просто так положить связь, когда она используется, специфика), но на импровизированной копии сети похоже работало нормально. Позже будет ясно.

[alibek]

Было такое подозрение — не удалось найти где бы получилась петля.

С петлями такое бывает. Иногда они получаются в самых банальных и простых, казалось бы, топологиях.
Трассировка выполнялась?

[Proxy]

Трассировка тоже странная (аналогично n-пакетов от узла после маршрутизатора теряются).
Но маршрут верный.

[alibek]

Трассировка между внутренними сетевыми узлами.

[Proxy]

Там аналогичная картина, как и с WAN.
Скажем, если из сети с ПЭВМ трассировать устройство из сети IP телефонами -- так же сначала 100% потеря пакетов, затем, начиная с какого-то там, все пакеты проходят. Ну и само-собой если повторить трассировку не дожидаясь нового сбоя -- будет всё норм. Сама же трассировка ничего интересного не выявляет, маршрут всегда один единственный, там иначе никак.

[Proxy]

Итак:
Роутер более новый (тоже EX3300-24P, но ПО JUNOS Base OS boot [12.3R3.4])

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

[Proxy]

Одновременно разные узлы из WAN:

[Proxy]

Небольшое открытие:
а) После замены маршрутизатора проблема осталась только с интернет шлюзом. Между узлами из разных сетей, связанных маршрутизатором, пакеты идут, проблем нет.
б) Если на шлюзе авторизацию по IP+MAC изменить на авторизацию по IP, то пакеты опять таки идут стабильно.

NAT на Juniper-е не вклюен, сам-по-себе Juniper доступа к глобальной сети не имеет с учётными данными собственного IP+MAC (т.е. даже если бы по какой-то причине он в некоторых случаях подменял бы IP источника на собственный — всё равно пакеты к узлам WAN не пошли бы, а они идут).

Если из способа авторизации не убрать mac, то в журнале интернет шлюза есть куча предупреждений "зафиксированы нарушения плитики авторизации". Похоже по времени совпадают с потерями (пока только предполагаю).

Однако этот шлюз не пишет в журнал подробности (что именно не понравилось, с какого mac и ip произведена попытка доступа и т.д).
Ради чистоты эксперимента АВП отключена (и шлюзовой а/в фильтр и станционный антивирус), межсетевой экран разрешает всё всем.

UPD. Пока совершенно не ясно, каким образом проверка mac влияет на потерю пакетов, однако проверил на большом количестве узлов — везде аналогичная картина. Только без проверки физического адреса работает.
Предполагаю, что не внутренний роутер виноват, а интернет шлюз, который скорее-всего имеет какие-то проблемы с ARP. Но опять же не ясно, почему без внутреннего роутера (Juniper) всё работает стабильно (если машине из той же сети, что и внешний шлюз, шлюзом прописать непосредственно его адрес, а не адрес внутреннего роутера).

UPD2. Может проблема в следующем: интернет шлюз необоснованно часто шлёт ARP запросы (даже если клиент ещё активен, либо таймаут активности низкий, а кэш ARP шлюз не использует). Если есть какая-то проблема с широковещательными пакетами (хотя с чего бы тут роутер был бы причастен, если проблемы и с узлами в одной сети со шлюзом? ), то интернет шлюз не может сопоставить IP-MAC и сбрасывает все пакеты от данного узла.