Я создал «линейную» топологию с использованием виртуального бокса - создав 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
для каждой машины
Я понял! Есть несколько причин, по которым установка не работала - во-первых, адреса были установлены неправильно. Интерфейсу должны быть назначены следующие (например) адреса, чтобы все работало:
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 networks {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
Наконец, вам нужно убедиться, что птица знает маршруты ОС и устанавливает маршруты в ОС. Ах, это может быть источником ваших неприятностей - от Вопросы-Ответы:
BIRD не импортирует некоторые маршрутизаторы из ядра
Во-первых, должна быть активна опция изучения протокола ядра.
Во-вторых, маршруты «устройства», связанные с интерфейсными адресами / префиксами, автоматически добавляемыми ОС / ядром, никогда не импортируются. Вы можете добавить их, используя прямой протокол.
В-третьих, по каким-то неясным и историческим причинам BIRD 1.3.x (или старше) не импортирует даже некоторые вручную добавленные маршруты устройств / хостов (т.е. маршруты без шлюза). Есть два способа исправить это. Либо добавьте эти маршруты в таблицу маршрутизации ядра со статическим источником протокола (например, '@ip route add 10.20.30.0/24 dev eth0 proto static @'), либо перекомпилируйте BIRD с прикрепленным патчем (см. Внизу страницы), чтобы исправить это вопрос.