Всем привет. Данная статья рассчитана на тех, у кого в парке находится много устройств микротик, и кому хочется сделать максимальную унификацию, чтобы не подключаться на каждое устройство в отдельности. В этой статье я опишу проект, который, к сожалению, не дошел до боевых условий из-за человеческих факторов. Вкратце: более 200 маршрутизаторов, быстрая настройка и обучение персонала, унификация по регионам, фильтрация сетей и определенных хостов, возможность легкого добавления правил на все устройства, логирование и контроль доступа.
То, что описано ниже не претендует на готовый кейс, но надеюсь пригодится вам при планировании своих сетей и минимизации ошибок. Возможно, некоторые пункты и решения вам покажутся не совсем правильными – если так, пишите в комментарии. Критика в данном случае будет опытом в общую копилку. Поэтому, читатель, загляни в комментарии, возможно, автор допустил грубую ошибку – сообщество поможет.
Количество маршрутизаторов 200-300, разбросаны по разным городам с разным качеством интернет соединения. Необходимо сделать все красиво и доступно разъяснить локальным админам, как будет все работать.
Итак, с чего же начинается любой проект. Конечно же, с ТЗ.
- Организация плана сетей по всем филиалам согласно требованиям заказчика, сегментация сетей (от 3 до 20 сетей в филиалах в зависимости от численности устройств).
- Настройка устройств в каждом филиале. Проверка реальной пропускной скорости провайдера в разных условиях работы.
- Организация защиты устройств, управление по белому списку, автодектирование атак с автозанесением в черный список на определенный промежуток времени, минимализация использования различных технических средств, используемых для перехвата доступа управления и отказа от обслуживания.
- Организация защищенных vpn соединений с фильтрацией по сетям согласно требованиям заказчика. Минимум 3 vpn соединения с каждого филиала до центра.
- На основе пункта 1, 2. Выбрать оптимальные пути построения отказоустойчивых vpn. Технологию динамической маршрутизации при корректном обосновании может выбрать исполнитель.
- Организация приоритизации трафика по протоколам, портам, хостам и другим специфичным сервисам которые использует заказчик. (VOIP, хосты с важными сервисами)
- Организация мониторинга и логирования событий маршрутизаторов для реагирования сотрудников технической поддержки.
Как мы понимаем, в ряде случаев ТЗ составляется от требований. Эти требования я сформулировал самостоятельно, выслушав основные проблемы. Допускал возможность, что выполнением этих пунктов, может заняться кто- то другой.
Какие инструменты будут использоваться для выполнения данных требований:
- Стэк ELK (спустя некоторое время, пришло понимание, что вместо logstash будет использоваться fluentd).
- Ansible. Для удобства администрирования и разделения доступа будем использовать AWX.
- GITLAB. Тут пояснять не надо. Куда без контроля версий наших конфигов.
- PowerShell. Будет простенький скрипт для первоначальной генерации конфига.
- Доку вики, для написания документации и руководств. В данном случаем, используем habr.com.
- Мониторинг будет осуществляться через zabbix. Там же будет нарисована схема подключений для общего понимания.
Моменты настройки EFK
По первому пункту опишу только идеологию, по которой будут строиться индексы. Есть много
прекрасных статей по настройке и приему логов с устройств под управлением mikrotik.
Остановлюсь на некоторых моментах:
1. Согласно схеме, стоит продумать прием логов с разных мест и по разным портам. Для этого мы будем использовать агрегатор логов. А также нам хочется сделать универсальные графики для всех маршрутизаторов с возможностью разделения доступа. Тогда индексы строим следующим образом:
tвот кусок конфига с fluentd
type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts elasticsearch:9200
port 9200
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts elasticsearch:9200
port 9200
Таким образом мы можем объединить роутеры и сегментировать согласно плана- mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Зачем так усложнять? Мы понимаем, что у нас будет 200 и более устройств. За всем не уследить. С 6.8 версии elasticsearch нам доступны настройки безопасности (без покупки лицензии), тем самым, мы можем распределить права на просмотр между сотрудниками тех.поддержки или локальными системными администраторами.
Таблицы, графики – тут уже надо просто договорится — либо использовать однообразные, либо каждый делает так, как будет удобно ему.
2. По логированию. Если в правилах firewall включаем log, то имена делаем без пробелов. Видно, что, использовав простой конфиг в fluentd, мы можем фильтровать данные и делать удобные панели. На картинке ниже- мой домашний роутер.
3. По занимаемому месту и логам. В среднем, при 1000 сообщений в час, логи занимают по 2-3 мб в сутки, что, согласитесь, не так много. Версия elasticsearch 7.5.
ANSIBLE.AWX
К нашему счастью у нас есть, готовый модуль для routeros
Я указал про AWX, но команды ниже только про ansible в чистом виде – думаю, для тех, кто работал с ansible, не возникнет проблем с использованием через gui awx.
Признаюсь честно, до этого смотрел другие гайды, где использовали ssh, и у всех были разные проблемы с временем ответа и еще куча других проблем. Повторюсь, до боя не дошло ?, воспринимайте данную информацию как эксперимент, не дошедший дальше стенда из 20 роутеров.
Нам необходимо использовать сертификат или учетку. Тут решать вам, я за сертификаты. Некоторый тонкий момент по правам. Даю права на write – хотя бы “reset config” сделать не получится.
По генерации, копированию сертификата и импорту не должно возникнуть проблем:
Вкратце листинг команд
На вашем ПК
ssh-keygen -t RSA, отвечаем на вопросы, сохраняем ключ.
Копируем на mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Предварительно надо создать учетку и выделить ей права.
Проверяем подключение по сертификату
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Прописываем vi /etc/ansible/hosts
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
ssh-keygen -t RSA, отвечаем на вопросы, сохраняем ключ.
Копируем на mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Предварительно надо создать учетку и выделить ей права.
Проверяем подключение по сертификату
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Прописываем vi /etc/ansible/hosts
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
Ну и пример playbook:
— name: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
tasks:
— name: add Work_sites
routeros_command:
commands:
— /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip firewall address-list add address=habr.com list=work_sites comment=for_habr
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
tasks:
— name: add Work_sites
routeros_command:
commands:
— /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip firewall address-list add address=habr.com list=work_sites comment=for_habr
Как видно из приведенной выше конфигурации, составление своих playbook несложное дело. Достаточно хорошо освоить cli mikrotik. Представим ситуацию, когда на всех роутерах надо убрать address list с определенными данными, тогда:
Найти и удалить
/ip firewal address-list remove [find where list=«gov.ru»]
Я намерено не вставил сюда весь листинг файрвола т.к. он будет индивидуален для каждого проекта. Но одно могу сказать точно, используйте только address list.
По GITLAB все ясно. Не буду останавливаться на этом моменте. Все красиво по отдельным tasks, templates, handlers.
Powershell
Тут будут 3 файлика. Почему powershell? Инструмент для генерации конфигов можно выбирать любой, кому что удобнее. В данном случае у всех на пк стоит windows, поэтому зачем делать на bash, когда удобнее powershell. Кому что удобнее.
Непосредственно сам скрипт (простой и понятный):
[cmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPADDRESS,
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)]
[string]$BWorknets,
[Parameter(Mandatory=$true)]
[string]$CWorknets,
[Parameter(Mandatory=$true)]
[string]$BVoipNets,
[Parameter(Mandatory=$true)]
[string]$CVoipNets,
[Parameter(Mandatory=$true)]
[string]$CClientss,
[Parameter(Mandatory=$true)]
[string]$BVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$CVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$NAMEROUTER,
[Parameter(Mandatory=$true)]
[string]$ServerCertificates,
[Parameter(Mandatory=$true)]
[string]$infile,
[Parameter(Mandatory=$true)]
[string]$outfile
)
Get-Content $infile | Foreach-Object {$_.Replace(«EXTERNIP», $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace(«EXTROUTE», $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace(«BWorknet», $BWorknets)} |
Foreach-Object {$_.Replace(«CWorknet», $CWorknets)} |
Foreach-Object {$_.Replace(«BVoipNet», $BVoipNets)} |
Foreach-Object {$_.Replace(«CVoipNet», $CVoipNets)} |
Foreach-Object {$_.Replace(«CClients», $CClientss)} |
Foreach-Object {$_.Replace(«BVPNWORK», $BVPNWORKs)} |
Foreach-Object {$_.Replace(«CVPNWORK», $CVPNWORKs)} |
Foreach-Object {$_.Replace(«BVPNCLIENTS», $BVPNCLIENTSs)} |
Foreach-Object {$_.Replace(«CVPNCLIENTS», $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace(«MYNAMERROUTER», $NAMEROUTER)} |
Foreach-Object {$_.Replace(«ServerCertificate», $ServerCertificates)} | Set-Content $outfile
Param(
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPADDRESS,
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)]
[string]$BWorknets,
[Parameter(Mandatory=$true)]
[string]$CWorknets,
[Parameter(Mandatory=$true)]
[string]$BVoipNets,
[Parameter(Mandatory=$true)]
[string]$CVoipNets,
[Parameter(Mandatory=$true)]
[string]$CClientss,
[Parameter(Mandatory=$true)]
[string]$BVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$CVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$NAMEROUTER,
[Parameter(Mandatory=$true)]
[string]$ServerCertificates,
[Parameter(Mandatory=$true)]
[string]$infile,
[Parameter(Mandatory=$true)]
[string]$outfile
)
Get-Content $infile | Foreach-Object {$_.Replace(«EXTERNIP», $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace(«EXTROUTE», $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace(«BWorknet», $BWorknets)} |
Foreach-Object {$_.Replace(«CWorknet», $CWorknets)} |
Foreach-Object {$_.Replace(«BVoipNet», $BVoipNets)} |
Foreach-Object {$_.Replace(«CVoipNet», $CVoipNets)} |
Foreach-Object {$_.Replace(«CClients», $CClientss)} |
Foreach-Object {$_.Replace(«BVPNWORK», $BVPNWORKs)} |
Foreach-Object {$_.Replace(«CVPNWORK», $CVPNWORKs)} |
Foreach-Object {$_.Replace(«BVPNCLIENTS», $BVPNCLIENTSs)} |
Foreach-Object {$_.Replace(«CVPNCLIENTS», $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace(«MYNAMERROUTER», $NAMEROUTER)} |
Foreach-Object {$_.Replace(«ServerCertificate», $ServerCertificates)} | Set-Content $outfile
Прошу меня простить, не могу выложить все правила т.к. это будет не совсем красиво. Правила можете составить сами, руководствуясь лучшими практиками.
Например, вот список ссылок по которым руководствовался я:
wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Manual:OSPF-examples
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual:Winbox
wiki.mikrotik.com/wiki/Manual:Upgrading_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack — тут надо знать, что при включении fasttrack не будут работать правила приоритезации и шейпинга трафика – полезно для слабых устройств.
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Manual:OSPF-examples
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual:Winbox
wiki.mikrotik.com/wiki/Manual:Upgrading_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack — тут надо знать, что при включении fasttrack не будут работать правила приоритезации и шейпинга трафика – полезно для слабых устройств.
Условные обозначения по переменным:
За пример взяты следующие сети:
192.168.0.0/24 рабочая сеть
172.22.4.0/24 VOIP сеть
10.0.0.0/24 сеть для клиентов без доступа к локальной сети
192.168.255.0/24 VPN сеть для крупных филиалов
172.19.255.0/24 VPN сеть для мелких
Адрес сети состоит из 4-х десятичных чисел, соответственно A.B.C.D, по такому же принципу работает замена, если при запуске запрашивает B, то, значит надо ввести для сети 192.168.0.0/24 номер 0, а для C = 0.
$EXTERNALIPADDRESS — выделенный адрес от провайдера.
$EXTERNALIPROUTE — маршрут по умолчанию на сеть 0.0.0.0/0
$BWorknets — Рабочая сеть, в нашем примере здесь будет 168
$CWorknets — Рабочая сеть, в нашем примере здесь будет 0
$BVoipNets — VOIP сеть в нашем примере здесь 22
$CVoipNets — VOIP сеть в нашем примере здесь 4
$CClientss — Сеть для клиентов – доступ только в интернет, в нашем случае здесь 0
$BVPNWORKs — VPN сеть для крупных филиалов, в нашем примере 20
$CVPNWORKs — VPN сеть для крупных филиалов, в нашем примере 255
$BVPNCLIENTS — VPN сеть для мелких филиалов, значит 19
$CVPNCLIENTS — VPN сеть для мелких филиалов, значит 255
$NAMEROUTER — имя роутера
$ServerCertificate — имя сертификата, который предварительно импортируете
$infile — Указать путь к файлу с которого будем считывать конфиг, например D:\config.txt (лучше английский путь без кавычек и пробелов)
$outfile — указать путь, где сохранить, например D:\MT-test.txt
192.168.0.0/24 рабочая сеть
172.22.4.0/24 VOIP сеть
10.0.0.0/24 сеть для клиентов без доступа к локальной сети
192.168.255.0/24 VPN сеть для крупных филиалов
172.19.255.0/24 VPN сеть для мелких
Адрес сети состоит из 4-х десятичных чисел, соответственно A.B.C.D, по такому же принципу работает замена, если при запуске запрашивает B, то, значит надо ввести для сети 192.168.0.0/24 номер 0, а для C = 0.
$EXTERNALIPADDRESS — выделенный адрес от провайдера.
$EXTERNALIPROUTE — маршрут по умолчанию на сеть 0.0.0.0/0
$BWorknets — Рабочая сеть, в нашем примере здесь будет 168
$CWorknets — Рабочая сеть, в нашем примере здесь будет 0
$BVoipNets — VOIP сеть в нашем примере здесь 22
$CVoipNets — VOIP сеть в нашем примере здесь 4
$CClientss — Сеть для клиентов – доступ только в интернет, в нашем случае здесь 0
$BVPNWORKs — VPN сеть для крупных филиалов, в нашем примере 20
$CVPNWORKs — VPN сеть для крупных филиалов, в нашем примере 255
$BVPNCLIENTS — VPN сеть для мелких филиалов, значит 19
$CVPNCLIENTS — VPN сеть для мелких филиалов, значит 255
$NAMEROUTER — имя роутера
$ServerCertificate — имя сертификата, который предварительно импортируете
$infile — Указать путь к файлу с которого будем считывать конфиг, например D:\config.txt (лучше английский путь без кавычек и пробелов)
$outfile — указать путь, где сохранить, например D:\MT-test.txt
Я намеренно изменил адреса в примерах по понятным причинам.
Пропустил пункт по детектированию атак и аномальному поведению – это заслуживает отдельной статьи. Но стоит указать, что в данной категории можно использовать значения данных мониторинга с Zabbix + отработанные данные curl с elasticsearch.
На каких моментах необходимо заострить внимание:
- План сетей. Лучше составить сразу в читаемом виде. Вполне хватит excel. К сожалению, очень часто вижу, что сети составляются по принципу «Появился новый филиал, вот вам /24». Никто не выясняет, сколько предполагается устройств в данном месте и будет ли дальнейший рост. Например, открылся небольшой магазин, в котором изначально понятно, что устройство будет не более 10, зачем выделять /24? По большим филиалам – наоборот, выделяют /24, а устройств становится 500 — просто добавить сеть можно, но хочется все продумать сразу.
- Правила фильтрации. Если по проекту предполагается, что будет разделение сетей и максимальная сегментация. Best Practice со временем меняются. Ранее делили сеть ПК и сеть принтеров, сейчас вполне нормально не делить эти сети. Стоит использовать здравый смысл и не плодить множество подсетей там, где они не нужны и не объединять в одну сеть все устройства.
- «Золотые» настройки на всех роутерах. Т.е. если вы определились с планом. Стоит сразу все предусмотреть и постараться сделать так, чтобы все настройки были идентичны- были только разные address list и ip адреса. В случае возникающих проблем, время на отладку будет меньше.
- Организационные моменты не менее важны, чем технические. Часто ленивые сотрудники выполняют указанные рекомендации «вручную», не используя готовые конфигурации и скрипты, что по итогу приводит к проблемам на пустом месте.
По динамической маршрутизации. Использовался OSPF с зональным делением. Но ведь это тестовый стенд, в боевых условиях такие вещи настраивать интереснее.
Надеюсь никто не расстроился, что я не выложил конфигурации маршрутизаторов. Думаю, что вполне хватит ссылок, а далее все зависит от требований. И конечно тесты, необходимо больше тестов.
Желаю всем в новом году реализовать свои проекты. Да прибудет с вами access granted!!!
AcidVenom
4 эрии в сумме?
iwram Автор
wiki.mikrotik.com/wiki/Manual:Routing/OSPF Не рекомендует создавать зоны, если количество маршрутизаторов менее 50. В данном проекте планировалось создать больше 4 зон, по географическому распределению — чтобы паутина vpn была более отказоустойчивая, клиентские сети вообще планировалось роутить через отдельные каналы. Акцент был на быструю работоспособность критически важных приложений, отсюда и куча address list, куда добавляется доступ и правила qos.
AcidVenom
Cisco Best Practice. На MTCRE тоже рассказывают о <50.
iwram Автор
Спасибо за дополнение.
igorsd
Подход у решению задачи очень даже неплох. Расскажете в дву словах почему не удалось реализовать?
iwram Автор
Как и писал выше — по человеческим факторам. Я всеми руками за. Подробности описывать не стоит т.к. «это выходит за рамки технической статьи».
Мы же все понимаем, статья написана коротко. А если все это реализовывать уйдет не 1 месяц — будет куча факторов:
— Могут быть проблемы с провайдерами на определенных точках.
— Могут быть проблемы с квалификацией сотрудников как на своей стороне так и на стороне сторонних организаций.
— Прозрачное переключение на работу новой маршрутизации, чтобы пользователь не заметил, тоже отдельный план.
— Тест работы приоритезации трафика, если действительно есть проблемы с пропускной способностью и «дрюкание провайдера, чтобы сумма оплаты=качеству услугу».
— Другие не учтенные факторы (хитрые пользователи, которые бояться контроля и по тихому отключают порты, мыши перегрызающие провода, зашумленный радиоэфир, «забота должностных лиц» и др.).
На все это необходимо время. И самое главное, чем больше круг заинтересованных лиц в реализации конкретного проекта, тем выше шанс успешного завершения.
algerka
По мне статья какая-то совсем теоретическая.
Мне интереснее было бы увидеть как другие решают такие насущные для меня проблемы:
1. Адресация. Невозможно заранее точно знать сколько будет устройств в филиалах. Неоднократно сталкивался когда из маленького филиала вырастает огромнейший перевалочный центр, и приходится выдавать дополнительные подсети. Сам для небольших филиалов использую 24 маску (внутри филиала режу на меньшие подсети для сегментирования). Это удобно и для единообразия и для остальных, т.к. один филиал это один октек в адресе. Но остается проблема с разрастанием филиала.
Ну и занимать весь rfc1918, как в вашем примере, я бы не стал. Надо максимально компактно подсеть планировать. Чтобы всю вашу подсеть можно было одной маской «накрыть». А то вдруг столкнетесь с слиянием компаний.
2. Вы указали один «центр». Конечно все зависит от задачи, но обычно, лучше иметь два «цетра» и между ними несколько каналов, и не через интернет.
3. Каналы. Интересно посмотреть как у других реализована работа с каналами. Согласитесь, при наличии нескольких каналов, одновременно использовать только один — иррационально! Как происходит переключение при отказе одного из каналов? Как отслеживается качество канала, при переключении на него? Например после отвала основного канала он восстанавливается, но скорость или задержки большие, или «флапает». Нет же смысла на такой канал важный трафик пускать!
4. QOS. Интересно посмотреть реализацию когда в центр, к примеру, с двумя по 500Мбит, лезут 200 филиалов по 10-20Мбит.
5. Вообще не затронута тема централизованной авторизации. Неужто все локально? Хотя бы radius или какие еще есть варианты? Нужно же разделить доступ по уровню и регионам. Тут тоже есть свои нюансы.
6. Единообразный конфиг. Как-то при задаче развертывания большого количества единообразных устройств я даже целое веб-приложение писал, чтобы ввел параметры каналов, внутренние адреса, и получил готовый конфиг. Упрощенная версия доступна на mikrotikwizard.com. К сожалению сайт давно забросил. Если кому интересно, готов отдать в хорошие руки.
Это только часть проблем с которыми сталкиваешься на практике :)
iwram Автор
Согласен. Спасибо за критику и дополнения. Да, я же написал, что до реализации не дошло. Хотел по началу выставить все настройки, но потом подумал, что будет слишком много и никто не будет разбираться в конфигурациях на основе принятого решения (все сложно!).
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 сразу генерит.
Для этого и написал, чтобы в комментарии дополнили. Заострил внимание только на тех моментах, которые считаю нужным. Ясно что на написанном все не остановится, будут еще разные проблемы, которые необходимо решать. Отдельно по безопасности, производительности и доступности.
AcidVenom
Просто напомню, что в текущей реализации ECMP не поддерживает Check Getaway. Нужно выходить из положения как-то еще. Делать реверс прокси с чек гейтвей, а уже сверху ECMP (например, не уверен).
algerka
Я пока, лучше хорошего скрипта не придумал. Скрипт проверяет наличие и качество каналов, а там уже, регулирует критичный или вторичный трафик.
garriad
200 маршрутизаторов без bgp? ospf сойдет с ума.
приоритезацией трафика mpls должен заняться.
iwram Автор
Как мы знаем, bgp — протокол политический, а ospf — динамический. Выбор в зависимости от задач.
Видел и админил реализации где BGP — подключение от корневых маршрутизаторов. Далее к корневым подключаются по ospf другая цепочка роутеров — схема рабочая, если надо сделать заодно так, чтобы ограничить маршруты от корневых маршрутизаторов.
Например старая новость по ospf yandex.ru/blog/company/38521
Но сударь, 200 маршрутизаторов — не так много, если грамотно распределить по зонам. Тем более, что современные CCR обладают 2 гб ОЗУ и мощными процессорами.
algerka
Есть опыт стабильной работы OSPF на более чем 400 устройствах.
Видимо вы не умеете его «готовить» :)
Все с наступающим Новым Годом!
iddqda
Не сойдет.
Бестпрактисес от циски про 50 рутеров в зоне были написаны 20 лет и исходили из производительности CPU тех рутеров.
Современные маршрутизаторы на порядки производительней и способны почти мгновенно пересчитывать LSDB.
Кроме того мы не увидели топологии и разделения на зоны поэтому не можем оценить насколько правильно ТС решает эту задачу, тем более что он ее и не решает :)
У себя использую BGP в транспорте (типа андерлей) а внутри vpn тунелей как раз OSPF