Comments 19
В вашем решении отсутствует балансировка и обработка отказов провайдеров.
Что есть то есть, как сделать балансировку подсказал yosemity
А с обработкой отказов — мы держим один канал всегда свободным, на тот случай если один из провайдеров откажет, это конечно не спасет если резервный канал тоже будет не доступным, но вероятность события значительно меньше.
А с обработкой отказов — мы держим один канал всегда свободным, на тот случай если один из провайдеров откажет, это конечно не спасет если резервный канал тоже будет не доступным, но вероятность события значительно меньше.
UFO just landed and posted this here
Похоже в сообщество надо было обращаться значительно раньше, а то мы себе мозги над стандартными вещами съели) (вот оригинал указанной ссылки http://lartc.org/howto/lartc.rpdb.multiple-links.html)
Ну если честно, вы тут абзац из «букваря» описали. Особенно забавляют плюсы и минусы. Например, минус работы через нескольких провайдеров — необходимость нескольких провайдеров.
Например, минус работы через нескольких провайдеров — необходимость нескольких провайдеров.
Возможно так будет не много понятнее:
“Под минусами данного решения по динамическому перенаправлению сетевого трафика можно выделить необходимость наличия нескольких провайдеров”
Возможно требуется пояснение:
“Чтобы в принципе иметь возможность реализовать данную схему, необходимо наличие нескольких независимых провайдеров, а поскольку это не везде достижимо, то и не везде применимо”.
UFO just landed and posted this here
Я решал подобную задачу для офисного интернета: https://habrahabr.ru/post/279777/
В вашем случае вы можете использовать --hmark-tuple src,sport и тогда никаких действий со стороны приложения не потребуется для того, чтобы попасть в разные каналы.
Что только не делают люди, чтобы не брать на работу сетевиков.
А толку их брать? У них на все один ответ: давай циску/джун за много-много денег, чтобы в итоге выкатить такое же решение, которое делается средствами iproute/netfilter.
А толку брать программистов на работу? Или дизайнеров? Или вообще любых специалистов?
Для:
* соответствия лучшим практикам, сиречь технологичности,
* стабильности и воспроизводимости результата,
* прозрачной модели обслуживания решения в дальнейшем,
* отсутствие необходимости чинить свою повозку на ходу/на полной скорости.
Понимаете, для динамического перенаправления сетевого траффика что-то своё придумывают те, кому катастрофически не хватает возможностей BGP, MP-BGP и всего стандартизованного поля TE.
Но чаще проблема в пробелах в профильных знаниях.
Для:
* соответствия лучшим практикам, сиречь технологичности,
* стабильности и воспроизводимости результата,
* прозрачной модели обслуживания решения в дальнейшем,
* отсутствие необходимости чинить свою повозку на ходу/на полной скорости.
Понимаете, для динамического перенаправления сетевого траффика что-то своё придумывают те, кому катастрофически не хватает возможностей BGP, MP-BGP и всего стандартизованного поля TE.
Но чаще проблема в пробелах в профильных знаниях.
UFO just landed and posted this here
Я первоначально использовал FreeBSD PF, но это без балансировки нагрузки
В конце концов оставил только прокси сервер SQUID с балансировкой для веб трафика, остальной пустил по одному каналу
pass in log on $int_if route-to {($ext_if1 $gw1), ($ext_if2 $gw2), ($ext_if3 $gw3)} round-robin from $int_lan to any
В конце концов оставил только прокси сервер SQUID с балансировкой для веб трафика, остальной пустил по одному каналу
Sign up to leave a comment.
Динамическое перенаправление сетевого трафика