Доброго времени суток Есть технический вопрос описание состоит из 2х частей не технической и технической Организационно НЕ техническая часть описания вопроса Есть 2 технические площадки размещенные в разных городах, исторически так сложилось что провайдеры имели устойчивую маршрутизацию между городом Х и городом Д По прошествии времени, административно изменили эту ситуацию в один момент и связанность города (всего города) Д с большой площадь резко одномоментно изменилась - отключились магистральные каналы связи... все провайдеры работали в основном через магистрали которые оказались отключенными в один момент. В этой ситуации площадка в г. Д несмотря на наличие 2х "независимых" провайдеров интернета оказалась в ситуации 30-35% уровня потерь пактов по каждому из 2х каналов связи т.к. количество живых магистралей было ограничено и у всех провайдеров потери были от 30% до 90 % пакетов Ситуация сохранялась достаточно долго чтобы просто переждать восстановления работоспособности магистралей ничего не делая т.к. понятно что крупные магистрали не строятся за считанные часы или дни. Техническая часть вопроса Дано: 2 площадки 1. Датацентр, устойчивый инет, Mikrotik RB3011, белый IP 2. Офис, Mikrotik RB2011, 2 провайдера, 2 белых IP, потери 30%-35%% на канале у каждого провайдера в разные периоды интенсивность разная, скорости каналов условно 20-25 Mbit/c. Требуется Объединение сети Датацентра и Офиса в сегмент L2 для доступа к ресурсам Датацентра из Офиса и ресурсам Офиса из Датацентра Игнорируется необходимость применять шифрование каналов из за недостаточной скорости процессора в RB2011 (допускаю что просто не умею правильно готовить шифрование поэтому получил такие показатели скорости которые не приемлемы для работы) Катастрофически быстро добиться работающего хоть как то соединения для работы RDP и ему подобного соединений. Что было сделано 1. По Белым IP с обоих провайдеров было поднято по 1 EoIP туннелю в Датацентр 2. Проверенно, что туннели устанавливаются и работают каждый через своего провайдера. 3. Поднят бондинг в режиме Broadcast в бондинг включены 2 EoIP туннеля поднятых в пункте 1 4. Полученный Bonding включается в Bridge на обоих микротиках Столкнулся с неустойчивостью работы этой конструкции - точных причин не выяснил и предположил, что вопрос в переупорядочивании пакетов приходящих от Bonding интерфейса в условиях существенно разных задержек и маршрутов у обоих провайдеров (по пингу было точно видно через какой из каналов он проходил) 5. Бондинг был исключен из Бриджа и поверх бондинг иинтерфейса, ему назначены серые адреса /30 и поверх них был поднят 3й EoIP 6. В Бриджи по обоим сторонам включен EoIP из пункта 5 Результат Потери пинга по туннелю практически свелись к единицам хотя и случались но с этим можно было работать ... если пакет по пути у двух провайдеров потерялся значит это его судьба ... Все-бы ничего - в целом работает и даже как-то переживает перебои у каждого из провайдеров но есть некие железки (сетевые принтеры фирмы HP m425dn у которых сканер работает по протоколу samba v.1 затем samba v.2 и время от времени у них сносит крышу и они перестают сканировать на сетевые шары находящиеся не под боком ... на те что в пределах сети офиса - сканируют а тех кто удаленно от них находится - не хотят ... причем если-бы один так себя вел - глюк единицы ... но когда перестают 4 сразу - приходится разбирать в чем причина.... Пока из трейсинга пакетов обмена принтера и остальной сети wiresharko'm ( снифер на микротике с трансляцией для анализа в wireshark) я вижу что на принтер валятся дублирующие пакеты одинакового размера и время от времени сообщения о том что пакет отброшен т.к. нет начала пакета ... т.е 2 видимые МНЕ проблемы - Реордеринг и дублирование пакетов от Бондинга в режиме broadcast видимо в схеме я в чем-то ошибся и мои ожидания не совпали с действительностью. Вопрос Как переделать схему чтобы 1. Пакеты после бондинга как транспортного уровня не дублировались а терминировались кем -то прямо на микротике и за пределы его не выходили 2. По возможности исключить (уменьшить вероятность) неверного порядка следования пакетов 3. Если возможно, фрагментированые пакеты собирать не на получателе пакета а на Микротике выпуская в локальную сеть уже собранный пакет Заранее Благодарю за ответ PS Решил написать после просмотра нескольких видео в Ютубе на MUM посвященного анализу производительности связок разных туннелей и бриджей Спасибо за интересные доклады
Добрый день! У меня возникла точно такая же ситуация и пока не могу найти решения. Удалось ли Вам решить вопрос корректного резервирования по двум каналам? Если да, то могли бы в кратце рассказать в какую сторону двигаться?
reordering на бродкасте зверь редкий. Там кто первый долетел тот и принимается. Дублирование есть сама суть этого бондинга. Вопрос, а какое время потери соединения для вас приемлемо?
Мне нужно общаться по скайпу и когда пинги пропадают становится не очень хорошо, поэтому зажержку в 1 сек наверное можно допустить. Хотя я не тестировал на сколько критичны в данном случае дубликаты пакетов. Может они и не будут мешать, но хотелось бы чтобы не было мусора. Как я планирую сделать: - Установить CHR_Mikrotik с белым IP на удаленном сервере со стабильным подключением. - Поднять на CHR_Mikrotik сервер L2TP - EoIP (как я понял Mikrotik может только на нем сделать туннель UDP). Хотя тут у меня возникла сложность как пустить два подключение от клиента по разным маршрутам, так как не получается отследить в Mangle какой именно пользователь коннектится. И порты клиента не поменять.. Пока решение только - на стороне CHR_Mikrotik получить 2 белых IP. - На моей стороне нестабильный LTE модем и нестабильный провайдер (WiFi) - у обоих серые IP - Настроить со своей стороны клиента поднять оба туннеля - Настроить бондинг двух каналов / либо OSPF маршрутизацию По поводу OSPF просто боюсь, что если будет пропадать то тут то там, то будут теряться еще сколько-то пакетов пока он переключает маршруты. Также я пока не уверен, что потоковое видео будет нормально идти в такой конструкции. Пока я только разрабатываю варианты решений и тестирую в песочнице "как это конфигурируется". Если вы подскажете какое-то решение лучше, буду очень признателен.
Да, это тоже неплохое решение, и действительно в данной ситуации недоступно. В любом случае мне интересно сделать систему с высокой выживаемостью, если так можно выразиться. Если я правильно понимаю, то MikroTik не умеет работать с PRP (Parallel Redundancy Protocol)
