Project

General

Profile

Actions
Copy link

Bug #14785

closed
MM MM

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

Bug #14785: Primary IPv6 interface address may be incorrect when a VIP is set

Added by Marcos M almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Marcos M
Category:
Interfaces
Target version:
2.7.1
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 1 (0 open — 1 closed)

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

Actions

MM Updated by Marcos M almost 3 years ago Actions
Copy link
 #1

  • Description updated (diff)

MM Updated by Marcos M almost 3 years ago Actions
Copy link
 #2

  • Status changed from New to Pull Request Review

MM Updated by Marcos M almost 3 years ago Actions
Copy link
 #3

  • Release Notes changed from Default to Force Exclusion

MM Updated by Marcos M almost 3 years ago Actions
Copy link
 #4

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

MM Updated by Marcos M almost 3 years ago Actions
Copy link
 #5

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

Applied in changeset commit:9bda254db22b1d87da8e17b14d045eb55a0c7e92.

AK Updated by Azamat Khakimyanov almost 3 years ago Actions
Copy link
 #6

  • 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.

JP Updated by Jim Pingle almost 3 years ago Actions
Copy link
 #7

  • 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?

MM Updated by Marcos M almost 3 years ago Actions
Copy link
 #8

  • 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.

JP Updated by Jim Pingle almost 3 years ago Actions
Copy link
 #9

  • Target version changed from 2.8.0 to 2.7.1
Actions
Copy link

Also available in: Atom