ipv6 nd suppress-ra does not take for OS-configured interface

[ZaphodB]

---

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.

[WenceyWang]

Is there any update on this issue?

[tichan]

Discovering the same issue - Are there any ideas for this?

[ZaphodB]

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.

[SvenVD-be]

Any update for this issue?

[nicklasfrahm]

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.

[CHH2000day]

Having the same issue here.
frr keeps sending RA,resulting unwanted route installations on other hosts.
Is there anyway to disable RA completely?

[Sokolmish]

We have encountered the same problem. After investigation, I've found that RA can be enabled by other daemons, namely in the following cases:

1. Extended nexthop BGP capability is activated (WHY?!).
2. Unnumbered BGP peers are used (seems logical at first glance).
3. 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_CONFIGURED in zebra_interface_radv_set is 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.

[Sokolmish]

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).