Bug #8925
closed
IPv6 RA Prefix Doesn't Match Interface Prefix ID
0%
Description
To summarize:
I have one WAN and one LAN interface. The LAN (igb) interface also has an OPT interface for VLAN 2 named GUESTVLAN (opt1), which is set to track the WAN interface with prefix ID 2. The WAN interface is configured for DHCPv6 and to request a prefix of size /60.Router advertisements are configured for both LAN subnets. In the LAN subnet, I can see a DNS server being advertised with a prefix ending in 0, and in the GUESTVLAN subnet, I can see a DNS server being advertised with a prefix ending in 2, as expected.However, the problem is that both subnets are advertising the same address prefix for use via SLAAC. I first confirmed this with Wireshark, and then I loaded /var/etc/radvd.conf and saw that the router advertisement daemon is set to advertise the same prefix on both networks. I'm including a copy of the automatically generated config file here.
Files
Updated by Jim Pingle about 6 years ago
- File radvd.conf radvd.conf added
- Status changed from New to Not a Bug
I can't reproduce this here. I have three local interfaces all set to track WAN with index 0, 1, 2 from a /60 delegation. All of them have the correct and expected (different) prefixes. See attached.
There must be something different about your environment or settings at play here. Please start a forum post with more detail about your configuration/setup, specifically the exact values used on the interfaces and in the DHCPv6/RA server settings.
Be sure you are on the latest 2.4.4 RC when testing, and after making any change to a tracking interface, save/apply on WAN or reboot and see if the configuration remains incorrect.
If, after discussing the problem in more detail, we find a bug here this can be reopened.
Updated by Allen Balaj about 6 years ago
Hi Jim,
Thanks for taking the time to try and reproduce this issue. I did create a forum issue last week (found here: https://forum.netgate.com/topic/135723/ipv6-ra-prefix-doesn-t-match-interface-prefix-id/3), but didn't receive any meaningful feedback. I have updated the post with the additional information that you requested, however.
I can confirm that issue occurs on the latest version of 2.4.4, as well as 2.4.3 and 2.4.2. I did not test this on versions earlier than that, but it has been happening for some time and I only just recently decided to investigate further.
Once the issue has been discussed further in the forum, would you prefer that I create a new bug for this issue, or post in this bug tracker thread requesting that this specific issue be reopened?
Thanks again,
Allen