Project

General

Profile

Bug #8276

Virtual IPs considered primary when using interface tracking for ipv6

Added by Jupiter Vuorikoski 8 days ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
radvd
Target version:
-
Start date:
01/13/2018
Due date:
% Done:

0%

Affected Version:
2.4.2_1
Affected Architecture:

Description

On boot, if you have VIPs configured on an interface that uses interface tracking for its primary IP, the primary ipv6 prefix will not be added to radvd configuration at all and instead a VIP prefix is announced on the prefix. This causes loss of connectivity when having ULA IP Alias configured on an interface that uses interface tracking for its addressing.

Expected behavior: the VIP should never be configured or even considered to be advertised through radvd unless explicitly added to the subnets to be announced in the RA configuration. This could be added at the same time with functionality described in ticket #8262 with a "Primary interface prefix" as a dynamic object existing as default entry in the subnets field.

History

#1 Updated by Jim Thompson 8 days ago

  • Assignee set to Jim Pingle

#2 Updated by Jupiter Vuorikoski 7 days ago

This affects the dhcpv6 server as well. Logic needs to be applied to never consider a VIP a primary address.

#3 Updated by Jim Pingle 5 days ago

  • Target version deleted (2.4.3)

I'm not sure we've ever officially endorsed that type of setup. The behavior is at best undefined. It's going to need more long-term design thought on how to handle that situation.

#4 Updated by Jupiter Vuorikoski 3 days ago

The problem of pfsense considering a VIP over the actual tracked interface IPv6 and never switching is still an issue that should be addressed. This is not something for some "long term design thought".

Behavior is not undefined when you want secondary addresses which prefixes are not announced in the RA packets on an interface. Only the primary address should ever be considered for radvd if there are no other prefixes configured to be announced. The behavior is the exact same as when one would have multiple ipv4 subnets on an interface (however invalid that design is), except in the case of IPv6 RAs exist instead of only one subnet being available to be served via DHCP in the ipv4 world.

Please dont bury this to be a footnote for future and fix the behavior instead. It will most likely only require some new variable to separate the primary address from secondaries.

Also available in: Atom PDF