Dpinger uses ULA as source after DHCP6 interface outage

netotter · Dpinger uses ULA as source after DHCP6 interface outage

On 26.7.2_2 DHCP6 interface outage results in dpinger using ULA source address after outage and restored connection. I am not sure if this started with 26.7 but it's the first time I observed this using 26.7. I can also reproduce this by disconnecting the router manually.

Before outage dpinger works as expected and uses GUA as source address for pinging and gets normal responses.

After a longer (don't know the exact time, several minutes to an hour) outage connection is restored but dpinger thinks the connection is down because it does not get replies. The reason is that ping source address is changed to ULA and the router does not accept that and no pinging happens.

Dpinger runs with right GUA source address in the -B parameter:
root@opns1:~ # ps axuww | grep INTERNET_DHCP6
root 51553 0.0 0.1 14716 2812 - Is 07:12 0:00.02 /usr/local/bin/dpinger -f -S -r 0 -i INTERNET_DHCP6 -B 2a0d:a:b:c:d:e:f:2d93 -p /var/run/dpinger_INTERNET_DHCP6.pid -u /var/run/dpinger_INTERNET_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888

Ping packets have anyway ULA as their source:
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:53.428522 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14719, length 9
07:02:53.429161 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:02:54.428627 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 50428, seq 14720, length 9
07:02:54.429308 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)

Manually pinging another destination with same GUA as source works:

root@opns1:~ # ping6 -I vlan0.9 -S 2a0d:a:b:c:d:e:f:2d93 2606:4700:4700::1001
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:02:57.844648 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 0, length 16
07:02:57.877492 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 0, length 16
07:02:58.846441 IP6 2a0d:a:b:c:d:e:f:2d93 > 2606:4700:4700::1001: ICMP6, echo request, id 6941, seq 1, length 16
07:02:58.874800 IP6 2606:4700:4700::1001 > 2a0d:a:b:c:d:e:f:2d93: ICMP6, echo reply, id 6941, seq 1, length 16

root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
route to: 2001:4860:4860::8888
destination: 2001:4860:4860::8888
gateway: fe80::bb:ccff:fedd:2e0%vlan0.9
fib: 0
interface: vlan0.9
flags: <UP,GATEWAY,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0

root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
   description: Internet (opt22)
   options=4000000<MEXTPG>
   ether 00:aa:bb:cc:2d:93
   inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
   inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
   inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
   inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
   inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
   groups: vlan
   carp: MASTER vhid 187 advbase 1 advskew 1
     peer 224.0.0.18 peer6 ff02::12
   vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
   media: Ethernet autoselect
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

I have IPv4 static and carp address on the same interface as DHCP6. Does that mess things up? This interface vlan0.9/opt22 is also the secondary IPv6 gateway if that gives any hint where this problem might originate from.

Restarting dpinger does not solve the situation.

root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.
root@opns1:~ # tcpdump -nli vlan0.9 icmp6
07:10:25.486875 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 11, length 9
07:10:25.487554 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)
07:10:26.486944 IP6 fdfe:a:b:c:d:e:f:2d93 > 2001:4860:4860::8888: ICMP6, echo request, id 64742, seq 12, length 9
07:10:26.487636 IP6 fdfe:a:b:c::1 > fdfe:a:b:c:d:e:f:2d93: ICMP6, destination unreachable, unknown unreach code (5)

Reconfiguring the interface and restarting dpinger:

root@opns1:~ # configctl interface reconfigure opt22
OK
root@opns1:~ # pluginctl -s dpinger restart INTERNET_DHCP6
Service `dpinger[INTERNET_DHCP6]' has been restarted.

Works and dpinger starts to use correct GUA source address 2a0d:a:b:c:d:e:f:2d93 again.

The only change I can see is the order of inet6 addresses returned by ifconfig and route information for the dpinger destination.

root@opns1:~ # ifconfig vlan0.9
vlan0.9: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
   description: Internet (opt22)
   options=4000000<MEXTPG>
   ether 00:aa:bb:cc:2d:93
   inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
   inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 vhid 187
   inet6 fe80::bb:ccff:fedd:2d93%vlan0.9 prefixlen 64 scopeid 0x1c
   inet6 2a0d:a:b:c:d:e:f:2d93 prefixlen 64 autoconf pltime 121 vltime 271
   inet6 fdfe:a:b:c:d:e:f:2d93 prefixlen 64 autoconf
   groups: vlan
   carp: MASTER vhid 187 advbase 1 advskew 1
     peer 224.0.0.18 peer6 ff02::12
   vlan: 9 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
   media: Ethernet autoselect
   status: active
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

root@opns1:~ # route -n get -inet6 2001:4860:4860::8888
route to: 2001:4860:4860::8888
destination: ::
mask: ::
gateway: fde7:a:b:c:d:e:f:11 (this is the primary default gw for IPv6)
fib: 0
interface: vlan0.11
flags: <UP,GATEWAY,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0

Dpinger uses ULA as source after DHCP6 interface outage

netotter

Today at 09:13:48 AM