infra/shx-network
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
16 Commits 1 Branch 0 Tags
5ffa42ec225b0f792ca3d1a6e86106c6b03c6d8f
T
Clone
Open with VS Code Open with VSCodium Open with Intellij IDEA
Download ZIP Download TAR.GZ Download BUNDLE

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 (резервный)

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

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

Мониторинг

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

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

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

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

Для GRE туннелей рекомендуется использовать отдельный диапазон, например, 10.100.0.0/16, чтобы избежать конфликтов с домашней сетью (192.168.0.0/16). Для каждого туннеля выделяется отдельная /30 подсеть (две точки).

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

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

Принцип: Домашний шлюз всегда получает первый IP (.1), удаленные серверы - второй (.2)

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

Правило: Домашний шлюз всегда получает первый IP (.1), удаленные серверы - второй (.2)

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

  • Логическая последовательность: HOME - точка входа в сеть, логично дать ему первый IP
  • Консистентность: Все туннели от HOME имеют одинаковую схему адресации
  • Упрощение конфигурации: Легче запомнить и настроить (HOME всегда .1)
  • Масштабируемость: При добавлении новых туннелей схема остается понятной
  • Устранение путаницы: Нет вопросов "кто где" - HOME всегда .1, серверы всегда .2

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

# Все GRE туннели на HOME получают .1 адрес
/ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS
/ip address add address=10.100.2.1/30 interface=gre-MSK-VPSVILLE-RTK
/ip address add address=10.100.3.1/30 interface=gre-MSK-IHOR-MTS
/ip address add address=10.100.4.1/30 interface=gre-MSK-IHOR-RTK

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

# Все серверы получают .2 адрес в своих туннелях
/ip address add address=10.100.1.2/30 interface=gre-MSK-VPSVILLE-MTS
/ip address add address=10.100.2.2/30 interface=gre-MSK-VPSVILLE-RTK

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

  • Использование диапазона 10.100.0.0/16 для GRE туннелей безопасно, если ваша домашняя сеть — 192.168.0.0/16.
  • Диапазоны не пересекаются, маршрутизация не сломается.
  • На CHR (RouterOS) это стандартная практика: GRE туннели выносят в отдельный диапазон, чтобы не было конфликтов с LAN.
  • Для GRE-интерфейсов прописывайте адресацию только из этого диапазона.
  • В маршрутах на CHR не должно быть статических маршрутов, которые бы направляли 10.100.0.0/16 в локальную сеть.

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

  • Для каждого GRE-интерфейса будет автоматически создан маршрут для /30 подсети.
  • Например, если GRE-интерфейс имеет адрес 10.100.1.1/30, а удалённый — 10.100.1.2, то маршрут до 10.100.1.2 будет через этот GRE-интерфейс.
  • Основная домашняя сеть (192.168.0.0/16) никак не пересекается с этими маршрутами.

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

/interface gre add name=gre-MSK-VPSVILLE-MTS remote-address=<REMOTE_IP> local-address=<YOUR_WAN_IP>
/ip address add address=10.100.1.1/30 interface=gre-MSK-VPSVILLE-MTS
/ip route add dst-address=10.100.1.2/32 gateway=gre-MSK-VPSVILLE-MTS
  • <REMOTE_IP> — внешний IP удалённого сервера
  • <YOUR_WAN_IP> — ваш внешний IP
  • Аналогично для остальных туннелей, меняя адресацию по таблице выше

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

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

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

  1. OSPF cost

    • Для GRE туннелей через Ростелеком (основной) выставить меньший cost (например, 10)
    • Для GRE туннелей через МТС (резервный) — больший cost (например, 100)
    • Это обеспечит приоритет Ростелекома для всего трафика, кроме HomeLab

  2. Policy Based Routing (PBR) для HomeLab

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

  3. OSPF Instance и Area

    • Использовать одну OSPF instance для всех туннелей (если нет особых требований)
    • Все GRE-интерфейсы добавить в одну area (обычно 0.0.0.0)

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

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

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

  • Для каждого нового туннеля используйте отдельную /30 подсеть из выделенного диапазона (например, 10.100.x.0/30).
  • Все GRE-интерфейсы сразу добавляйте в OSPF через interface-template.
  • Используйте шаблоны и автоматизацию для быстрой настройки новых точек.
  • Документируйте назначение каждой подсети и туннеля (см. таблицу выше).

Пример добавления нового 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 при недоступности туннеля.
  • Гибкость: Можно легко расширять список европейских подсетей или добавить резервные маршруты.

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

Грамотный нейминг серверов и шлюзов облегчает сопровождение, масштабирование и диагностику сети.

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

Если у вас несколько хостеров/площадок в одном городе или стране, рекомендуется использовать следующий формат:

<город>.<площадка>.<роль>.<домен>
  • <город> — код города или страны (например, msk, swe)
  • <площадка> — название хостера или дата-центра (например, vpsville, ihor, hiphost)
  • <роль> — rt (router), gw (gateway), srv (server) и т.д.
  • <домен> — основной домен вашей инфраструктуры

Пример:

  • msk.vpsville.rt.shx.su — роутер в Москве, площадка VPSVILLE
  • msk.ihor.rt.shx.su — роутер в Москве, площадка IHOR
  • swe.hiphost.rt.shx.su — роутер в Швеции, площадка HIPHOST
  • home.rt.shx.su — домашний роутер

Примеры для вашей сети

