IPv6 with framed IPv6-prefix
-
I can't think of anything else. Post the capture file here, so I can see if it reveals anything.
-
@JKnott got the packet capture done.
attached is pcap with wan on vtnet1.101 and lan on vtnet0.
also a screenshot of the packet capture configpacketcapture-vtnet1.101-20231207075856.pcap
-
I see you're requesting and receiving a /48 prefix. However, I also see you have some release XID packets. That's your system releasing the prefix you've been assigned. I have never seen that in my system. Also, did you restart the system, before you did the packet capture, as described in my instructions? The first line should be a solicit, as shown in mine.
Here mine starts with a solicit and only has 4 packets, ending with the reply. In this, IPv6 works just like the IPv4 DHCP sequence, with only 4 packets for normal operation.
-
This post is deleted! -
@JKnott I disconnected the WAN, rebooted the system. Started the packet capture and then reconnected the WAN.
Could it be my ISP that does something weird? I spoke to a co-worker of mine who runs a Unifi setup with a UDM non-Pro on the same ISP. He had IPv6 working for a few months and then suddenly it stopped working.
If packets are missing in the transmission, then perhaps that might explain why it drops out when connecting the secondary LAN to IPv6I am not sure if it matters anything, but my pfSense runs virtualized and has done for years with no issues
-
@Kenneth_H said in IPv6 with framed IPv6-prefix:
Could it be my ISP that does something weird?
Entirely possible. Around 5 years ago, I had a problem with my ISP. While devices on my LAN got IPv6 addresses, they couldn't reach anything via IPv6. In my own testing I determined the problem was not on my LAN, as I could see pings going out, but no response coming back. I then called tech support and talked to 2nd level (I rarely waste my time talking to 1st level). Working with 2nd level I was able to demonstrate the problem was not on my LAN. When they tried to escalate, the network guys wouldn't do anything, as I had my own router. This despite the fact my next door neighbour had the same problem and he was only using the supplied gateway. Eventually, a senior tech came out, with his own modem and computer, and experienced the same problem. By this point I had discovered an error and even identified the failing CMTS by host name. The tech then took his computer and modem to the head end and tried with 4 different CMTS. It only failed with the one I was connected to. The network guys finally accepted they had a problem and fixed it.
BTW, last spring I was doing some work in that head end and found my CMTS.
Incidentally, I have a strong background in telecom, computers and networks, going back over half a century (I first worked on a LAN in early 1978), so I generally know more about the situation than the 1st level support and have even found myself educating 2nd level. For example, when I was talking to both 2nd level support and the senior tech, I had to explain how DHCPv6-PD works.
-
@JKnott Will try in the coming week to use a mirror port on a switch to capture dhcpv6 output of the router supplied by my ISP.
If that is also missing the expected "solicit" package, then something is perhaps wrong on their implementation -
If I'd known you had a mirror port, I wouldn't have told you to use Packet Capture.
I have a 5 port switch configured as a data tap, which I used when working on that problem. I also have a Cisco switch on my LAN, which also does port mirroring.
-
@JKnott seems some issue is there with the port mirror on my end. Most likely an issue due to me using the same switch as for the LAN side, although I am not using VLAN 101 for anything.
Nothing got mirrored with pfSense or the ISP router and both got no connection. Will dig out an older 8-port managed switch and get it configured as a proper data tap device and try it again.For now I made another packet capture from pfSense and this time it seems as if I got a "solicit" package
packetcapture-vtnet1.101-20231213105317.pcap
Not sure if it all looks correct now, but seems more consistent. it does however seem strange that the lease time is around 5 minutes
-
The first 4 packets are normal, but then you get multiple solicits. The DHCPv6 sequence should be done after the first 4.
-
@Kenneth_H said in IPv6 with framed IPv6-prefix:
it does however seem strange that the lease time is around 5 minutes
My lease time is over 164 hours.
