T

denozord 0b669e7053 Enhance README.md with detailed instructions for configuring OSPF in "receive-only" mode on HOME. Added multiple approaches for achieving this configuration, including disabling route redistribution, using filters, and creating stub areas. Included a comparison table of methods and emphasized the importance of avoiding inter-server routing. Updated sections on OSPF instance isolation and provided comprehensive examples for each method.

2025-07-11 09:49:08 +07:00

README.md

Enhance README.md with detailed instructions for configuring OSPF in "receive-only" mode on HOME. Added multiple approaches for achieving this configuration, including disabling route redistribution, using filters, and creating stub areas. Included a comparison table of methods and emphasized the importance of avoiding inter-server routing. Updated sections on OSPF instance isolation and provided comprehensive examples for each method.

2025-07-11 09:49:08 +07:00

README.md

SHX Network Infrastructure

Обзор сети

Данный проект описывает сетевую инфраструктуру с двумя провайдерами интернет-соединения и множественными GRE туннелями для обеспечения отказоустойчивости и географического распределения.

Архитектура сети

Основная схема (обновлено)

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<br/>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

Детальная схема туннелей (обновлено)

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<br/>GRE Tunnel]
            RTK_VPS[MSK-VPSVILLE-RTK<br/>GRE Tunnel]
        end
        
        subgraph "Москва - IHOR"
            MTS_IHOR[MSK-IHOR-MTS<br/>GRE Tunnel]
            RTK_IHOR[MSK-IHOR-RTK<br/>GRE Tunnel]
        end
        
        subgraph "Швеция - HIPHOST"
            MTS_HIP[SWE-HIPHOST-MTS<br/>GRE Tunnel]
            RTK_HIP[SWE-HIPHOST-RTK<br/>GRE Tunnel]
        end
    end
    
    subgraph "Удаленные серверы"
        VPS[VPSVILLE Server<br/>Москва]
        IHR[IHOR Server<br/>Москва]
        HIP["HIPHOST<br/>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

Схема европейского трафика (новая)

graph TD
    subgraph "Москва"
        VPSVILLE_MSK[VPSVILLE<br/>Москва]
        IHOR_MSK[IHOR<br/>Москва]
    end
    subgraph "Швеция"
        HIPHOST_SWE["HIPHOST<br/>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 (новая)

graph TB
    subgraph "Москва - VPSVILLE"
        VPSVILLE[VPSVILLE<br/>msk.vpsville.rt.shx.su]
    end
    
    subgraph "Москва - IHOR"
        IHOR[IHOR<br/>msk.ihor.rt.shx.su]
    end
    
    subgraph "Домашний шлюз"
        HOME[HOME<br/>home.rt.shx.su]
    end
    
    %% GRE туннели от домашнего шлюза (только клиентские подключения)
    HOME -- "GRE MSK-VPSVILLE-RTK<br/>10.100.2.0/30" --> VPSVILLE
    HOME -- "GRE MSK-VPSVILLE-MTS<br/>10.100.1.0/30" --> VPSVILLE
    HOME -- "GRE MSK-IHOR-RTK<br/>10.100.4.0/30" --> IHOR
    HOME -- "GRE MSK-IHOR-MTS<br/>10.100.3.0/30" --> IHOR
    
    %% GRE туннель между московскими серверами (независимо от HOME)
    VPSVILLE -- "GRE MSK-VPSVILLE-IHOR<br/>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

Схема отказоустойчивости (обновлено)

graph TB
    subgraph "Основной путь"
        GW[Gateway]
        MTS[MТС - Основной]
        RTK[Ростелеком - Резервный]
    end
    
    subgraph "Туннели по приоритету"
        subgraph "VPSVILLE"
            VPS_MTS[MSK-VPSVILLE-MTS<br/>Приоритет 1]
            VPS_RTK[MSK-VPSVILLE-RTK<br/>Приоритет 2]
        end
        
        subgraph "IHOR"
            IHR_MTS[MSK-IHOR-MTS<br/>Приоритет 1]
            IHR_RTK[MSK-IHOR-RTK<br/>Приоритет 2]
        end
        
        subgraph "HIPHOST"
            HIP_MTS[SWE-HIPHOST-MTS<br/>Приоритет 1]
            HIP_RTK[SWE-HIPHOST-RTK<br/>Приоритет 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	Автоматическое переключение при потере связи	Обеспечение отказоустойчивости

Тип туннеля	Туннель	Подсеть	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

OSPF: Оптимальная настройка для GRE туннелей

В данной архитектуре используется OSPF для динамической маршрутизации между всеми GRE туннелями. Основной провайдер — Ростелеком, резервный — МТС. Для HomeLab (например, 192.168.111.0/24) весь трафик направляется через МТС с помощью policy routing (route-table=MTS).

Пример конфигурации OSPF на RouterOS

# 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=<MTS-GW> routing-table=MTS
/ip firewall mangle
add chain=prerouting src-address=192.168.111.0/24 action=mark-routing new-routing-mark=MTS

# <MTS-GW> — адрес следующего хопа через МТС (например, 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

# 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+)

# 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+)

# 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 туннели (пример)

/interface gre add name=gre-MSK-VPSVILLE-RTK remote-address=<REMOTE_IP> local-address=<YOUR_WAN_IP>
/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+)

# 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 убирает маршруты, трафик идёт по резервным путям.
Масштабируемость: количество туннелей ограничено только ресурсами оборудования, добавление новых площадок не требует изменений на старых.

Пример добавления нового GRE туннеля и OSPF (RouterOS 7.14+)

/interface gre add name=gre-NEW-SITE remote-address=<NEW_REMOTE_IP> local-address=<YOUR_WAN_IP>
/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+)

# 1. Создаём таблицу маршрутизации для Европы
/routing table
add name=EU fib

# 2. Routing rule для европейского трафика (пример: по dst-address)
/routing rule
add dst-address=<EU_SUBNETS> 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  # Резервный канал

<EU_SUBNETS> — список европейских подсетей или диапазонов (можно использовать address-list и mangle для сложных случаев).

Преимущества

Оптимизация маршрутов: Европейский трафик идёт по кратчайшему пути через SWE-HIPHOST.
Резервирование: OSPF обеспечивает автоматический failover при недоступности туннеля.
Гибкость: Можно легко расширять список европейских подсетей или добавить резервные маршруты.

Локация	Имя сервера	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, Швеция

Туннель	Подсеть	Сервер 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

Конфигурация GRE туннеля между московскими серверами

На VPSVILLE (msk.vpsville.rt.shx.su):

# Создание GRE туннеля к IHOR
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<IHOR_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/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):

