Comments 19
В вашем решении отсутствует балансировка и обработка отказов провайдеров.
Что есть то есть, как сделать балансировку подсказал yosemity
А с обработкой отказов — мы держим один канал всегда свободным, на тот случай если один из провайдеров откажет, это конечно не спасет если резервный канал тоже будет не доступным, но вероятность события значительно меньше.
А с обработкой отказов — мы держим один канал всегда свободным, на тот случай если один из провайдеров откажет, это конечно не спасет если резервный канал тоже будет не доступным, но вероятность события значительно меньше.
Похоже в сообщество надо было обращаться значительно раньше, а то мы себе мозги над стандартными вещами съели) (вот оригинал указанной ссылки http://lartc.org/howto/lartc.rpdb.multiple-links.html)
Ну если честно, вы тут абзац из «букваря» описали. Особенно забавляют плюсы и минусы. Например, минус работы через нескольких провайдеров — необходимость нескольких провайдеров.
Например, минус работы через нескольких провайдеров — необходимость нескольких провайдеров.
Возможно так будет не много понятнее:
“Под минусами данного решения по динамическому перенаправлению сетевого трафика можно выделить необходимость наличия нескольких провайдеров”
Возможно требуется пояснение:
“Чтобы в принципе иметь возможность реализовать данную схему, необходимо наличие нескольких независимых провайдеров, а поскольку это не везде достижимо, то и не везде применимо”.
Я решал подобную задачу для офисного интернета: https://habrahabr.ru/post/279777/
В вашем случае вы можете использовать --hmark-tuple src,sport и тогда никаких действий со стороны приложения не потребуется для того, чтобы попасть в разные каналы.
Что только не делают люди, чтобы не брать на работу сетевиков.
А толку их брать? У них на все один ответ: давай циску/джун за много-много денег, чтобы в итоге выкатить такое же решение, которое делается средствами iproute/netfilter.
А толку брать программистов на работу? Или дизайнеров? Или вообще любых специалистов?
Для:
* соответствия лучшим практикам, сиречь технологичности,
* стабильности и воспроизводимости результата,
* прозрачной модели обслуживания решения в дальнейшем,
* отсутствие необходимости чинить свою повозку на ходу/на полной скорости.
Понимаете, для динамического перенаправления сетевого траффика что-то своё придумывают те, кому катастрофически не хватает возможностей BGP, MP-BGP и всего стандартизованного поля TE.
Но чаще проблема в пробелах в профильных знаниях.
Для:
* соответствия лучшим практикам, сиречь технологичности,
* стабильности и воспроизводимости результата,
* прозрачной модели обслуживания решения в дальнейшем,
* отсутствие необходимости чинить свою повозку на ходу/на полной скорости.
Понимаете, для динамического перенаправления сетевого траффика что-то своё придумывают те, кому катастрофически не хватает возможностей BGP, MP-BGP и всего стандартизованного поля TE.
Но чаще проблема в пробелах в профильных знаниях.
Я первоначально использовал 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.
Динамическое перенаправление сетевого трафика