forum.opennet.ru - "RSTP поверх OpenVPN для связи удаленных филиалов" (11)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"RSTP поверх OpenVPN для связи удаленных филиалов"

Форум Открытые системы на сервере (Маршрутизация, NAT / Другая система)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
Сообщение от dimawar (ok) on 24-Апр-11, 16:41
Возникла задача организовать стабильную связь между двумя филиалами. Сейчас канал между серверами филиалов собран на MS ISA 2006. Надо переходить на OpenSource. Требуется максимально отказоустойчивое соединение с филиалами, т.к. вся основная работа идет в терминальном сервере 1С предприятие. Погуглив, я пришел к такому решению: - серверы (шлюзы) на Linuxe (Debian/Ubuntu или Suse), т.к. есть пакет iproute2 - к каждому серверу подключено 2 интернет-провайдера - канал между филиалами через OpenVPN - iproute2 позволяет настроить маршрутизацию таким образом: если пакет приходит на интерфейс резервного провайдера, который не является шлюзом по умолчанию, то ответ идет через этот же интерфейс. Это является большим плюсом для соединения удаленных филиалов к головному офису. Недостаток, который виден в данном решении, что система обладает большой инерционностью: если случилась проблема с каналом связи основного провайдера на сервере в головном офисе, то клиенты это понимают и пытаются переподключиться к тому же IP-адресу сервера, если попытка неудачна, то они используют IP-адрес резервного провайдера головного офиса. На эти переключения уйдет примерно от 1 до 5 минут. Можно ли как-то сделать связь между филиалами так же, как и протокол RSTP (rapid spanning tree protocol) у Cisco? Например, филиал подключается к головному офису 4 линками: 1. с основного IP филиала до основного IP центрального офиса 2. с основного IP филиала до резервного IP центрального офиса 3. с резервного IP филиала до основного IP центрального офиса 4. с резервного IP филиала до резервного IP центрального офиса 1 линк остается активным, а остальные переводятся в режим ожидания. Если что-то случается с линком №1, то линк 2 становится активным, а линк 1 переводится в режим ожидания и пытается настроиться. Когда связь восстановиться, то линк 1 станет активным, а линк 2 уйдет в резерв. может есть какие-то решения, позволяющие так делать?
Ответить \| Правка \| Cообщить модератору

Оглавление

RSTP поверх OpenVPN для связи удаленных филиалов, PavelR, 18:31 , 24-Апр-11, (1)
RSTP поверх OpenVPN для связи удаленных филиалов, sm00th1980, 18:35 , 24-Апр-11, (2)

RSTP поверх OpenVPN для связи удаленных филиалов, dimawar, 20:23 , 24-Апр-11, (3)

RSTP поверх OpenVPN для связи удаленных филиалов, PavelR, 20:29 , 24-Апр-11, (4)

RSTP поверх OpenVPN для связи удаленных филиалов, dimawar, 20:40 , 24-Апр-11, (5)

RSTP поверх OpenVPN для связи удаленных филиалов, sm00th1980, 21:59 , 24-Апр-11, (6)
RSTP поверх OpenVPN для связи удаленных филиалов, яубьютогоктосломалмойпробел, 15:56 , 25-Апр-11, (7)
RSTP поверх OpenVPN для связи удаленных филиалов, PavelR, 16:10 , 25-Апр-11, (8)

RSTP поверх OpenVPN для связи удаленных филиалов, ALex_hha, 17:42 , 25-Апр-11, (9)

RSTP поверх OpenVPN для связи удаленных филиалов, McLeod095, 19:33 , 25-Апр-11, (10)
RSTP поверх OpenVPN для связи удаленных филиалов, dimawar, 17:04 , 26-Апр-11, (11)

Сообщения по теме [Сортировка по времени | RSS]

1. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от PavelR (??) on 24-Апр-11, 18:31

Можно наподнимать линков между серверами (не особо важно, какой тип тунеллирования), а по ним поднять динамическую маршрутизацию, например BGP. Выкрутить таймауты на минимум, и можно получить время переключения в несколько секунд.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от sm00th1980 (ok) on 24-Апр-11, 18:35

RSTP тут у вас вообще не в тему. Это L2-протокол - он вам в данном случае не нужен.
Для резервирования линков между филиалами у циски есть решение на базе IP SLA, route tracking, DMVPN(http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/p...)
и можно будет динамически переключаться между провайдерами - без наличия BGP на бордерах.
Смотреть в эту сторону рекомендую вообщем.
Как раз делал такое решение для одного из заказчиков - с похожей архитектурой сети - тоже HUB и много Spoke-ов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от dimawar (ok) on 24-Апр-11, 20:23

