https://opennet.ru/openforum/vsluhforumID6/22757.html Дано:<br>3 провайдера, заведенные на отдельные 1821W<br>~150 клиентских устройств, выходящих в интернет.<br><br>Нужно:<br>Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.<br><br>Текущая схема:<br>Если пользователь подключен к одной из сетей wifi то ходит в инет через ту циску, на которой этот wifi раздается. Если нужен другой пров, то вручную переключается на другую wifi сеть.<br><br>Вопрос:<br>Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если пользователь сидит на проводе?<br> <br> https://opennet.ru/openforum/vsluhforumID6/22757.html#11 Fri, 17 Jun 2011 08:27:07 GMT Основная масса пользователей программеры, которым &gt; нужна возможность перелезть на другого прова. <br>&gt; Для дебага своих глючащих сетевых приложений :)<br>&gt; <br>&gt; Пока мысли создать некую гибридную схему.<br>&gt; 1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым распределить &gt; пользователей по каналам. В случае падения одного из каналов, менять маршрут на другой.<br><br>Первая мысль самая оптимальная при таких обстоятельствах. <br><br>Программисты вполне способны поменять у себя на компе шлюз. 10.0.0.1 на 10.0.0.2 или 10.0.0.3<br><br>Однако если аплинки к провайдерам задохлые, флапаются и насмерть забиваются трафиком,<br>то намучаетесть вы с этим sla. Ещё и nat наверно есть.<br> Пусть лучше программисты шлюз у себя перещелкивают и капают на начальство, чтоб денег дало побольше на толстый и надежный интернет.<br> https://opennet.ru/openforum/vsluhforumID6/22757.html#10 Fri, 17 Jun 2011 08:26:17 GMT &gt; Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.<br>&gt; Это производственная необходимость. Основная масса пользователей программеры, которым &gt; нужна возможность перелезть на другого прова. <br>&gt; Для дебага своих глючащих сетевых приложений :)<br>&gt; <br>&gt; Пока мысли создать некую гибридную схему.<br>&gt; 1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым распределить &gt; пользователей по каналам. В случае падения одного из каналов, менять маршрут на другой.<br><br>Первая мысль самая оптимальная при таких обстоятельствах. <br><br>Программисты вполне способны поменять у себя на компе шлюз. 10.0.0.1 на 10.0.0.2 или 10.0.0.3<br><br>Однако если аплинки к провайдерам задохлые, флапаются и насмерть забиваются трафиком,<br>то намучаетесть вы с этим sla. Ещё и nat наверно есть.<br> Пусть лучше программисты шлюз у себя перещелкивают и капают на начальство, чтоб денег дало побольше на толстый и надежный интернет.<br> https://opennet.ru/openforum/vsluhforumID6/22757.html#9 Fri, 17 Jun 2011 05:57:44 GMT &gt;[оверквотинг удален]<br>&gt; ~150 клиентских устройств, выходящих в интернет.<br>&gt; Нужно: <br>&gt; Клиент мог самостоятельно в любое время, переключить себя на другого провайдера.<br>&gt; Текущая схема: <br>&gt; Если пользователь подключен к одной из сетей wifi то ходит в инет <br>&gt; через ту циску, на которой этот wifi раздается. Если нужен другой <br>&gt; пров, то вручную переключается на другую wifi сеть.<br>&gt; Вопрос: <br>&gt; Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если <br>&gt; пользователь сидит на проводе?<br><br>Можно на маршрутизаторах поднять VPN сервера, а на клиентских ПК использовать Cisco VPN Client'ы. В VPN Client'е три разных коннекта на три разных циски (соответственно на три разных ISP'а). <br> https://opennet.ru/openforum/vsluhforumID6/22757.html#8 Fri, 17 Jun 2011 05:29:01 GMT &gt;&gt; А зачем вообще провод? Адаптеры usb-wifi копейки стоят.<br>&gt; Радио обстановка на объекте не очень хорошая. В том смысле, что вокруг <br>&gt; много wifi сетей, и много пакетов доходит битыми. Для клиента это <br>&gt; выражается в том, что пинг возрастает до ~1000-3000. После многократных плясок <br>&gt; с настройками радио модуля на cisco, использования wifi оборудования ASUS и <br>&gt; Apple, добиться устойчивой связи не удалось. Причем что самое нездоровое, проблема <br>&gt; возникает рандомно и помогает ее решить переключение wifi передатчика на другой <br>&gt; канал.<br>&gt; Соответственно было принято решение, все оборудование, которое возможно, посадить на витую <br>&gt; пару.<br><br>Правильное решение!!<br><br>Варианты:<br>1. vlan-ы.<br>2. в зависимости от дефаулт гейтвея.<br>3. VPN-ы всех мастей (от pppoe по имени сервиса до IPSec-ов)<br>4. DHCP+ опция 121 или 249 (в зависимости от ОС-и)<br><br>Что дает 4-ый вариант:<br>допустим для тестирования используются 3 (5,10 и т.д.) ресурсов, выдаем абонентам маршрут к ресурсу 1 через шлюз 1 (1-й пров), ресурсу 2 - шлюз 2 https://opennet.ru/openforum/vsluhforumID6/22757.html#7 Fri, 17 Jun 2011 00:17:52 GMT &gt; А зачем вообще провод? Адаптеры usb-wifi копейки стоят.<br><br>Радио обстановка на объекте не очень хорошая. В том смысле, что вокруг много wifi сетей, и много пакетов доходит битыми. Для клиента это выражается в том, что пинг возрастает до ~1000-3000. После многократных плясок с настройками радио модуля на cisco, использования wifi оборудования ASUS и Apple, добиться устойчивой связи не удалось. Причем что самое нездоровое, проблема возникает рандомно и помогает ее решить переключение wifi передатчика на другой канал.<br><br>Соответственно было принято решение, все оборудование, которое возможно, посадить на витую пару.<br> https://opennet.ru/openforum/vsluhforumID6/22757.html#6 Thu, 16 Jun 2011 16:44:46 GMT &gt; Дано: <br>&gt; 3 провайдера, заведенные на отдельные 1821W <br>&gt; . . .<br>&gt; Какие есть иные схемы выбора пользователем маршрута в интернет, в условиях если <br>&gt; пользователь сидит на проводе?<br><br>Для пользователя также изящно как выбор SSID в WiFi, на проводе сделать нельзя.<br><br>А зачем вообще провод? Адаптеры usb-wifi копейки стоят. <br><br> https://opennet.ru/openforum/vsluhforumID6/22757.html#5 Thu, 16 Jun 2011 06:18:18 GMT &gt;[оверквотинг удален]<br>&gt; Это производственная необходимость. Основная масса пользователей программеры, которым <br>&gt; нужна возможность перелезть на другого прова. Для дебага своих глючащих сетевых <br>&gt; приложений :) <br>&gt;&gt; P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla <br>&gt;&gt; на случай падения не рассматривается совсем?<br>&gt; Пока мысли создать некую гибридную схему.<br>&gt; 1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым <br>&gt; распределить пользователей по каналам. В случае падения одного из каналов, менять <br>&gt; маршрут на другой.<br>&gt; 2) Шлюз по направлению. Выбрав определенный шлюз, маршрут через определенного провайдера. <br><br>Простейший вариант - несколько VLAN-ов, каждый VLAN - к своему провайдеру, недостатки - надо чтобы тачки клиентские vlan-ы поддерживали.... <br><br><br> https://opennet.ru/openforum/vsluhforumID6/22757.html#4 Thu, 16 Jun 2011 06:14:24 GMT &gt;[оверквотинг удален]<br>&gt; Т.е. предполагается, что клиент лучше знает где ему лучше.<br>&gt;&gt; Вопрос: <br>&gt;&gt; Какие есть иные схемы выбора пользователем маршрута в интернет, <br>&gt;&gt; в условиях если пользователь сидит на проводе?<br>&gt; Можно продолжить мастырить костыли. Подняв на каждом маршрутизаторе по vpn серверу на <br>&gt; ваш выбор, и людям которые сидят на проводе предложить авторизовываться на <br>&gt; них и таким образом ходить в интернет. Схема маразматическая, но в <br>&gt; вашу текущую парадигму укладывается вполне.<br>&gt; P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla <br>&gt; на случай падения не рассматривается совсем?<br><br>1. BGP пиринг с фулвью с каждым клиентом - и у него полная свобода выбора.<br>2. как уже сказано выше - куча VPN серверов с привязкой каждого к отдельному прову.<br> https://opennet.ru/openforum/vsluhforumID6/22757.html#3 Thu, 16 Jun 2011 05:20:27 GMT &gt; Сильно. <br>&gt; Т.е. предполагается, что клиент лучше знает где ему лучше.<br><br>Это производственная необходимость. Основная масса пользователей программеры, которым нужна возможность перелезть на другого прова. Для дебага своих глючащих сетевых приложений :)<br><br>&gt; P.S. Вариант, из двух провайдеров с нормальным QOS и backup через sla <br>&gt; на случай падения не рассматривается совсем?<br><br>Пока мысли создать некую гибридную схему.<br>1) Шлюз по умолчанию, используется ip sla и статичные правила, по которым распределить пользователей по каналам. В случае падения одного из каналов, менять маршрут на другой.<br>2) Шлюз по направлению. Выбрав определенный шлюз, маршрут через определенного провайдера.<br><br><br>