Маршрутизаторы OSPF (с BIRD на debian) распознают друг друга как соседей, но не могут пропинговать друг друга

Я создал "линейную" топологию с использованием виртуального блока - создав 4 машины и создав отдельную связь между каждой из них с использованием внутренних сетей - R1 (eth0, 10.0.1.1) <-> (eth0, 10.0.2.1) R2 (eth2, 10.0.2.2) <-> (eth0, 10.0.3.1) R3 (eth2, 10.0.3.2) <-> (eth0, 10.0.4.1) R4. Я включил пересылку пакетов для ipv4, используя:

sudo sysctl net.ipv4.ip_forward=1

конфигурация OSPF для R2 и R3 в /etc/bird.conf выглядит следующим образом:

protocol ospf MyOSPF {
    tick 2;
    rfc1583compat yes;
    area 0.0.0.0 {
        stub no;
        interface "eth2" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
        interface "eth0" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
    };
}

когда я ввожу birdc и введите

ospf  show topology

а также

ospf show neighbors

кажется, что все маршрутизаторы видят правильную топологию, распознают соседние маршрутизаторы как соседей и правильно рассчитывают затраты. Однако невозможно пропинговать R3 из R2, если интерфейс не указан вручную (ping -I eth2 10.0.3.1). Это не относится к R1 и R2, где eth0 используется на обоих концах.

Вот как выглядит /etc/network/interfaces на R2:

allow-hotplug eth0
iface eth0 inet static
address 10.0.2.1

auto eth1 #this is the bridged adapter used to ssh to the vm from the host
iface eth1 inet dhcp 

allow-hotplug eth2
iface eth2 inet static
address 10.0.2.2

Я немного сбит с толку, заключается ли проблема в конфигурации интерфейсов или в протоколе маршрутизации.

Вот вывод

ip link

а также

ip route

для каждой машины

Источник

2 ответа

Решение

Я понял! Есть несколько причин, по которым установка не работала - во-первых, адреса не были установлены правильно. Для работы интерфейса должны быть назначены следующие (например) адреса:

R1 (eth0, 10.0.1.1) <-> (eth0, 10.0.1.2) R2 (eth2, 10.0.2.1) <-> (eth0, 10.0.2.2) R3 (eth2, 10.0.3.1) <-> (eth0, 10.0.3.2) R4

чтобы оба интерфейса, обращенные друг к другу на каждых двух соседних маршрутизаторах, находились в одном широковещательном домене (подсеть /24). Маска сети на каждом интерфейсе должна быть установлена ​​на 255.255.255.0.

Что касается конфигурации OSPF в BIRD, в область необходимо было добавить блок "сети", чтобы указать, какую информацию должны обмениваться маршрутизаторы (в частности, о каких сетях говорят маршрутизаторы). В этом случае, поскольку у нас есть сеть /24 (255.255.255.0) на каждом конце, мы можем использовать сеть /16 (255.255.0.0) в операторе сетей для обмена информацией между двумя соседними /24 сетями (10.0.1 и 10.0)..2 например). Итак, в конце это выглядит так:

protocol ospf MyOSPF {
    tick 2;
    rfc1583compat yes;
    area 0.0.0.0 {
        networks {
            10.0.0.0/16;
        };
        stub no;
        interface "eth2" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
        interface "eth0" {
            hello 9;
            retransmit 6;
            cost 10;
            transmit delay 5;
            dead count 5;
            wait 50;
            type broadcast;
        };
    };
}

от bird ospf Конфигурация ручных сетей {set} - Определение области IP диапазонов. Это используется в итоговом происхождении LSA. Скрытые сети не распространяются в другие области.

Источник

Ваши маршрутизаторы могут видеть друг друга через OSPF, потому что OSPF использует многоадресную рассылку любого интерфейса для обнаружения соседей. Это означает, что вам не нужны рабочие таблицы маршрутизации для просмотра соседей, если два маршрутизатора находятся в одном многоадресном домене.

Итак, смотрите на ваши скриншоты - все ваши интерфейсы маршрутизатора находятся либо в 10.0.0.0/8, либо в 192.168.0.0/24. Ваши маршрутизаторы увидят это и предположят, что они находятся в одном и том же широковещательном домене, поэтому вместо отправки пакета eth0 или eth2 или чего-либо еще, они просто отправят трафик через случайные интерфейсы.

Вы должны использовать небольшие прямые подсети для связи маршрутизатора с маршрутизатором, а не иметь этих гигантских подсетей / 8, которые просто могут запутать.

Распространенной ситуацией является наличие маршрутизатора с множеством различных перекрывающихся таблиц маршрутизации, которые на самом деле являются разными реальными сетями.

В частности, для птиц: http://bird.network.cz/?get_doc&f=bird-2.html

Наконец, вам нужно убедиться, что птица знает о маршрутах ОС и задает маршруты в ОС. Ах, это может быть источником вашей проблемы - из FAQ:

BIRD не импортирует некоторые роутеры из ядра

Во-первых, опция обучения протокола ядра должна быть активной.

Во-вторых, маршруты "устройств", связанные с интерфейсными адресами / префиксами, автоматически добавляемыми ОС / ядром, никогда не импортируются. Вы можете добавить их, используя прямой протокол.

В-третьих, по некоторым неясным и историческим причинам BIRD 1.3.x (или старше) не импортирует даже некоторые добавленные вручную маршруты устройства / хоста (то есть те, которые не имеют шлюза). Есть два способа это исправить. Либо добавьте эти маршруты в таблицу маршрутизации ядра со статическим источником протокола (например, "@ip route add 10.20.30.0/24 dev eth0 proto static@"), либо перекомпилируйте BIRD с прикрепленным патчем (см. Внизу страницы), чтобы исправить это вопрос.

Источник
Другие вопросы по тегам