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
