Здравствуйте! Конечно, виним провайдера в происходящем, но понимаем, что сами с устройством не до конца разобрались.

Есть dfl-860e, на нём 2 канала: 1 ppoe от Ростелеком, по нему приходит белый статический адрес (212.3.ххх.yyy) и ещё подсеть из 4 белых адресов (212.3.zzz.rrr/30), через первый адрес выпускаем наружу пользователей, делаем пробросы портов. Подсеть маршрутизируется в dmz: на нём прописан один из адресов, второй адрес прописан на устройстве. Устройство, соответственно, имеет белый ip, используя dmz порт как шлюз.
2 канал - статический адрес от Мегафона. Через него тоже выпускаем пользователей, делаем port forwarding.
Настроено резервирование этих каналов. Всё работает. До тех пор, пока Ростелеком не начинает какие-либо работы на своих узлах. dfl начинает терять пакеты на 1 канале. Т.е. бОльшую часть времени работает нормально. Пингуем любой из наших адресов, получаемых по ppoe, видим сначала нормальный ровный пинг, затем заметное удлинение пинга, а потом обрыв минуты на 2-3. Бывает больше, бывает меньше. И так в цикле с разными интервалами времени работы и "зависаний". 2 канал при этом вполне хорошо себя чувствует, ничего не теряет. Пользователей внутри сети перебрасывает на него во время зависаний, потом благополучно возвращает.

Примечательно, что до установки dfl стояли 2 сервера на windows с межсетевыми экранами ISA на борту. На винде "провалов" в ppoe не было. Ставим dfl вместо серверов - "зависания" на основном канале. Включаем провайдеров обратно в сервера - всё отлично.

Был опыт общения со шлюзом на ZeroShell (linux) в другом месте но на аналогичном ppoe Ростелеком. Похожее тоже наблюдалось. Периодически надолго пропадал пинг до головного офиса. VPN не поднимался. Втыкаем кабель провайдера в комп с виндой - всё шикарно работает. Решилось так: в головном офисе взяли Ростелеком в кач-ве ещё одного провайдера и сделали точку входа для VPN. В моём текущем случае это не подходит.

Были аналогичные проблемы с dfl-860е и ppoe Ростелекома с 1 белым адресов у знакомого в ещё одной фирме. Тоже "задумывался" время от времени. Т.е. день-два-неделю стоит, потом некоторое время "провалы" связи. Они трепали Ростелеком, Ростелеком "подкручивал" MTU, может, ещё что-то делал, проблема временно решалась. Но полностью решилась лишь когда они перешли на статический адрес от Ростелекома. Над таким решением мы тоже сейчас работаем, но РТК тупит и не хочет (не может, не знает, как) нам сделать всё наше добро статическим. Адреса менять не вариант. Техподдержку нашу съедят.

Какие есть ещё детали по текущему случаю. Соединений dfl держит порядка 10 тысяч (не заметили зависимости глюков от кол-ва соединений), процессор больше чем на 20% не забит. На ситуацию не повлияло лицензирование AV, WCF и Web Filtering. Что с лицензиями, антивирусом, IDP, что без них картина аналогичная. Отключение dmz, на котором висит доп. подсеть ничего не даёт.

Задались вопросом, почему же на windows всё работает, а на dfl глючит. Техподдержка РТК тоже радует фразами "поднимите шлюз на windows"
В чём же отличия? На windows дефолтный MTU для ppoe - 1480 (проверяли натурно методом пинга с флагом "запретить фрагментацию", меняя размеры пакетов) и есть алгоритм PMTU Discovery, на dfl-1492 и нет алгоритма "из коробки"... Пробовали уменьшать размер пакетов на ppoe интерфейсе dfl вплоть и до 1480 и вплоть до 1400. Ничего не дало.
Вообще понятно, почему работает решение со статическим ip. Там MTU=1500 байт. И на всех интерфейсах dfl он такой же. Проблема, видимо, заключается в периодическом превращении dfl в black hole.. Но это лишь версия.

Подскажите, пожалуйста, какие настройки "покрутить", какой MTU на каких интерфейсах прописать, чтобы не было потерь.

Извините, если утомил, спасибо заранее..

MTU явно не при чем. Оно не может вызывать сбои на 2-3 мин. И у Вас же пинг не только же на больших пакетах пропадает? Для стандартного пинга проблемы MTU вообще не бывает . Может у Вас падает PPPoE, а восстанавливается медленно? (посмотрите Interfaces/Ststus в момент сбоя). Винда, возможно, восстанавливает PPPoE быстрее или вообще не роняет. Также, возможно, у Вас неправильно настроен RFO: например, указан только один тестовый адрес, который периодически перестает отвечать на пинги (перегружен), в результате переключение на резерв. Если при этом еще нет возврата через альтернативную таблицу для основного канала (сделайте!), то будет Ваш эффект пропадания пинга на wan1_ip.

В момент сбоя статус ppoe подключения - Open, т.е. всё ок, однако маршрут через него помечается как мёртвый
Failover настроен на мониторинг по icmp 2 хостов (яндекс и google dns), причём доступен должен быть хотя бы 1, чтобы маршрут считался живым.

В альтернативной таблице есть возврат на основной канал.

Пингуем мы внешние адреса ppoe-подключения с машины, подключенной к другому провайдеру НЕ через dfl. И внешние, как раз-таки отваливаются. Внутри сети и адрес второго провайдера (статика) остаются в норме

Поставьте временно метрику на маршруте через основной канал больше, чем у резерва. Убедитесь, что Интернет изнутри идет через резерв. Проверьте пинг снаружи на основной канал в таком состоянии.

Если сделать статический маршрут (без мониторинга) через РРРоЕ, то в момент падения мониторинга, идет ли по нему трафик?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Поставили вчера железяку, пока нормально всё.. Нужно теперь ждать, когда у РТК критические дни начнутся.. Основной поток трафика (а это телефония) пустили через 2 канал, на основном оставили веб-серфинг некоторым пользователям, VPN (мало нагружен) и входящие подключения (rdp, http)

