FRRouting
ipv6 nd suppress-ra does not take for OS-configured interface
Describe the bug Hoster reported my router VM to be sending IPv6 RAs, disabling them via
otemachi(config-if)# interface eth0
otemachi(config-if)# ipv6 nd suppress-ra
otemachi(config-if)# end
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:
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 217.197.86.170
netmask 255.255.255.240
broadcast 217.197.86.171
#gateway 217.197.83.129
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 8.8.8.8
dns-search zaphods.net
post-up /sbin/ip ro add 217.197.83.128/25 dev eth0
post-up /sbin/ip ro add default via 217.197.83.129 dev eth0
Interface eth0 not configured in frr.
otemachi(config-if)# interface eth0
otemachi(config-if)# ipv6 nd suppress-ra
otemachi(config-if)# end
Expected behavior
!
interface eth0
ipv6 nd suppress-ra
!
in show running-config. Not sending router advertisement messages on interface eth0.
Versions
- OS Version: Debian 10.7 current
- Kernel: 4.19.0-9-amd64
- FRR Version: 7.5-0~deb10
ii frr 7.5-0~deb10 amd64 FRRouting suite of internet protocols (BGP, OSPF, IS-IS, ...)
ii frr-doc 7.5-0~deb10 all FRRouting suite - user manual
ii frr-pythontools 7.5-0~deb10 all FRRouting suite - Python tools
Additional context
otemachi# show interface eth0
Interface eth0 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
Description: Description
index 2 metric 0 mtu 1500 speed 4294967295
flags: <UP,BROADCAST,RUNNING,MULTICAST>
Type: Ethernet
HWaddr: 52:54:00:d9:18:69
inet 217.197.86.170/28
inet6 2001:67c:1400:1220::179/64
inet6 fe80::5054:ff:fed9:1869/64
Interface Type Other
Interface Slave Type None
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND advertised hop-count limit is 64 hops
ND router advertisements sent: 270573 rcvd: 1055
ND router advertisements are sent every 10 seconds
ND router advertisements lifetime tracks ra-interval
ND router advertisement default router preference is medium
Hosts use stateless autoconfig for addresses.
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.
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:
- Extended nexthop BGP capability is activated (WHY?!).
- Unnumbered BGP peers are used (seems logical at first glance).
- Something in VRRP, haven't looked into it.
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:
- RA can be implicitly enabled by other daemons, which isn't stated in the docs.
- Being enabled by bgpd, RA cannot be disabled from VTY until bgpd doesn't disable it.
- There are implications in the source code that only bgpd can turn on the RA (aside from VTY), though VRRP also does it. Maybe there should be another flag for it or some naming refactoring. E.g.,
BGP_RA_CONFIGUREDinzebra_interface_radv_setis reached from VRRP. It doesn't matter, mention it just in case. - I don't see the reason for turning on RA with BGP extended-nexthop, so I'm going to patch out such places that are not related to unnumbered peers and look at what will happen.
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).