Serejka Опубликовано 25 июня, 2014 (изменено) · Жалоба Поставлена задача проработки вариантов реорганизации существующей сети. В данный момент схема включения территориальных узлов следующая: 1. На центральном узле стоит linux сервер, который выступает сервером туннелей 2. В территориальных узлах стоят модифицированные OpenWRT роутеры, которые осуществляют маршрутизацию трафика полученного от транспортного провайдера и выступающие в роли L2TP client (поднимают туннели на сервер) Собственно рассматриваем варианты замены линукс сервера на специализированную железяку(покруче), а OpenWRT роутеров на специализированные желязки(попроще) само собой желательно одного вендора. Есть одно обязательное требование к железякам. На центральном узле железка обязательно должна поддерживать поднятие множества туннелей с одним VLAN ID и общение этих клиентов между собой. Слышал что это возможно организовать на Mikrotik, но вот на каких конкретно моделях это возможно не знаю. Можно рассмотреть и других производителей. Подскажите кто знает. Изменено 25 июня, 2014 пользователем Serejka Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ChargeSet Опубликовано 25 июня, 2014 · Жалоба А dot1q и opt82 не рассматриваете? На микротиках можно любых с лицензией l5 и старше, ЕМНИП. Это софтроутеры с мышеориентированным интерфейсом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serejka Опубликовано 25 июня, 2014 · Жалоба А dot1q и opt82 не рассматриваете? На микротиках можно любых с лицензией l5 и старше, ЕМНИП. Это софтроутеры с мышеориентированным интерфейсом. По поводу opt82 вроде как не наш случай. На счёт dot1q не совсем понял что имеется в виду. 802.1q у нас и так используется, я же в изначальном сообщении озвучил требование к оборудованию, что узловая железяка должна обеспечивать поднятие множества туннелей для членов с одиннаковым VLAN ID и их взаимодействие между собой. На счёт любых микротиков с лицензией L5+, конкретно это где-то почитать можно? Или же основано на собственном опыте, если на опыте то насколько подобная схема была? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 25 июня, 2014 · Жалоба Есть одно обязательное требование к железякам. На центральном узле железка обязательно должна поддерживать поднятие множества туннелей с одним VLAN ID и общение этих клиентов между собой. Не надо так делать, обречете на вечные проблемы при большом количестве устройств. Например все каналы до всех устройств 100 мегабит, до одного устройства канал 10 мегабит, тут вдруг все остальные начали гнать широковещательный трафик или что-то подобное на скорости 20 мегабит, естественно все клиенты отработали нормально, а тот, у которого 10 мегабит отрубился. Поэтому желательно рассмотреть возможность изменения ТЗ и осуществлять пропуск L3 трафика, это и в настройке намного проще. На счёт любых микротиков с лицензией L5+, конкретно это где-то почитать можно? Или же основано на собственном опыте, если на опыте то насколько подобная схема была? У него есть 2 возможности реализовать вашу схему: 1. BCP - когда PPP туннели автоматически бриджуются при подключении абонента, никаких дополнительных манипуляций не требуется. Минусы - управление в этом же канале, случись что не сможете до управления достучаться. 2. EoIP поверх PPP - выдаете удаленным устройствам адреса, поверх создаете EoIP туннель, который со стороны центра бриджуете с бриджем, а с удаленной с нужными сетевыми интерфейсами. На микротиках можно любых с лицензией l5 и старше, ЕМНИП. Это софтроутеры с мышеориентированным интерфейсом. При чем тут L5? У него ограничение на количество подключенных устройств по PPP, то есть если в центре поставить L5 или L6, то все взлетит, да и при L4 тоже взлетит, только ограничение будет на 200 клиентов. На оконечных устройствах достаточно и L4. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serejka Опубликовано 26 июня, 2014 · Жалоба Есть одно обязательное требование к железякам. На центральном узле железка обязательно должна поддерживать поднятие множества туннелей с одним VLAN ID и общение этих клиентов между собой. Не надо так делать, обречете на вечные проблемы при большом количестве устройств. Например все каналы до всех устройств 100 мегабит, до одного устройства канал 10 мегабит, тут вдруг все остальные начали гнать широковещательный трафик или что-то подобное на скорости 20 мегабит, естественно все клиенты отработали нормально, а тот, у которого 10 мегабит отрубился. Поэтому желательно рассмотреть возможность изменения ТЗ и осуществлять пропуск L3 трафика, это и в настройке намного проще. На удалённых устройствах должен быть целый букет VLAN-ов, не повторяющихся между устройствами, из стабильно повторяющегося ADMIN VLAN. Кроме него есть буквально пара VLAN с одиннаковыми ID, которые нужно забриджевать между собой, например сеть корпоративной IP телефонии. На счёт вариантов реализации, спасибо что направили в какую сторону копать, поизучаю внимательнее, на первый взгляд EoIP выглядит предпочтительнее, и больше похоже на текущую схему. Дополнительно интересует вопрос с наличием у Микротиков сертификатов РФ. Нам в принципе WiFi не нужен. Посоветовали присмотреться к связке оборудования CCR1036(узел) + RB951-2HnD(территории). Есть какой опыт по этому железу? Стабильность работы, неприхотливость к обслуживанию и прочее? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ChargeSet Опубликовано 26 июня, 2014 · Жалоба Работает такая связка вполне. Только вот про ССС у МТ не слышал никогда, разве что дилеры могли заморочиться. Стабильность - настроил, сделал бэкап конфига, сбросил железку и залил конфиг. Загадочные глюки МТ загадочны. И не стоит спешить обновляться в 6.1х ветку, она сырая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 26 июня, 2014 · Жалоба Работает такая связка вполне. Только вот про ССС у МТ не слышал никогда, разве что дилеры могли заморочиться. Стабильность - настроил, сделал бэкап конфига, сбросил железку и залил конфиг. Загадочные глюки МТ загадочны. И не стоит спешить обновляться в 6.1х ветку, она сырая. Важно - взяли новую железку, зашли первый раз на нее, она предложила сбросить конфиг, жмете сброс. После загрузки заходите в system reset-configuration и делаете полный сброс без дефолтного конфига. Настроили одну клиентскую железку, слили конфиг в текстовом виде, удалили все лишнее, вроде l2mtu у бриджей и всякие упоминания про хотспот и т.п. На удалённых устройствах должен быть целый букет VLAN-ов, не повторяющихся между устройствами, из стабильно повторяющегося ADMIN VLAN. Вам надо пересмотреть структуру сети, если основная задача это осуществлять связь с удаленными офисами, то самое оптимальное переход на L3 сеть с OSPF, при этом в каждом офисе будете выделять определенные сети - для компьютеров, принтеров, телефонии и т.п. Кроме него есть буквально пара VLAN с одиннаковыми ID, которые нужно забриджевать между собой, например сеть корпоративной IP телефонии. Телефонию выгодно по L3 пускать, тогда легко делать приоритеты - ведь IP адреса телефонов вы знаете. На счёт вариантов реализации, спасибо что направили в какую сторону копать, поизучаю внимательнее, на первый взгляд EoIP выглядит предпочтительнее, и больше похоже на текущую схему. Про L2 я уже писал, когда будет большое количество устройств, например 30-50 и более, начнутся различные сложно решаемые проблемы по уменьшению мусорного трафика. Дополнительно интересует вопрос с наличием у Микротиков сертификатов РФ. Нам в принципе WiFi не нужен. Сертификатов в данный момент нет. Посоветовали присмотреться к связке оборудования CCR1036(узел) + RB951-2HnD(территории). На узел можно поставить и 9 ядерный CCR, RB951-2HnD на данный момент самый производительный роутер из бюджетных, по производительности аналог RB2011, только портов меньше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 26 июня, 2014 · Жалоба Serejka как я вам уже рассказывал, туннелировать л2 поверх л3 можно двумя способами (если речь идет о микротик): mpls eoip с первым в реализации микротика я не сталкивался, последнее работает, но vendor lock. В вашем случае действительно необходим л3. Ну а про надежность данного решения, все было сказано в скайпе .) то самое оптимальное переход на L3 сеть с OSPF л3 с оспф то оптимально, но не в случае микротика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serejka Опубликовано 27 июня, 2014 · Жалоба Да спасибо Дмитрию (myst), поделился богатым опытом по микротикам в том числе :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 27 июня, 2014 · Жалоба л3 с оспф то оптимально, но не в случае микротика. Да ладно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serejka Опубликовано 27 июня, 2014 (изменено) · Жалоба Может есть у кого опыт работы с оборудованием NSG. После того как Дмитрий в скайпе раскритиковал Микротик, просматриваю альтернативы на уровне L2. В общим словах, потенциал L2 транспорта на NSG Подробнее с картинками через туннели Смотрится многообещающе, интересно что в реальности. Изменено 27 июня, 2014 пользователем Serejka Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vovannovig Опубликовано 27 июня, 2014 · Жалоба L2 еще можно получить с помощью OpenVPN - рабочий вариант но нагрузка больше(правда не сравнивал с EoIP и OpenVPN без шифрования) Сам ловил глючи EoIP если строить поверх SSTP/PPTP/L2TP(даже пробовал) но это проверялось в начальных релизах 6й версии и как сейчас не знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 27 июня, 2014 · Жалоба Сам ловил глючи EoIP если строить поверх SSTP/PPTP/L2TP(даже пробовал) но это проверялось в начальных релизах 6й версии и как сейчас не знаю. Нет там никаких глюков. В некоторых версиях не работал SSTP, а все остальное всегда работало. Проблемы могут быть если кто-то вручную начинает баловаться всякими там change mss и прочими не нужными вещами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serejka Опубликовано 28 июня, 2014 · Жалоба Неужели никто NSG не ковырял? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...