Hi!
I think the DEVICE protocol has not yet learned this interface and,
accordingly, the next-hop cannot be used.
I have similar errors when starting a bird and using BFD in static routes.
06/25/22 19:57:22 <ERR> megafon4: Invalid NEXT_HOP attribute - neighbor
address 188.170.160.53
06/25/22 19:57:22 <ERR> megafon4: Invalid route 0.0.0.0/0 withdrawn
06/25/22 19:57:22 <ERR> megafon6: Invalid NEXT_HOP attribute - neighbor
address 2a03:d000:2780:1::11
06/25/22 19:57:22 <ERR> megafon6: Invalid route ::/0 withdrawn
But after BFD will be established, route appears in route table.
On 07.06.2022 13:28, Eugene M. Zheganin wrote:
Hello,
I have a peculiar VPN client that I want to redistributes the routes
from. Technically it creates a tun0 interface and
attaches all the routes it's connected to as it's own on-interface
routes pointing to it's own IP (yeah, I know it's la
me, but seems like it's written by Windows 98 addicts, so it's still
pretty normal for them). This confuses bird and it
's complaining with usual
===Cut===
Jun 7 15:10:43 vipnet bird[28752]: KRT: Received route 1.2.3.4/26
with strange next-hop 5.6.7.8
===Cut===
However:
===Cut===
[root@host ~]# ip addr show tun0
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
fq_codel state UNKNOWN group default qlen 500
link/none
inet 5.6.7.8/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::6d6d:315d:3deb:6ae0/64 scope link stable-privacy
valid_lft forever preferred_lft forever
===Cut===
So far I'm reexporting these routes as static, but is there any way to
do thsi automatically ?
Thanks.
--
Regards,
Mikhail V. Majorov
Megalink, CEO
B.Bulvarnaya 11, Taganrog, Russia, 347913
tel work: +7 8634 431431 (ext 101)
tel mobile: +7 905 4309006
pg19.ru
