https://docs.frrouting.org/en/latest/bgp.html#clicmd-bgp-ipv6-auto-ra
Please add a no-ipv6-auto-ra option to the BGP parameters because FRR is sending RA packets with different settings on my intranet at the same time as radvd!
All tasks should be on our forge if you want a new feature.⚓ T7531 Add FRR no-ipv6-auto-ra option
Comparing to other vendors this should be configured on interface level and not in the “router bgp” settings.
Do you know if FRR supports it?
No idea, it seems like its a global option according to BGP — FRR latest documentation
However according to this support ticket it seems like you can define interface configuration in FRR aswell:
opened 10:29AM - 15 Dec 20 UTC
closed 12:28PM - 28 Oct 24 UTC
triage
zebra
good-report
---------------
**Describe the bug**
Hoster reported my router VM to be send… ing 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.
```
So I would vote for having that statically disabled (as in “no bgp ipv6-auto-ra”) and let radvd (or whatever is used) to deal with sending RA’s at interface level?
suppress-ra can currently be configured at the interface level in FRR, but this setting is overridden by bgpd if extended-nexthop is enabled
https://docs.frrouting.org/en/latest/ipv6.html#clicmd-ipv6-nd-suppress-ra
I also tested it and it does
And no bgp ipv6-auto-ra will disable this behaviour completely from FRR/bgpd ?
Yes, setting no bgp ipv6-auto-ra will no longer cause the FRR to send RA packets just because the Extended Next Hop in BGP is enabled
Maybe in the future VyOS should remove radvd and use FRR included features instead