Локация Имя сервера DNS имя Описание
Домашний home-gw home.rt.shx.su Домашний роутер
Москва 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, Швеция

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

  • Используйте короткие, но однозначные аббревиатуры для локаций: msk (Москва), swe (Швеция), home (домашний роутер)
  • Для роли роутера используйте rt (router) вместо gw (gateway)
  • Если есть несколько провайдеров на одной площадке, добавляйте суффикс: msk-ihor-rt-rtk (Москва, IHOR, роутер, Ростелеком)
  • Для серверов без роутерной роли используйте, например, srv (server): msk-ihor-srv

Почему именно такой порядок? Если у вас несколько хостеров в одном городе, такой нейминг позволяет удобно группировать и искать объекты по локации, а внутри — по площадке. Это облегчает навигацию и масштабирование инфраструктуры.

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

Грамотное распределение IP-адресов между GRE-туннелями между хостерами (site-to-site) обеспечивает прозрачность, масштабируемость и отсутствие конфликтов.

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

  • Выделяйте отдельный диапазон для межхостовых туннелей, например, 10.200.0.0/16.
  • Для каждого GRE-туннеля между двумя хостерами используйте отдельную /30 подсеть (2 usable IP).
  • Систематизируйте назначение подсетей (например, по ID площадок или по алфавиту).
  • Документируйте все туннели и адреса в README.

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

Туннель Подсеть 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
  • Для новых туннелей просто берите следующую свободную /30 из диапазона.
  • Такой подход облегчает масштабирование и поддержку сети.

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

Для обеспечения отказоустойчивости и оптимизации маршрутов все московские серверы связаны через OSPF. Это обеспечивает автоматический failover между площадками и оптимальный выбор маршрутов.

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

  1. Автоматический failover между московскими площадками

    • Если VPSVILLE недоступен, трафик автоматически пойдет через IHOR
    • Если IHOR недоступен, трафик пойдет через VPSVILLE

  2. Оптимизация маршрутов

    • OSPF автоматически выберет кратчайший путь
    • Можно настроить разные cost для разных провайдеров

  3. Масштабируемость

    • Легко добавлять новые московские площадки
    • Автоматическое распространение маршрутов

Конфигурация 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 между московскими серверами

  1. Прямая связь между серверами: VPSVILLE ↔ IHOR через GRE туннель 10.200.0.0/30
  2. OSPF анонсирует маршруты: Каждый сервер анонсирует свои сети через OSPF
  3. HOME получает маршруты: HOME получает маршруты от обоих серверов через OSPF
  4. Автоматический failover: Если один сервер недоступен, OSPF убирает маршруты через него
  5. Оптимальные маршруты: 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 между серверами может происходить дублирование маршрутов в таблице маршрутизации. Это нормальное поведение, но важно понимать, как это контролировать.

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

  1. OSPF анонсирует маршруты: Каждый сервер анонсирует свои сети через OSPF
  2. Множественные пути: HOME может получить маршрут до одной сети через разные серверы
  3. 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 автоматически добавит маршруты в соответствующие таблицы

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

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

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

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

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

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

  1. SWE-HIPHOST анонсирует маршрут 0.0.0.0/0 через оба канала:

    • gre-SWE-HIPHOST-RTK (cost=10) - основной
    • gre-SWE-HIPHOST-MTS (cost=100) - резервный

  2. MSK-VPSVILLE анонсирует маршрут 0.0.0.0/0 через оба канала:

    • gre-MSK-VPSVILLE-RTK (cost=10) - основной
    • gre-MSK-VPSVILLE-MTS (cost=100) - резервный

  3. HOME получает маршруты от обоих серверов и выбирает оптимальный путь на основе cost

  4. Автоматический failover: Если основной канал падает, OSPF автоматически переключается на резервный

Настройка OSPF Area

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

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

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

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

Для вашей сети с несколькими локациями и провайдерами рекомендуется использовать многоуровневую схему areas:

Схема 1: Простая (рекомендуемая для начала)

Area 0.0.0.0 (Backbone) - все устройства
├── HOME (home.rt.shx.su)
├── MSK-VPSVILLE (msk.vpsville.rt.shx.su)
├── MSK-IHOR (msk.ihor.rt.shx.su)
└── SWE-HIPHOST (swe.hiphost.rt.shx.su)

Схема 2: По локациям (для масштабирования)

Area 0.0.0.0 (Backbone) - HOME
├── Area 0.0.0.1 (MSK) - московские серверы
│   ├── MSK-VPSVILLE
│   └── MSK-IHOR
└── Area 0.0.0.2 (SWE) - шведский сервер
    └── SWE-HIPHOST

Схема 3: По провайдерам (для изоляции)

Area 0.0.0.0 (Backbone) - HOME
├── Area 0.0.0.10 (RTK) - Ростелеком туннели
│   ├── MSK-VPSVILLE-RTK
│   ├── MSK-IHOR-RTK
│   └── SWE-HIPHOST-RTK
└── Area 0.0.0.20 (MTS) - МТС туннели
    ├── MSK-VPSVILLE-MTS
    ├── MSK-IHOR-MTS
    └── SWE-HIPHOST-MTS

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

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

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

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

  1. Простота настройки: Все устройства в одной area
  2. Быстрая конвергенция: Нет меж-area маршрутизации
  3. Простота отладки: Легче диагностировать проблемы
  4. Совместимость: Работает с любыми версиями 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:

# Стандартные Area ID:
0.0.0.0    # Backbone 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

Проверка работы 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:

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

Диагностика проблем с 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
Reference in New Issue View Git Blame Copy Permalink
S
Description
No description provided
Readme
394 KiB
Languages
Markdown 100%