FreeBSD quagga-ospfd и немного mpd

[old]

Настраивая ospfd из quagg'и, обнаружил, что в последней версии из портов (quagga-0.99.17_3) он не работает в 7.3-RELEASE-p*, выдавая ошибку

sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 80, interface vlan0, mtu 1500: Permission denied

при этом в "ifmcstat -i vlan0" видно, что vlan0 не слушает multicast-группу 224.0.0.5. В тоже время на 8.1-RELEASE-p* все работает без проблем.

 

Гугление привело к закрытому PR. После того, как откатил назад патч, закрывающий этот PR (что бы не заморачиваться с portdowngrade, просто удалил net/quagga/files/patch-lib-sockopt.c) и пересобрал quagga, все заработало. На тех машинах с 7.3-RELEASE-p*, где стояла quagga-0.99.17, собранная до сентября (время закрытия PR), все заработало сразу без танцев с откатом патча.

 

Похоже, в портах поломанная quagga (для случая FreeBSD 7.3), никто с подобным не сталкивался?

 

И немного про mpd 5.5 + quagga ospfd: когда mpd создает новые интерфейсы ng (скажем, после перезагрузки), в конфиге ospfd они появляются с прописанной на них командой

ip ospf network broadcast

Клиентский IP с такого интерфейса почему-то либо не анонсится вообще, либо вместо него анонсится IP с нашего конца туннеля, причем не взирая на route-map или distribution list. После очистки конфига интерфейса ng ("no ip ospf network") все работает нормально до следующего ребута. "passive-interface default" в настройках ospf включено:

router ospf
ospf router-id 192.168.25.92
log-adjacency-changes detail
compatible rfc1583
redistribute connected route-map STATIC-VPN
passive-interface default
no passive-interface vlan0
network 192.168.25.88/29 area 0.0.0.2
network 192.168.96.0/23 area 0.0.0.2
area 0.0.0.2 authentication message-digest
area 0.0.0.2 stub
!
access-list 10 permit 192.168.96.0 0.0.1.255
route-map STATIC-VPN permit 10
  match ip address 10
!

 

Такое поведение вообще нормально или я что-то пропустил?

[Ivan_83]

Клиентский IP с такого интерфейса почему-то либо не анонсится вообще, либо вместо него анонсится IP с нашего конца туннеля, причем не взирая на route-map или distribution list. После очистки конфига интерфейса ng ("no ip ospf network") все работает нормально до следующего ребута.

В качестве костыль-решения могу посоветовать в мпд5 прописать скрипт на поднятие интерфейсов и в него эту команду.

В командной строке имя интерфейса приходит.

 

#!/bin/sh
### mpd.script: incomming link up
###

# $0 - script name
# $1 - if name (ng0...)
# $2 - proto
# $3 - local-ip
# $4 - remote-ip
# $5 - authname
# $6 - [ dns1 server-ip ]
# $7 - [ dns2 server-ip ]
# $8 - peer-address

....

exit 0

[old]

Клиентский IP с такого интерфейса почему-то либо не анонсится вообще, либо вместо него анонсится IP с нашего конца туннеля, причем не взирая на route-map или distribution list. После очистки конфига интерфейса ng ("no ip ospf network") все работает нормально до следующего ребута.

В качестве костыль-решения могу посоветовать в мпд5 прописать скрипт на поднятие интерфейсов и в него эту команду.

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