nhrp в linux (frr, quagga, opennhrp)

[wtyd]

Всем привет.

 

Есть задача сделать point-to-multipoint сеть на nbma сети. Т.е. mgre + nhrp овер интернет. Как бы большая плоская сеть с кучекй нейборов в mgre. В статике всё работает, если на всех хостах прописать всех нейборов, то всё ок. Хочется динамики. Для этого вроде бы есть nhrp: ноды регистрируются на хабе (или на нескольких хабах), хабы знают про все ноды. При необходимости (как ее создать ?) нода запрашивает у хаба nbma(т.е. публичный адрес ноды в интернете) адрес, получает ответ и туннель начинает работать. Вторая нода так же узнает про первую на хабе по загадочной необходимости и у себя делает запись про нейбора (на какой-то ТТЛ) и туннель в обратную сторону тоже начинает работать. Что-то типа АРП но для гре. Так всё в теории, на виртуалках так не работает --  ноды не хотят ничего узнавать у хаба, точнее, я пока не знаю, как сказать нодам "адреса нейборов вот для этого диапазона надо узнавать у хаба, потому что он доступен напрямую через туннель". Делаю пока всё без ipsec (там столько мест, где можно ошибиться). За основу для frr и quagga взял https://github.com/FRRouting/frr/blob/master/nhrpd/README.nhrpd. Вот там как бы и нет указания на то, что именно надо "резолвить у хаба", а адреса на туннелях делаются /32, с другими масками регистрация на хабе вообще не работает.

 

Три ноды в трёх разных ip-сетях (192.168.10{1..3}.2), гре туннели вида:

iface gre1 inet static
        pre-up ip tunnel add $IFACE mode gre key 42 ttl 64 dev e#th0 || true
        address 10.0.0.{1..3}
        netmask 255.255.255.255
        post-down ip tunnel del $IFACE || true

 

a1# sh ru #(hab)
Building configuration...

Current configuration:
!
frr version 7.1
frr defaults traditional
hostname a1
log syslog
no ipv6 forwarding
!
debug nhrp all
!
interface gre1
 ip nhrp network-id 1
 ip nhrp registration no-unique
 ip nhrp shortcut
 no link-detect
 tunnel source eth0
!
router bgp 65000
 neighbor Q peer-group
 neighbor Q remote-as 65000
 neighbor Q disable-connected-check
 bgp listen range 0.0.0.0/0 peer-group Q
 !
 address-family ipv4 unicast
  network 10.0.0.0/16
  redistribute nhrp
  neighbor Q route-reflector-client
 exit-address-family
!
line vty
!

# spoke 1
alpine2# sh ru
Building configuration...

Current configuration:
!
frr version 7.1
frr defaults traditional
hostname alpine2
no ip forwarding
no ipv6 forwarding
!
interface gre1
 ip nhrp network-id 1
 ip nhrp nhs dynamic nbma 192.168.101.2
 ip nhrp registration no-unique
 ip nhrp shortcut
 no link-detect
 tunnel source eth0
!
router bgp 65000
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 disable-connected-check
!
line vty
!
end
alpine2#

# spoke2
alpine3# sh ru
Building configuration...

Current configuration:
!
frr version 7.1
frr defaults traditional
hostname alpine3
no ip forwarding
no ipv6 forwarding
!
interface gre1
 ip nhrp network-id 1
 ip nhrp nhs dynamic nbma 192.168.101.2
 ip nhrp registration no-unique
 ip nhrp shortcut
 no link-detect
 tunnel source eth0
!
router bgp 65000
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 disable-connected-check
!
line vty
!
end
alpine3#

Вроде бы рекомендуют именно так делать. В этой схеме почему-то надо чтобы первый пакет пошел через хаб, хаб бы его пророутил и послал бы nhrp-redirect, после чего на ноде возникает нейбор и туннелирование идёт напрямую минуя хаб. Один раз даже заработало (включил форвардинг и iptables правило из документации на хабе), заработало только в одну сторону, второй спок продолжал слать ответы через хаб.

 

С opennhrp на туннелях делал /16 , геристрация вообще не работала. В сети вообще очень мало про opennhrp и он наверное мёртв (?)

 

Вопрос: как объяснить спокам, что надо узнавать адреса нейборов на хабе и слать трафик напрямую в туннель между споками, а не через хаб ? Если есть рабочие конфиги для любых nhrp  демонов, то просьба поделиться ими и нюансами в настройке. У цыски настраивается немного иначе, но в frr/quagga нет таких точно команд, а у меня нет цысок чтобы проверить :-).

 

Может быть есть другой способ сделать point-to-multipoint на линуксах ?

