Project

General

Profile

Actions

Bug #14785

closed

Primary IPv6 interface address may be incorrect when a VIP is set

Added by Marcos M 6 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Interfaces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Force Exclusion
Affected Version:
Affected Architecture:
All

Description

If a compressed IPv6 VIP exists, the interface's primary IPv6 address will be set to the VIP even when a non-VIP GUA exists. Example (partially redacted):

vmx1.98: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
    description: ISP2
    options=4000000<MEXTPG>
    ether 00:50:56:b2:b1:89
    inet 192.168.1.253 netmask 0xfffffffc broadcast 192.168.1.255
    inet6 fe80::250:56ff:feb2:b189%vmx1.98 prefixlen 64 scopeid 0xf
    inet6 VIP:VIP:VIP:VIP:5:5:0:1 prefixlen 128
    inet6 ULA:ULA:ULA:ULA:250:56ff:feb2:b189 prefixlen 64 autoconf pltime 3600 vltime 86400
    inet6 GUA:GUA:GUA:GUA:250:56ff:feb2:b189 prefixlen 64 autoconf pltime 2592000 vltime 2592000
    groups: vlan
    vlan: 98 vlanproto: 802.1q vlanpcp: 0 parent interface: vmx1
    media: Ethernet autoselect
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Here, the primary address should be GUA:GUA:GUA:GUA:250:56ff:feb2:b189, but instead Status > Interfaces shows it's VIP:VIP:VIP:VIP:5:5:0:1.


Related issues

Related to Regression #14623: Primary interface address is incorrectly set to the last address on the interfaceResolvedMarcos M

Actions
Actions #1

Updated by Marcos M 6 months ago

  • Description updated (diff)
Actions #2

Updated by Marcos M 6 months ago

  • Status changed from New to Pull Request Review
Actions #3

Updated by Marcos M 6 months ago

  • Release Notes changed from Default to Force Exclusion
Actions #4

Updated by Marcos M 6 months ago

  • Related to Regression #14623: Primary interface address is incorrectly set to the last address on the interface added
Actions #5

Updated by Marcos M 6 months ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #6

Updated by Azamat Khakimyanov 5 months ago

  • Status changed from Feedback to Assigned

Tested on 23.05_1 and 23.09-DEV (built on Tue Oct 3 6:00:00 UTC 2023)

I partly can reproduce this issue on 23.05_1 with uncompressed IPv6 VIP:
- I don't see VIP:VIP:VIP:VIP:5:4:3:1 as an WAN IPv6 address in Status/Interfaces
- but I see VIP:VIP:VIP:VIP:5:4:3:1 as a Primary WAN IPv6 address (first IPv6-address after LL and above DHCPv6 IPv6 addresses (ULA and GLA)) in 'ifconfig' output.

On 23.09-DEV the behavior is different, DHCPv6 IPv6 address is always above uncompressed VIP IPv6.

BUT when I used compressed IPv6-address (VIP:VIP::1/128) as a WAN VIP, I still saw this compressed VIP IPv6 as a Primary WAN IPv6 address in 'ifconfig' output even on latest 23.09-DEV.

Actions #7

Updated by Jim Pingle 5 months ago

  • Status changed from Assigned to Feedback

Azamat Khakimyanov wrote in #note-6:

BUT when I used compressed IPv6-address (VIP:VIP::1/128) as a WAN VIP, I still saw this compressed VIP IPv6 as a Primary WAN IPv6 address in 'ifconfig' output even on latest 23.09-DEV.

The changes here affect the output of get_interface_addresses(), the order on ifconfig output doesn't matter so long as the functions return the expected addresses. Was the output of the function for that interface correct in each case?

Actions #8

Updated by Marcos M 5 months ago

  • Status changed from Feedback to Resolved

The ifconfig output order has not changed, but rather what the system determines to be primary address (e.g. under Status > Interfaces). Testing here shows it's currently working as expected with the patch.

Actions #9

Updated by Jim Pingle 4 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF