T

denozord 43b1804731 Expand README.md with a comprehensive architecture overview for Moscow servers as a unified OSPF cluster. Added detailed configuration steps for MSK-VPSVILLE, MSK-IHOR, SWE-HIPHOST, and HOME, including GRE tunnel setups, OSPF configurations, failover logic, and monitoring/testing procedures. Enhanced clarity on failover advantages and scalability.

2025-07-11 00:03:35 +07:00

README.md

Expand README.md with a comprehensive architecture overview for Moscow servers as a unified OSPF cluster. Added detailed configuration steps for MSK-VPSVILLE, MSK-IHOR, SWE-HIPHOST, and HOME, including GRE tunnel setups, OSPF configurations, failover logic, and monitoring/testing procedures. Enhanced clarity on failover advantages and scalability.

2025-07-11 00:03:35 +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

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

Ростелеком (RTK) - ОСНОВНОЙ провайдер

Туннель	Назначение	Локация	Статус	Приоритет
MSK-VPSVILLE-RTK	Основной канал VPSVILLE	Москва	Активен	1 (основной)
MSK-IHOR-RTK	Основной канал IHOR	Москва	Активен	1 (основной)
SWE-HIPHOST-RTK	Основной канал HIPHOST	Швеция	Активен	1 (основной)

МТС (MTS) - РЕЗЕРВНЫЙ провайдер

Туннель	Назначение	Локация	Статус	Приоритет
MSK-VPSVILLE-MTS	Резервный канал VPSVILLE	Москва	Активен	2 (резервный)
MSK-IHOR-MTS	Резервный канал IHOR	Москва	Активен	2 (резервный)
SWE-HIPHOST-MTS	Резервный канал HIPHOST	Швеция	Активен	2 (резервный)

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

Отказоустойчивость: Два независимых провайдера обеспечивают непрерывность работы
Географическое распределение: Серверы в разных локациях (Москва, Швеция)
Балансировка нагрузки: Возможность распределения трафика между провайдерами
Масштабируемость: Легкое добавление новых туннелей и серверов

Мониторинг

Отслеживание состояния всех GRE туннелей
Мониторинг пропускной способности каналов
Автоматическое переключение при отказе основного канала
Логирование событий и статистики

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

Протокол: GRE (Generic Routing Encapsulation)
Шифрование: IPSec (опционально)
Мониторинг: Keepalive пакеты
Failover: Автоматическое переключение при потере связи

Туннель	Подсеть	HOME (домашний)	Remote (удалённый)	Описание
MSK-VPSVILLE-MTS	10.100.1.0/30	10.100.1.1	10.100.1.2	Резервный канал VPSVILLE
MSK-VPSVILLE-RTK	10.100.2.0/30	10.100.2.1	10.100.2.2	Основной канал VPSVILLE
MSK-IHOR-MTS	10.100.3.0/30	10.100.3.1	10.100.3.2	Резервный канал IHOR
MSK-IHOR-RTK	10.100.4.0/30	10.100.4.1	10.100.4.2	Основной канал IHOR
SWE-HIPHOST-MTS	10.100.5.0/30	10.100.5.1	10.100.5.2	Резервный канал HIPHOST
SWE-HIPHOST-RTK	10.100.6.0/30	10.100.6.1	10.100.6.2	Основной канал 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	Домашний роутер
Москва IHOR	msk-ihor-gw	msk.ihor.rt.shx.su	Роутер IHOR, Москва
Москва VPSVILLE	msk-vpsville-gw	msk.vpsville.rt.shx.su	Роутер VPSVILLE, Москва
Швеция HIPHOST	swe-hiphost-gw	swe.hiphost.rt.shx.su	Роутер HIPHOST, Швеция

Туннель	Подсеть	IP (левый хостер)	IP (правый хостер)
msk.vpsville ↔ msk.ihor	10.200.0.0/30	10.200.0.1	10.200.0.2
msk.vpsville ↔ swe.hiphost	10.200.0.4/30	10.200.0.5	10.200.0.6
msk.ihor ↔ swe.hiphost	10.200.0.8/30	10.200.0.9	10.200.0.10

Конфигурация 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 выбирает кратчайший путь между серверами

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

HOME - конечная точка: Подключается к серверам по GRE, но не участвует в межсерверной маршрутизации
Получение маршрутов: HOME получает маршруты от серверов через OSPF
Policy routing: HOME использует route tables для выбора нужного сервера/провайдера
Отправка трафика: HOME отправляет трафик по правилам маршрутизации

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

Трафик 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

Выбор способа

Способ 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
/routing ospf area
add name=backbone instance=default area-id=0.0.0.0

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

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