Насчёт снять мониторинг с маршрута думали, попробуем, как представится возможность... Пока только изменил метод мониторинга: 1 хост (yandex) мониторится по TCP, второй (google dns) - по ICMP... Нелогично чуть, но пойдёт.. ((=
Для того, чтобы маршрут считался "живым", требуется доступность хотя бы одного...

Столкнулись с ещё одной головоломкой... С машин, которые выпущены наружу по 1 каналу, не доступен внешний адрес 2 канала. Даже не пингуется, хотя другие хосты "аллё"... Внешние пользователи внешний адрес 2 канала без проблем видят... Это такая особенность работы failover-конфигурации? Можно её обойти как-то? Пользователям внутренней сети нужен этот адрес..

Спасибо заранее, как будут проблемы с ppoe, напишу, справились или нет...

Это такая особенность работы Вашей failover-конфигурации. Особенность DFL в том, что нет там никаких особенностей, по крайней мере в том, что касается маршрутизации и NAT, вот как лично Вы ей сказали, так она и работает .
Настраивая faiilover, нужно обязательно проводить эксперименты как с отключением каналов, так и со сменой соотношения метрик, что я Вам уже предлагал, наблюдая при этом за доступностью внешних адресов извне (проверка настройки PBR).
И выложите скриншоты хотя бы таблиц и правил маршрутизации.

Спасибо за правильную наводку!. С недоступностью резервного канала внутри сети разобрались... И дело, таки-да, было в моей failover.. ((=
Делал-то по мануалу всё... А там не написано, что в альтернативной таблице маршрутизации нужно прописывать маршруты
wan1 -> wan1_net
wan2 -> wan2_net
dmz -> dmz_net
lan -> lannet
vlan -> vlan_net (у меня пара вланов есть, туда резервный канал раздаётся)
Прописал, заработало...

И проблема, конечно, тут не в dfl, а в моей голове... ((=

Метрику маршрута ppoe -> all_nets в основной таблице пробовал ставить побольше, Интернет внутри сети начинает идти по резервному каналу, но перестаёт пинговаться внешний адрес основного канала... Странно... Но не стал пока с этим заморачиваться... Итак, скрины..
Маршрутизация:

Правила IP:

И по изначальной проблеме... Циклической потере пакетов по ppoe... Пока не наблюдается... Может, пока у РТК всё хорошо... Вчера ночью был отвал РТК, по логам ppoe_tunnel_down, dfl всё отработала корректно, переключила на резерв, вернула обратно всё часа через 3, когда ppoe поднялось... Это для справки...
Изначальная потеря пакетов происходила при поднятом ppoe и вполне доступным каналом...
Что сделали, прежде чем ввести железку в эксплуатацию: MTU на pppoe поставили 1480 (как на винде было), на остальных интерфейсах по 1500 не стали трогать... Телефонию от греха подальше PBR-кой завернули на резерв (пользователи негодуэ за провалы), сделали такие настройки ICMP (см. скрин ниже, галка там по дефолту стояла, убрали)
Прост моё мнение, потеря пакетов могла происходить из-за перегрузки ICMP-запросами... В т.ч. могли дропаться ответы запросы icmp 3:4, отвечающие за необходимость дефрагментации пакетов, что неизбежно для МТU в 1480... Пока, повторюсь, всё хорошо, что-то из этого, возможно, сработало... Уважаемые гуру, ваше мнение?

Правильно не написано. Их там не нужно прописывать.


Я это и подозревал.

Солгамши, однако .
Правильно настройте PBR на возврат !. Вот так: http://forum.dlink.ru/viewtopic.php?f=3&t=161874. Пока это не сделано, обсуждать Ваши пропадания пинга не имеет смысла.


Неужели не понятно, что нужно давать всю информацию? Какой смысл показывать правила SAT без скрина вкладок SAT? Какая польза от сводной таблички правил маршрутизации, если в ней не видно прямых и обратных таблиц, на которые правила отправляют?
Пока, кроме кривой PBR (см. выше), обратил внимание на, что в пробросах Вы используете NAT, хотя лучше бы Allow (адрес клиента на сервере не виден при NAT). И, в порядке совета -- может быть лучше VPN поднять вместо такого количества пробросов?

Если их там не прописывать, с серверов и машин в сети, которые выпущены по основному каналу, нет пингов до внешнего адреса резервного канала... Сервисы на серверах, опубликованные наружу, изнутри сети по внешним адресам можно заставить работать, лишь сделав NAT при публикации... Если для rdp-серверов ещё могу обратно вернуть allow... Необязательно им быть доступными изнутри сети, то для http есть доменное имя, к которому оба внешних адреса привязаны и все пользуют его как внутри сети, так и снаружи...
Допустим, делаю для главного нашего http-ресурса NAT - юзеры набирают в браузере plastic-kruto.ru (напоминаю, 2 внешних адреса dfl к имени привязано на dns-хостинге) и попадают на наш внутренний http-сервер независимо от того, внутри сети они находятся или снаружи, делаю allow - СНАРУЖИ попадают нормально, изнутри - не попадают... NAT также без разницы есть маршруты в alt или нет (на то он и NAT )))
Т.е., если в alt присутствуют "лишние" маршруты, внутри сети пингуются оба внешних адреса, если их нет, wan2_ip не пингуется, но сервисы работают, благодаря NAT...
Медитирую по вечерам, стараясь понять логику работы устройства, но пока только просветы в темноте... ((=
Выкладываю ещё раз все скрины, как есть на данный момент..
Маршрутизация:

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

Основная табличка:

Недостающие скрины PBR:

Далее проброс портов на резервном канале одновременно с основным

И ещё 2 PBR, которые заворачивают на резерв VLAN в кол-ве 2 шт. (нужно ли более подробно расписывать?)