[zhenya`]

Почему у вас на туннеле маска 255.255.255.255? Ну и ноуты почитайте.

[wtyd]

Потому что иначе регистрация в хабе вообще не происходит, я пробовал. Еще в примерах frr именно так указано делать (http://docs.frrouting.org/en/latest/nhrpd.html). Про какие ноуты идет речь ?

Такое ощущение, что mgre + nhrp только на цысках работает. opennhrp последний релиз от 2013 года, а в рассылке к нему пишут про требование ARPD со стороны ядра. В том-то и дело, что рабочих современных экзамплов найти не могу.

Edited September 15, 2019 by wtyd

[wtyd]

Получилось запустить на opennhrp, дело было не в бобине ... alpine sysctl пре-сет сидел в кабине :-). После удаления sysctl файлов и ребута всех нод, opennhrp почему-то заработал, а frr так и не работает. Это портит дальнейшую перспективу для ipsec, можетне получится, т.к. opennhrp очень старый для современногос офта и инструкций пока не нашел. Кому интересно вот более менее рабочий вариант конфигов для стенда описанного выше (маски на туннельных ойпи посенял на /16 как того хочет opennhrp):

a1:~# cat /etc/opennhrp/opennhrp.conf

interface gre1
        non-caching
        redirect
        shortcut
        cisco-authentication secret8
        holding-time 30

interface eth0
        shortcut-destination

interface lo
        shortcut-destination

alpine2:~# cat /etc/opennhrp/opennhrp.conf
interface gre1
#       map 10.0.0.1/16 192.168.101.2 register
        dynamic-map 10.0.0.0/16 192.168.101.2
        shortcut
        redirect
        non-caching
        cisco-authentication secret8
#       holding-time 30
        holding-time 300

alpine3:~# cat /etc/opennhrp/opennhrp.conf
#interface gre1
#       map 10.0.0.1/16 192.168.101.2 register
#       shortcut
#       redirect
#       non-caching
#       cisco-authentication secret8

interface gre1
        dynamic-map 10.0.0.0/16 192.168.101.2
        shortcut
        redirect
        non-caching
        cisco-authentication secret8
        holding-time 60

Ну еще закомментил все упоминания про racoonctl в файлах /etc/opennhrp/opennhrp-script, а то иначе скрипт ругался.

 

Впечатления пока не очень, работает как-то ненадежно. Если рестартануть хаб, то ноды в нем не быстро перерегистрируются - holdtime афектит вообще на всё, протокол stateless. Когда пинг со спока на спок запускаешь, то теряется 1-3 первых пакета, пока не происходит разрешение нейбора, но зато потом вроде не теряются даже когда holdtime проходит и надо заново резолвить. безопасность ... её нет, т.е. надо ойписекас делать.

[vop]

14 hours ago, wtyd said:

Может быть есть другой способ сделать point-to-multipoint на линуксах ?

 

Я отказался от opennhrp в свое время, так-как он хотел в то время патченого ядра, а мне надо было делать на дистрибутивных. Сейчас не знаю.

 

У меня есть небольшая, порядка 30 узлов. Поэтому у меня два узла выполняют роль хабов. При этом там ведется база в виде списка, которая просто при обновлении рассылается по нодам, где лежат скрипты, обновляющие ip ne список. Обновления рассылаются моими программными средствами, в которые встроены инструменты отслеживания обновления. Но это вообще не принципиально, можно обычным curl'ом дергать регулярно - трафик мизерный.

 

Ну и да, маску бы поставить. А качестве ключа я использую network виртуальной сети - так не надо "запоминать" его значение, и оно выставляется "автоматически" (у меня скрипт сам "выдергивает" его).

 

ipv6 вообще выставляются просто по isatap. Там достаточно lladdr.

 

Если у вас сеть небольшая, то NHRP может подождать до лучших времен.

[VolanD666]

Т.е. так можно и к цисковскому DMVPN подключаться?

[wtyd]

On 9/16/2019 at 2:21 PM, VolanD666 said:

Т.е. так можно и к цисковскому DMVPN подключаться?

Ну вообще воде можно, но я не пробовал :-). У меня нет цыскиного DMVPN. У меня пока что-то не очень понятное с несколькими хабами получается. Один тушу и какой-то расколбас в сети появляется, пока непонятно, как хабы между собой конфигурить надо.

[vop]

11 hours ago, wtyd said:

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

У вас замечательная возможность наловить блох в реализации хабов, и дописать туда код, что бы исправить "карманы". Если, конечно, есть условия и желание.

 

PS А то есть ощущение, что этот протокол немного заброшенный и мало кем используемый.