# Создание GRE туннеля к VPSVILLE
/interface gre add name=gre-MSK-IHOR-VPSVILLE remote-address=<VPSVILLE_WAN_IP> local-address=<IHOR_WAN_IP>
/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):

# 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 между московскими серверами

Прямая связь между серверами: VPSVILLE ↔ IHOR через GRE туннель 10.200.0.0/30
OSPF анонсирует маршруты: Каждый сервер анонсирует свои сети через OSPF
HOME получает маршруты: HOME получает маршруты от обоих серверов через OSPF (только получение)
Автоматический failover: Если один сервер недоступен, OSPF убирает маршруты через него
Оптимальные маршруты: OSPF выбирает кратчайший путь между серверами

Настройка OSPF "только получение" на HOME

ВАЖНО: passive=yes отключает OSPF полностью, включая получение маршрутов! Это НЕ подходит для вашей задачи.

Для того чтобы HOME gateway только получал маршруты от VPSVILLE и IHOR, но не отправлял свои маршруты, используется несколько подходов:

❌ НЕ РАБОТАЕТ: Passive Mode

# ВНИМАНИЕ: Это НЕ работает!
add interfaces=gre-MSK-VPSVILLE-RTK cost=10 area=backbone passive=yes  # ❌ Маршруты пропадут

Почему не работает: passive=yes отключает OSPF полностью - нет hello пакетов, нет соседства, нет маршрутов.

Способ 1: Отключение redistribute (Рекомендуемый)

# На 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: Использование фильтров

# На 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 (для сложных сетей)

# Создать 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 (НЕ РЕКОМЕНДУЕТСЯ)

# ВНИМАНИЕ: 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+	Низкая	❌ Нет	НЕ РЕКОМЕНДУЕТСЯ

Проверка работы OSPF "только получение"

# На 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

Мониторинг связей

# Проверка состояния GRE туннелей
/interface gre print

# Проверка OSPF соседей
/routing ospf neighbor print

# Проверка маршрутов
/ip route print

OSPF и дублирование маршрутов

При использовании OSPF между серверами может происходить дублирование маршрутов в таблице маршрутизации. Это нормальное поведение, но важно понимать, как это контролировать.

Как работает дублирование маршрутов

OSPF анонсирует маршруты: Каждый сервер анонсирует свои сети через OSPF
Множественные пути: HOME может получить маршрут до одной сети через разные серверы
Distance и cost: OSPF использует cost для выбора оптимального пути, но может создавать резервные маршруты

Пример дублирования маршрутов

# На 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

# Настройка разных 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 для разделения трафика

# Создание отдельных таблиц маршрутизации
/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 автоматически добавит маршруты в соответствующие таблицы

Преимущества дублирования маршрутов

Автоматический failover: Если основной маршрут недоступен, используется резервный
Load balancing: Можно настроить балансировку нагрузки между маршрутами
Отказоустойчивость: Сеть продолжает работать даже при отказе части каналов

Мониторинг дублирования

# Просмотр всех маршрутов с деталями
/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

# Создание фильтра, который пропускает только 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+)

# Настройка 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

# Настройка 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)

# В 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 (опционально)

# Фильтр для входящих 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

Проверка конфигурации

# Проверка OSPF маршрутов на удаленном сервере
/routing ospf route print

# Проверка OSPF маршрутов на HOME
/routing ospf route print

# Проверка таблицы маршрутизации на HOME
/ip route print where protocol=ospf

Пример полной конфигурации на удаленном сервере (RouterOS 7.14+)

Способ 1: С фильтром (если работает)

# 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: Без фильтров (простой)

# 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: Только статические маршруты

# 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: Простой статический маршрут (гарантированно работает)

# 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

# Просто добавить статический маршрут на 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

Логика работы

Удаленный сервер имеет маршрут по умолчанию (0.0.0.0/0) в своей таблице
Redistribute анонсирует маршруты через OSPF (с фильтром или без)
HOME получает маршруты от удаленного сервера
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 (рекомендуемый)

# 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: Без фильтрации (если фильтры не работают)

# 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:

# 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:

# Если 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):

# 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):

# 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 (получает маршруты):

# 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:

SWE-HIPHOST анонсирует маршрут 0.0.0.0/0 через оба канала:
- gre-SWE-HIPHOST-RTK (cost=10) - основной
- gre-SWE-HIPHOST-MTS (cost=100) - резервный
MSK-VPSVILLE анонсирует маршрут 0.0.0.0/0 через оба канала:
- gre-MSK-VPSVILLE-RTK (cost=10) - основной
- gre-MSK-VPSVILLE-MTS (cost=100) - резервный
HOME получает маршруты от обоих серверов и выбирает оптимальный путь на основе cost
Автоматический failover: Если основной канал падает, OSPF автоматически переключается на резервный

Настройка OSPF Area

Важно: Все устройства должны использовать одинаковую area для корректной работы OSPF.

Вариант 1: Одна area (рекомендуемый для простых сетей)

# На всех устройствах (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

# На всех устройствах создать одинаковую 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 настройки:

# Проверить существующие area:
/routing ospf area print

# Проверить OSPF соседей:
/routing ospf neighbor print

# Проверить что соседи в одной area:
/routing ospf neighbor print detail

Оптимальная схема OSPF Areas для вашей сети

Рекомендация: Начните с простой схемы

Для вашей текущей сети рекомендую начать с Схемы 1 (одна area):

Конфигурация для Схемы 1:

# На всех устройствах (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:

# На 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 для полного контроля

# На 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 работают:

Полная изоляция: Каждый сервер работает в своем OSPF instance
Нет межсерверных маршрутов: VPSVILLE и IHOR не могут создать маршруты друг к другу через HOME
Прямая связь: Каждый сервер анонсирует маршруты только напрямую HOME
Простота: Каждый instance работает независимо, без сложных area настроек

Важные особенности отдельных OSPF Instances:

Дублирование маршрутов:

✅ Нормально: HOME получает маршрут 0.0.0.0/0 от каждого сервера
✅ Автоматический выбор: RouterOS выбирает маршрут с лучшим distance
✅ Failover: Если один сервер недоступен, используется маршрут от другого

Cost работает только внутри instance:

❌ Между instances: Cost не сравнивается
✅ Внутри instance: Cost работает нормально (Ростелеком vs МТС)
✅ Distance: Используется для приоритизации между instances

Пример маршрутов на HOME:

/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:

graph TB
    subgraph "OSPF Instance: vpsville-instance"
        HOME_VPS[HOME<br/>home.rt.shx.su]
        VPSVILLE[MSK-VPSVILLE<br/>msk.vpsville.rt.shx.su]
        GRE_VPS[GRE туннели<br/>VPSVILLE-HOME]
    end
    
    subgraph "OSPF Instance: ihor-instance"
        HOME_IHR[HOME<br/>home.rt.shx.su]
        IHOR[MSK-IHOR<br/>msk.ihor.rt.shx.su]
        GRE_IHR[GRE туннели<br/>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 и фильтрами:

# На 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

# Создать фильтр для запрета межсерверных маршрутов (простой вариант)
/routing filter
add name=ospf-no-inter-server chain=input protocol=ospf rule="if (dst-address=10.100.0.0/16) { reject } else { accept }"

# Применить фильтр к OSPF instance
/routing ospf instance
set [ find default=yes ] in-filter=ospf-no-inter-server

Альтернативный фильтр (более точный):

# Создать фильтр который отклоняет маршруты между серверами
/routing filter
add name=ospf-block-inter-server chain=input protocol=ospf rule="if (dst-address=10.100.2.0/30 && src-address=10.100.4.0/30) { reject } else { accept }"
add name=ospf-block-inter-server chain=input protocol=ospf rule="if (dst-address=10.100.4.0/30 && src-address=10.100.2.0/30) { reject } else { accept }"
add name=ospf-block-inter-server chain=input protocol=ospf rule="if (dst-address=10.100.1.0/30 && src-address=10.100.3.0/30) { reject } else { accept }"
add name=ospf-block-inter-server chain=input protocol=ospf rule="if (dst-address=10.100.3.0/30 && src-address=10.100.1.0/30) { reject } else { accept }"

# Применить фильтр
/routing ospf instance
set [ find default=yes ] in-filter=ospf-block-inter-server

На серверах (VPSVILLE, IHOR):

# Обычная 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

Почему это решение лучше:

✅ Cost работает: Все в одном instance, cost сравнивается
✅ Нет межсерверных маршрутов: Фильтры блокируют нежелательные маршруты
✅ Простота: Один instance, простая настройка
✅ Гибкость: Можно точно настроить что блокировать
✅ Производительность: Меньше OSPF трафика чем с отдельными instances

Как работают фильтры:

Простой фильтр (рекомендуемый):

# Блокирует ВСЕ маршруты к 10.100.0.0/16
if (dst-address=10.100.0.0/16) { reject } else { accept }

Что это означает:

✅ HOME получает маршруты 0.0.0.0/0 от серверов
❌ HOME НЕ получает маршруты к GRE туннелям (10.100.x.x)
✅ Серверы не могут создать маршруты друг к другу через HOME
✅ Cost работает для выбора оптимального пути к интернету

Результат:

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 с фильтрами:

# Проверить 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"

Мониторинг отдельных OSPF Instances:

# На 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:

# Если маршруты не получаются, проверить:
# 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):

Простота настройки: Все устройства в одной area
Быстрая конвергенция: Нет меж-area маршрутизации
Простота отладки: Легче диагностировать проблемы
Совместимость: Работает с любыми версиями RouterOS

Когда переходить на сложные схемы:

Переход на Схему 2 (по локациям) если:

У вас будет больше московских серверов (5+)
Нужна изоляция московского трафика
Планируется добавление других стран

Переход на Схему 3 (по провайдерам) если:

Нужна полная изоляция трафика по провайдерам
Планируется добавление третьего провайдера
Требуется сложная политика маршрутизации

Конфигурация для Схемы 2 (по локациям):

# На 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 (по провайдерам):

# На всех устройствах:
/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:

# Проверить все areas
/routing ospf area print

# Проверить интерфейсы в каждой area
/routing ospf interface-template print

# Проверить соседей и их areas
/routing ospf neighbor print detail

# Проверить маршруты по areas
/routing ospf route print

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 для Швеции	Изоляция шведского трафика

Миграция с простой схемы на сложную:

# Шаг 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, весь трафик автоматически идет через другой сервер.

Схема архитектуры

graph TB
    subgraph "Москва - OSPF кластер"
        VPSVILLE[MSK-VPSVILLE<br/>msk.vpsville.rt.shx.su]
        IHOR[MSK-IHOR<br/>msk.ihor.rt.shx.su]
    end
    
    subgraph "Швеция"
        HIPHOST[SWE-HIPHOST<br/>swe.hiphost.rt.shx.su]
    end
    
    subgraph "Домашний шлюз"
        HOME[HOME<br/>home.rt.shx.su]
    end
    
    %% GRE туннели от HOME к московским серверам
    HOME -- "GRE MSK-VPSVILLE-RTK<br/>10.100.2.0/30" --> VPSVILLE
    HOME -- "GRE MSK-VPSVILLE-MTS<br/>10.100.1.0/30" --> VPSVILLE
    HOME -- "GRE MSK-IHOR-RTK<br/>10.100.4.0/30" --> IHOR
    HOME -- "GRE MSK-IHOR-MTS<br/>10.100.3.0/30" --> IHOR
    
    %% GRE туннели от московских серверов к SWE-HIPHOST
    VPSVILLE -- "GRE SWE-HIPHOST<br/>10.200.1.0/30" --> HIPHOST
    IHOR -- "GRE SWE-HIPHOST<br/>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):

# 1. GRE туннель к SWE-HIPHOST (межсерверный туннель)
/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/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=<IHOR_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/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):

# 1. GRE туннель к SWE-HIPHOST (межсерверный туннель)
/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<IHOR_WAN_IP>
/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=<VPSVILLE_WAN_IP> local-address=<IHOR_WAN_IP>
/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):

# 1. GRE туннели от московских серверов (межсерверные туннели)
/interface gre add name=gre-SWE-HIPHOST remote-address=<VPSVILLE_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.200.1.2/30 interface=gre-SWE-HIPHOST

/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<IHOR_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/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):

# 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

Преимущества единого именования:

Массовая настройка: Одинаковые команды для всех серверов
Упрощение скриптов: Можно использовать шаблоны конфигурации
Единообразие: Легче поддерживать и документировать
Масштабируемость: При добавлении новых серверов схема остается понятной

Пример массовой рассылки конфигурации:

# Шаблон для всех серверов с туннелем gre-SWE-HIPHOST
/interface gre add name=gre-SWE-HIPHOST remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/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=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/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

Преимущества единого диапазона:

Простота: Все туннели в одном диапазоне
Логичность: Последовательная нумерация
Масштабируемость: Легко добавлять новые туннели
Документирование: Проще вести учет адресов

Логика работы failover

Нормальная работа:
- HOME получает маршрут 0.0.0.0/0 от MSK-VPSVILLE через OSPF
- MSK-VPSVILLE имеет GRE туннель gre-SWE-HIPHOST к SWE-HIPHOST (10.200.1.0/30)
Отказ 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)
Автоматическое восстановление:
- Когда GRE туннель gre-SWE-HIPHOST на MSK-VPSVILLE восстанавливается
- MSK-VPSVILLE снова анонсирует маршрут 0.0.0.0/0
- OSPF выбирает оптимальный путь (обычно через MSK-VPSVILLE)

Преимущества этой архитектуры

Полная отказоустойчивость: Если один московский сервер теряет связь с SWE-HIPHOST, трафик идет через другой
Автоматический failover: OSPF автоматически переключает маршруты
Быстрое восстановление: При восстановлении связи автоматически возвращается к оптимальному маршруту
Масштабируемость: Легко добавить третий московский сервер

Мониторинг failover

# Проверить OSPF маршруты
/routing ospf route print

# Проверить активные маршруты
/ip route print where active=yes

# Проверить состояние GRE туннелей
/interface gre print

# Проверить OSPF соседей
/routing ospf neighbor print

Массовая рассылка конфигурации

Шаблон для всех серверов с туннелем gre-SWE-HIPHOST:

# Заменить <REMOTE_IP>, <LOCAL_IP>, <TUNNEL_IP> на соответствующие значения
/interface gre add name=gre-SWE-HIPHOST remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/30 interface=gre-SWE-HIPHOST
/routing ospf interface-template add interfaces=gre-SWE-HIPHOST cost=10 area=backbone

Шаблон для всех серверов с туннелем gre-MSK-VPSVILLE-IHOR:

# Заменить <REMOTE_IP>, <LOCAL_IP>, <TUNNEL_IP> на соответствующие значения
/interface gre add name=gre-MSK-VPSVILLE-IHOR remote-address=<REMOTE_IP> local-address=<LOCAL_IP>
/ip address add address=<TUNNEL_IP>/30 interface=gre-MSK-VPSVILLE-IHOR
/routing ospf interface-template add interfaces=gre-MSK-VPSVILLE-IHOR cost=5 area=backbone

Пример конкретных команд для каждого сервера:

MSK-VPSVILLE:

/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/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=<IHOR_WAN_IP> local-address=<VPSVILLE_WAN_IP>
/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:

/interface gre add name=gre-SWE-HIPHOST remote-address=<SWE-HIPHOST_WAN_IP> local-address=<IHOR_WAN_IP>
/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=<VPSVILLE_WAN_IP> local-address=<IHOR_WAN_IP>
/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:

/interface gre add name=gre-SWE-HIPHOST remote-address=<VPSVILLE_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/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=<IHOR_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/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

# На 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:

# На 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+):

# 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+):

# 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+):

# 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+):

# 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+):

# Проверить статус 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:

Быстрое обнаружение: 300ms вместо нескольких секунд OSPF
Надежность: Независимое от OSPF обнаружение недоступности
Гибкость: Настраиваемые параметры для разных каналов
Совместимость: Работает с любыми протоколами маршрутизации

Диагностика проблем с BFD

Проблема: BFD session в статусе "init" и "down"

Если BFD сессия не устанавливается, это может быть связано с несколькими причинами:

1. Проверка базовой связности

# Проверить что GRE туннель работает
/interface gre print

# Проверить ping через GRE туннель
ping 10.100.5.2 count=5

# Проверить что OSPF соседи установлены
/routing ospf neighbor print

2. Проверка BFD конфигурации

# Проверить BFD сессии
/routing bfd print

# Проверить детали BFD
/routing bfd print detail

# Проверить что BFD включен в OSPF
/routing ospf interface-template print where bfd=yes

3. Возможные решения

Решение 1: Проверить параметры BFD

# Убедиться что параметры одинаковые на обеих сторонах
/routing bfd print

# Если параметры разные, исправить:
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=100ms multiplier=3

Решение 2: Перезапустить BFD сессию

# Удалить и пересоздать 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

# Проверить что BFD пакеты не блокируются
/ip firewall filter print where protocol=udp

# BFD использует UDP порт 3784, убедиться что он не заблокирован

Решение 4: Использовать более медленные параметры

# Попробовать более медленные параметры для стабильности
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3

4. Пошаговая диагностика

# Шаг 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 временно

# Если BFD не работает, можно временно отключить
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no

# OSPF будет работать без BFD, но медленнее

6. Специфичные проблемы и решения

Проблема: BFD не работает на GRE туннелях

Некоторые версии RouterOS могут иметь проблемы с BFD на GRE туннелях. В этом случае:

# Проверить версию 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

# Проверить OSPF соседей
/routing ospf neighbor print

# Если OSPF работает, но BFD нет - отключить BFD
/routing ospf interface-template set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=no

Проблема: Неправильные параметры BFD

# Проверить текущие параметры
/routing bfd print detail

# Установить стандартные параметры
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3

7. Рекомендуемая последовательность настройки BFD

# Шаг 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

# Добавить логирование BFD
/system logging
add topics=bfd

# Проверить логи BFD
/log print where topics~"bfd"

# Мониторинг BFD сессий
:put "BFD Status:"
/routing bfd print

9. Быстрая диагностика для вашего случая

Выполните эти команды на обеих сторонах (gateway и сервер):

# На 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:

# Временно отключить 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 пакетами

# На gateway проверить детали BFD сессии
/routing bfd print detail

