Я пытаюсь установить базовую связь с протоколом RIPv2 между двумя запущенными хостами. демон маршрутизации BIRD.
у меня есть Host A с интерфейсом enp0 который имеет адрес 10.0.1.50/24.
У меня есть другой хозяин Host B с интерфейсом enp1 который имеет адрес 10.1.1.25/24. Эти интерфейсы напрямую соединены кабелем. Я могу пинговать между обеими машинами, если я добавлю статический маршрут на обеих машинах.
У меня есть следующие bird.conf на Host A:
protocol kernel {
learn; # Learn all alien routes from the kernel
persist; # Don't remove routes on bird shutdown
scan time 20; # Scan kernel routing table every 20 seconds
export all; # Default is export none
}
protocol device {
scan time 10; # Scan interfaces every 10 seconds
}
protocol direct {
interface "enp0"
}
protocol rip MyRIP {
export all;
import all;
interface "enp0" { mode multicast;};
}
В bird.conf на Host B идентичен, за исключением enp0 заменяется на enp1
После запуска демона птиц на обоих хостах я могу выполнить tcpdump -ni enp0 -vv
13:21:41.943537 IP (tos 0xc0, ttl 1, id 4933, offset 0, flags [none], proto UDP (17), length 132)
10.1.1.25.520 > 224.0.0.9.7742: [udp sum ok] UDP, length 104
13:21:41.943704 IP (tos 0xc0, ttl 1, id 150, offset 0, flags [none], proto UDP (17), length 272)
10.0.1.50.520 > 224.0.0.9.7742: [bad udp cksum 0xec48 -> 0x1219!] UDP, length 244
Я могу прыгнуть внутрь birdcl командная строка и запустить show rip neighbors и получите пустой стол.
Если я установлю адреса в одной подсети, я могу запустить show rip neighbors и я вижу 10.0.1.50 в моих списках соседей.
Как я могу заставить эти маршрутизаторы указывать друг друга в качестве соседей, если два конца ссылки не в той же подсети?
У меня должно быть какое-то неправильное представление о том, как работают сети, разве маршрутизаторам не нужно постоянно разговаривать с соседями, которые не находятся в одной подсети?
Я не зацикливаюсь на ответе, относящемся к BIRD.
Еще в древние времена, когда в сети было больше протоколов, чем TCP / IP, я запускал RIP. Тогда это был RIPv1, и он использовал широковещательные рассылки. Сетевые топологии выглядели примерно так:
[10.0.0.0/24] <-- router --> [10.0.1.0/24] <-- router --> [10.0.2.0/24]
[10.0.3.0/24] <-- router ------^ ^---- router --> [10.0.4.0/24]
[10.0.5.0/24] <-- router -------^ ^----- router --> [10.0.6.0/24]
Где все маршрутизаторы будут совместно использовать подсеть, в которой есть только маршрутизаторы. Для конфигураций с двумя маршрутизаторами между ними был протянут один кабель, как и вы. Для более крупных установок подсеть будет работать с быстрым сетевым устройством (возможно, коммутатором, но не всегда). Таким образом, все было в двух прыжках, и схождение маршрутов прошло просто. Это то, что у нас было в то время.
Затем последовали RIPv2 и многоадресная передача, и большее количество переходов было менее подвержено проблемам сходимости. Если TTL многоадресной рассылки был установлен на +1 по диаметру прыжка, каждый маршрутизатор фактически сообщал напрямую каждому другому маршрутизатору, что ускоряло конвергенцию.
Однако главное, о чем следует подумать: посмотрите на исходные адреса в выходных данных TCPDUMP.
10.1.1.25.520 > 224.0.0.9.7742
10.0.1.50.520 > 224.0.0.9.7742
Роутер 10.0.1.50 было сказано, что маршрутизатор в 10.1.1.25 имеет подсеть 10.1.1.0/24 местные к нему. Однако роутер на 10.0.1.50 нет пути к адресу 10.1.1.25, поэтому он не будет добавлять его в таблицу. Multicast - это ваш канал объявлений, но он не может передавать маршрутизируемый трафик.
Еще не все потеряно.
Если по какой-то причине вы ограничены одним кабелем, вы можете определить виртуальные интерфейсы. куда enp0.0 находится на 10.3.1.0/24 и enp0.1 находится на 10.0.1.0/24. Таким образом, вы можете использовать 10.3.1.0/24 в качестве «сети маршрутизации».