> RSTP тут у вас вообще не в тему. Это L2-протокол - он
> вам в данном случае не нужен.
> Для резервирования линков между филиалами у циски есть решение на базе IP
> SLA, route tracking, DMVPN(http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/p...)
> и можно будет динамически переключаться между провайдерами - без наличия BGP на
> бордерах.
> Смотреть в эту сторону рекомендую вообщем.
> Как раз делал такое решение для одного из заказчиков - с похожей
> архитектурой сети - тоже HUB и много Spoke-ов.
тут цисок маршрутизаторов нет. Надо на серверах это делать.
Поэтому я и рассматриваю решение типа: наподымать кучу линков и настроить динамическую маршрутизацию.
Хотя интересней было бы сделать на L2-протоколе, чтобы без маршрутизации обойтись. Возможно ли такое?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от PavelR (??) on 24-Апр-11, 20:29

> тут цисок маршрутизаторов нет. Надо на серверах это делать.
> Поэтому я и рассматриваю решение типа: наподымать кучу линков и настроить динамическую
> маршрутизацию.
> Хотя интересней было бы сделать на L2-протоколе, чтобы без маршрутизации обойтись. Возможно
> ли такое?
Всё, что вы можете сделать с физическим eth (ну, не ethtool, конечно) вы можете сделать и с tap.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от dimawar (ok) on 24-Апр-11, 20:40

>> тут цисок маршрутизаторов нет. Надо на серверах это делать.
>> Поэтому я и рассматриваю решение типа: наподымать кучу линков и настроить динамическую
>> маршрутизацию.
>> Хотя интересней было бы сделать на L2-протоколе, чтобы без маршрутизации обойтись. Возможно
>> ли такое?
> Всё, что вы можете сделать с физическим eth (ну, не ethtool, конечно)
> вы можете сделать и с tap.
это понятно. А каким образом?
и тут же навевается вопрос, как реализовать линки 2 и 4, при уже поднятых 1 и 3 ?
линки:
   1. с основного IP филиала до основного IP центрального офиса
   2. с основного IP филиала до резервного IP центрального офиса
   3. с резервного IP филиала до основного IP центрального офиса
   4. с резервного IP филиала до резервного IP центрального офиса

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от sm00th1980 (ok) on 24-Апр-11, 21:59

L2 я бы не рекомендовал использовать - большой оверхед может получиться - броадкасты и т.д. - хотя если линки скоростные то можно попробовать - но обычно подобное на L3 - делается.
Для распределённой L2 обычно уже провайдеры MPLS разворачивают - но это уже совсем не ваш уровень цен.
Поэтому если у вас облако L3 между офисами - то нужно строить туннели - поверх L3 и туннели должны быть L3 + развернуть динамическую маршрутизацию видимо(OSPF, RIP, EIGRP - я бы рекомендовал OSPF)
+ сделать каким-то образом отслеживание падения линка в интернет. Хз, как это делают на unix-box-ах. Я бы сделал на cisco - но возможно тут коллеги что-то посоветует отличное от cisco.
Теперь по поводу второго туннеля между spoke и hub. Просто поднимите на хабе - второй внешний адрес(альясом или на другом интерфейсе) - и с этим уже вторым адресом и стройте второй туннель.
Кстати по поводу 2х интерфейсов и отправки трафика через тот интерфейс что пришёл - можно использовать подобие VRF(это на cisco так называется технология), на unix-ах - подобное можно реализовать тоже: искать по ключевым словам multiple route tables.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от яубьютогоктосломалмойпробел on 25-Апр-11, 15:56

Возможно, вам надо что-то типа mesh VPN? Такие есть. Даже опенсорсные. Tinc, n2n, peervpn, ...
Основное их свойство - они стараются гнать информацию напрямую адресату.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от PavelR (??) on 25-Апр-11, 16:10

> это понятно. А каким образом?
> и тут же навевается вопрос, как реализовать линки 2 и 4, при
> уже поднятых 1 и 3 ?
а какие проблемы ?
у OpenVPN есть опции:   --local host   --remote host [port] [proto]
не опенвпн, а ipip/gre - туннели тоже имеют в настройках пару "локальный" + "удаленный"

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от ALex_hha (??) on 25-Апр-11, 17:42

