https://www.opennet.me/openforum/vsluhforumID3/38461.html В документе (http://xgu.ru/wiki/openvpn/gw) описывается как с помощью OpenVPN и двух независимых интернет-каналов низкой надёжности организовать надёжное подключение удалённой сети (или системы) к центральной сети.<br><br><br>Приведённое решение может быть полезно и без использования VPN - для решения задачи автоматического выбора основного шлюза. <br><br>URL: http://xgu.ru/wiki/openvpn/gw<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=12103<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#39 Tue, 20 May 2008 12:50:59 GMT что то туплю.<br>есть 2 канала от одного и того же провайдера в разных офисах связанных между собой отдельной линией.<br>как переключить на второй офис в случае падения канала в первом понятно, но что то немогу представить, как переключить обратно, когда канал в первом офисе восстановится? не будешь же при каждой проверке переключать маршрут обратно и пинговать...<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#38 Sat, 29 Sep 2007 12:19:26 GMT &gt;Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня <br>&gt;есть ответы на ваши вопросы: <br>&gt;- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но <br>&gt;конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в <br>&gt;одной области <br>&gt;- время перестройки на резервный канал для ospf составит, скажем, 3 секунды <br>&gt;(не вижу смысла приводить в его в неких абстрактных hello timeout) <br>&gt;<br><br>Некие абстрактные hello timeout, которые на самом деле hello intervals -- это как раз те значения в которых измеряется такой интервал, как DeadInterval (Таймер, который начинает отсчитываться после того как маршрутизатор перестает слышать hello пакеты от соседа и по истечению которого сосед считается ушедшим в down). Только по истечению этого таймера ospf будет считать маршрут недоступным (а точнее маршруты через этого соседа).<br>Как правило hello interval = 10 sec, dead = 40 (для броадкаст сетей и point=to-point соединений).<br><br>А вот Ваше утвержд https://www.opennet.me/openforum/vsluhforumID3/38461.html#37 Wed, 26 Sep 2007 16:05:32 GMT Расскажите, пожалуйста, в двух словах <br>как закрыть туннель через DNS,<br>если это возможно<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#36 Wed, 26 Sep 2007 15:38:47 GMT &gt;Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня <br>&gt;есть ответы на ваши вопросы: <br>&gt;- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но <br>&gt;конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в <br>&gt;одной области <br><br>Спасибо.<br><br>&gt;- время перестройки на резервный канал для ospf составит, скажем, 3 секунды <br>&gt;(не вижу смысла приводить в его в неких абстрактных hello timeout) <br>&gt;<br>&gt;- при всём моём уважении к Вашим усилиям, 30 секунд время решительно <br>&gt;неприемлемое т. к. за это время вполне могут откиснуть tcp сессии, <br>&gt;застопорится картинка в потоковом видео и возникнет неуместная пауза в разговоре <br>&gt;по телефону <br><br>Если 30 в скрипте заменить на 3 что-то принципиально изменится?<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#35 Sat, 22 Sep 2007 20:43:19 GMT &gt;Ну у _Вас_ - может быть, a у _нас_ и имена резольвятся <br>&gt;и хрена ты такой тунель поднимишь :) Причем это не rocket <br>&gt;science - почти во всех вменяемых сетях это заткнуто. <br><br>А зачем собственно?<br>Наша сеть представляется мне вполне вменяемой, хотя ничего у нас не позатыкано: если пользователь хочет поднять туннель через днс-пакеты вместо нормального ip, то это его полное право.<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#34 Sat, 22 Sep 2007 20:39:27 GMT Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня есть ответы на ваши вопросы:<br>- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в одной области<br>- время перестройки на резервный канал для ospf составит, скажем, 3 секунды (не вижу смысла приводить в его в неких абстрактных hello timeout)<br>- при всём моём уважении к Вашим усилиям, 30 секунд время решительно неприемлемое т. к. за это время вполне могут откиснуть tcp сессии, застопорится картинка в потоковом видео и возникнет неуместная пауза в разговоре по телефону<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#33 Fri, 21 Sep 2007 16:21:09 GMT Ну у _Вас_ - может быть, a у _нас_ и имена резольвятся и хрена ты такой тунель поднимишь :) Причем это не rocket science - почти во всех вменяемых сетях это заткнуто.<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#32 Thu, 20 Sep 2007 22:50:36 GMT Так уж получилось, что подобную задачу мне необходимо решить в ближайшее время.<br><br>два канала Интернет, колокейшн который должен быть доступен с некой "внутренней адресацией" (специфика), припадении канала с туннелем, автоматический "переход" на второй канал.<br><br>Сделаю это с помощью OSPF, отвечу на все Ваши вопросы - подготовлю материал и "запощу" на опеннет.<br><br>Пойдет?<br> https://www.opennet.me/openforum/vsluhforumID3/38461.html#31 Thu, 20 Sep 2007 19:35:10 GMT Для двух хостов это хорошее решение. Для сотен - уже сомневаюсь.<br><br>Кроме того, OSPF позволяет по другому живому каналу уведомить другую систему о смене маршрута и необходимости перерулить трафик. При правильно выставленных тайм-аутах работать это будет более эффективно, чем пинг.<br><br>Моя фраза запихнуть все в одну область касалась случая, когда есть сравнительно небольшое кол-во хостов. Если их много, то никто не мешает делать тупиковые области. Тогда вся таблица маршрутизации не будет передаваться в каждую точку. Всё о всех будет знать только центр. Люди, которые изобретали и развивали OSPF не лаптем щи хлебали. Думали о подобных проблемах. :)<br><br>Кроме того, OSPF позволит строить более извращенные и сложные подключения, раз уж у вас сотни хостов. Логичнее было бы подобную сеть задублировать через соседей. И тут только протоколы динамической маршрутизации смогут решить эту задачу. Я вас за язык не тянул, сами про масштабируемость заговорили. :)<br><br>Предлагаю флейм закончить. Ваше решение вполне жизнеспособно и