Дано:
3 провайдера, заведенные на отдельные 1821W
~150 клиентских устройств, выходящих в интернет.Нужно:
Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.Текущая схема:
Если пользователь подключен к одной из сетей wifi то ходит в инет через ту циску, на которой этот wifi раздается. Если нужен другой пров, то вручную переключается на другую wifi сеть.Вопрос:
Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если пользователь сидит на проводе?
>[оверквотинг удален]
> ~150 клиентских устройств, выходящих в интернет.
> Нужно:
> Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.
> Текущая схема:
> Если пользователь подключен к одной из сетей wifi то ходит в инет
> через ту циску, на которой этот wifi раздается. Если нужен другой
> пров, то вручную переключается на другую wifi сеть.
> Вопрос:
> Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если
> пользователь сидит на проводе?Один из самых простых способов: использовать прокси-сервер. Тогда пользователь мог бы выбирать по какому каналу пойти путём выбора порта на нём. К сожалению, это сделать не всегда можно.
Другой, более сложный способ, создать несколько виртуальных интерфейсов (с разными МАК-адресами), которые подключить через виртуальный бридж в одну и ту же сеть (но с разными IP-адресами на каждом виртуальном интерфейсе). В зависимости от того, какой из них указан как шлюз, трафик можно будет роутить по-разным маршрутам.
> Нужно:
> Клиент мог самостоятельно в любое время,
> переключить себя на другого провайдера.Сильно.
Т.е. предполагается, что клиент лучше знает где ему лучше.> Вопрос:
> Какие есть иные схемы выбора пользователем маршрута в интернет,
> в условиях если пользователь сидит на проводе?Можно продолжить мастырить костыли. Подняв на каждом маршрутизаторе по vpn серверу на ваш выбор, и людям которые сидят на проводе предложить авторизовываться на них и таким образом ходить в интернет. Схема маразматическая, но в вашу текущую парадигму укладывается вполне.
P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla на случай падения не рассматривается совсем?
> Сильно.
> Т.е. предполагается, что клиент лучше знает где ему лучше.Это производственная необходимость. Основная масса пользователей программеры, которым нужна возможность перелезть на другого прова. Для дебага своих глючащих сетевых приложений :)
> P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla
> на случай падения не рассматривается совсем?Пока мысли создать некую гибридную схему.
1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым распределить пользователей по каналам. В случае падения одного из каналов, менять маршрут на другой.
2) Шлюз по направлению. Выбрав определенный шлюз, маршрут через определенного провайдера.
>[оверквотинг удален]
> Это производственная необходимость. Основная масса пользователей программеры, которым
> нужна возможность перелезть на другого прова. Для дебага своих глючащих сетевых
> приложений :)
>> P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla
>> на случай падения не рассматривается совсем?
> Пока мысли создать некую гибридную схему.
> 1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым
> распределить пользователей по каналам. В случае падения одного из каналов, менять
> маршрут на другой.
> 2) Шлюз по направлению. Выбрав определенный шлюз, маршрут через определенного провайдера.Простейший вариант - несколько VLAN-ов, каждый VLAN - к своему провайдеру, недостатки - надо чтобы тачки клиентские vlan-ы поддерживали....
> Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.
> Это производственная необходимость. Основная масса пользователей программеры, которым > нужна возможность перелезть на другого прова.
> Для дебага своих глючащих сетевых приложений :)
>
> Пока мысли создать некую гибридную схему.
> 1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым распределить > пользователей по каналам. В случае падения одного из каналов, менять маршрут на другой.Первая мысль самая оптимальная при таких обстоятельствах.
Программисты вполне способны поменять у себя на компе шлюз. 10.0.0.1 на 10.0.0.2 или 10.0.0.3
Однако если аплинки к провайдерам задохлые, флапаются и насмерть забиваются трафиком,
то намучаетесть вы с этим sla. Ещё и nat наверно есть.
Пусть лучше программисты шлюз у себя перещелкивают и капают на начальство, чтоб денег дало побольше на толстый и надежный интернет.
>[оверквотинг удален]
> Т.е. предполагается, что клиент лучше знает где ему лучше.
>> Вопрос:
>> Какие есть иные схемы выбора пользователем маршрута в интернет,
>> в условиях если пользователь сидит на проводе?
> Можно продолжить мастырить костыли. Подняв на каждом маршрутизаторе по vpn серверу на
> ваш выбор, и людям которые сидят на проводе предложить авторизовываться на
> них и таким образом ходить в интернет. Схема маразматическая, но в
> вашу текущую парадигму укладывается вполне.
> P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla
> на случай падения не рассматривается совсем?1. BGP пиринг с фулвью с каждым клиентом - и у него полная свобода выбора.
2. как уже сказано выше - куча VPN серверов с привязкой каждого к отдельному прову.
> Дано:
> 3 провайдера, заведенные на отдельные 1821W
> . . .
> Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если
> пользователь сидит на проводе?Для пользователя также изящно как выбор SSID в WiFi, на проводе сделать нельзя.
А зачем вообще провод? Адаптеры usb-wifi копейки стоят.
> А зачем вообще провод? Адаптеры usb-wifi копейки стоят.Радио обстановка на объекте не очень хорошая. В том смысле, что вокруг много wifi сетей, и много пакетов доходит битыми. Для клиента это выражается в том, что пинг возрастает до ~1000-3000. После многократных плясок с настройками радио модуля на cisco, использования wifi оборудования ASUS и Apple, добиться устойчивой связи не удалось. Причем что самое нездоровое, проблема возникает рандомно и помогает ее решить переключение wifi передатчика на другой канал.
Соответственно было принято решение, все оборудование, которое возможно, посадить на витую пару.
>> А зачем вообще провод? Адаптеры usb-wifi копейки стоят.
> Радио обстановка на объекте не очень хорошая. В том смысле, что вокруг
> много wifi сетей, и много пакетов доходит битыми. Для клиента это
> выражается в том, что пинг возрастает до ~1000-3000. После многократных плясок
> с настройками радио модуля на cisco, использования wifi оборудования ASUS и
> Apple, добиться устойчивой связи не удалось. Причем что самое нездоровое, проблема
> возникает рандомно и помогает ее решить переключение wifi передатчика на другой
> канал.
> Соответственно было принято решение, все оборудование, которое возможно, посадить на витую
> пару.Правильное решение!!
Варианты:
1. vlan-ы.
2. в зависимости от дефаулт гейтвея.
3. VPN-ы всех мастей (от pppoe по имени сервиса до IPSec-ов)
4. DHCP+ опция 121 или 249 (в зависимости от ОС-и)Что дает 4-ый вариант:
допустим для тестирования используются 3 (5,10 и т.д.) ресурсов, выдаем абонентам маршрут к ресурсу 1 через шлюз 1 (1-й пров), ресурсу 2 - шлюз 2 (2-ой пров), ресурсу 3 - шлюз 3 (третий пров), в результате программер может проверять свое ПО связываясь с одним из 3-х ресурсов по выбору и автоматом попадая в нужного прова без всяких перенастроек.
>[оверквотинг удален]
> ~150 клиентских устройств, выходящих в интернет.
> Нужно:
> Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.
> Текущая схема:
> Если пользователь подключен к одной из сетей wifi то ходит в инет
> через ту циску, на которой этот wifi раздается. Если нужен другой
> пров, то вручную переключается на другую wifi сеть.
> Вопрос:
> Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если
> пользователь сидит на проводе?Можно на маршрутизаторах поднять VPN сервера, а на клиентских ПК использовать Cisco VPN Client'ы. В VPN Client'е три разных коннекта на три разных циски (соответственно на три разных ISP'а).
Основная масса пользователей программеры, которым > нужна возможность перелезть на другого прова.
> Для дебага своих глючащих сетевых приложений :)
>
> Пока мысли создать некую гибридную схему.
> 1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым распределить > пользователей по каналам. В случае падения одного из каналов, менять маршрут на другой.Первая мысль самая оптимальная при таких обстоятельствах.
Программисты вполне способны поменять у себя на компе шлюз. 10.0.0.1 на 10.0.0.2 или 10.0.0.3
Однако если аплинки к провайдерам задохлые, флапаются и насмерть забиваются трафиком,
то намучаетесть вы с этим sla. Ещё и nat наверно есть.
Пусть лучше программисты шлюз у себя перещелкивают и капают на начальство, чтоб денег дало побольше на толстый и надежный интернет.