Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
wiki.mikrotik.com/wiki/Manual:Routing/OSPF Не рекомендует создавать зоны, если количество маршрутизаторов менее 50. В данном проекте планировалось создать больше 4 зон, по географическому распределению — чтобы паутина vpn была более отказоустойчивая, клиентские сети вообще планировалось роутить через отдельные каналы. Акцент был на быструю работоспособность критически важных приложений, отсюда и куча address list, куда добавляется доступ и правила qos.
Подход у решению задачи очень даже неплох. Расскажете в дву словах почему не удалось реализовать?
Как и писал выше — по человеческим факторам. Я всеми руками за. Подробности описывать не стоит т.к. «это выходит за рамки технической статьи».
Мы же все понимаем, статья написана коротко. А если все это реализовывать уйдет не 1 месяц — будет куча факторов:
— Могут быть проблемы с провайдерами на определенных точках.
— Могут быть проблемы с квалификацией сотрудников как на своей стороне так и на стороне сторонних организаций.
— Прозрачное переключение на работу новой маршрутизации, чтобы пользователь не заметил, тоже отдельный план.
— Тест работы приоритезации трафика, если действительно есть проблемы с пропускной способностью и «дрюкание провайдера, чтобы сумма оплаты=качеству услугу».
— Другие не учтенные факторы (хитрые пользователи, которые бояться контроля и по тихому отключают порты, мыши перегрызающие провода, зашумленный радиоэфир, «забота должностных лиц» и др.).
На все это необходимо время. И самое главное, чем больше круг заинтересованных лиц в реализации конкретного проекта, тем выше шанс успешного завершения.
Мы же все понимаем, статья написана коротко. А если все это реализовывать уйдет не 1 месяц — будет куча факторов:
— Могут быть проблемы с провайдерами на определенных точках.
— Могут быть проблемы с квалификацией сотрудников как на своей стороне так и на стороне сторонних организаций.
— Прозрачное переключение на работу новой маршрутизации, чтобы пользователь не заметил, тоже отдельный план.
— Тест работы приоритезации трафика, если действительно есть проблемы с пропускной способностью и «дрюкание провайдера, чтобы сумма оплаты=качеству услугу».
— Другие не учтенные факторы (хитрые пользователи, которые бояться контроля и по тихому отключают порты, мыши перегрызающие провода, зашумленный радиоэфир, «забота должностных лиц» и др.).
На все это необходимо время. И самое главное, чем больше круг заинтересованных лиц в реализации конкретного проекта, тем выше шанс успешного завершения.
По мне статья какая-то совсем теоретическая.
Мне интереснее было бы увидеть как другие решают такие насущные для меня проблемы:
1. Адресация. Невозможно заранее точно знать сколько будет устройств в филиалах. Неоднократно сталкивался когда из маленького филиала вырастает огромнейший перевалочный центр, и приходится выдавать дополнительные подсети. Сам для небольших филиалов использую 24 маску (внутри филиала режу на меньшие подсети для сегментирования). Это удобно и для единообразия и для остальных, т.к. один филиал это один октек в адресе. Но остается проблема с разрастанием филиала.
Ну и занимать весь rfc1918, как в вашем примере, я бы не стал. Надо максимально компактно подсеть планировать. Чтобы всю вашу подсеть можно было одной маской «накрыть». А то вдруг столкнетесь с слиянием компаний.
2. Вы указали один «центр». Конечно все зависит от задачи, но обычно, лучше иметь два «цетра» и между ними несколько каналов, и не через интернет.
3. Каналы. Интересно посмотреть как у других реализована работа с каналами. Согласитесь, при наличии нескольких каналов, одновременно использовать только один — иррационально! Как происходит переключение при отказе одного из каналов? Как отслеживается качество канала, при переключении на него? Например после отвала основного канала он восстанавливается, но скорость или задержки большие, или «флапает». Нет же смысла на такой канал важный трафик пускать!
4. QOS. Интересно посмотреть реализацию когда в центр, к примеру, с двумя по 500Мбит, лезут 200 филиалов по 10-20Мбит.
5. Вообще не затронута тема централизованной авторизации. Неужто все локально? Хотя бы radius или какие еще есть варианты? Нужно же разделить доступ по уровню и регионам. Тут тоже есть свои нюансы.
6. Единообразный конфиг. Как-то при задаче развертывания большого количества единообразных устройств я даже целое веб-приложение писал, чтобы ввел параметры каналов, внутренние адреса, и получил готовый конфиг. Упрощенная версия доступна на mikrotikwizard.com. К сожалению сайт давно забросил. Если кому интересно, готов отдать в хорошие руки.
Это только часть проблем с которыми сталкиваешься на практике :)
Мне интереснее было бы увидеть как другие решают такие насущные для меня проблемы:
1. Адресация. Невозможно заранее точно знать сколько будет устройств в филиалах. Неоднократно сталкивался когда из маленького филиала вырастает огромнейший перевалочный центр, и приходится выдавать дополнительные подсети. Сам для небольших филиалов использую 24 маску (внутри филиала режу на меньшие подсети для сегментирования). Это удобно и для единообразия и для остальных, т.к. один филиал это один октек в адресе. Но остается проблема с разрастанием филиала.
Ну и занимать весь rfc1918, как в вашем примере, я бы не стал. Надо максимально компактно подсеть планировать. Чтобы всю вашу подсеть можно было одной маской «накрыть». А то вдруг столкнетесь с слиянием компаний.
2. Вы указали один «центр». Конечно все зависит от задачи, но обычно, лучше иметь два «цетра» и между ними несколько каналов, и не через интернет.
3. Каналы. Интересно посмотреть как у других реализована работа с каналами. Согласитесь, при наличии нескольких каналов, одновременно использовать только один — иррационально! Как происходит переключение при отказе одного из каналов? Как отслеживается качество канала, при переключении на него? Например после отвала основного канала он восстанавливается, но скорость или задержки большие, или «флапает». Нет же смысла на такой канал важный трафик пускать!
4. QOS. Интересно посмотреть реализацию когда в центр, к примеру, с двумя по 500Мбит, лезут 200 филиалов по 10-20Мбит.
5. Вообще не затронута тема централизованной авторизации. Неужто все локально? Хотя бы radius или какие еще есть варианты? Нужно же разделить доступ по уровню и регионам. Тут тоже есть свои нюансы.
6. Единообразный конфиг. Как-то при задаче развертывания большого количества единообразных устройств я даже целое веб-приложение писал, чтобы ввел параметры каналов, внутренние адреса, и получил готовый конфиг. Упрощенная версия доступна на mikrotikwizard.com. К сожалению сайт давно забросил. Если кому интересно, готов отдать в хорошие руки.
Это только часть проблем с которыми сталкиваешься на практике :)
Согласен. Спасибо за критику и дополнения. Да, я же написал, что до реализации не дошло. Хотел по началу выставить все настройки, но потом подумал, что будет слишком много и никто не будет разбираться в конфигурациях на основе принятого решения (все сложно!).
1. По адресации. В данном случае все известно и составлен план сетей для устройств. Если надо делать с запасом, то делайте. Ясно что по «красивости» (например вот 192.168.60.0-192.168.63.255 — это один филиал, вот другой и тут раз устройств больше и на одном роутере появляется еще сеть 192.168.250.0/24 -ай некрасиво) и функциональности при должной документации проблем быть не должно.
2. На первой картинке подключены 4 маршрутизатора. Так обозначил центральные (где находятся основные мощности).
3. По каналам, как писал в тз. Могут быть разные момент. Например северные города, где есть городской пиринг и медленный интернет (и очень дорогой). Если в данном регионе есть 20 филиалов- то можно продумать вариант централизации внутри региона и перенаправлять трафик через один маршрутизатор с более толстым каналом, а остальные по городскому пирингу с более дешевыми тарифами. Также по каналам для других сетей- есть часть ресурсов по регионам и на центр, ясно что городить 400 соединений на центр будет не совсем правильно, лучше локализовать и уменьшить нагрузку на основные роутеры.
4. Qos в данном случае рассматривался как на внешние ресурсы, так и на внутренние. Спасибо за замечание.
5. До централизованной авторизации просто не дошли. Но думали использовать сертификаты и локальные учетки, которые будут раскидываться через ansible. По radius тоже смотрели.
6. По единообразному конфигу. Написал как пример, не более. Кто то через тот же ansible сразу генерит.
Для этого и написал, чтобы в комментарии дополнили. Заострил внимание только на тех моментах, которые считаю нужным. Ясно что на написанном все не остановится, будут еще разные проблемы, которые необходимо решать. Отдельно по безопасности, производительности и доступности.
1. По адресации. В данном случае все известно и составлен план сетей для устройств. Если надо делать с запасом, то делайте. Ясно что по «красивости» (например вот 192.168.60.0-192.168.63.255 — это один филиал, вот другой и тут раз устройств больше и на одном роутере появляется еще сеть 192.168.250.0/24 -ай некрасиво) и функциональности при должной документации проблем быть не должно.
2. На первой картинке подключены 4 маршрутизатора. Так обозначил центральные (где находятся основные мощности).
3. По каналам, как писал в тз. Могут быть разные момент. Например северные города, где есть городской пиринг и медленный интернет (и очень дорогой). Если в данном регионе есть 20 филиалов- то можно продумать вариант централизации внутри региона и перенаправлять трафик через один маршрутизатор с более толстым каналом, а остальные по городскому пирингу с более дешевыми тарифами. Также по каналам для других сетей- есть часть ресурсов по регионам и на центр, ясно что городить 400 соединений на центр будет не совсем правильно, лучше локализовать и уменьшить нагрузку на основные роутеры.
4. Qos в данном случае рассматривался как на внешние ресурсы, так и на внутренние. Спасибо за замечание.
5. До централизованной авторизации просто не дошли. Но думали использовать сертификаты и локальные учетки, которые будут раскидываться через ansible. По radius тоже смотрели.
6. По единообразному конфигу. Написал как пример, не более. Кто то через тот же ansible сразу генерит.
Для этого и написал, чтобы в комментарии дополнили. Заострил внимание только на тех моментах, которые считаю нужным. Ясно что на написанном все не остановится, будут еще разные проблемы, которые необходимо решать. Отдельно по безопасности, производительности и доступности.
200 маршрутизаторов без bgp? ospf сойдет с ума.
приоритезацией трафика mpls должен заняться.
Как мы знаем, bgp — протокол политический, а ospf — динамический. Выбор в зависимости от задач.
Видел и админил реализации где BGP — подключение от корневых маршрутизаторов. Далее к корневым подключаются по ospf другая цепочка роутеров — схема рабочая, если надо сделать заодно так, чтобы ограничить маршруты от корневых маршрутизаторов.
Например старая новость по ospf yandex.ru/blog/company/38521
Но сударь, 200 маршрутизаторов — не так много, если грамотно распределить по зонам. Тем более, что современные CCR обладают 2 гб ОЗУ и мощными процессорами.
Видел и админил реализации где BGP — подключение от корневых маршрутизаторов. Далее к корневым подключаются по ospf другая цепочка роутеров — схема рабочая, если надо сделать заодно так, чтобы ограничить маршруты от корневых маршрутизаторов.
Например старая новость по ospf yandex.ru/blog/company/38521
Но сударь, 200 маршрутизаторов — не так много, если грамотно распределить по зонам. Тем более, что современные CCR обладают 2 гб ОЗУ и мощными процессорами.
Есть опыт стабильной работы OSPF на более чем 400 устройствах.
Видимо вы не умеете его «готовить» :)
Все с наступающим Новым Годом!
Видимо вы не умеете его «готовить» :)
Все с наступающим Новым Годом!
Не сойдет.
Бестпрактисес от циски про 50 рутеров в зоне были написаны 20 лет и исходили из производительности CPU тех рутеров.
Современные маршрутизаторы на порядки производительней и способны почти мгновенно пересчитывать LSDB.
Кроме того мы не увидели топологии и разделения на зоны поэтому не можем оценить насколько правильно ТС решает эту задачу, тем более что он ее и не решает :)
У себя использую BGP в транспорте (типа андерлей) а внутри vpn тунелей как раз OSPF
Бестпрактисес от циски про 50 рутеров в зоне были написаны 20 лет и исходили из производительности CPU тех рутеров.
Современные маршрутизаторы на порядки производительней и способны почти мгновенно пересчитывать LSDB.
Кроме того мы не увидели топологии и разделения на зоны поэтому не можем оценить насколько правильно ТС решает эту задачу, тем более что он ее и не решает :)
У себя использую BGP в транспорте (типа андерлей) а внутри vpn тунелей как раз OSPF
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой нереализованный проект. Сеть из 200 маршрутизаторов MikroTik