Is there an IPv6 forwarding bug in FRR running in namespace?
Or am I doing it wrong? (But it works in quagga.) Debian 10.5. FRR tried both 6.0.2 and 7.3.1. Installed package is frr-snmp. This is what i do: /etc/sysctl.d/local.conf: net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 mkdir -p /run/frr/$NS chown frr:frr /run/frr/$NS /sbin/ip netns add $NS /sbin/ip netns exec $NS /sbin/ip link set dev lo up Create two interfaces, one of which is a veth peer to a veth interface in the default namespace. Both interfaces have IPv4 and IPv6 addresses. /sbin/ip netns exec $NS /usr/lib/frr/zebra -d -A 127.0.0.1 -s 90000000 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/bgpd -d -A 127.0.0.1 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/ospfd -d -A 127.0.0.1 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/ospf6d -d -A 127.0.0.1 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/staticd -d -A 127.0.0.1 -N $NS cat /proc/sys/net/ipv6/conf/*/forwarding show all ones. (However, the namespace interfaces aren't displayed in /proc/sys/net/ipv6/conf, just the default namespace interfaces. But the same goes for IPv4, and I have no problems with IPv4.) In /etc/frr/$NS/zebra.conf I have this configuration: " frr version 7.3.1 frr defaults traditional hostname xxx password xxx enable password xxx log syslog informational log facility local6 ! interface xxx ip address xxx ipv6 address xxx ! interface veth-xxx-C ip address xxx ipv6 address xxx ! line vty exec-timeout 60 0 " Every time I reboot this server, ipv6 forwarding is turned off in the namespace zebra. ipv6 forwarding works fine in the default namespace, and ipv4 forwarding works fine both in $NS and the default namespace. # ip netns exec ipvpn-gotanet telnet localhost 2601 Hello, this is FRRouting (version 7.3.1). # sh run ... no ipv6 forwarding ... # sh ip for IP forwarding is on # sh ipv for ipv6 forwarding is off sh start doesn't display the "no ipv6 forwarding" line. I also noticed that two other FRR servers, running Debian 10.3, have the same problem, showing "no ipv6 forwarding" in the running zebra configuration. Those two servers don't use IPv6 in namespaces, so I haven't noticed this problem in them before now. This has never been a problem in quagga. Thanks! Peter Olsson
On Wed, Sep 23, 2020 at 10:31:48PM +0200, Peter Olsson wrote:
Or am I doing it wrong? (But it works in quagga.)
Debian 10.5. FRR tried both 6.0.2 and 7.3.1. Installed package is frr-snmp.
This is what i do:
/etc/sysctl.d/local.conf: net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
mkdir -p /run/frr/$NS chown frr:frr /run/frr/$NS /sbin/ip netns add $NS /sbin/ip netns exec $NS /sbin/ip link set dev lo up
Create two interfaces, one of which is a veth peer to a veth interface in the default namespace. Both interfaces have IPv4 and IPv6 addresses.
/sbin/ip netns exec $NS /usr/lib/frr/zebra -d -A 127.0.0.1 -s 90000000 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/bgpd -d -A 127.0.0.1 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/ospfd -d -A 127.0.0.1 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/ospf6d -d -A 127.0.0.1 -N $NS /sbin/ip netns exec $NS /usr/lib/frr/staticd -d -A 127.0.0.1 -N $NS
cat /proc/sys/net/ipv6/conf/*/forwarding show all ones. (However, the namespace interfaces aren't displayed in /proc/sys/net/ipv6/conf, just the default namespace interfaces. But the same goes for IPv4, and I have no problems with IPv4.)
Found this: # ip netns exec $NS sysctl -a|grep forwarding|grep -v bc_|grep -v mc_ net.ipv4.conf.all.forwarding = 1 net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.enp10s0f0/117.forwarding = 1 net.ipv4.conf.lo.forwarding = 1 net.ipv4.conf.veth-gotanet-C.forwarding = 1 net.ipv6.conf.all.forwarding = 0 net.ipv6.conf.default.forwarding = 0 net.ipv6.conf.enp10s0f0/117.forwarding = 0 net.ipv6.conf.lo.forwarding = 0 net.ipv6.conf.veth-gotanet-C.forwarding = 0 So the IPv4 forwarding configuration in Debian is inherited by the namespace, but not the IPv6 forwarding configuration. I don't know how to fix this, my attempts at echo 1 > xxx/forwarding or sysctl -w net.ipv6.conf.all.forwarding=1 in the namespace during the boot sequence fail. But anyway, this is not an FRR problem. Sorry about the noise! Peter Olsson
participants (1)
-
Peter Olsson