ER605 sending out RA's for multiple networks incorrectly
ER605 sending out RA's for multiple networks incorrectly
I have multiple networks configured on the controller with individual IPv6 networks assigned to each one.
When I connect a wired client to a LAN port on the ER605, this receives RA's for multiple networks all without the expected VLAN's. This persists even when changing the PVID assigned to the port. DHCP IPv4 addresses are correctly assigned, so this appears to be a IPv6 specific issue.
Screenshots of my networks, showing the VLAN and the associated IPv6 prefix, and from Wireshark on the client showing the RA's from both networks within the same capture along with the output of ipconfig on the windows client showing it having addresses in multiple IPv6 prefix ranges.There are additional IPv6 networks configured, and ultimately the wired client receives RA's and addresses from each, completely isolating the client from the other IPv6 networks as it believes these are on link.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @Clive_A,
This turned out to be a bug on the Realtek Network adapter on the windows machine - this was stripping the vlan tags of all ingress traffic. Extremely concerning that support consistently tried to gaslight me into believing this was working as intended when it quite obviously was not. I can only assume this post made it no where near someone with the required technical skills to understand the packet captures, because it would have been readily apparent that something wasn't behaving as intended to anyone who did, no matter if the blame was on the ER605 or the end device, as was be the case.
Anyone who comes across this post googling a similar issue, there was details on a Wireshark post - which unfortunately I am not allowed to link, because why would posting helpful links be allowed on a support forum?
I will include the details below directly for anyone who is searching:
If changing that setting alone doesn't work for you:
1: Update your realtek drivers
2: The key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{4D36E972-E325-11CE-BFC1-08002BE10318}\00nn needs to have 4 values. '00nn' is the specific key that has the information for the adapter you intend on capturing on. Add or edit the following DWORDs
MonitorModeEnabled - 1
MonitorMode - 1
*PriorityVLANTag - 0
SkDisableVlanStrip - 1
Restart your computer, make sure there's no firewall preventing wireshark from seeing the no longer vlan tagged packets, and you should be good to go.
- Copy Link
- Report Inappropriate Content
For anyone who tries this above solution shared by the OP, please proceed based on your discretion. Please back up your registry for safety. If there is any issues, please contact your computer vendor for further recovering and technical support.
We, TP-Link, will not be responsible for any malfunction that happens to your computer if you modify your system settings. Data is invaluable and be sure you have them properly backed up.
- Copy Link
- Report Inappropriate Content
Hi @cakemix
Thanks for posting in our business forum.
So, these IPv6 IPs are not usable on your computer as we have tested this.
The reason why you have IPs from other VLANs is that when the VLAN arrives at the port, the router/switch removes the VLAN header. You can only use the IP from the matching PVID. Rest of them do not work.
Fixes to this problem:
Option 1. Remove VLAN other VLANs from the port. So stop VLANs arriving at this PC's port.
Option 2. If your NIC supports VLAN ID and PVID, set them up to the desired VLAN you want. This will stop getting different v6 IPs.
- Copy Link
- Report Inappropriate Content
Hi @Clive_A ,
I would not expect any VLAN headers to get removed, other than the VLAN that is set as the PVID for that interface. Can you confirm what release you expect this bug to be resolved in?
Kind regards,
Keith
- Copy Link
- Report Inappropriate Content
Hi @cakemix
Thanks for posting in our business forum.
cakemix wrote
Hi @Clive_A ,
I would not expect any VLAN headers to get removed, other than the VLAN that is set as the PVID for that interface. Can you confirm what release you expect this bug to be resolved in?
Kind regards,
Keith
Test team does not consider this as a bug and over a phone call with him.
This is expected behavior per the comment and test.
When it is a trunk port, it will remove the VLAN header when it arrives at the interface. At this point, IP from that VLAN is known to the client. But it does not work like commented above. So, try to remove the rest of other VLANs on this port and set only one VLAN. Will it work properly?
- Copy Link
- Report Inappropriate Content
Hi @Clive_A ,
I cannot understand how they can think this is anything but a bug? I have a port that is configured for multiple VLAN's, which is set to PVID of a specific VLAN, I would expect all vlans to be trunked out except the PVID vlan which I would expect to be accessed out.
VLAN's are indended for layer 2 isolation, if you are removing the VLAN headers from multiple VLAN's on egress, that is not happening, and we then see this erronous behaviour where a client received IPv6 addresses from multiple different VLAN's.
The methods you have advised in your previous message are a work around at best and not a solution to the issue. There are use cases where I need vlan tagged and access mode traffic to co-exist towards the same host device, are you saying that I cannot expect IPv6 to work reliably in that case if I have a VLAN that is tagged on the switchport, but not on the end device?
Kind regards,
Keith
- Copy Link
- Report Inappropriate Content
Hi @Clive_A ,
The work around you provided previously does not actually work when tested.
As you are unable to change the port configured with the default VLAN, this will always be present resulting in multiple RA's being received with this behavior, thus multiple IPv6 addresses being set on the client.
Please can you escalate this with your engineers to get an actual fix to the issue, rather than them claiming that removing the VLAN tags other than the PVID at their whim is intended behavior.
Kind regards,
Keith Summers
- Copy Link
- Report Inappropriate Content
Hi @cakemix
Thanks for posting in our business forum.
cakemix wrote
Hi @Clive_A ,
The work around you provided previously does not actually work when tested.
As you are unable to change the port configured with the default VLAN, this will always be present resulting in multiple RA's being received with this behavior, thus multiple IPv6 addresses being set on the client.
Please can you escalate this with your engineers to get an actual fix to the issue, rather than them claiming that removing the VLAN tags other than the PVID at their whim is intended behavior.
Kind regards,
Keith Summers
You have the option to create a new profile and apply that profile to a port in the following setup which can narrow down to a single VLAN.
You cannot remove the VLAN 1 on all TP-Link products. I don't know why you need to delete the default VLAN which is not what I am instructing you to do. If this is what you need, I have answered that none of the products we sell can remove the VLAN 1. Consider a different solution if you need to remove the VLAN 1.
Update:
And this is not a behavior on the router. It is what your PC does. The port on the router/switch is supposed to work in this way. It is just your NIC requests that IP in that VLAN and which the router responds. Well, you have multiple VLANs and it just responds as your PC requests. Only one IPv6 works because PVID you've set.
Limit it to a single VLAN and (PC) request from a single VLAN is what you should configure.
- Copy Link
- Report Inappropriate Content
Hi @cakemix
cakemix wrote
Hi @Clive_A ,
I cannot understand how they can think this is anything but a bug? I have a port that is configured for multiple VLAN's, which is set to PVID of a specific VLAN, I would expect all vlans to be trunked out except the PVID vlan which I would expect to be accessed out.
VLAN's are indended for layer 2 isolation, if you are removing the VLAN headers from multiple VLAN's on egress, that is not happening, and we then see this erronous behaviour where a client received IPv6 addresses from multiple different VLAN's.
The methods you have advised in your previous message are a work around at best and not a solution to the issue. There are use cases where I need vlan tagged and access mode traffic to co-exist towards the same host device, are you saying that I cannot expect IPv6 to work reliably in that case if I have a VLAN that is tagged on the switchport, but not on the end device?
Kind regards,
Keith
802.1Q VLAN is not the VLAN interface we are discussing here. I don't think you should use "VLAN" to describe this situation.
Though VLAN tag/untag is based on 802.1Q VLAN. But VLAN interface is not the same concept as 802.1Q VLAN. And no one would agree with this statement because they are different.
About the ingress(the subject is the router/switch), mainly about the PVID, you ONLY have one IP working because it is inserting the VLAN in the traffic from the PC. Egress is VLANIF. Determined by your VLAN ID. It is removing the other VLAN IDs but the VLAN ID you set.
I did not say it is a workaround. It is the solution because it is not a problem with the router/switch.
And I did not imply that IPv6 would not work. It is about the IPv6. RA packet would be sent in each and every VLAN interface. Unless you can change IPv6. Or we just follow what IPv6 does and how RA is supposed to work.
As this is confirmed to be a normal case for IPv6 and RA mechanism, you can also try a different system instead of just Omada. If they behave the same, that's a "bug" in every vendor, I suppose.
- Copy Link
- Report Inappropriate Content
Hi @Clive_A ,
The issue I am having is not on ingress (from the ER605 point of view) it's on egress form the ER605.
I understand that setting the PVID is going to have all untagged ingress traffic to the ER605 put into that VLAN, that is how PVID works. I understand that every network I have configured with IPv6 will be sending out RA's, that is intended behavior and how all hosts will receive their IPv6 addressing advertisements.
What I am not expecting is that the ER605 is going to remove the VLAN ID's from *all* Ethernet frames on egress. I am not aware of *any* vendor that would expect that to be intended behavior in any situation.
Additionally, if you are trying to tell me that we are not talking about 802.1Q VLAN's, you *really* need to update your ER605 product page to stop advising it supports the 802.1Q standards, and the Omada controller software to stop referring to them as 802.1Q tags when configuring the networks!
Kind regards,
Keith
- Copy Link
- Report Inappropriate Content
Hi @cakemix
cakemix wrote
Hi @Clive_A ,
The issue I am having is not on ingress (from the ER605 point of view) it's on egress form the ER605.
I understand that setting the PVID is going to have all untagged ingress traffic to the ER605 put into that VLAN, that is how PVID works. I understand that every network I have configured with IPv6 will be sending out RA's, that is intended behavior and how all hosts will receive their IPv6 addressing advertisements.
What I am not expecting is that the ER605 is going to remove the VLAN ID's from *all* Ethernet frames on egress. I am not aware of *any* vendor that would expect that to be intended behavior in any situation.
Additionally, if you are trying to tell me that we are not talking about 802.1Q VLAN's, you *really* need to update your ER605 product page to stop advising it supports the 802.1Q standards, and the Omada controller software to stop referring to them as 802.1Q tags when configuring the networks!
Kind regards,
Keith
First, my point is VLAN interface is a set of different concepts together to form a function called a VLAN Interface. It is not a single function and when you refer to it, you need to consider other aspects. 802.1Q VLAN is the pure concept of the VLAN and tag/untag stuff.
I have to clear this on our forum and I don't care how you call it on other platforms. But we have this clearly distinguished.
Second, ER605 > PC, VLANIF, egress, all packets/frames, regardless of their tag/untag from all VLAN interfaces are landing on the port and the PC. Removing happens to the untagged frames and keeping the status quo happens to the tagged frames if this is a trunk port. They are landing on the port/PC but only one of them can and will work because of VLANIF and untag(removing).
I did not say "all".
Third, I was referring to the only one IPv6 (under the current situation where you have multiple v6 IPs and if you have concerns about safety) that would work because of ingress and PVID which are limiting the traffic. The rest of them would not even work. I have explained the reason why you would get the multiple RA v6 IPs previously(in #7). If you are willing to re-read what I wrote.
Let's jump out from this. Get back to the issue. In IPv6 networks, broadcast RA messages are sent with multicast addresses and delivered to all devices within a specific range. This means that regardless of whether they are VLAN-tagged or not(untagged), the device connected to the same physical link on this port of the switch or router will receive RA messages sent from different VLAN Interfaces.
That's why we recommend you follow the steps in #7.
My best suggestion in this would be you can try out different vendors if you insist this is a problem with only us instead of IPv6 which is the whole point of your thread from the beginning and as the title "ER605 sending out RA's for multiple networks incorrectly" indicating the ER605 is the perp.
- Copy Link
- Report Inappropriate Content
Hi @Clive_A,
You either seem to be focusing on the wrong point of the issue, or not understanding the issue. This may be partly my fault due to putting IPv6 terminology into the subject, however this is *not* a layer 3 issue per se, this is a layer 2 issue.
To simplify the issue, take 3 networks, the default using the pre-configured vlan id 1 as this cannot be removed, wifi_lan on vlan id 100 and servers on vlan id 128.
I have a port on the er605 gateway that is connected to a client that needs to be in vlan 100, and I have another port that is connected to a switch which needs to have vlan 100 and 128 as tagged.
If I mirror the port that is connected to the switch, I can see all frames leave the ER605 with the correct dot1q tags, or lack thereof.
If I set PVID 100 on the port that is connected to the device that needs to be in vlan 100, it *still* received multicast/ broadcast packets that should be in vlan 1 and 128 without the dot1q tags added added to the Ethernet frame header. This is the unexpected behavior, and why my device is configuring IPv6 addresses for all of my VLANs breaking my IPv6 network for this client.
I have configured devices with similar configuration on Netgear, D-Link, Cisco, Juniper, Huawei, Fortigate, Extreme, Brocade and many other vendors, *none* of them show this behavior when setting a port PVID, Trunk Native or access VLAN on the port, they all correctly send the tagged traffic as tagged an the untagged traffic as untagged with the vlans that are configured on the port.
I should not need to send you packet captures from these other vendors devices for such a basic behavior before you investigate and resolve the issue.
Kind regards,
Keith
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1213
Replies: 13
Voters 0
No one has voted for it yet.