High packet loss on SLAAC clients with DHCP-PD
-
Hi there, I'm running pfSense 2.2.6 on my home router. Currently I'm experiencing an interesting issue that I didn't notice due to where it occurs within my network.
My ISP offers me a static /56 which I access using DHCP-PD. I am then tracking this onto multiple interfaces, which gives me a /62 for further PD (which I haven't got working on my Cisco RV320 for the neighbour, but I consider that far less critical), and four /64s with the prefixs 00, 01, 25, and 26.
Devices on the 01 network are configured using either DHCPv6 or statically. These hosts do not have an issue.
However on the other networks, most notably 25, the hosts by and large configure via SLAAC. These hosts experience high packet loss, both to the outside world and to other hosts on other VLANs (i.e. anything crossing the router). Please refer the following (redacted) output from one the affected hosts:
Local interface information for problem host.
Demeter:~ user$ ifconfig en0 en0: flags=8863 <up,broadcast,smart,running,simplex,multicast>mtu 1500 options=10b <rxcsum,txcsum,vlan_hwtagging,av>ether ac:87:a3:0a:70:fb inet6 fe80::ae87:a3ff:fe0a:70fb%en0 prefixlen 64 scopeid 0x4 inet6 xxxx:x:x:xx25:ae87:a3ff:fe0a:70fb prefixlen 64 autoconf inet6 xxxx:x:x:xx25:6d05:9e80:b496:a8e1 prefixlen 64 autoconf temporary inet 192.168.1.132 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=1 <performnud>media: autoselect (1000baseT <full-duplex>) status: active</full-duplex></performnud></rxcsum,txcsum,vlan_hwtagging,av></up,broadcast,smart,running,simplex,multicast>
Ping to a host on same subnet
Demeter:~ user$ ping6 -qc20 printer PING6(56=40+8+8 bytes) xxxx:x:x:xx25:ae87:a3ff:fe0a:70fb --> xxxx:x:x:xx25::15 --- printer.nightkhaos.org ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.413/0.548/0.655/0.061 ms
Ping to host across filewall
Demeter:~ user$ ping6 -qc20 nyx PING6(56=40+8+8 bytes) xxxx:x:x:xx25:6d05:9e80:b496:a8e1 -->xxxx:x:x:xx01::1490 --- nyx.nightkhaos.org ping6 statistics --- 20 packets transmitted, 12 packets received, 40.0% packet loss round-trip min/avg/max/std-dev = 0.457/0.658/0.896/0.145 ms
Ping to Google.
Demeter:~ user$ ping6 -qc20 www.google.com PING6(56=40+8+8 bytes) xxxx:x:x:xx25:6d05:9e80:b496:a8e1 --> 2404:6800:4006:807::1014 --- www.google.com ping6 statistics --- 20 packets transmitted, 5 packets received, 75.0% packet loss round-trip min/avg/max/std-dev = 34.895/35.527/36.582/0.587 ms
I have done some tcpdumps on the interfaces of my pfSense instance, and discovered that in the case of lost packets I can see the echo-request entering the firewall, but I cannot see it exiting. This would indicate the packets are getting dropped internally for some reason.
Statically configured hosts and hosts configured using DHCPv6 do not have this issue.
Does anyone have an ideas what might be causing this in my configuration? I've giving my firewall rules the once over and can't see anything that would prevent them (in fact my firewall rules are pretty simple right now)?
If you're around on IRC, you can find me on ##pfsense in freenode (NightKhaos), and I'll be willing to do a tmate session with you to help diagnose.
Thanks for your help in advance!
Please note that IPv4 is not affected at all.
-
It is possible that your issues relate to one of the issues I've been working on, and you might like to try the patch for 2.2.6 to see if that helps. I am, however, very sceptical that it will help.
What happens when you ping6 Internet addresses and addresses on your LAN from pfSense itself? You can either use the Diagnostics part of the GUI or SSH to your pfSense box.
-
[2.2.6-RELEASE][admin@router.nightkhaos.org]/root: ping6 -qc20 www.google.com PING6(56=40+8+8 bytes) xxxx:x:x:xx00:5054:ff:fe48:d0b0 --> 2404:6800:4006:803::2004 --- www.google.com ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 34.397/35.272/36.243/0.531 ms
Hi David, I'll try the patch later tonight. The problem does not persist on the router actual, as above.
-
Hi David, I'll try the patch later tonight. The problem does not persist on the router actual, as above.
So I applied the patch and while I think there is a marginal improvement the issue still persists. I'd have to sample it more to see if there actually is an improvement, but the fact packets are being dropped at all concerns me.
-
Okay, while investigating this issue I found a very interesting coloration between the dropped packets and when the router is performing an RA.
I've also noticed the stated router lifetimes are quite low, at 60 seconds, with 20 seconds for the rdnss, which will increase the number of RS on the network, which increases the number of RAs, which may explain, if there is a relationship here, why the packet loss can get so high.