Jump to content
Калькуляторы

nhrp в linux (frr, quagga, opennhrp)

Всем привет.

 

Есть задача сделать 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 на линуксах ?

Share this post


Link to post
Share on other sites

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

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

Edited by wtyd

Share this post


Link to post
Share on other sites

Получилось запустить на 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 проходит и надо заново резолвить. безопасность ... её нет, т.е. надо ойписекас делать.

Share this post


Link to post
Share on other sites

14 hours ago, wtyd said:

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

 

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

11 hours ago, wtyd said:

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

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.