Sorry, top-posting this time. Capturing on WAN(x:y:z:d8ff::2/64), link-local = fe80::250:56ff:febf:7014 (is MASTER), I can see:
00:15:27.653423 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:28.663409 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:29.673410 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:30.683425 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:31.693405 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:32.703418 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 At the same time on WAN(x:y:z:d8ff::3/64), link-local = fe80::250:56ff:febf:3f5 (is BACKUP), I see: 00:15:27.196544 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:28.606544 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:30.016541 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:31.426541 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:32.836536 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 I'm concerned about the source address being the BACKUP IPv6 link-local in those packets. Shouldn't they be the above :7014 instead of :3f5? With IPv4, that's one can see, the same source (the master) in those packets wether they're captured on master or backup. on x.y.z.130 WAN (master): 00:24:24.943397 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:25.953407 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:26.963397 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 on x.y.z.131 WAN (backup): 00:24:47.151981 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:48.162019 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:49.172016 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 What is it different with IPv6 (if that if) for these packets to stick their source address to the link-local? Or would it be that my BACKUP (according to /status_carp.php) do also advertise (which it shouldn't as BACKUP)? Indeed, if I halt the master, the backup switches to master role and look at the capture: 00:41:21.016506 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:22.426501 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:23.836499 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:25.246504 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:26.656497 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 The same as when it was backup... I think I start narrowing it a bit more here. But I'd do well with a gentle tap on the shoulder from one IPv6 / CARP guru from here... Must be some simple horrible configuration mistake... or a bug related to CARP IPv6 and in such case, if I can help gather whatever is needed to debug and fix it... -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 2 mai 2016 à 20:24, Olivier Mascia <o...@integral.be> a écrit : > > I have a problem with IPv6 on a HA setup. > > With IPv4, it is OK. > >> IPv4 : >> VLAN MAC Address Type Age Port >> Mod >> ---------+-----------------+-------+---------+------------------------------+--- >> 2776 0000.5e00.0168 dynamic 0 Veth5 >> 5 >> 2776 0000.5e00.0168 dynamic 0 Po4 >> 6 >> Total MAC Addresses: 2 > > With IPv6 the MAC is reported active on both pfSense's (Veth5/Veth6 instead > of Veth5/Po4 as above). > >> IPv6 >> VLAN MAC Address Type Age Port >> Mod >> ---------+-----------------+-------+---------+------------------------------+--- >> 2776 0000.5e00.016a dynamic 1 Veth5 >> 5 >> 2776 0000.5e00.016a dynamic 2 Veth6 >> 6 >> Total MAC Addresses: 2 > > I proceeded for IPv6 as for IPv4. > > One IPv6 address for each WAN interface: > x:y:z:d8ff::2/64 and x:y:z:d8ff::3/64. > And a CARP virtual IP definition of x:y:z:d8ff::1/64 on WAN interface. > The VHID is 106. > > Pinging from outside either one of the WAN adresses looks good. > Pinging the CARP VIP loose packets at varying rate and captures show echo > requests packets arriving randomly on each WAN interface. > > The IPv4 part of that same setup works wonderfully. > > x.y.z.130/28 and x.y.z.131/28 > CARP virtual IP of x.y.z.129/28 on WAN interface. > The VHID is 104. > > No visible issue with simple pinging, no suspect packet captures, and no > internetworking issues at all with IPv4. > > The direct link using opt1 on both boxes uses 172.16.0.2/24 and 172.16.0.3/24. > The rules on that opt1 'sync' interfaces are setup according to the Book. > > One weird dumb question: would the opt1 'sync' interface also need IPv6 > subnets in order for this to work? > > What could I do to help diagnose this further? > Could it be a problem with 2.3-REL? I never had the opportunity to build and > test such a setup with previous versions. > > I have support incidents purchased along with other pfSense hardware, but > this is not on pfSense hardware but on VMs. > > -- > Meilleures salutations, Met vriendelijke groeten, Best Regards, > Olivier Mascia, integral.be/om _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
