Open ZaphodB opened 3 years ago
Is there any update on this issue?
Discovering the same issue - Are there any ideas for this?
i used
ip6tables -A OUTPUT -o eth0 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j DROP
as a workaround but that leaves me with the following error from zebra logging constantly
zebra[4865]: [EC 100663299] eth0(2): Tx RA failed, socket 11 error 1 (Operation not permitted)
currently on version 7.5.1-0~deb10.
Any update for this issue?
I can confirm that this issue still exists in 8.4.2
. Interestingly, after if I apply the following configuration:
interface wg2
ipv6 nd suppress-ra
!
I still receive this:
alfa# show ipv6 nd ra-interfaces
VRF: default
Interfaces:
wg2
Interfaces(msec):
Doing write t
shows that there is no configuration for wg2
, but I assume that is because ipv6 nd suppress-ra
is the default according to this section of the documentation.
Would be nice to suppress the neighbor discovery though.
Having the same issue here. frr keeps sending RA,resulting unwanted route installations on other hosts. Is there anyway to disable RA completely?
We have encountered the same problem. After investigation, I've found that RA can be enabled by other daemons, namely in the following cases:
I've got these cases by looking for zclient_send_interface_radv_req()
. The bgp_zebra_initiate_radv()
uses the previous one but is used in several places, so greping it is useful too. We have the first case, so I only consider it.
By tracking the mentioned functions, I've found several detailed comments. Also, there are several commits (one, two, three) with some explanation, but I still don't see the reason for mandatory enabling RA.
To sum up my investigation:
BGP_RA_CONFIGURED
in zebra_interface_radv_set
is reached from VRRP. It doesn't matter, mention it just in case.I've started a discussion #16317 about this problem.
There is my minimal FRR config to reproduce the problem. The BGP daemon is enabled.
There is no need for the BGP peer to exist; the problem reproduces even if there are no other hosts in the network. Once FRR starts, there are RA in wireshark and show ipv6 nd ra-interfaces
shows the interface, as has been mentioned above in this thread.
interface eth0
ipv6 nd suppress-ra
exit
ipv6 prefix-list IP_EXPORT_LIST seq 1 permit ::/0 le 128
ipv6 prefix-list IP_IMPORT_LIST seq 1 permit ::/0 le 128
route-map EXPORT_MAP permit 1
match ipv6 address prefix-list IP_EXPORT_LIST
exit
route-map IMPORT_MAP permit 1
match ipv6 address prefix-list IP_IMPORT_LIST
exit
router bgp 111
bgp router-id 11.1.1.1
no bgp default ipv4-unicast
bgp default ipv6-unicast
no bgp ebgp-requires-policy
neighbor NEIGH_UTM peer-group
neighbor NEIGH_UTM remote-as 222
neighbor NEIGH_UTM disable-connected-check
neighbor NEIGH_UTM capability extended-nexthop
neighbor fd00:1111::3 peer-group NEIGH_UTM
address-family ipv6 unicast
redistribute connected
neighbor NEIGH_UTM route-map IMPORT_MAP in
neighbor NEIGH_UTM route-map EXPORT_MAP out
exit-address-family
exit
Tested in master of official container: FRRouting 10.2-dev_git20240701 (95ac4f0e2b81) on Linux(5.4.0-187-generic)
.
Describe the bug Hoster reported my router VM to be sending IPv6 RAs, disabling them via
on the OS-configured interface did not take meaning the configuration did not disable the RAs from being sent and did not show up in show running-config.
[x] Did you check if this is a duplicate issue? [-] Did you test it on the latest FRRouting/frr master branch?
To Reproduce Debian /etc/network/interfaces configuration for eth0:
Interface eth0 not configured in frr.
Expected behavior
in show running-config. Not sending router advertisement messages on interface eth0.
Versions
Additional context