# Должно показать что-то вроде:
# packets-tx: 1234
# packets-rx: 0  # ← Проблема здесь
# state: down

Возможные причины и решения:

Причина 1: BFD не настроен на сервере

# На сервере проверить 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 пакеты

# На сервере проверить 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

# На обеих сторонах проверить параметры BFD
/routing bfd print detail

# Убедиться что interval и multiplier одинаковые
# Если разные - исправить на сервере:
/routing bfd set [ find where interface=gre-SWE-HIPHOST-MTS ] interval=200ms multiplier=3

Причина 4: GRE туннель нестабилен

# Проверить стабильность GRE туннеля
/interface gre print

# Проверить ping через туннель
ping 10.100.5.2 count=10 interval=100ms

# Если есть потери пакетов, BFD может не работать

Быстрое решение для диагностики:

# На сервере временно отключить 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 заново:

# Шаг 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:

# Проверить тип маршрута 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

README.md Unescape Escape

SHX Network Infrastructure

Обзор сети

Архитектура сети

Основная схема (обновлено)

Детальная схема туннелей (обновлено)

Схема европейского трафика (новая)

Схема связывания московских серверов через OSPF (новая)

Схема отказоустойчивости (обновлено)

Конфигурация туннелей

Туннели от HOME к удаленным серверам

Преимущества архитектуры

Мониторинг

Технические детали

Рекомендации по адресации GRE туннелей

Полная схема адресации GRE туннелей

Принцип адресации GRE туннелей

Безопасность и маршрутизация на RouterOS

Пример маршрутизации на RouterOS

Пример конфигурации GRE туннеля на RouterOS

OSPF: Оптимальная настройка для GRE туннелей

Рекомендации по настройке

Пример конфигурации OSPF на RouterOS

Логика работы

Failover между московскими туннелями (route-table=MSK)

Как это работает

Пример конфигурации на RouterOS

Примеры конфигурации для RouterOS 7.14+

OSPF (RouterOS 7.14+)

Policy Based Routing (RouterOS 7.14+)

GRE туннели (пример)

Актуальные рекомендации для RouterOS 7.14+

Пример failover для route-table=MSK (RouterOS 7.14+)

Масштабирование сети с GRE и OSPF

Преимущества

Рекомендации

Пример добавления нового GRE туннеля и OSPF (RouterOS 7.14+)

Европейский трафик через GRE SWE-HIPHOST

Как это реализовано

Пример конфигурации (RouterOS 7.14+)

Преимущества

Рекомендации по неймингу CHR серверов

Рекомендуемая структура имени

Пример:

Схема именования серверов

Рекомендации

Распределение IP-адресов между GRE туннелями между хостерами

Рекомендации

Схема адресации для GRE между хостерами

Связывание московских серверов через OSPF

Преимущества связывания московских серверов

Конфигурация GRE туннеля между московскими серверами

На VPSVILLE (msk.vpsville.rt.shx.su):

На IHOR (msk.ihor.rt.shx.su):

На HOME (home.rt.shx.su):

Логика работы OSPF между московскими серверами

Настройка OSPF "только получение" на HOME

❌ НЕ РАБОТАЕТ: Passive Mode

Способ 1: Отключение redistribute (Рекомендуемый)

Способ 2: Использование фильтров

Способ 3: Stub Area (для сложных сетей)

Способ 4: Passive Mode (НЕ РЕКОМЕНДУЕТСЯ)

Сравнение способов настройки OSPF "только получение"

Рекомендуемая конфигурация для HOME

Проверка работы OSPF "только получение"

Роль HOME в архитектуре

Преимущества OSPF "только получение" на HOME

Пример маршрутизации

Мониторинг связей

OSPF и дублирование маршрутов

Как работает дублирование маршрутов

Пример дублирования маршрутов

Контроль дублирования через OSPF cost

Использование route tables для разделения трафика

Преимущества дублирования маршрутов

Мониторинг дублирования

Настройка OSPF для анонса только 0.0.0.0/0 (RouterOS 7.14+)

Конфигурация на удаленных серверах (VPSVILLE, IHOR, HIPHOST)

1. Создание Out filter для OSPF

2. Настройка OSPF Redistribute с фильтром (основной способ для RouterOS 7.14+)

README.md