# SHX Network Infrastructure ## Обзор сети Данный проект описывает сетевую инфраструктуру с двумя провайдерами интернет-соединения и множественными GRE туннелями для обеспечения отказоустойчивости и географического распределения. ## Архитектура сети ### Основная схема (обновлено) ```mermaid graph TB subgraph "Шлюз (Gateway)" GW[Основной шлюз] end subgraph "Провайдеры" MTS[МТС] RTK[Ростелеком] end subgraph "GRE Туннели" subgraph "Ростелеком (RTK)" RTK1[MSK-VPSVILLE-RTK] RTK2[MSK-IHOR-RTK] RTK3[SWE-HIPHOST-RTK] end subgraph "МТС (MTS)" MTS1[MSK-VPSVILLE-MTS] MTS2[MSK-IHOR-MTS] MTS3[SWE-HIPHOST-MTS] end end subgraph "Удаленные узлы" VPSVILLE[VPSVILLE] IHOR[IHOR] HIPHOST["HIPHOST
SWE"] end GW --> MTS GW --> RTK MTS --> MTS1 MTS --> MTS2 MTS --> MTS3 RTK --> RTK1 RTK --> RTK2 RTK --> RTK3 MTS1 --> VPSVILLE MTS2 --> IHOR MTS3 --> HIPHOST RTK1 --> VPSVILLE RTK2 --> IHOR RTK3 --> HIPHOST %% Новое: GRE SWE-HIPHOST от всех МСК серверов VPSVILLE -- GRE SWE-HIPHOST --> HIPHOST IHOR -- GRE SWE-HIPHOST --> HIPHOST style GW fill:#e1f5fe style MTS fill:#ffebee style RTK fill:#e8f5e8 style VPSVILLE fill:#fff3e0 style IHOR fill:#fff3e0 style HIPHOST fill:#fff3e0 ``` ### Детальная схема туннелей (обновлено) ```mermaid graph LR subgraph "Шлюз" GW[Gateway] end subgraph "Провайдер МТС" MTS_ISP[МТС ISP] end subgraph "Провайдер Ростелеком" RTK_ISP[Ростелеком ISP] end subgraph "GRE Туннели" subgraph "Москва - VPSVILLE" MTS_VPS[MSK-VPSVILLE-MTS
GRE Tunnel] RTK_VPS[MSK-VPSVILLE-RTK
GRE Tunnel] end subgraph "Москва - IHOR" MTS_IHOR[MSK-IHOR-MTS
GRE Tunnel] RTK_IHOR[MSK-IHOR-RTK
GRE Tunnel] end subgraph "Швеция - HIPHOST" MTS_HIP[SWE-HIPHOST-MTS
GRE Tunnel] RTK_HIP[SWE-HIPHOST-RTK
GRE Tunnel] end end subgraph "Удаленные серверы" VPS[VPSVILLE Server
Москва] IHR[IHOR Server
Москва] HIP["HIPHOST
SWE"] end GW --> MTS_ISP GW --> RTK_ISP MTS_ISP --> MTS_VPS MTS_ISP --> MTS_IHOR MTS_ISP --> MTS_HIP RTK_ISP --> RTK_VPS RTK_ISP --> RTK_IHOR RTK_ISP --> RTK_HIP MTS_VPS --> VPS MTS_IHOR --> IHR MTS_HIP --> HIP RTK_VPS --> VPS RTK_IHOR --> IHR RTK_HIP --> HIP %% Новое: GRE SWE-HIPHOST от всех МСК серверов VPS -- GRE SWE-HIPHOST --> HIP IHR -- GRE SWE-HIPHOST --> HIP style GW fill:#2196f3,stroke:#1976d2,stroke-width:2px,color:#fff style MTS_ISP fill:#f44336,stroke:#d32f2f,stroke-width:2px,color:#fff style RTK_ISP fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff style VPS fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff style IHR fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff style HIP fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff ``` ### Схема европейского трафика (новая) ```mermaid graph TD subgraph "Москва" VPSVILLE_MSK[VPSVILLE
Москва] IHOR_MSK[IHOR
Москва] end subgraph "Швеция" HIPHOST_SWE["HIPHOST
SWE"] end VPSVILLE_MSK -- GRE SWE-HIPHOST --> HIPHOST_SWE IHOR_MSK -- GRE SWE-HIPHOST --> HIPHOST_SWE HIPHOST_SWE -- "Европейский интернет" --> EU[EU Resources] classDef eu fill:#e3f2fd,stroke:#1976d2,stroke-width:2px; class EU eu; ``` ### Схема связывания московских серверов через OSPF (новая) ```mermaid graph TB subgraph "Москва - VPSVILLE" VPSVILLE[VPSVILLE
msk.vpsville.rt.shx.su] end subgraph "Москва - IHOR" IHOR[IHOR
msk.ihor.rt.shx.su] end subgraph "Домашний шлюз" HOME[HOME
home.rt.shx.su] end %% GRE туннели от домашнего шлюза (только клиентские подключения) HOME -- "GRE MSK-VPSVILLE-RTK
10.100.2.0/30" --> VPSVILLE HOME -- "GRE MSK-VPSVILLE-MTS
10.100.1.0/30" --> VPSVILLE HOME -- "GRE MSK-IHOR-RTK
10.100.4.0/30" --> IHOR HOME -- "GRE MSK-IHOR-MTS
10.100.3.0/30" --> IHOR %% GRE туннель между московскими серверами (независимо от HOME) VPSVILLE -- "GRE MSK-VPSVILLE-IHOR
10.200.0.0/30" --> IHOR %% OSPF связи только между серверами VPSVILLE -. "OSPF" .- IHOR %% HOME только получает маршруты от серверов VPSVILLE -. "OSPF маршруты" .- HOME IHOR -. "OSPF маршруты" .- HOME style VPSVILLE fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff style IHOR fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff style HOME fill:#e0e0e0,stroke:#9e9e9e,stroke-width:2px,color:#000 ``` ### Схема отказоустойчивости (обновлено) ```mermaid graph TB subgraph "Основной путь" GW[Gateway] MTS[MТС - Основной] RTK[Ростелеком - Резервный] end subgraph "Туннели по приоритету" subgraph "VPSVILLE" VPS_MTS[MSK-VPSVILLE-MTS
Приоритет 1] VPS_RTK[MSK-VPSVILLE-RTK
Приоритет 2] end subgraph "IHOR" IHR_MTS[MSK-IHOR-MTS
Приоритет 1] IHR_RTK[MSK-IHOR-RTK
Приоритет 2] end subgraph "HIPHOST" HIP_MTS[SWE-HIPHOST-MTS
Приоритет 1] HIP_RTK[SWE-HIPHOST-RTK
Приоритет 2] end end GW --> MTS GW --> RTK MTS --> VPS_MTS MTS --> IHR_MTS MTS --> HIP_MTS RTK --> VPS_RTK RTK --> IHR_RTK RTK --> HIP_RTK VPS_MTS -.->|Failover| VPS_RTK IHR_MTS -.->|Failover| IHR_RTK HIP_MTS -.->|Failover| HIP_RTK %% Новое: Европейский трафик через SWE-HIPHOST VPS_MTS -- "EU трафик" --> HIP_MTS VPS_RTK -- "EU трафик" --> HIP_RTK IHR_MTS -- "EU трафик" --> HIP_MTS IHR_RTK -- "EU трафик" --> HIP_RTK style GW fill:#2196f3,stroke:#1976d2,stroke-width:3px,color:#fff style MTS fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff style RTK fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff ``` ## Конфигурация туннелей ### Туннели от HOME к удаленным серверам | Провайдер | Туннель | Назначение | Локация | Статус | Приоритет | Подсеть | HOME IP | Remote IP | |-----------|---------|------------|---------|--------|-----------|---------|---------|-----------| | **Ростелеком (RTK)** | MSK-VPSVILLE-RTK | Основной канал VPSVILLE | Москва | Активен | 1 (основной) | 10.100.2.0/30 | 10.100.2.1 | 10.100.2.2 | | **Ростелеком (RTK)** | MSK-IHOR-RTK | Основной канал IHOR | Москва | Активен | 1 (основной) | 10.100.4.0/30 | 10.100.4.1 | 10.100.4.2 | | **Ростелеком (RTK)** | SWE-HIPHOST-RTK | Основной канал HIPHOST | Швеция | Активен | 1 (основной) | 10.100.6.0/30 | 10.100.6.1 | 10.100.6.2 | | **МТС (MTS)** | MSK-VPSVILLE-MTS | Резервный канал VPSVILLE | Москва | Активен | 2 (резервный) | 10.100.1.0/30 | 10.100.1.1 | 10.100.1.2 | | **МТС (MTS)** | MSK-IHOR-MTS | Резервный канал IHOR | Москва | Активен | 2 (резервный) | 10.100.3.0/30 | 10.100.3.1 | 10.100.3.2 | | **МТС (MTS)** | SWE-HIPHOST-MTS | Резервный канал HIPHOST | Швеция | Активен | 2 (резервный) | 10.100.5.0/30 | 10.100.5.1 | 10.100.5.2 | ## Преимущества архитектуры | Преимущество | Описание | Практическое применение | |--------------|----------|-------------------------| | **Отказоустойчивость** | Два независимых провайдера обеспечивают непрерывность работы | Автоматический failover при отказе одного провайдера | | **Географическое распределение** | Серверы в разных локациях (Москва, Швеция) | Оптимизация маршрутов и снижение задержек | | **Балансировка нагрузки** | Возможность распределения трафика между провайдерами | Эффективное использование каналов | | **Масштабируемость** | Легкое добавление новых туннелей и серверов | Простое расширение инфраструктуры | ## Мониторинг | Компонент | Метод мониторинга | Цель | |-----------|-------------------|------| | **GRE туннели** | Отслеживание состояния всех GRE туннелей | Контроль связности | | **Пропускная способность** | Мониторинг каналов | Оптимизация производительности | | **Failover** | Автоматическое переключение при отказе основного канала | Обеспечение непрерывности | | **Логирование** | События и статистика | Диагностика и анализ | ## Технические детали | Параметр | Значение | Описание | |----------|----------|----------| | **Протокол** | GRE (Generic Routing Encapsulation) | Основной протокол туннелирования | | **Шифрование** | IPSec (опционально) | Дополнительная защита трафика | | **Мониторинг** | Keepalive пакеты | Контроль состояния туннелей | | **Failover** | Автоматическое переключение при потере связи | Обеспечение отказоустойчивости | --- ## Рекомендации по адресации GRE туннелей Для GRE туннелей рекомендуется использовать отдельный диапазон, например, `10.100.0.0/16`, чтобы избежать конфликтов с домашней сетью (`192.168.0.0/16`). Для каждого туннеля выделяется отдельная /30 подсеть (две точки). ### Полная схема адресации GRE туннелей | Тип туннеля | Туннель | Подсеть | HOME IP | Remote IP | Провайдер | Приоритет | Описание | |-------------|---------|---------|---------|-----------|-----------|-----------|----------| | **HOME → Remote** | MSK-VPSVILLE-MTS | 10.100.1.0/30 | 10.100.1.1 | 10.100.1.2 | МТС | 2 (резервный) | Резервный канал VPSVILLE | | **HOME → Remote** | MSK-VPSVILLE-RTK | 10.100.2.0/30 | 10.100.2.1 | 10.100.2.2 | Ростелеком | 1 (основной) | Основной канал VPSVILLE | | **HOME → Remote** | MSK-IHOR-MTS | 10.100.3.0/30 | 10.100.3.1 | 10.100.3.2 | МТС | 2 (резервный) | Резервный канал IHOR | | **HOME → Remote** | MSK-IHOR-RTK | 10.100.4.0/30 | 10.100.4.1 | 10.100.4.2 | Ростелеком | 1 (основной) | Основной канал IHOR | | **HOME → Remote** | SWE-HIPHOST-MTS | 10.100.5.0/30 | 10.100.5.1 | 10.100.5.2 | МТС | 2 (резервный) | Резервный канал HIPHOST | | **HOME → Remote** | SWE-HIPHOST-RTK | 10.100.6.0/30 | 10.100.6.1 | 10.100.6.2 | Ростелеком | 1 (основной) | Основной канал HIPHOST | **Принцип**: Домашний шлюз всегда получает первый IP (.1), удаленные серверы - второй (.2) ### Принцип адресации GRE туннелей **Правило**: Домашний шлюз всегда получает первый IP (.1), удаленные серверы - второй (.2) **Преимущества такого подхода:** - **Логическая последовательность**: HOME - точка входа в сеть, логично дать ему первый IP - **Консистентность**: Все туннели от HOME имеют одинаковую схему адресации - **Упрощение конфигурации**: Легче запомнить и настроить (HOME всегда .1) - **Масштабируемость**: При добавлении новых туннелей схема остается понятной - **Устранение путаницы**: Нет вопросов "кто где" - HOME всегда .1, серверы всегда .2 **Пример конфигурации на HOME:** ```shell # Все GRE туннели на HOME получают .1 адрес /ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS /ip address add address=10.100.2.1/30 interface=gre-MSK-VPSVILLE-RTK /ip address add address=10.100.3.1/30 interface=gre-MSK-IHOR-MTS /ip address add address=10.100.4.1/30 interface=gre-MSK-IHOR-RTK ``` **Пример конфигурации на серверах:** ```shell # Все серверы получают .2 адрес в своих туннелях /ip address add address=10.100.1.2/30 interface=gre-MSK-VPSVILLE-MTS /ip address add address=10.100.2.2/30 interface=gre-MSK-VPSVILLE-RTK ``` ### Безопасность и маршрутизация на RouterOS - Использование диапазона `10.100.0.0/16` для GRE туннелей безопасно, если ваша домашняя сеть — `192.168.0.0/16`. - Диапазоны не пересекаются, маршрутизация не сломается. - На CHR (RouterOS) это стандартная практика: GRE туннели выносят в отдельный диапазон, чтобы не было конфликтов с LAN. - Для GRE-интерфейсов прописывайте адресацию только из этого диапазона. - В маршрутах на CHR не должно быть статических маршрутов, которые бы направляли `10.100.0.0/16` в локальную сеть. #### Пример маршрутизации на RouterOS - Для каждого GRE-интерфейса будет автоматически создан маршрут для /30 подсети. - Например, если GRE-интерфейс имеет адрес 10.100.1.1/30, а удалённый — 10.100.1.2, то маршрут до 10.100.1.2 будет через этот GRE-интерфейс. - Основная домашняя сеть (`192.168.0.0/16`) никак не пересекается с этими маршрутами. #### Пример конфигурации GRE туннеля на RouterOS ```shell /interface gre add name=gre-MSK-VPSVILLE-MTS remote-address= local-address= /ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS /ip route add dst-address=10.100.1.2/32 gateway=gre-MSK-VPSVILLE-MTS ``` - `` — внешний IP удалённого сервера - `` — ваш внешний IP - Аналогично для остальных туннелей, меняя адресацию по таблице выше --- --- ## OSPF: Оптимальная настройка для GRE туннелей В данной архитектуре используется OSPF для динамической маршрутизации между всеми GRE туннелями. Основной провайдер — Ростелеком, резервный — МТС. Для HomeLab (например, 192.168.111.0/24) весь трафик направляется через МТС с помощью policy routing (route-table=MTS). ### Рекомендации по настройке 1. **OSPF cost** - Для GRE туннелей через Ростелеком (основной) выставить меньший cost (например, 10) - Для GRE туннелей через МТС (резервный) — больший cost (например, 100) - Это обеспечит приоритет Ростелекома для всего трафика, кроме HomeLab 2. **Policy Based Routing (PBR) для HomeLab** - Для HomeLab (например, 192.168.111.0/24) настроить policy routing: - Весь исходящий трафик с HomeLab отправлять в route-table=MTS - В этой таблице основной маршрут — через МТС (резервный провайдер) 3. **OSPF Instance и Area** - Использовать одну OSPF instance для всех туннелей (если нет особых требований) - Все GRE-интерфейсы добавить в одну area (обычно 0.0.0.0) ### Пример конфигурации OSPF на RouterOS ```shell # 1. Настройка OSPF instance /routing ospf instance set [ find default=yes ] router-id=10.100.0.1 # 2. Добавление GRE-интерфейсов в OSPF с разным cost # Ростелеком (основной провайдер) - низкий cost /routing ospf interface add interface=gre-MSK-VPSVILLE-RTK cost=10 network-type=point-to-point add interface=gre-MSK-IHOR-RTK cost=10 network-type=point-to-point add interface=gre-SWE-HIPHOST-RTK cost=10 network-type=point-to-point # МТС (резервный провайдер) - высокий cost add interface=gre-MSK-VPSVILLE-MTS cost=100 network-type=point-to-point add interface=gre-MSK-IHOR-MTS cost=100 network-type=point-to-point add interface=gre-SWE-HIPHOST-MTS cost=100 network-type=point-to-point # 3. Добавление сетей в OSPF /routing ospf network add network=10.100.0.0/16 area=backbone # 4. Policy Based Routing для HomeLab (использует резервный МТС) /ip route add dst-address=0.0.0.0/0 gateway= routing-table=MTS /ip firewall mangle add chain=prerouting src-address=192.168.111.0/24 action=mark-routing new-routing-mark=MTS # — адрес следующего хопа через МТС (например, 10.100.1.2) ``` #### Логика работы - OSPF сам будет выбирать основной маршрут через Ростелеком (основной провайдер, cost=10). - Если основной канал падает, трафик автоматически пойдёт через МТС (резервный провайдер, cost=100). - Для HomeLab весь трафик всегда идёт через МТС (резервный провайдер), независимо от состояния каналов, благодаря policy routing. --- --- ## Failover между московскими туннелями (route-table=MSK) Для клиентов/серверов, использующих отдельную таблицу маршрутизации `MSK`, реализован автоматический failover между московскими GRE туннелями. Если один из туннелей (MSK-VPSVILLE или MSK-IHOR) падает, весь трафик автоматически идёт через оставшийся рабочий туннель. ### Как это работает - OSPF анонсирует маршруты через оба московских туннеля. - Если один туннель недоступен, маршрут через него исчезает из таблицы MSK. - Policy Based Routing (PBR) направляет трафик нужных клиентов в таблицу MSK. - В таблице MSK всегда есть маршрут через рабочий туннель. ### Пример конфигурации на RouterOS ```shell # 1. Маркируем трафик для route-table=MSK /ip firewall mangle add chain=prerouting src-address=192.168.222.0/24 action=mark-routing new-routing-mark=MSK # 2. В таблице MSK маршруты через оба московских туннеля /ip route # OSPF сам добавит маршруты через gre-MSK-VPSVILLE и gre-MSK-IHOR, если они живы # Если хотите вручную: add dst-address=0.0.0.0/0 gateway=10.100.1.2 routing-table=MSK distance=1 add dst-address=0.0.0.0/0 gateway=10.100.3.2 routing-table=MSK distance=2 # 3. OSPF интерфейсы для московских туннелей /routing ospf interface add interface=gre-MSK-VPSVILLE-RTK cost=10 network-type=point-to-point add interface=gre-MSK-IHOR-RTK cost=10 network-type=point-to-point add interface=gre-MSK-VPSVILLE-MTS cost=100 network-type=point-to-point add interface=gre-MSK-IHOR-MTS cost=100 network-type=point-to-point ``` - OSPF будет держать маршруты только через живые туннели. - Если оба туннеля живы — оба маршрута в таблице, основной с меньшим distance. - Если один туннель падает — маршрут через него исчезает, трафик идёт через оставшийся. --- --- ## Примеры конфигурации для RouterOS 7.14+ ### OSPF (RouterOS 7.14+) ```shell # 1. Создание OSPF instance и area /routing ospf instance add name=default router-id=10.100.0.1 /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 2. Добавление GRE-интерфейсов с нужным cost # Ростелеком (основной провайдер) - низкий cost /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone ``` ### Policy Based Routing (RouterOS 7.14+) ```shell # 1. Создание таблиц маршрутизации /routing table add name=MSK fib # Основной трафик через Ростелеком add name=MTS fib # HomeLab трафик через МТС (резервный) # 2. Routing rules для выбора таблицы по источнику /routing rule add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС (резервный) add src-address=192.168.222.0/24 action=lookup table=MSK # Основной трафик → Ростелеком # OSPF сам добавит маршруты в эти таблицы, если GRE-интерфейсы участвуют в OSPF ``` ### GRE туннели (пример) ```shell /interface gre add name=gre-MSK-VPSVILLE-RTK remote-address= local-address= /ip address add address=10.100.2.1/30 interface=gre-MSK-VPSVILLE-RTK # Аналогично для остальных туннелей по таблице адресации ``` --- ## Актуальные рекомендации для RouterOS 7.14+ - Используйте `/routing rule` для Policy Based Routing вместо mangle. - OSPF интерфейсы и cost настраиваются через `interface-template`. - Все GRE туннели должны быть добавлены в OSPF через interface-template для корректного анонса маршрутов. - OSPF автоматически поддерживает failover между туннелями: если один туннель падает, маршрут исчезает из таблицы. - Для отдельных сегментов (например, HomeLab или MSK) используйте отдельные routing table и routing rule для выбора нужного провайдера/туннеля. --- ## Пример failover для route-table=MSK (RouterOS 7.14+) ```shell # 1. Routing rule для сегмента MSK /routing rule add src-address=192.168.222.0/24 action=lookup table=MSK # 2. OSPF сам добавит маршруты через gre-MSK-VPSVILLE и gre-MSK-IHOR в таблицу MSK # Если хотите вручную: /ip route add dst-address=0.0.0.0/0 gateway=10.100.1.2 routing-table=MSK distance=1 add dst-address=0.0.0.0/0 gateway=10.100.3.2 routing-table=MSK distance=2 ``` --- --- ## Масштабирование сети с GRE и OSPF Схема с GRE-туннелями и OSPF идеально подходит для масштабируемых и отказоустойчивых сетей. ### Преимущества - **Лёгкое добавление новых туннелей:** для нового хоста создаётся GRE-интерфейс, выделяется /30 подсеть, добавляется в OSPF — маршруты распространяются автоматически. - **Быстрая замена хоста:** при замене сервера/маршрутизатора достаточно повторить настройки GRE и OSPF — сеть быстро перестроится без ручных правок на других устройствах. - **Гибкая топология:** можно строить как “звезду”, так и “mesh” — OSPF сам выберет оптимальные маршруты и обеспечит резервирование. - **Автоматический failover:** при недоступности туннеля или хоста OSPF убирает маршруты, трафик идёт по резервным путям. - **Масштабируемость:** количество туннелей ограничено только ресурсами оборудования, добавление новых площадок не требует изменений на старых. ### Рекомендации - Для каждого нового туннеля используйте отдельную /30 подсеть из выделенного диапазона (например, 10.100.x.0/30). - Все GRE-интерфейсы сразу добавляйте в OSPF через interface-template. - Используйте шаблоны и автоматизацию для быстрой настройки новых точек. - Документируйте назначение каждой подсети и туннеля (см. таблицу выше). ### Пример добавления нового GRE туннеля и OSPF (RouterOS 7.14+) ```shell /interface gre add name=gre-NEW-SITE remote-address= local-address= /ip address add address=10.100.10.1/30 interface=gre-NEW-SITE /routing ospf interface-template add interfaces=gre-NEW-SITE cost=10 area=backbone ``` --- --- ## Европейский трафик через GRE SWE-HIPHOST У всех московских серверов настроен GRE-туннель на SWE-HIPHOST. Обычно через этот туннель направляется европейский трафик для оптимизации маршрутов и повышения скорости доступа к европейским ресурсам. ### Как это реализовано - Все GRE-туннели SWE-HIPHOST добавлены в OSPF через interface-template. - OSPF обеспечивает резервирование и автоматический failover для туннеля SWE-HIPHOST. - Policy Based Routing (PBR) позволяет направлять трафик, предназначенный для Европы, через отдельную таблицу маршрутизации (EU), где основной маршрут — через GRE SWE-HIPHOST. ### Пример конфигурации (RouterOS 7.14+) ```shell # 1. Создаём таблицу маршрутизации для Европы /routing table add name=EU fib # 2. Routing rule для европейского трафика (пример: по dst-address) /routing rule add dst-address= action=lookup table=EU # 3. В таблице EU маршрут по умолчанию через GRE SWE-HIPHOST /ip route add dst-address=0.0.0.0/0 gateway=10.100.5.2 routing-table=EU distance=1 # 4. GRE SWE-HIPHOST добавлен в OSPF /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # Основной канал add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # Резервный канал ``` - `` — список европейских подсетей или диапазонов (можно использовать address-list и mangle для сложных случаев). ### Преимущества - **Оптимизация маршрутов:** Европейский трафик идёт по кратчайшему пути через SWE-HIPHOST. - **Резервирование:** OSPF обеспечивает автоматический failover при недоступности туннеля. - **Гибкость:** Можно легко расширять список европейских подсетей или добавить резервные маршруты. --- --- ## Рекомендации по неймингу CHR серверов Грамотный нейминг серверов и шлюзов облегчает сопровождение, масштабирование и диагностику сети. ### Рекомендуемая структура имени Если у вас несколько хостеров/площадок в одном городе или стране, рекомендуется использовать следующий формат: ``` <город>.<площадка>.<роль>.<домен> ``` - **<город>** — код города или страны (например, msk, swe) - **<площадка>** — название хостера или дата-центра (например, vpsville, ihor, hiphost) - **<роль>** — rt (router), gw (gateway), srv (server) и т.д. - **<домен>** — основной домен вашей инфраструктуры #### Пример: - `msk.vpsville.rt.shx.su` — роутер в Москве, площадка VPSVILLE - `msk.ihor.rt.shx.su` — роутер в Москве, площадка IHOR - `swe.hiphost.rt.shx.su` — роутер в Швеции, площадка HIPHOST - `home.rt.shx.su` — домашний роутер ### Схема именования серверов | Локация | Имя сервера | DNS имя | Роль | Описание | |---------|-------------|---------|------|----------| | Домашний | home-gw | home.rt.shx.su | Gateway | Домашний роутер | | Москва IHOR | msk-ihor-gw | msk.ihor.rt.shx.su | Router | Роутер IHOR, Москва | | Москва VPSVILLE | msk-vpsville-gw | msk.vpsville.rt.shx.su | Router | Роутер VPSVILLE, Москва | | Швеция HIPHOST | swe-hiphost-gw | swe.hiphost.rt.shx.su | Router | Роутер HIPHOST, Швеция | ### Рекомендации - Используйте короткие, но однозначные аббревиатуры для локаций: `msk` (Москва), `swe` (Швеция), `home` (домашний роутер) - Для роли роутера используйте `rt` (router) вместо `gw` (gateway) - Если есть несколько провайдеров на одной площадке, добавляйте суффикс: `msk-ihor-rt-rtk` (Москва, IHOR, роутер, Ростелеком) - Для серверов без роутерной роли используйте, например, `srv` (server): `msk-ihor-srv` > **Почему именно такой порядок?** > Если у вас несколько хостеров в одном городе, такой нейминг позволяет удобно группировать и искать объекты по локации, а внутри — по площадке. Это облегчает навигацию и масштабирование инфраструктуры. --- --- ## Распределение IP-адресов между GRE туннелями между хостерами Грамотное распределение IP-адресов между GRE-туннелями между хостерами (site-to-site) обеспечивает прозрачность, масштабируемость и отсутствие конфликтов. ### Рекомендации - Выделяйте отдельный диапазон для межхостовых туннелей, например, `10.200.0.0/16`. - Для каждого GRE-туннеля между двумя хостерами используйте отдельную /30 подсеть (2 usable IP). - Систематизируйте назначение подсетей (например, по ID площадок или по алфавиту). - Документируйте все туннели и адреса в README. ### Схема адресации для GRE между хостерами | Туннель | Подсеть | Сервер A | IP A | Сервер B | IP B | Описание | |---------|---------|----------|------|----------|------|----------| | gre-MSK-VPSVILLE-IHOR | 10.200.0.0/30 | MSK-VPSVILLE | 10.200.0.1 | MSK-IHOR | 10.200.0.2 | VPSVILLE ↔ IHOR | | gre-SWE-HIPHOST | 10.200.1.0/30 | MSK-VPSVILLE | 10.200.1.1 | SWE-HIPHOST | 10.200.1.2 | VPSVILLE ↔ SWE | | gre-SWE-HIPHOST | 10.200.2.0/30 | MSK-IHOR | 10.200.2.1 | SWE-HIPHOST | 10.200.2.2 | IHOR ↔ SWE | - Для новых туннелей просто берите следующую свободную /30 из диапазона. - Такой подход облегчает масштабирование и поддержку сети. --- ## Связывание московских серверов через OSPF Для обеспечения отказоустойчивости и оптимизации маршрутов все московские серверы связаны через OSPF. Это обеспечивает автоматический failover между площадками и оптимальный выбор маршрутов. ### Преимущества связывания московских серверов 1. **Автоматический failover между московскими площадками** - Если VPSVILLE недоступен, трафик автоматически пойдет через IHOR - Если IHOR недоступен, трафик пойдет через VPSVILLE 2. **Оптимизация маршрутов** - OSPF автоматически выберет кратчайший путь - Можно настроить разные cost для разных провайдеров 3. **Масштабируемость** - Легко добавлять новые московские площадки - Автоматическое распространение маршрутов ### Конфигурация GRE туннеля между московскими серверами #### На VPSVILLE (msk.vpsville.rt.shx.su): ```shell # Создание GRE туннеля к IHOR /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.0.1/30 interface=gre-MSK-VPSVILLE-IHOR # Добавление в OSPF (межсерверная связь через основной провайдер) /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=10 area=backbone ``` #### На IHOR (msk.ihor.rt.shx.su): ```shell # Создание GRE туннеля к VPSVILLE /interface gre add name=gre-MSK-IHOR-VPSVILLE remote-address= local-address= /ip address add address=10.200.0.2/30 interface=gre-MSK-IHOR-VPSVILLE # Добавление в OSPF (межсерверная связь через основной провайдер) /routing ospf interface-template add interfaces=gre-MSK-IHOR-VPSVILLE cost=10 area=backbone ``` #### На HOME (home.rt.shx.su): ```shell # HOME не создает GRE туннели между серверами # HOME только подключается к серверам по GRE и получает маршруты через OSPF # OSPF настроен для получения маршрутов от серверов /routing ospf interface-template # Ростелеком (основной провайдер) - низкий cost add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone # Policy routing для выбора нужного сервера/провайдера /routing rule add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС (резервный) add src-address=192.168.222.0/24 action=lookup table=MSK # Основной трафик → Ростелеком ``` ### Логика работы OSPF между московскими серверами 1. **Прямая связь между серверами**: VPSVILLE ↔ IHOR через GRE туннель 10.200.0.0/30 2. **OSPF анонсирует маршруты**: Каждый сервер анонсирует свои сети через OSPF 3. **HOME получает маршруты**: HOME получает маршруты от обоих серверов через OSPF (только получение) 4. **Автоматический failover**: Если один сервер недоступен, OSPF убирает маршруты через него 5. **Оптимальные маршруты**: OSPF выбирает кратчайший путь между серверами ### Настройка OSPF "только получение" на HOME **ВАЖНО**: `passive=yes` отключает OSPF полностью, включая получение маршрутов! Это НЕ подходит для вашей задачи. Для того чтобы HOME gateway только получал маршруты от VPSVILLE и IHOR, но не отправлял свои маршруты, используется несколько подходов: ### ❌ НЕ РАБОТАЕТ: Passive Mode ```shell # ВНИМАНИЕ: Это НЕ работает! add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone passive=yes # ❌ Маршруты пропадут ``` **Почему не работает**: `passive=yes` отключает OSPF полностью - нет hello пакетов, нет соседства, нет маршрутов. #### Способ 1: Отключение redistribute (Рекомендуемый) ```shell # На HOME - нормальные OSPF интерфейсы (получение + отправка hello) /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone # Отключить redistribute (не анонсировать маршруты) /routing ospf instance set [ find default=yes ] redistribute=none ``` **Как это работает**: - ✅ OSPF соседство устанавливается (hello пакеты отправляются) - ✅ Маршруты от VPSVILLE/IHOR получаются - ❌ HOME не анонсирует свои маршруты (redistribute=none) #### Способ 2: Использование фильтров ```shell # На HOME - нормальные OSPF интерфейсы /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone # Создать фильтр который отклоняет все исходящие маршруты /routing filter add name=ospf-out-reject-all chain=output protocol=ospf rule="reject" # Применить фильтр к OSPF instance /routing ospf instance set [ find default=yes ] out-filter=ospf-out-reject-all ``` #### Способ 3: Stub Area (для сложных сетей) ```shell # Создать stub area для HOME /routing ospf area add name=home-stub instance=default area-id=0.0.0.1 stub=yes # Добавить интерфейсы HOME в stub area /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=home-stub add interfaces=gre-MSK-IHOR-RTK cost=10 area=home-stub ``` #### Способ 4: Passive Mode (НЕ РЕКОМЕНДУЕТСЯ) ```shell # ВНИМАНИЕ: passive=yes отключает OSPF полностью, включая получение маршрутов! # Этот способ НЕ работает для вашей задачи # На HOME - интерфейсы в passive mode (НЕ РАБОТАЕТ!) /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone passive=yes # ❌ Маршруты пропадут add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone passive=yes # ❌ Маршруты пропадут ``` ### Сравнение способов настройки OSPF "только получение" | Способ | Простота | Совместимость | Гибкость | Работает | Рекомендация | |--------|----------|---------------|----------|----------|--------------| | **Отключение redistribute** | Высокая | Все версии | Низкая | ✅ Да | **Рекомендуемый** | | **Фильтры** | Средняя | Все версии | Высокая | ✅ Да | Для точного контроля | | **Stub Area** | Низкая | Все версии | Низкая | ✅ Да | Для сложных сетей | | **Passive Mode** | Высокая | RouterOS 7.14+ | Низкая | ❌ Нет | НЕ РЕКОМЕНДУЕТСЯ | ### Рекомендуемая конфигурация для HOME ```shell # 1. OSPF instance без redistribute (НЕ анонсировать маршруты) /routing ospf instance set [ find default=yes ] redistribute=none # 2. Нормальные OSPF интерфейсы (получение + отправка hello) /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone # 3. Проверка что маршруты получаются /routing ospf route print /ip route print where protocol=ospf ``` ### Проверка работы OSPF "только получение" ```shell # На HOME проверить что маршруты получаются /routing ospf route print # На VPSVILLE/IHOR проверить что маршруты от HOME не анонсируются /routing ospf route print # Проверить OSPF соседей /routing ospf neighbor print # Проверить что HOME не анонсирует маршруты /routing ospf route print where originator=10.100.0.1 ``` ### Роль HOME в архитектуре | Роль | Описание | OSPF настройка | |------|----------|----------------| | **Конечная точка** | Подключается к серверам по GRE, но не участвует в межсерверной маршрутизации | passive=yes | | **Получение маршрутов** | HOME получает маршруты от серверов через OSPF | redistribute=none | | **Policy routing** | HOME использует route tables для выбора нужного сервера/провайдера | routing rules | | **Отправка трафика** | HOME отправляет трафик по правилам маршрутизации | route tables | ### Преимущества OSPF "только получение" на HOME | Преимущество | Описание | Практическое применение | |--------------|----------|-------------------------| | **Безопасность** | HOME не раскрывает свои внутренние сети | Защита от несанкционированного доступа | | **Производительность** | Меньше OSPF трафика | Снижение нагрузки на сеть | | **Простота** | Меньше конфигурации | Легче поддерживать | | **Контроль** | Точный контроль над маршрутизацией | Предсказуемое поведение сети | ### Пример маршрутизации - **Трафик VPSVILLE → IHOR**: Прямо через GRE туннель 10.200.0.0/30 (без участия HOME) - **Трафик HOME → Интернет**: Через VPSVILLE или IHOR согласно route tables - **Трафик HOME → Европа**: Через SWE-HIPHOST согласно policy routing ### Мониторинг связей ```shell # Проверка состояния GRE туннелей /interface gre print # Проверка OSPF соседей /routing ospf neighbor print # Проверка маршрутов /ip route print ``` --- ## OSPF и дублирование маршрутов При использовании OSPF между серверами может происходить дублирование маршрутов в таблице маршрутизации. Это нормальное поведение, но важно понимать, как это контролировать. ### Как работает дублирование маршрутов 1. **OSPF анонсирует маршруты**: Каждый сервер анонсирует свои сети через OSPF 2. **Множественные пути**: HOME может получить маршрут до одной сети через разные серверы 3. **Distance и cost**: OSPF использует cost для выбора оптимального пути, но может создавать резервные маршруты ### Пример дублирования маршрутов ```shell # На HOME может быть несколько маршрутов до одной сети: /ip route print Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC, r - RIP, m - MODEM, b - BGP, o - OSPF, M - MME, B - BLACKHOLE, U - UNREACHABLE, F - FIB, v - VPLS, V - VRF, l - LISP, a - BFD, M - MME, t - TTLS, I - IDE, W - WINBOX, X - XAUTH, g - 7GRE, S - SNAT Columns: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY DISTANCE 0 A s 0.0.0.0/0 10.100.2.2 1 # Через VPSVILLE-RTK (основной) 1 A s 0.0.0.0/0 10.100.4.2 1 # Через IHOR-RTK (основной) 2 A s 0.0.0.0/0 10.100.1.2 2 # Через VPSVILLE-MTS (резервный) 3 A s 0.0.0.0/0 10.100.3.2 2 # Через IHOR-MTS (резервный) ``` ### Контроль дублирования через OSPF cost ```shell # Настройка разных cost для приоритизации маршрутов /routing ospf interface-template # Ростелеком (основной провайдер) - низкий cost add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone ``` ### Использование route tables для разделения трафика ```shell # Создание отдельных таблиц маршрутизации /routing table add name=MSK fib # Основной трафик через Ростелеком add name=MTS fib # HomeLab трафик через МТС (резервный) # Routing rules для выбора таблицы /routing rule add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС (резервный) add src-address=192.168.222.0/24 action=lookup table=MSK # Основной трафик → Ростелеком # В каждой таблице будет свой набор маршрутов # OSPF автоматически добавит маршруты в соответствующие таблицы ``` ### Преимущества дублирования маршрутов 1. **Автоматический failover**: Если основной маршрут недоступен, используется резервный 2. **Load balancing**: Можно настроить балансировку нагрузки между маршрутами 3. **Отказоустойчивость**: Сеть продолжает работать даже при отказе части каналов ### Мониторинг дублирования ```shell # Просмотр всех маршрутов с деталями /ip route print detail # Просмотр OSPF маршрутов /routing ospf route print # Проверка активных маршрутов /ip route print where active=yes ``` --- ## Настройка OSPF для анонса только 0.0.0.0/0 (RouterOS 7.14+) Для того чтобы удаленные серверы анонсировали только маршрут по умолчанию (0.0.0.0/0) через OSPF, нужно настроить Redistribute с Out filter. В RouterOS 7.14+ команда `/routing ospf network` больше не используется. ### Конфигурация на удаленных серверах (VPSVILLE, IHOR, HIPHOST) #### 1. Создание Out filter для OSPF ```shell # Создание фильтра, который пропускает только 0.0.0.0/0 /routing filter add name=ospf-out-default-only chain=output protocol=ospf rule="if (dst-address=0.0.0.0/0) { accept } else { reject }" ``` #### 2. Настройка OSPF Redistribute с фильтром (основной способ для RouterOS 7.14+) ```shell # Настройка OSPF instance для redistribute /routing ospf instance set [ find default=yes ] redistribute=connected,static # Применение фильтра к OSPF /routing ospf instance set [ find default=yes ] out-filter=ospf-out-default-only ``` #### 2a. Альтернативный способ без routing filters ```shell # Настройка OSPF instance только для redistribute connected /routing ospf instance set [ find default=yes ] redistribute=connected # Или только для redistribute static (если 0.0.0.0/0 - статический маршрут) /routing ospf instance set [ find default=yes ] redistribute=static ``` #### 3. Альтернативный способ через OSPF networks (RouterOS 6.x) ```shell # В RouterOS 6.x можно было использовать networks /routing ospf network add network=0.0.0.0/0 area=backbone # В RouterOS 7.14+ эта команда больше не используется # Вместо неё используется redistribute с фильтрами ``` ### Конфигурация на HOME #### 1. Создание In filter для OSPF (опционально) ```shell # Фильтр для входящих OSPF маршрутов (если нужна дополнительная фильтрация) /routing filter add name=ospf-in-default-only chain=input protocol=ospf rule="if (dst-address=0.0.0.0/0) { accept } else { reject }" # Применение фильтра к OSPF instance /routing ospf instance set [ find default=yes ] in-filter=ospf-in-default-only ``` ### Проверка конфигурации ```shell # Проверка OSPF маршрутов на удаленном сервере /routing ospf route print # Проверка OSPF маршрутов на HOME /routing ospf route print # Проверка таблицы маршрутизации на HOME /ip route print where protocol=ospf ``` ### Пример полной конфигурации на удаленном сервере (RouterOS 7.14+) #### Способ 1: С фильтром (если работает) ```shell # 1. Создание фильтра для анонса только 0.0.0.0/0 /routing filter add name=ospf-out-default-only chain=output protocol=ospf rule="if (dst-address=0.0.0.0/0) { accept } else { reject }" # 2. Настройка OSPF instance с redistribute и фильтром /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 redistribute=connected,static out-filter=ospf-out-default-only # 3. Добавление GRE интерфейсов в OSPF /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # 4. Проверка что только 0.0.0.0/0 анонсируется /routing ospf route print ``` #### Способ 2: Без фильтров (простой) ```shell # 1. Настройка OSPF instance только для redistribute connected /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 redistribute=connected # 2. Добавление GRE интерфейсов в OSPF /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # 3. Проверка анонсируемых маршрутов /routing ospf route print ``` #### Способ 3: Только статические маршруты ```shell # 1. Настройка OSPF instance только для redistribute static /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 redistribute=static # 2. Добавление GRE интерфейсов в OSPF /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # 3. Проверка анонсируемых маршрутов /routing ospf route print ``` #### Способ 4: Простой статический маршрут (гарантированно работает) ```shell # 1. Добавление статического маршрута 0.0.0.0/0 через SWE-HIPHOST-MTS /ip route add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 # 2. Настройка OSPF instance для redistribute static /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 redistribute=static # 3. Добавление GRE интерфейсов в OSPF /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # 4. Проверка что маршрут анонсируется /routing ospf route print ``` #### Способ 5: Самый простой - без OSPF ```shell # Просто добавить статический маршрут на HOME /ip route add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 routing-table=EU # Или для основной таблицы /ip route add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 ``` ### Логика работы 1. **Удаленный сервер** имеет маршрут по умолчанию (0.0.0.0/0) в своей таблице 2. **Redistribute** анонсирует маршруты через OSPF (с фильтром или без) 3. **HOME** получает маршруты от удаленного сервера 4. **OSPF** выбирает оптимальный путь на основе cost ### Выбор способа настройки OSPF | Способ | Метод | Преимущества | Недостатки | Рекомендация | |--------|-------|--------------|------------|--------------| | **Способ 1** | С фильтром | Точный контроль, только нужные маршруты | Сложнее настройка, может не работать в некоторых версиях | Для опытных | | **Способ 2** | redistribute=connected | Простая настройка, работает стабильно | Анонсирует все connected маршруты | **Рекомендуемый** | | **Способ 3** | redistribute=static | Простая настройка, только статические маршруты | Анонсирует все статические маршруты | Если 0.0.0.0/0 статический | | **Способ 4** | Простой статический маршрут | Гарантированно работает, простой | Нужно вручную добавить маршрут | Самый надежный | ### Преимущества такого подхода | Преимущество | Описание | Влияние | |--------------|----------|---------| | **Чистая таблица маршрутизации** | Только нужные маршруты (при использовании фильтров) | Упрощение диагностики | | **Контроль трафика** | Можно точно указать, какие маршруты анонсировать | Безопасность и производительность | | **Безопасность** | Не раскрываются внутренние сети удаленных серверов | Защита от несанкционированного доступа | | **Производительность** | Меньше маршрутов = быстрее обработка | Оптимизация работы роутера | | **Простота** | Можно обойтись без сложных фильтров | Легкость настройки и поддержки | --- ## Конкретное решение: Маршрут 0.0.0.0/0 через SWE-HIPHOST-MTS ### На SWE-HIPHOST (удаленный сервер): #### Способ 1: С фильтрацией AWS metadata (рекомендуемый) ```shell # 1. Маршрут 0.0.0.0/0 уже есть (получен через DHCP) # Проверить текущие маршруты: /ip route print # 2. Создать фильтр для исключения AWS metadata /routing filter add name=ospf-out-no-aws chain=output protocol=ospf rule="if (dst-address=169.254.169.254/32) { reject } else { accept }" # 3. Настроить OSPF с фильтром /routing ospf instance set [ find default=yes ] router-id=10.100.0.5 redistribute=connected out-filter=ospf-out-no-aws # 4. Добавить GRE интерфейс в OSPF /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # 5. Проверить что маршрут анонсируется /routing ospf route print ``` #### Способ 2: Без фильтрации (если фильтры не работают) ```shell # 1. Проверить текущие маршруты: /ip route print # 2. Настроить OSPF для redistribute connected /routing ospf instance set [ find default=yes ] router-id=10.100.0.5 redistribute=connected # 3. Добавить GRE интерфейс в OSPF /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # 4. Проверить что маршрут анонсируется /routing ospf route print ``` ### На HOME: ```shell # 1. Добавить GRE интерфейс в OSPF /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # 2. Проверить получение маршрута /routing ospf route print # 3. Проверить таблицу маршрутизации /ip route print where protocol=ospf ``` ### Альтернатива - статический маршрут на HOME: ```shell # Если OSPF не работает, просто добавить статический маршрут /ip route add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 # Или для отдельной таблицы маршрутизации /ip route add dst-address=0.0.0.0/0 gateway=10.100.5.2 distance=1 routing-table=EU ``` --- ## Настройка OSPF cost для failover между серверами Для того чтобы OSPF cost работал и один маршрут заменялся другим в зависимости от cost, нужно настроить OSPF на всех серверах, которые анонсируют маршруты. ### Конфигурация на SWE-HIPHOST (анонсирует маршрут 0.0.0.0/0): ```shell # 1. Создать фильтр для исключения AWS metadata /routing filter add name=ospf-out-no-aws chain=output protocol=ospf rule="if (dst-address=169.254.169.254/32) { reject } else { accept }" # 2. Настроить OSPF с фильтром и redistribute /routing ospf instance set [ find default=yes ] router-id=10.100.0.5 redistribute=connected out-filter=ospf-out-no-aws # 3. Создать area (если не существует) /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 4. Добавить GRE интерфейсы в OSPF с разным cost /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # Основной канал add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # Резервный канал # 5. Проверить что маршрут анонсируется /routing ospf route print ``` ### Конфигурация на MSK-VPSVILLE (анонсирует маршрут 0.0.0.0/0): ```shell # 1. Создать фильтр для исключения AWS metadata (если есть) /routing filter add name=ospf-out-no-aws chain=output protocol=ospf rule="if (dst-address=169.254.169.254/32) { reject } else { accept }" # 2. Настроить OSPF с фильтром и redistribute /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 redistribute=connected out-filter=ospf-out-no-aws # 3. Создать area (если не существует) /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 4. Добавить GRE интерфейсы в OSPF с разным cost /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone # Основной канал add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # Резервный канал # 5. Проверить что маршрут анонсируется /routing ospf route print ``` ### Конфигурация на HOME (получает маршруты): ```shell # 1. Создать area (если не существует) /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 2. Добавить все GRE интерфейсы в OSPF с соответствующим cost /routing ospf interface-template # Ростелеком (основной провайдер) - низкий cost add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone # 3. Проверить полученные маршруты /routing ospf route print # 4. Проверить таблицу маршрутизации /ip route print where protocol=ospf ``` ### Логика работы OSPF cost: 1. **SWE-HIPHOST** анонсирует маршрут 0.0.0.0/0 через оба канала: - gre-SWE-HIPHOST-RTK (cost=10) - основной - gre-SWE-HIPHOST-MTS (cost=100) - резервный 2. **MSK-VPSVILLE** анонсирует маршрут 0.0.0.0/0 через оба канала: - gre-MSK-VPSVILLE-RTK (cost=10) - основной - gre-MSK-VPSVILLE-MTS (cost=100) - резервный 3. **HOME** получает маршруты от обоих серверов и выбирает оптимальный путь на основе cost 4. **Автоматический failover**: Если основной канал падает, OSPF автоматически переключается на резервный ### Настройка OSPF Area **Важно**: Все устройства должны использовать одинаковую area для корректной работы OSPF. #### Вариант 1: Одна area (рекомендуемый для простых сетей) ```shell # На всех устройствах (HOME, SWE-HIPHOST, MSK-VPSVILLE, MSK-IHOR): /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # Или использовать существующую area: /routing ospf area print # Если area уже создана, используйте её имя ``` #### Вариант 2: Создание новой area ```shell # На всех устройствах создать одинаковую area: /routing ospf area add name=main-area instance=default area-id=0.0.0.1 # Затем использовать её в interface-template: /routing ospf interface-template add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=main-area add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=main-area ``` #### Проверка area настройки: ```shell # Проверить существующие area: /routing ospf area print # Проверить OSPF соседей: /routing ospf neighbor print # Проверить что соседи в одной area: /routing ospf neighbor print detail ``` --- ## Оптимальная схема OSPF Areas для вашей сети ### Рекомендуемая архитектура Areas Для вашей сети с несколькими локациями и провайдерами рекомендуется использовать **многоуровневую схему areas**: #### Схема 1: Простая (рекомендуемая для начала) ``` Area 0.0.0.0 (Backbone) - все устройства ├── HOME (home.rt.shx.su) ├── MSK-VPSVILLE (msk.vpsville.rt.shx.su) ├── MSK-IHOR (msk.ihor.rt.shx.su) └── SWE-HIPHOST (swe.hiphost.rt.shx.su) ``` #### Схема 2: По локациям (для масштабирования) ``` Area 0.0.0.0 (Backbone) - HOME ├── Area 0.0.0.1 (MSK) - московские серверы │ ├── MSK-VPSVILLE │ └── MSK-IHOR └── Area 0.0.0.2 (SWE) - шведский сервер └── SWE-HIPHOST ``` #### Схема 3: По провайдерам (для изоляции) ``` Area 0.0.0.0 (Backbone) - HOME ├── Area 0.0.0.10 (RTK) - Ростелеком туннели │ ├── MSK-VPSVILLE-RTK │ ├── MSK-IHOR-RTK │ └── SWE-HIPHOST-RTK └── Area 0.0.0.20 (MTS) - МТС туннели ├── MSK-VPSVILLE-MTS ├── MSK-IHOR-MTS └── SWE-HIPHOST-MTS ``` ### Рекомендация: Начните с простой схемы Для вашей текущей сети **рекомендую начать с Схемы 1** (одна area): #### Конфигурация для Схемы 1: ```shell # На всех устройствах (HOME, MSK-VPSVILLE, MSK-IHOR, SWE-HIPHOST): # 1. Создать backbone area (ВАЖНО: используйте area-id=0.0.0.1 вместо 0.0.0.0) /routing ospf area add name=backbone instance=default area-id=0.0.0.1 # 2. Добавить все GRE интерфейсы в backbone area /routing ospf interface-template # Ростелеком (основной провайдер) - низкий cost add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=backbone ``` **ВАЖНО**: В некоторых случаях area-id=0.0.0.0 может вызывать проблемы. Если OSPF не работает с area-id=0.0.0.0, используйте area-id=0.0.0.1. ### Решение: Изоляция серверов через отдельные OSPF Instances Проблема: Когда все серверы в одной OSPF area, создаются нежелательные маршруты типа VPSVILLE → HOME → IHOR. **Решение: Использовать отдельные OSPF instances для каждого сервера** #### Конфигурация с отдельными OSPF Instances: ```shell # На HOME (home.rt.shx.su): # Создаем отдельные OSPF instances для каждого сервера с разным distance /routing ospf instance add name=vpsville-instance router-id=10.100.0.1 distance=110 # Основной (Ростелеком) add name=ihor-instance router-id=10.100.0.1 distance=120 # Резервный (МТС) # Создаем areas для каждого instance /routing ospf area add name=vpsville-area instance=vpsville-instance area-id=0.0.0.0 add name=ihor-area instance=ihor-instance area-id=0.0.0.0 # VPSVILLE интерфейсы в свой instance /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=vpsville-area instance=vpsville-instance add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=vpsville-area instance=vpsville-instance # IHOR интерфейсы в свой instance add interfaces=gre-MSK-IHOR-RTK cost=10 area=ihor-area instance=ihor-instance add interfaces=gre-MSK-IHOR-MTS cost=100 area=ihor-area instance=ihor-instance # На MSK-VPSVILLE (msk.vpsville.rt.shx.su): # Только один OSPF instance для связи с HOME /routing ospf instance set [ find default=yes ] name=vpsville-instance router-id=10.100.0.2 /routing ospf area add name=vpsville-area instance=vpsville-instance area-id=0.0.0.0 /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=vpsville-area instance=vpsville-instance add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=vpsville-area instance=vpsville-instance # На MSK-IHOR (msk.ihor.rt.shx.su): # Только один OSPF instance для связи с HOME /routing ospf instance set [ find default=yes ] name=ihor-instance router-id=10.100.0.3 /routing ospf area add name=ihor-area instance=ihor-instance area-id=0.0.0.0 /routing ospf interface-template add interfaces=gre-MSK-IHOR-RTK cost=10 area=ihor-area instance=ihor-instance add interfaces=gre-MSK-IHOR-MTS cost=100 area=ihor-area instance=ihor-instance ``` #### Альтернатива: Route Tables для полного контроля ```shell # На HOME создать отдельные таблицы маршрутизации /routing table add name=vpsville-table fib add name=ihor-table fib # Настроить routing rules для выбора таблицы /routing rule add src-address=192.168.111.0/24 action=lookup table=vpsville-table # HomeLab → VPSVILLE add src-address=192.168.222.0/24 action=lookup table=ihor-table # Основной трафик → IHOR # OSPF автоматически добавит маршруты в соответствующие таблицы # В vpsville-table будет маршрут от VPSVILLE # В ihor-table будет маршрут от IHOR ``` #### Почему отдельные OSPF Instances работают: 1. **Полная изоляция**: Каждый сервер работает в своем OSPF instance 2. **Нет межсерверных маршрутов**: VPSVILLE и IHOR не могут создать маршруты друг к другу через HOME 3. **Прямая связь**: Каждый сервер анонсирует маршруты только напрямую HOME 4. **Простота**: Каждый instance работает независимо, без сложных area настроек #### Важные особенности отдельных OSPF Instances: **Дублирование маршрутов:** - ✅ **Нормально**: HOME получает маршрут 0.0.0.0/0 от каждого сервера - ✅ **Автоматический выбор**: RouterOS выбирает маршрут с лучшим distance - ✅ **Failover**: Если один сервер недоступен, используется маршрут от другого **Cost работает только внутри instance:** - ❌ **Между instances**: Cost не сравнивается - ✅ **Внутри instance**: Cost работает нормально (Ростелеком vs МТС) - ✅ **Distance**: Используется для приоритизации между instances **Пример маршрутов на HOME:** ```shell /ip route print where dst-address=0.0.0.0/0 # Результат: # dst-address=0.0.0.0/0 gateway=10.100.2.2 distance=110 # От VPSVILLE (основной) # dst-address=0.0.0.0/0 gateway=10.100.4.2 distance=120 # От IHOR (резервный) ``` #### Детальное объяснение проблемы и решения: **Проблема с одним OSPF instance:** - Все серверы в одном OSPF instance обмениваются всеми маршрутами - VPSVILLE может создать маршрут VPSVILLE → HOME → IHOR - IHOR может создать маршрут IHOR → HOME → VPSVILLE - Это создает нежелательные межсерверные маршруты через HOME - HOME становится транзитным узлом между серверами **Решение с отдельными OSPF instances:** - **VPSVILLE-HOME**: Работает в отдельном instance (vpsville-instance) - **IHOR-HOME**: Работает в отдельном instance (ihor-instance) - **Полная изоляция**: Серверы не могут создать маршруты друг к другу - **Прямая связь**: Каждый сервер анонсирует маршруты только напрямую HOME #### Схема работы отдельных OSPF Instances: ```mermaid graph TB subgraph "OSPF Instance: vpsville-instance" HOME_VPS[HOME
home.rt.shx.su] VPSVILLE[MSK-VPSVILLE
msk.vpsville.rt.shx.su] GRE_VPS[GRE туннели
VPSVILLE-HOME] end subgraph "OSPF Instance: ihor-instance" HOME_IHR[HOME
home.rt.shx.su] IHOR[MSK-IHOR
msk.ihor.rt.shx.su] GRE_IHR[GRE туннели
IHOR-HOME] end HOME_VPS -. "OSPF" .- GRE_VPS GRE_VPS --> VPSVILLE HOME_IHR -. "OSPF" .- GRE_IHR GRE_IHR --> IHOR %% НЕТ связи между instances! VPSVILLE -. "НЕТ OSPF" .- IHOR style HOME_VPS fill:#e1f5fe style HOME_IHR fill:#e1f5fe style VPSVILLE fill:#ff9800 style IHOR fill:#ff9800 ``` #### Преимущества отдельных OSPF Instances: | Преимущество | Описание | Практическое применение | |--------------|----------|-------------------------| | **Полная изоляция** | Каждый сервер в своем instance | Нет межсерверных маршрутов | | **Простота** | Простая настройка без сложных areas | Легко понять и поддерживать | | **Контроль** | Точный контроль над маршрутизацией | HOME получает маршруты только напрямую | | **Масштабируемость** | Легко добавлять новые серверы | Каждый новый сервер получает свой instance | | **Отладка** | Простая диагностика проблем | Проблемы локализованы в конкретном instance | | **Производительность** | Меньше OSPF трафика | Каждый instance работает независимо | #### Сравнение подходов для решения проблемы межсерверных маршрутов: | Подход | Дублирование маршрутов | Cost между серверами | Сложность настройки | Рекомендация | |--------|------------------------|---------------------|-------------------|--------------| | **Один OSPF instance** | ❌ Нет дублирования | ✅ Cost работает | 🟢 Простая | ❌ Создает межсерверные маршруты | | **Один instance + фильтры** | ❌ Нет дублирования | ✅ Cost работает | 🟡 Средняя | ✅ **Рекомендуемый** | | **Отдельные instances** | ✅ Есть дублирование | ❌ Cost не работает | 🟢 Простая | ✅ Альтернатива | | **Route Tables** | ✅ Нет дублирования | ✅ Полный контроль | 🟡 Средняя | ✅ Для сложных случаев | | **NSSA Areas** | ✅ Нет дублирования | ✅ Cost работает | 🔴 Сложная | ❌ Избыточно для вашей задачи | #### Решение 3: Один OSPF Instance с фильтрами (рекомендуемое) **Лучшее решение**: Использовать один OSPF instance с фильтрами для запрета межсерверных маршрутов. #### Конфигурация с одним OSPF Instance и фильтрами: ```shell # На HOME (home.rt.shx.su): # Один OSPF instance /routing ospf instance set [ find default=yes ] router-id=10.100.0.1 # Одна area /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # Все интерфейсы в один instance с разным cost /routing ospf interface-template # Ростелеком (основной провайдер) - низкий cost add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone # Создать фильтр для запрета маршрутов через HOME как gateway /routing filter add name=ospf-no-inter-server chain=input protocol=ospf rule="if (gateway=10.100.0.0/16) { reject } else { accept }" # Применить фильтр к OSPF instance /routing ospf instance set [ find default=yes ] in-filter=ospf-no-inter-server ``` #### Альтернативный фильтр (более точный): ```shell # Создать фильтр который отклоняет маршруты через HOME как gateway /routing filter add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.2.1) { reject } else { accept }" add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.4.1) { reject } else { accept }" add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.1.1) { reject } else { accept }" add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.3.1) { reject } else { accept }" # Применить фильтр /routing ospf instance set [ find default=yes ] in-filter=ospf-block-inter-server ``` #### Еще более точный фильтр (только межсерверные маршруты): ```shell # Блокировать только маршруты где gateway = IP другого сервера /routing filter add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.2.2 && dst-address=10.100.4.0/30) { reject } else { accept }" add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.4.2 && dst-address=10.100.2.0/30) { reject } else { accept }" add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.1.2 && dst-address=10.100.3.0/30) { reject } else { accept }" add name=ospf-block-inter-server chain=input protocol=ospf rule="if (gateway=10.100.3.2 && dst-address=10.100.1.0/30) { reject } else { accept }" ``` #### На серверах (VPSVILLE, IHOR): ```shell # Обычная OSPF конфигурация без изменений /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 # или 10.100.0.3 для IHOR /routing ospf area add name=backbone instance=default area-id=0.0.0.0 /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone # или gre-MSK-IHOR-RTK add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # или gre-MSK-IHOR-MTS ``` #### Почему это решение лучше: 1. ✅ **Cost работает**: Все в одном instance, cost сравнивается 2. ✅ **Нет межсерверных маршрутов**: Фильтры блокируют нежелательные маршруты 3. ✅ **Простота**: Один instance, простая настройка 4. ✅ **Гибкость**: Можно точно настроить что блокировать 5. ✅ **Производительность**: Меньше OSPF трафика чем с отдельными instances #### Как работают фильтры: **Точный фильтр** (рекомендуемый): ```shell # Блокирует маршруты где gateway = 10.100.0.0/16 (через HOME) if (gateway=10.100.0.0/16) { reject } else { accept } ``` **Что это означает:** - ✅ HOME получает маршруты 0.0.0.0/0 от серверов напрямую - ❌ HOME НЕ получает маршруты где gateway = 10.100.x.x (через себя как транзит) - ✅ Серверы не могут создать маршруты друг к другу через HOME - ✅ Cost работает для выбора оптимального пути к интернету **Примеры блокируемых маршрутов:** - VPSVILLE → gateway=10.100.4.1 → IHOR (блокируется) - IHOR → gateway=10.100.2.1 → VPSVILLE (блокируется) - VPSVILLE → gateway=10.100.1.1 → HOME (блокируется) **Примеры разрешенных маршрутов:** - VPSVILLE → gateway=0.0.0.0 → Интернет (разрешается) - IHOR → gateway=0.0.0.0 → Интернет (разрешается) **Результат:** - VPSVILLE анонсирует: 0.0.0.0/0 (cost=10 через Ростелеком, cost=100 через МТС) - IHOR анонсирует: 0.0.0.0/0 (cost=10 через Ростелеком, cost=100 через МТС) - HOME выбирает лучший маршрут на основе cost - НЕТ маршрутов типа VPSVILLE → HOME → IHOR #### Проверка работы одного OSPF Instance с фильтрами: ```shell # Проверить OSPF instance /routing ospf instance print # Проверить OSPF соседей /routing ospf neighbor print # Проверить маршруты /routing ospf route print # Проверить интерфейсы /routing ospf interface-template print # Проверить фильтры /routing filter print # Проверить что нет межсерверных маршрутов /routing ospf route print where dst-address~"10.100" # Проверить что нет маршрутов через HOME как gateway /routing ospf route print where gateway~"10.100" # Проверить работу фильтра /routing filter print /routing filter print detail ``` #### Мониторинг отдельных OSPF Instances: ```shell # На HOME проверить маршруты от VPSVILLE (vpsville-instance) /routing ospf route print where instance=vpsville-instance # На HOME проверить маршруты от IHOR (ihor-instance) /routing ospf route print where instance=ihor-instance # Проверить OSPF соседей в каждом instance /routing ospf neighbor print where instance=vpsville-instance /routing ospf neighbor print where instance=ihor-instance # Убедиться что нет межсерверных маршрутов /routing ospf route print where dst-address~"10.100" ``` #### Диагностика проблем с отдельными Instances: ```shell # Если маршруты не получаются, проверить: # 1. OSPF instances /routing ospf instance print # 2. OSPF соседей /routing ospf neighbor print # 3. GRE туннели /interface gre print # 4. Interface template /routing ospf interface-template print # 5. Логи OSPF /log print where topics~"ospf" # 6. Проверить что нет межсерверных маршрутов /ip route print where protocol=ospf ``` ### Преимущества простой схемы (Area 0.0.0.0): 1. **Простота настройки**: Все устройства в одной area 2. **Быстрая конвергенция**: Нет меж-area маршрутизации 3. **Простота отладки**: Легче диагностировать проблемы 4. **Совместимость**: Работает с любыми версиями RouterOS ### Когда переходить на сложные схемы: #### Переход на Схему 2 (по локациям) если: - У вас будет больше московских серверов (5+) - Нужна изоляция московского трафика - Планируется добавление других стран #### Переход на Схему 3 (по провайдерам) если: - Нужна полная изоляция трафика по провайдерам - Планируется добавление третьего провайдера - Требуется сложная политика маршрутизации ### Конфигурация для Схемы 2 (по локациям): ```shell # На HOME (Area 0.0.0.0 - Backbone): /routing ospf area add name=backbone instance=default area-id=0.0.0.0 add name=msk-area instance=default area-id=0.0.0.1 add name=swe-area instance=default area-id=0.0.0.2 # На MSK-VPSVILLE и MSK-IHOR (Area 0.0.0.1 - MSK): /routing ospf area add name=backbone instance=default area-id=0.0.0.0 add name=msk-area instance=default area-id=0.0.0.1 # На SWE-HIPHOST (Area 0.0.0.2 - SWE): /routing ospf area add name=backbone instance=default area-id=0.0.0.0 add name=swe-area instance=default area-id=0.0.0.2 ``` ### Конфигурация для Схемы 3 (по провайдерам): ```shell # На всех устройствах: /routing ospf area add name=backbone instance=default area-id=0.0.0.0 add name=rtk-area instance=default area-id=0.0.0.10 add name=mts-area instance=default area-id=0.0.0.20 # Ростелеком туннели в rtk-area: /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=rtk-area add interfaces=gre-MSK-IHOR-RTK cost=10 area=rtk-area add interfaces=gre-SWE-HIPHOST-RTK cost=10 area=rtk-area # МТС туннели в mts-area: add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=mts-area add interfaces=gre-MSK-IHOR-MTS cost=100 area=mts-area add interfaces=gre-SWE-HIPHOST-MTS cost=100 area=mts-area ``` ### Проверка конфигурации Areas: ```shell # Проверить все areas /routing ospf area print # Проверить интерфейсы в каждой area /routing ospf interface-template print # Проверить соседей и их areas /routing ospf neighbor print detail # Проверить маршруты по areas /routing ospf route print ``` ### Рекомендации по выбору Area ID: | Area ID | Назначение | Описание | |---------|------------|----------| | 0.0.0.0 | Backbone area | Основная area (обязательно) | | 0.0.0.1 | Первая обычная area | Для простых сетей | | 0.0.0.2 | Вторая обычная area | Для расширенных сетей | | 0.0.0.10 | Area для Ростелеком | Изоляция трафика Ростелеком | | 0.0.0.20 | Area для МТС | Изоляция трафика МТС | | 0.0.0.100 | Area для Москвы | Изоляция московского трафика | | 0.0.0.200 | Area для Швеции | Изоляция шведского трафика | ### Миграция с простой схемы на сложную: ```shell # Шаг 1: Добавить новые areas /routing ospf area add name=msk-area instance=default area-id=0.0.0.1 # Шаг 2: Изменить area для московских интерфейсов /routing ospf interface-template set [ find where interfaces=gre-MSK-VPSVILLE-RTK ] area=msk-area set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] area=msk-area # Шаг 3: Проверить что OSPF работает /routing ospf neighbor print ``` --- ## Архитектура: Московские серверы как единый OSPF кластер ### Концепция Все московские серверы (MSK-VPSVILLE, MSK-IHOR) объединены в единый OSPF кластер. Если на одном из них падает GRE туннель к SWE-HIPHOST, весь трафик автоматически идет через другой сервер. ### Схема архитектуры ```mermaid graph TB subgraph "Москва - OSPF кластер" VPSVILLE[MSK-VPSVILLE
msk.vpsville.rt.shx.su] IHOR[MSK-IHOR
msk.ihor.rt.shx.su] end subgraph "Швеция" HIPHOST[SWE-HIPHOST
swe.hiphost.rt.shx.su] end subgraph "Домашний шлюз" HOME[HOME
home.rt.shx.su] end %% GRE туннели от HOME к московским серверам HOME -- "GRE MSK-VPSVILLE-RTK
10.100.2.0/30" --> VPSVILLE HOME -- "GRE MSK-VPSVILLE-MTS
10.100.1.0/30" --> VPSVILLE HOME -- "GRE MSK-IHOR-RTK
10.100.4.0/30" --> IHOR HOME -- "GRE MSK-IHOR-MTS
10.100.3.0/30" --> IHOR %% GRE туннели от московских серверов к SWE-HIPHOST VPSVILLE -- "GRE SWE-HIPHOST
10.200.1.0/30" --> HIPHOST IHOR -- "GRE SWE-HIPHOST
10.200.2.0/30" --> HIPHOST %% OSPF связи между московскими серверами VPSVILLE -. "OSPF" .- IHOR %% HOME получает маршруты от московских серверов VPSVILLE -. "OSPF маршруты" .- HOME IHOR -. "OSPF маршруты" .- HOME style VPSVILLE fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff style IHOR fill:#ff9800,stroke:#f57c00,stroke-width:2px,color:#fff style HIPHOST fill:#4caf50,stroke:#388e3c,stroke-width:2px,color:#fff style HOME fill:#e0e0e0,stroke:#9e9e9e,stroke-width:2px,color:#000 ``` ### Конфигурация на московских серверах #### На MSK-VPSVILLE (msk.vpsville.rt.shx.su): ```shell # 1. GRE туннель к SWE-HIPHOST (межсерверный туннель) /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=10.200.1.1/30 interface=gre-SWE-HIPHOST # 2. GRE туннель к MSK-IHOR (межсерверный туннель) /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.0.1/30 interface=gre-MSK-VPSVILLE-IHOR # 3. OSPF конфигурация /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 4. Добавить все интерфейсы в OSPF /routing ospf interface-template # Интерфейсы к HOME add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone # Интерфейс к SWE-HIPHOST add interfaces=gre-SWE-HIPHOST cost=10 area=backbone # Интерфейс к MSK-IHOR add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone # 5. Анонсировать маршрут 0.0.0.0/0 через SWE-HIPHOST /ip route add dst-address=0.0.0.0/0 gateway=10.200.1.2 distance=1 # 6. OSPF redistribute /routing ospf instance set [ find default=yes ] router-id=10.100.0.2 redistribute=connected,static ``` #### На MSK-IHOR (msk.ihor.rt.shx.su): ```shell # 1. GRE туннель к SWE-HIPHOST (межсерверный туннель) /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=10.200.2.1/30 interface=gre-SWE-HIPHOST # 2. GRE туннель к MSK-VPSVILLE (межсерверный туннель) /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.0.2/30 interface=gre-MSK-VPSVILLE-IHOR # 3. OSPF конфигурация /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 4. Добавить все интерфейсы в OSPF /routing ospf interface-template # Интерфейсы к HOME add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone # Интерфейс к SWE-HIPHOST add interfaces=gre-SWE-HIPHOST cost=10 area=backbone # Интерфейс к MSK-VPSVILLE add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone # 5. Анонсировать маршрут 0.0.0.0/0 через SWE-HIPHOST /ip route add dst-address=0.0.0.0/0 gateway=10.200.2.2 distance=1 # 6. OSPF redistribute /routing ospf instance set [ find default=yes ] router-id=10.100.0.3 redistribute=connected,static ``` ### Конфигурация на SWE-HIPHOST (swe.hiphost.rt.shx.su): ```shell # 1. GRE туннели от московских серверов (межсерверные туннели) /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=10.200.1.2/30 interface=gre-SWE-HIPHOST /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.2.2/30 interface=gre-MSK-VPSVILLE-IHOR # 2. OSPF конфигурация /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 3. Добавить интерфейсы в OSPF /routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone add interfaces=gre-MSK-VPSVILLE-IHOR cost=10 area=backbone # 4. OSPF redistribute (маршрут 0.0.0.0/0 получен через DHCP) /routing ospf instance set [ find default=yes ] router-id=10.100.0.5 redistribute=connected ``` ### Конфигурация на HOME (home.rt.shx.su): ```shell # 1. OSPF конфигурация - только получение маршрутов /routing ospf area add name=backbone instance=default area-id=0.0.0.0 # 2. Добавить интерфейсы к московским серверам в OSPF (нормальные) /routing ospf interface-template # Ростелеком (основной провайдер) - низкий cost add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone add interfaces=gre-MSK-IHOR-RTK cost=10 area=backbone # МТС (резервный провайдер) - высокий cost add interfaces=gre-MSK-VPSVILLE-MTS cost=100 area=backbone add interfaces=gre-MSK-IHOR-MTS cost=100 area=backbone # 3. Policy routing для выбора сервера /routing rule add src-address=192.168.111.0/24 action=lookup table=MTS # HomeLab → МТС add src-address=192.168.222.0/24 action=lookup table=MSK # Основной трафик → Ростелеком # 4. Отключить redistribute на HOME (не анонсировать маршруты) /routing ospf instance set [ find default=yes ] redistribute=none ``` ### Межсерверные туннели (OSPF кластер) | Туннель | Подсеть | Сервер A | IP A | Сервер B | IP B | Описание | OSPF Cost | |---------|---------|----------|------|----------|------|----------|-----------| | gre-SWE-HIPHOST | 10.200.1.0/30 | MSK-VPSVILLE | 10.200.1.1 | SWE-HIPHOST | 10.200.1.2 | VPSVILLE ↔ SWE | 10 | | gre-SWE-HIPHOST | 10.200.2.0/30 | MSK-IHOR | 10.200.2.1 | SWE-HIPHOST | 10.200.2.2 | IHOR ↔ SWE | 10 | | gre-MSK-VPSVILLE-IHOR | 10.200.0.0/30 | MSK-VPSVILLE | 10.200.0.1 | MSK-IHOR | 10.200.0.2 | VPSVILLE ↔ IHOR | 5 | **Примечание**: Все межсерверные туннели используют диапазон 10.200.0.0/16, что обеспечивает четкое разделение от туннелей HOME (10.100.0.0/16). ### Единая система именования межсерверных туннелей Для удобства массовой рассылки статических списков маршрутизации все межсерверные туннели используют единые названия: #### Принцип именования: - **gre-SWE-HIPHOST** - все туннели к SWE-HIPHOST (от VPSVILLE и IHOR) - **gre-MSK-VPSVILLE-IHOR** - все туннели между московскими серверами и к IHOR #### Преимущества единого именования: 1. **Массовая настройка**: Одинаковые команды для всех серверов 2. **Упрощение скриптов**: Можно использовать шаблоны конфигурации 3. **Единообразие**: Легче поддерживать и документировать 4. **Масштабируемость**: При добавлении новых серверов схема остается понятной #### Пример массовой рассылки конфигурации: ```shell # Шаблон для всех серверов с туннелем gre-SWE-HIPHOST /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=/30 interface=gre-SWE-HIPHOST /routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone # Шаблон для всех серверов с туннелем gre-MSK-VPSVILLE-IHOR /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=/30 interface=gre-MSK-VPSVILLE-IHOR /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone ``` ### Логика разделения адресов на диапазоны #### Диапазон 10.100.0.0/16 - Туннели от HOME - **Назначение**: Все GRE туннели, которые создает HOME (домашний шлюз) - **Принцип**: HOME всегда инициирует туннели к удаленным серверам - **Примеры**: - MSK-VPSVILLE-RTK (10.100.2.0/30) - HOME → VPSVILLE через Ростелеком - MSK-VPSVILLE-MTS (10.100.1.0/30) - HOME → VPSVILLE через МТС - MSK-IHOR-RTK (10.100.4.0/30) - HOME → IHOR через Ростелеком - MSK-IHOR-MTS (10.100.3.0/30) - HOME → IHOR через МТС - SWE-HIPHOST-RTK (10.100.6.0/30) - HOME → HIPHOST через Ростелеком - SWE-HIPHOST-MTS (10.100.5.0/30) - HOME → HIPHOST через МТС #### Диапазон 10.200.0.0/16 - Межсерверные туннели - **Назначение**: GRE туннели между серверами (без участия HOME) - **Принцип**: Серверы создают туннели друг к другу для OSPF связности - **Примеры**: - MSK-VPSVILLE ↔ MSK-IHOR (10.200.0.0/30) - связь между московскими серверами - MSK-VPSVILLE ↔ SWE-HIPHOST (10.200.1.0/30) - связь VPSVILLE → SWE - MSK-IHOR ↔ SWE-HIPHOST (10.200.2.0/30) - связь IHOR → SWE ### Альтернативный подход: Единый диапазон Если хотите использовать единый диапазон 10.100.0.0/16 для всех туннелей: | Туннель | Подсеть | IP (левый сервер) | IP (правый сервер) | Описание | |--------------------------------|-----------------|-------------------|--------------------|----------| | MSK-VPSVILLE ↔ SWE-HIPHOST | 10.100.7.0/30 | 10.100.7.1 | 10.100.7.2 | VPSVILLE → SWE | | MSK-IHOR ↔ SWE-HIPHOST | 10.100.8.0/30 | 10.100.8.1 | 10.100.8.2 | IHOR → SWE | | MSK-VPSVILLE ↔ MSK-IHOR | 10.100.9.0/30 | 10.100.9.1 | 10.100.9.2 | Межсерверная связь | ### Рекомендация: Единый диапазон **Рекомендую использовать единый диапазон 10.100.0.0/16** для всех туннелей: | Тип туннеля | Туннель | Подсеть | Описание | |-------------|---------|---------|----------| | **HOME → Remote** | MSK-VPSVILLE-MTS | 10.100.1.0/30 | HOME → VPSVILLE (МТС) | | **HOME → Remote** | MSK-VPSVILLE-RTK | 10.100.2.0/30 | HOME → VPSVILLE (Ростелеком) | | **HOME → Remote** | MSK-IHOR-MTS | 10.100.3.0/30 | HOME → IHOR (МТС) | | **HOME → Remote** | MSK-IHOR-RTK | 10.100.4.0/30 | HOME → IHOR (Ростелеком) | | **HOME → Remote** | SWE-HIPHOST-MTS | 10.100.5.0/30 | HOME → HIPHOST (МТС) | | **HOME → Remote** | SWE-HIPHOST-RTK | 10.100.6.0/30 | HOME → HIPHOST (Ростелеком) | | **Server ↔ Server** | gre-SWE-HIPHOST | 10.100.7.0/30 | VPSVILLE ↔ SWE | | **Server ↔ Server** | gre-SWE-HIPHOST | 10.100.8.0/30 | IHOR ↔ SWE | | **Server ↔ Server** | gre-MSK-VPSVILLE-IHOR | 10.100.9.0/30 | VPSVILLE ↔ IHOR | **Преимущества единого диапазона:** 1. **Простота**: Все туннели в одном диапазоне 2. **Логичность**: Последовательная нумерация 3. **Масштабируемость**: Легко добавлять новые туннели 4. **Документирование**: Проще вести учет адресов ### Логика работы failover 1. **Нормальная работа**: - HOME получает маршрут 0.0.0.0/0 от MSK-VPSVILLE через OSPF - MSK-VPSVILLE имеет GRE туннель gre-SWE-HIPHOST к SWE-HIPHOST (10.200.1.0/30) 2. **Отказ GRE туннеля gre-SWE-HIPHOST на MSK-VPSVILLE**: - MSK-VPSVILLE больше не может достичь SWE-HIPHOST через gre-SWE-HIPHOST - MSK-VPSVILLE убирает маршрут 0.0.0.0/0 из OSPF - HOME получает маршрут 0.0.0.0/0 от MSK-IHOR через OSPF - Весь трафик идет через MSK-IHOR → gre-SWE-HIPHOST → SWE-HIPHOST (10.200.2.0/30) 3. **Автоматическое восстановление**: - Когда GRE туннель gre-SWE-HIPHOST на MSK-VPSVILLE восстанавливается - MSK-VPSVILLE снова анонсирует маршрут 0.0.0.0/0 - OSPF выбирает оптимальный путь (обычно через MSK-VPSVILLE) ### Преимущества этой архитектуры 1. **Полная отказоустойчивость**: Если один московский сервер теряет связь с SWE-HIPHOST, трафик идет через другой 2. **Автоматический failover**: OSPF автоматически переключает маршруты 3. **Быстрое восстановление**: При восстановлении связи автоматически возвращается к оптимальному маршруту 4. **Масштабируемость**: Легко добавить третий московский сервер ### Мониторинг failover ```shell # Проверить OSPF маршруты /routing ospf route print # Проверить активные маршруты /ip route print where active=yes # Проверить состояние GRE туннелей /interface gre print # Проверить OSPF соседей /routing ospf neighbor print ``` ### Массовая рассылка конфигурации #### Шаблон для всех серверов с туннелем gre-SWE-HIPHOST: ```shell # Заменить , , на соответствующие значения /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=/30 interface=gre-SWE-HIPHOST /routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone ``` #### Шаблон для всех серверов с туннелем gre-MSK-VPSVILLE-IHOR: ```shell # Заменить , , на соответствующие значения /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=/30 interface=gre-MSK-VPSVILLE-IHOR /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone ``` #### Пример конкретных команд для каждого сервера: **MSK-VPSVILLE:** ```shell /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=10.200.1.1/30 interface=gre-SWE-HIPHOST /routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.0.1/30 interface=gre-MSK-VPSVILLE-IHOR /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone ``` **MSK-IHOR:** ```shell /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=10.200.2.1/30 interface=gre-SWE-HIPHOST /routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.0.2/30 interface=gre-MSK-VPSVILLE-IHOR /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone ``` **SWE-HIPHOST:** ```shell /interface gre add name=gre-SWE-HIPHOST remote-address= local-address= /ip address add address=10.200.1.2/30 interface=gre-SWE-HIPHOST /routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone /interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address= local-address= /ip address add address=10.200.2.2/30 interface=gre-MSK-VPSVILLE-IHOR /routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=10 area=backbone ``` ### Тестирование failover ```shell # На MSK-VPSVILLE отключить GRE туннель gre-SWE-HIPHOST /interface gre disable [ find where name=gre-SWE-HIPHOST ] # Проверить что маршрут исчез из OSPF /routing ospf route print # На HOME проверить что маршрут изменился /ip route print where dst-address=0.0.0.0/0 # Включить туннель обратно /interface gre enable [ find where name=gre-SWE-HIPHOST ] # На MSK-IHOR отключить GRE туннель gre-SWE-HIPHOST /interface gre disable [ find where name=gre-SWE-HIPHOST ] # Проверить что маршрут исчез из OSPF /routing ospf route print # Включить туннель обратно /interface gre enable [ find where name=gre-SWE-HIPHOST ] ``` ### Проверка работы cost: ```shell # На HOME проверить OSPF маршруты с cost /routing ospf route print # Должно показать что-то вроде: # dst-address=0.0.0.0/0 gateway=10.100.2.2 cost=10 # Основной # dst-address=0.0.0.0/0 gateway=10.100.5.2 cost=10 # Основной # dst-address=0.0.0.0/0 gateway=10.100.1.2 cost=100 # Резервный # dst-address=0.0.0.0/0 gateway=10.100.5.2 cost=100 # Резервный ``` --- ## Настройка BFD для OSPF BFD (Bidirectional Forwarding Detection) обеспечивает быстрое обнаружение недоступности каналов и ускоряет failover OSPF. ### Конфигурация BFD на HOME (RouterOS 7.14+): ```shell # 1. Настроить BFD параметры для GRE интерфейсов /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3 add interface=gre-SWE-HIPHOST-RTK interval=100ms multiplier=3 add interface=gre-MSK-VPSVILLE-MTS interval=100ms multiplier=3 add interface=gre-MSK-VPSVILLE-RTK interval=100ms multiplier=3 add interface=gre-MSK-IHOR-MTS interval=100ms multiplier=3 add interface=gre-MSK-IHOR-RTK interval=100ms multiplier=3 # 2. Включить BFD для OSPF /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes set [ find where interfaces=gre-SWE-HIPHOST-RTK ] bfd=yes set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] bfd=yes set [ find where interfaces=gre-MSK-VPSVILLE-RTK ] bfd=yes set [ find where interfaces=gre-MSK-IHOR-MTS ] bfd=yes set [ find where interfaces=gre-MSK-IHOR-RTK ] bfd=yes ``` ### Конфигурация BFD на SWE-HIPHOST (RouterOS 7.14+): ```shell # 1. Настроить BFD параметры для GRE интерфейсов /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3 add interface=gre-SWE-HIPHOST-RTK interval=100ms multiplier=3 add interface=gre-SWE-HIPHOST interval=100ms multiplier=3 add interface=gre-MSK-VPSVILLE-IHOR interval=100ms multiplier=3 # 2. Включить BFD для OSPF /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes set [ find where interfaces=gre-SWE-HIPHOST-RTK ] bfd=yes set [ find where interfaces=gre-SWE-HIPHOST ] bfd=yes set [ find where interfaces=gre-MSK-VPSVILLE-IHOR ] bfd=yes ``` ### Конфигурация BFD на MSK-VPSVILLE (RouterOS 7.14+): ```shell # 1. Настроить BFD параметры для GRE интерфейсов /routing bfd add interface=gre-MSK-VPSVILLE-MTS interval=100ms multiplier=3 add interface=gre-MSK-VPSVILLE-RTK interval=100ms multiplier=3 add interface=gre-SWE-HIPHOST interval=100ms multiplier=3 add interface=gre-MSK-VPSVILLE-IHOR interval=100ms multiplier=3 # 2. Включить BFD для OSPF /routing ospf interface-template set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] bfd=yes set [ find where interfaces=gre-MSK-VPSVILLE-RTK ] bfd=yes set [ find where interfaces=gre-SWE-HIPHOST ] bfd=yes set [ find where interfaces=gre-MSK-VPSVILLE-IHOR ] bfd=yes ``` ### Конфигурация BFD на MSK-IHOR (RouterOS 7.14+): ```shell # 1. Настроить BFD параметры для GRE интерфейсов /routing bfd add interface=gre-MSK-IHOR-MTS interval=100ms multiplier=3 add interface=gre-MSK-IHOR-RTK interval=100ms multiplier=3 add interface=gre-SWE-HIPHOST interval=100ms multiplier=3 add interface=gre-MSK-VPSVILLE-IHOR interval=100ms multiplier=3 # 2. Включить BFD для OSPF /routing ospf interface-template set [ find where interfaces=gre-MSK-IHOR-MTS ] bfd=yes set [ find where interfaces=gre-MSK-IHOR-RTK ] bfd=yes set [ find where interfaces=gre-SWE-HIPHOST ] bfd=yes set [ find where interfaces=gre-MSK-VPSVILLE-IHOR ] bfd=yes ``` ### Параметры BFD: | Параметр | Значение | Описание | |----------|----------|----------| | **interval** | 100ms | Интервал отправки BFD пакетов (быстрое обнаружение) | | **multiplier** | 3 | Количество пропущенных пакетов для объявления недоступности | | **Время обнаружения** | 300ms | interval × multiplier = 100ms × 3 = 300ms | ### Полная конфигурация BFD для всех серверов: | Сервер | GRE интерфейсы с BFD | BFD параметры | OSPF интеграция | |--------|---------------------|---------------|-----------------| | **HOME** | gre-SWE-HIPHOST-MTS, gre-SWE-HIPHOST-RTK, gre-MSK-VPSVILLE-MTS, gre-MSK-VPSVILLE-RTK, gre-MSK-IHOR-MTS, gre-MSK-IHOR-RTK | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes | | **MSK-VPSVILLE** | gre-MSK-VPSVILLE-MTS, gre-MSK-VPSVILLE-RTK, gre-SWE-HIPHOST, gre-MSK-VPSVILLE-IHOR | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes | | **MSK-IHOR** | gre-MSK-IHOR-MTS, gre-MSK-IHOR-RTK, gre-SWE-HIPHOST, gre-MSK-VPSVILLE-IHOR | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes | | **SWE-HIPHOST** | gre-SWE-HIPHOST-MTS, gre-SWE-HIPHOST-RTK, gre-SWE-HIPHOST, gre-MSK-VPSVILLE-IHOR | interval=100ms, multiplier=3 | Все интерфейсы в OSPF с bfd=yes | ### Альтернативные настройки BFD: | Тип обнаружения | Interval | Multiplier | Время обнаружения | Применение | |----------------|----------|------------|-------------------|------------| | Быстрое | 50ms | 3 | 150ms | Критичные каналы | | Стандартное | 200ms | 3 | 600ms | Обычные каналы | | Медленное | 500ms | 3 | 1.5s | Экономия ресурсов | ### Проверка BFD (RouterOS 7.14+): ```shell # Проверить статус BFD сессий /routing bfd print # Проверить детали BFD сессий /routing bfd print detail # Проверить BFD на интерфейсах /interface gre print # Проверить OSPF с BFD /routing ospf interface-template print where bfd=yes # Проверить BFD логи /log print where topics~"bfd" # Проверить BFD статистику /routing bfd print stats ``` ### Преимущества BFD: 1. **Быстрое обнаружение**: 300ms вместо нескольких секунд OSPF 2. **Надежность**: Независимое от OSPF обнаружение недоступности 3. **Гибкость**: Настраиваемые параметры для разных каналов 4. **Совместимость**: Работает с любыми протоколами маршрутизации --- ## Диагностика проблем с BFD ### Проблема: BFD session в статусе "init" и "down" Если BFD сессия не устанавливается, это может быть связано с несколькими причинами: #### 1. Проверка базовой связности ```shell # Проверить что GRE туннель работает /interface gre print # Проверить ping через GRE туннель ping 10.100.5.2 count=5 # Проверить что OSPF соседи установлены /routing ospf neighbor print ``` #### 2. Проверка BFD конфигурации ```shell # Проверить BFD сессии /routing bfd print # Проверить детали BFD /routing bfd print detail # Проверить что BFD включен в OSPF /routing ospf interface-template print where bfd=yes ``` #### 3. Возможные решения ##### Решение 1: Проверить параметры BFD ```shell # Убедиться что параметры одинаковые на обеих сторонах /routing bfd print # Если параметры разные, исправить: /routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=100ms multiplier=3 ``` ##### Решение 2: Перезапустить BFD сессию ```shell # Удалить и пересоздать BFD сессию /routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ] /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3 ``` ##### Решение 3: Проверить firewall ```shell # Проверить что BFD пакеты не блокируются /ip firewall filter print where protocol=udp # BFD использует UDP порт 3784, убедиться что он не заблокирован ``` ##### Решение 4: Использовать более медленные параметры ```shell # Попробовать более медленные параметры для стабильности /routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3 ``` #### 4. Пошаговая диагностика ```shell # Шаг 1: Проверить GRE туннель /interface gre print # Шаг 2: Проверить OSPF соседей /routing ospf neighbor print # Шаг 3: Проверить BFD сессии /routing bfd print # Шаг 4: Проверить BFD детали /routing bfd print detail # Шаг 5: Проверить логи /log print where topics~"bfd" ``` #### 5. Альтернатива: Отключить BFD временно ```shell # Если BFD не работает, можно временно отключить /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no # OSPF будет работать без BFD, но медленнее ``` #### 6. Специфичные проблемы и решения ##### Проблема: BFD не работает на GRE туннелях Некоторые версии RouterOS могут иметь проблемы с BFD на GRE туннелях. В этом случае: ```shell # Проверить версию RouterOS /system resource print # Если версия < 7.14, BFD может не работать на GRE # В этом случае лучше отключить BFD /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no ``` ##### Проблема: BFD конфликтует с OSPF ```shell # Проверить OSPF соседей /routing ospf neighbor print # Если OSPF работает, но BFD нет - отключить BFD /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no ``` ##### Проблема: Неправильные параметры BFD ```shell # Проверить текущие параметры /routing bfd print detail # Установить стандартные параметры /routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3 ``` #### 7. Рекомендуемая последовательность настройки BFD ```shell # Шаг 1: Убедиться что OSPF работает /routing ospf neighbor print # Шаг 2: Настроить BFD с медленными параметрами /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=200ms multiplier=3 # Шаг 3: Включить BFD в OSPF /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes # Шаг 4: Проверить статус /routing bfd print # Шаг 5: Если работает, ускорить параметры /routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=100ms multiplier=3 ``` #### 8. Мониторинг BFD ```shell # Добавить логирование BFD /system logging add topics=bfd # Проверить логи BFD /log print where topics~"bfd" # Мониторинг BFD сессий :put "BFD Status:" /routing bfd print ``` #### 9. Быстрая диагностика для вашего случая Выполните эти команды на обеих сторонах (gateway и сервер): ```shell # На gateway (HOME): # 1. Проверить GRE туннель /interface gre print where name~"SWE-HIPHOST" # 2. Проверить ping до сервера ping 10.100.5.2 count=5 # 3. Проверить OSPF соседей /routing ospf neighbor print # 4. Проверить BFD сессии /routing bfd print # 5. Проверить детали BFD /routing bfd print detail # На сервере (SWE-HIPHOST): # 1. Проверить GRE туннель /interface gre print where name~"SWE-HIPHOST" # 2. Проверить ping до gateway ping 10.100.5.1 count=5 # 3. Проверить OSPF соседей /routing ospf neighbor print # 4. Проверить BFD сессии /routing bfd print # 5. Проверить детали BFD /routing bfd print detail ``` #### 10. Быстрое решение Если диагностика показывает проблемы с BFD: ```shell # Временно отключить BFD на обеих сторонах /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no # Удалить BFD сессии /routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ] # Проверить что OSPF работает /routing ospf neighbor print ``` #### 11. Проблема: BFD packets Rx = 0 Если на gateway BFD session показывает `packets Rx = 0`, это означает что BFD пакеты не доходят от сервера до gateway. ##### Диагностика проблемы с BFD пакетами ```shell # На gateway проверить детали BFD сессии /routing bfd print detail # Должно показать что-то вроде: # packets-tx: 1234 # packets-rx: 0 # ← Проблема здесь # state: down ``` ##### Возможные причины и решения: ###### Причина 1: BFD не настроен на сервере ```shell # На сервере проверить BFD конфигурацию /routing bfd print # Если BFD не настроен, добавить: /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=200ms multiplier=3 # И включить в OSPF: /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes ``` ###### Причина 2: Firewall блокирует BFD пакеты ```shell # На сервере проверить firewall правила /ip firewall filter print where protocol=udp # BFD использует UDP порт 3784, проверить что он не заблокирован # Добавить правило для разрешения BFD (если нужно): /ip firewall filter add chain=forward protocol=udp dst-port=3784 action=accept comment="BFD" ``` ###### Причина 3: Разные параметры BFD ```shell # На обеих сторонах проверить параметры BFD /routing bfd print detail # Убедиться что interval и multiplier одинаковые # Если разные - исправить на сервере: /routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3 ``` ###### Причина 4: GRE туннель нестабилен ```shell # Проверить стабильность GRE туннеля /interface gre print # Проверить ping через туннель ping 10.100.5.2 count=10 interval=100ms # Если есть потери пакетов, BFD может не работать ``` ##### Быстрое решение для диагностики: ```shell # На сервере временно отключить BFD /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no /routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ] # На gateway тоже отключить /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no /routing bfd remove [ find where interface=gre-SWE-HIPHOST-MTS ] # Проверить что OSPF работает без BFD /routing ospf neighbor print ``` ##### Пошаговая настройка BFD заново: ```shell # Шаг 1: Убедиться что OSPF работает /routing ospf neighbor print # Шаг 2: Настроить BFD на сервере с медленными параметрами /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=500ms multiplier=3 # Шаг 3: Включить BFD в OSPF на сервере /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes # Шаг 4: Настроить BFD на gateway с теми же параметрами /routing bfd add interface=gre-SWE-HIPHOST-MTS interval=500ms multiplier=3 # Шаг 5: Включить BFD в OSPF на gateway /routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes # Шаг 6: Проверить статус /routing bfd print ``` ### Пояснение: DHCP маршруты в OSPF - **DHCP маршруты** считаются как `connected` в RouterOS - **redistribute=connected** анонсирует все connected маршруты, включая DHCP - **redistribute=static** анонсирует только статические маршруты - **DHCP маршрут 0.0.0.0/0** автоматически попадет в OSPF при `redistribute=connected` - **AWS metadata service (169.254.169.254)** тоже может анонсироваться и мешать ### Проблема с AWS metadata service AWS автоматически добавляет маршрут к 169.254.169.254 (metadata service), который тоже будет анонсироваться через OSPF при `redistribute=connected`. Это может создавать нежелательные маршруты. ### Проверка DHCP маршрута и AWS metadata: ```shell # Проверить тип маршрута 0.0.0.0/0 /ip route print where dst-address=0.0.0.0/0 # Проверить AWS metadata маршрут /ip route print where dst-address=169.254.169.254/32 # Должно показать что-то вроде: # Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC # Маршрут от DHCP будет помечен как DYNAMIC # AWS metadata маршрут тоже будет DYNAMIC ``` ---