# Шаг 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.100.5.0/30" --> HIPHOST
    IHOR -- "GRE SWE-HIPHOST<br/>10.100.6.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.100.5.1/30 interface=gre-SWE-HIPHOST

# 2. GRE туннель к MSK-IHOR (для OSPF)
/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.100.5.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.100.6.1/30 interface=gre-SWE-HIPHOST

# 2. GRE туннель к MSK-VPSVILLE (для OSPF)
/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

# 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-IHOR-VPSVILLE cost=5 area=backbone

# 5. Анонсировать маршрут 0.0.0.0/0 через SWE-HIPHOST
/ip route add dst-address=0.0.0.0/0 gateway=10.100.6.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-VPSVILLE remote-address=<VPSVILLE_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.100.5.2/30 interface=gre-SWE-HIPHOST-VPSVILLE

/interface gre add name=gre-SWE-HIPHOST-IHOR remote-address=<IHOR_WAN_IP> local-address=<SWE-HIPHOST_WAN_IP>
/ip address add address=10.100.6.2/30 interface=gre-SWE-HIPHOST-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-VPSVILLE cost=10 area=backbone
add interfaces=gre-SWE-HIPHOST-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  # Основной трафик → Ростелеком

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

Нормальная работа:
- HOME получает маршрут 0.0.0.0/0 от MSK-VPSVILLE через OSPF
- MSK-VPSVILLE имеет GRE туннель к SWE-HIPHOST
Отказ GRE туннеля MSK-VPSVILLE → SWE-HIPHOST:
- MSK-VPSVILLE больше не может достичь SWE-HIPHOST
- MSK-VPSVILLE убирает маршрут 0.0.0.0/0 из OSPF
- HOME получает маршрут 0.0.0.0/0 от MSK-IHOR через OSPF
- Весь трафик идет через MSK-IHOR → SWE-HIPHOST
Автоматическое восстановление:
- Когда GRE туннель MSK-VPSVILLE → SWE-HIPHOST восстанавливается
- 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

Тестирование failover

# На MSK-VPSVILLE отключить 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 ]

Проверка работы 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-MSK-VPSVILLE-MTS interval=100ms multiplier=3
add interface=gre-MSK-IHOR-MTS 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-MSK-VPSVILLE-MTS ] bfd=yes
set [ find where interfaces=gre-MSK-IHOR-MTS ] bfd=yes

Конфигурация BFD на SWE-HIPHOST (RouterOS 7.14+):

# 1. Настроить BFD параметры для GRE интерфейса
/routing bfd
add interface=gre-SWE-HIPHOST-MTS interval=100ms multiplier=3

# 2. Включить BFD для OSPF
/routing ospf interface-template
set [ find where interfaces=gre-SWE-HIPHOST-MTS ] bfd=yes

Конфигурация BFD на MSK-VPSVILLE (RouterOS 7.14+):

# 1. Настроить BFD параметры для GRE интерфейса
/routing bfd
add interface=gre-MSK-VPSVILLE-MTS interval=100ms multiplier=3

# 2. Включить BFD для OSPF
/routing ospf interface-template
set [ find where interfaces=gre-MSK-VPSVILLE-MTS ] bfd=yes

Параметры BFD:

interval=100ms - интервал отправки BFD пакетов (100ms = быстрое обнаружение)
multiplier=3 - количество пропущенных пакетов для объявления недоступности
Время обнаружения = interval × multiplier = 100ms × 3 = 300ms

Альтернативные настройки BFD:

# Быстрое обнаружение (для критичных каналов)
/routing bfd
add interface=gre-SWE-HIPHOST-MTS interval=50ms multiplier=3  # 150ms

# Стандартное обнаружение
/routing bfd
add interface=gre-SWE-HIPHOST-MTS interval=200ms multiplier=3  # 600ms

# Медленное обнаружение (для экономии ресурсов)
/routing bfd
add interface=gre-SWE-HIPHOST-MTS interval=500ms multiplier=3  # 1.5s

Проверка BFD (RouterOS 7.14+):

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

# Проверить BFD на интерфейсах
/interface gre print

# Проверить OSPF с BFD
/routing ospf interface-template print where bfd=yes

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

Преимущества 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 (новая)

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

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

Ростелеком (RTK) - ОСНОВНОЙ провайдер

МТС (MTS) - РЕЗЕРВНЫЙ провайдер

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

Мониторинг

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

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

Роль 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+)

2a. Альтернативный способ без routing filters

3. Альтернативный способ через OSPF networks (RouterOS 6.x)

Конфигурация на HOME

1. Создание In filter для OSPF (опционально)

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

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

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

Способ 2: Без фильтров (простой)

Способ 3: Только статические маршруты

README.md