On Mon, May 2, 2016 at 5:43 PM, Olivier Mascia <[email protected]> wrote: > 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?
That's how it's supposed to be. > Or would it be that my BACKUP (according to /status_carp.php) do also > advertise (which it shouldn't as BACKUP)? That's the problem. I'm seeing that in some cases and not others with IPv6 CARP in 2.3, with no apparent reason as to why. It seems like it continues to work fine in that circumstance for me, but that could definitely affect switch CAM tables and cause issues like packet loss in some environments. I need to look at it closer tomorrow. _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