> может есть какие-то решения, позволяющие так делать?
OSPF. На линуксе реализуется с помощью quagga.
http://wiki.sys-adm.org.ua/net/quagga-ospf.php
данная связка отлично проработала несколько лет.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от McLeod095 (??) on 25-Апр-11, 19:33

>> может есть какие-то решения, позволяющие так делать?
> OSPF. На линуксе реализуется с помощью quagga.
> http://wiki.sys-adm.org.ua/net/quagga-ospf.php
> данная связка отлично проработала несколько лет.
Поддерживаю
OSPF отлично справится, мало того даже не придется ничего мудрить.
У самого 3 линка, 1 основной, два других резервных, естественно у каждого своя цена и своя скорость. OSPF нормально разруливает подение основного линка и переключение на резервный и т.д. Время схождения я уменьшил до 10 секунд, чего достаточно для продолжения работы без переподключения (при отказе основного канала, на резервных 40 сек, т.к. проверка связи тоже денег стоит). Могу еще посоветовать, когда будете поднимать скорее всего будете использовать gre туннели, называйте их более одинаково, что бы в iptables прописать что то вроде iptables -A FORWARD -i tun* -s xxx.xxx.xxx.xx -d yyy.yyy.yyy.yyy -j ACCEPT
так соединения рваться не будут.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "RSTP поверх OpenVPN для связи удаленных филиалов" +/–

Сообщение от dimawar (ok) on 26-Апр-11, 17:04

>> может есть какие-то решения, позволяющие так делать?
> OSPF. На линуксе реализуется с помощью quagga.
> http://wiki.sys-adm.org.ua/net/quagga-ospf.php
> данная связка отлично проработала несколько лет.
посмотрел что такое quagga - очень порадовал функционал. В репозиториях SLES 11 sp1 этот пакет присутствует штатно на диске1.
Буду пробовать!

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
Сообщение от PavelR (??) on 24-Апр-11, 18:31
Можно наподнимать линков между серверами (не особо важно, какой тип тунеллирования), а по ним поднять динамическую маршрутизацию, например BGP. Выкрутить таймауты на минимум, и можно получить время переключения в несколько секунд.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

2. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
Сообщение от sm00th1980 (ok) on 24-Апр-11, 18:35
RSTP тут у вас вообще не в тему. Это L2-протокол - он вам в данном случае не нужен. Для резервирования линков между филиалами у циски есть решение на базе IP SLA, route tracking, DMVPN(http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/p...) и можно будет динамически переключаться между провайдерами - без наличия BGP на бордерах. Смотреть в эту сторону рекомендую вообщем. Как раз делал такое решение для одного из заказчиков - с похожей архитектурой сети - тоже HUB и много Spoke-ов.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от dimawar (ok) on 24-Апр-11, 20:23
	> RSTP тут у вас вообще не в тему. Это L2-протокол - он > вам в данном случае не нужен. > Для резервирования линков между филиалами у циски есть решение на базе IP > SLA, route tracking, DMVPN(http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/p...) > и можно будет динамически переключаться между провайдерами - без наличия BGP на > бордерах. > Смотреть в эту сторону рекомендую вообщем. > Как раз делал такое решение для одного из заказчиков - с похожей > архитектурой сети - тоже HUB и много Spoke-ов. тут цисок маршрутизаторов нет. Надо на серверах это делать. Поэтому я и рассматриваю решение типа: наподымать кучу линков и настроить динамическую маршрутизацию. Хотя интересней было бы сделать на L2-протоколе, чтобы без маршрутизации обойтись. Возможно ли такое?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от PavelR (??) on 24-Апр-11, 20:29
	> тут цисок маршрутизаторов нет. Надо на серверах это делать. > Поэтому я и рассматриваю решение типа: наподымать кучу линков и настроить динамическую > маршрутизацию. > Хотя интересней было бы сделать на L2-протоколе, чтобы без маршрутизации обойтись. Возможно > ли такое? Всё, что вы можете сделать с физическим eth (ну, не ethtool, конечно) вы можете сделать и с tap.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от dimawar (ok) on 24-Апр-11, 20:40
	>> тут цисок маршрутизаторов нет. Надо на серверах это делать. >> Поэтому я и рассматриваю решение типа: наподымать кучу линков и настроить динамическую >> маршрутизацию. >> Хотя интересней было бы сделать на L2-протоколе, чтобы без маршрутизации обойтись. Возможно >> ли такое? > Всё, что вы можете сделать с физическим eth (ну, не ethtool, конечно) > вы можете сделать и с tap. это понятно. А каким образом? и тут же навевается вопрос, как реализовать линки 2 и 4, при уже поднятых 1 и 3 ? линки: 1. с основного IP филиала до основного IP центрального офиса 2. с основного IP филиала до резервного IP центрального офиса 3. с резервного IP филиала до основного IP центрального офиса 4. с резервного IP филиала до резервного IP центрального офиса
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от sm00th1980 (ok) on 24-Апр-11, 21:59
	L2 я бы не рекомендовал использовать - большой оверхед может получиться - броадкасты и т.д. - хотя если линки скоростные то можно попробовать - но обычно подобное на L3 - делается. Для распределённой L2 обычно уже провайдеры MPLS разворачивают - но это уже совсем не ваш уровень цен. Поэтому если у вас облако L3 между офисами - то нужно строить туннели - поверх L3 и туннели должны быть L3 + развернуть динамическую маршрутизацию видимо(OSPF, RIP, EIGRP - я бы рекомендовал OSPF) + сделать каким-то образом отслеживание падения линка в интернет. Хз, как это делают на unix-box-ах. Я бы сделал на cisco - но возможно тут коллеги что-то посоветует отличное от cisco. Теперь по поводу второго туннеля между spoke и hub. Просто поднимите на хабе - второй внешний адрес(альясом или на другом интерфейсе) - и с этим уже вторым адресом и стройте второй туннель. Кстати по поводу 2х интерфейсов и отправки трафика через тот интерфейс что пришёл - можно использовать подобие VRF(это на cisco так называется технология), на unix-ах - подобное можно реализовать тоже: искать по ключевым словам multiple route tables.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от яубьютогоктосломалмойпробел on 25-Апр-11, 15:56
	Возможно, вам надо что-то типа mesh VPN? Такие есть. Даже опенсорсные. Tinc, n2n, peervpn, ... Основное их свойство - они стараются гнать информацию напрямую адресату.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	8. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от PavelR (??) on 25-Апр-11, 16:10
	> это понятно. А каким образом? > и тут же навевается вопрос, как реализовать линки 2 и 4, при > уже поднятых 1 и 3 ? а какие проблемы ? у OpenVPN есть опции: --local host --remote host [port] [proto] не опенвпн, а ipip/gre - туннели тоже имеют в настройках пару "локальный" + "удаленный"
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору

9. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
Сообщение от ALex_hha (??) on 25-Апр-11, 17:42
> может есть какие-то решения, позволяющие так делать? OSPF. На линуксе реализуется с помощью quagga. http://wiki.sys-adm.org.ua/net/quagga-ospf.php данная связка отлично проработала несколько лет.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	10. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от McLeod095 (??) on 25-Апр-11, 19:33
	>> может есть какие-то решения, позволяющие так делать? > OSPF. На линуксе реализуется с помощью quagga. > http://wiki.sys-adm.org.ua/net/quagga-ospf.php > данная связка отлично проработала несколько лет. Поддерживаю OSPF отлично справится, мало того даже не придется ничего мудрить. У самого 3 линка, 1 основной, два других резервных, естественно у каждого своя цена и своя скорость. OSPF нормально разруливает подение основного линка и переключение на резервный и т.д. Время схождения я уменьшил до 10 секунд, чего достаточно для продолжения работы без переподключения (при отказе основного канала, на резервных 40 сек, т.к. проверка связи тоже денег стоит). Могу еще посоветовать, когда будете поднимать скорее всего будете использовать gre туннели, называйте их более одинаково, что бы в iptables прописать что то вроде iptables -A FORWARD -i tun* -s xxx.xxx.xxx.xx -d yyy.yyy.yyy.yyy -j ACCEPT так соединения рваться не будут.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "RSTP поверх OpenVPN для связи удаленных филиалов"	+/–
	Сообщение от dimawar (ok) on 26-Апр-11, 17:04
	>> может есть какие-то решения, позволяющие так делать? > OSPF. На линуксе реализуется с помощью quagga. > http://wiki.sys-adm.org.ua/net/quagga-ospf.php > данная связка отлично проработала несколько лет. посмотрел что такое quagga - очень порадовал функционал. В репозиториях SLES 11 sp1 этот пакет присутствует штатно на диске1. Буду пробовать!
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору