EAP245 VLAN Problems

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

EAP245 VLAN Problems

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
EAP245 VLAN Problems
EAP245 VLAN Problems
2020-05-01 16:26:16 - last edited 2020-05-07 17:47:34
Model: EAP245  
Hardware Version: V3
Firmware Version: 2.4.0 Build 20200117 Rel. 39932(4555)

Hi All,

 

I fear the solution is staring me in the face but I am a little stuck so here goes.

 

I recently replaced my WA701ND AP for an EAP245 after it died. The WA701 had 2 SSIDs with  associated vlans to provide serperation. The AP was connected to a TPLink SG2109 which was then in turn connected to another TPLink SG switch (16 Port Switch) for onwards connection to a firewall and router.   The vlans are split out on the 16 port switch and presented to the firewall on two individaul interfaces. The firewall acts as a dhcp server for each vlan and controls traffic flow. A third interface on the firewall connects the ADSL router to the internet. The setup worked really well until i replaced the WA701 with the EAP.

 

I am using the EAP in stand alone mode with no controller. I have configured it with the same SSID and VLAN details and wired it into the network in the same way. I can connect to the AP but do not get any DHCP assigned addresses, if i put in a manual address this does not route. If I remove the VLAN assignment for the SSIDs within the AP then i get dhcp addresses assigned and everything works, however both SSIDs are now on VLAN 20 as per diagram which provides no seperatation.

 

Heres a view on the setup - can some one help to fix this problem?

 

 

Thx

  0      
  0      
#1
Options
2 Accepted Solutions
Re:EAP245 VLAN Problems-Solution
2020-05-07 13:09:21 - last edited 2020-05-07 17:47:34

@SoHoAdmin,

 

why do you egress frames of VLAN 2 untagged from switch 1? They will end up in VLAN 1 on switch2. Can't work.

 

The rules of thumb are:

  • In a VLAN-aware network there is no such thing as untagged traffic. If a non-VLAN-aware device sends untagged traffic, it gets assigned a VLAN ID and thus it »enters« the VLAN network at this switch port. On egress to such a device the frame »leaves« the VLAN network, it's »terminated« at this port. For such devices you use access ports. For any other VLAN-aware device you always use a trunk port (switch interconnection, EAPs) and they are still part of the VLAN network as a whole, meaning the frames do neither »enter« nor »leave« the VLAN they are assigned to. The switch keeps the VLAN ID always intact and does not fiddle with it.
  • An access port is always an untagged member of exactly one VLAN. PVID is the same as the VLAN ID the port is a member of.
  • A trunk port is a tagged member of one or more VLANs. PVID doesn't matter at all, since you should never receive untagged frames on a trunk port.

 

Thus, do not mix tagged and untagged frames on the same port. Either the switch removes the tag on egress and assigns one at ingress for a given port, then a VLAN-unaware device is connected to this (access) port. Or the switch keeps the VLAN ID and doesn't assign any other, then it's a VLAN-aware device which is attached to this (trunk) port.

 

Just draw separate, unrelated network topologies for each one of the three networks (1, 2 and 12) and then combine the different routers / cables / switches / APs and servers to one device each using VLANs. Every VLAN-aware device is part of the VLAN network and uses trunks for interconnection, while every other VLAN-unaware device is a »leaf node« outside the VLAN network and assigned to only one »real« network.

 

BTW: I use the so-called system VLAN 1 only for unused ports and to discard untagged frames arriving on a trunk. So only unused ports are members of VLAN 1 until anything gets connected to them. Then I assign it a member of a »real« VLAN. My trunks are not members of VLAN 1, but have PVID 1, therefore kind of »dropping« untagged frames on cheaper switches, while more expensive ones allow to drop untagged traffic arriving on a trunk using an ingress setting (»Acceptable Frame Types« set to »Tagged only«).

 

The »system« or »native« or »default« VAN once was introduced to be able to migrate non-VLAN-aware networks to VLAN-aware networks. Once migrated, a default VLAN is obsolete. Another use case is for old HP servers, which output untagged traffic even on a trunk for specific protocols (e.g. to talk to all devices no matter in which VLANs they are members of).

 

Of course, you can use VLAN 1 as a regular VLAN much like 2 or 12 if you want. The switch just provides a mechanism which you can use in any way which makes sense to you. But if using VLAN 1 as a normal network, unused ports are always part of your network with VLAN 1.

 

I prefer to assign unused ports membership of a non-existing network which is never forwarded to any other switch, especially if switches are not under my direct control (managed by others).

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
Recommended Solution
  0  
  0  
#8
Options
Re:EAP245 VLAN Problems-Solution
2020-05-07 17:47:22 - last edited 2020-05-07 17:47:45

 

R1D2 wrote

@SoHoAdmin,

 

why do you egress frames of VLAN 2 untagged from switch 1? They will end up in VLAN 1 on switch2. Can't work.

@R1D2 

 

BOOM! obvious when you think it about - just stopped thinking about it!!

 

R1D2 wrote

 

The rules of thumb are:

  • In a VLAN-aware network there is no such thing as untagged traffic. If a non-VLAN-aware device sends untagged traffic, it gets assigned a VLAN ID and thus it »enters« the VLAN network at this switch port. On egress to such a device the frame »leaves« the VLAN network, it's »terminated« at this port. For such devices you use access ports. For any other VLAN-aware device you always use a trunk port (switch interconnection, EAPs) and they are still part of the VLAN network as a whole, meaning the frames do neither »enter« nor »leave« the VLAN they are assigned to. The switch keeps the VLAN ID always intact and does not fiddle with it.
  • An access port is always an untagged member of exactly one VLAN. PVID is the same as the VLAN ID the port is a member of.
  • A trunk port is a tagged member of one or more VLANs. PVID doesn't matter at all, since you should never receive untagged frames on a trunk port.

 

Thus, do not mix tagged and untagged frames on the same port. Either the switch removes the tag on egress and assigns one at ingress for a given port, then a VLAN-unaware device is connected to this (access) port. Or the switch keeps the VLAN ID and doesn't assign any other, then it's a VLAN-aware device which is attached to this (trunk) port.

 

Just draw separate, unrelated network topologies for each one of the three networks (1, 2 and 12) and then combine the different routers / cables / switches / APs and servers to one device each using VLANs. Every VLAN-aware device is part of the VLAN network and uses trunks for interconnection, while every other VLAN-unaware device is a »leaf node« outside the VLAN network and assigned to only one »real« network.

 

Following your advice I have gone back to basics to ensure that the access ports are exactly one member of one vlan + untagged and the PVIDs align.

 

Everything is now working as it should - a big thank you for you help yes

Recommended Solution
  0  
  0  
#9
Options
9 Reply
Re:EAP245 VLAN Problems
2020-05-01 17:30:18

@SoHoAdmin, I have no idea what you mean with »Egress Frame Add/Drop« in the table, but there are several errors in this topology. For example, I can't see a VLAN membership of ports 15/16 of the main switch and several access ports are member of two VLANs (why?).

 

For the Multi-SSID feature you need to assign:

 

  • port 15 of the main switch as an untagged member of VLAN 20, PVID 20. No other VLAN membership (especially not VLAN 1).
  • port 16 of the main switch as an untagged member of VLAN 100, PVID 100. No other VLAN membership.
  • port 5 of the main switch and port 1 of the secondary switch as a tagged member of VLANs 1, 20, 100, PVID 1.
  • port 8 of the secondary switch as a tagged member of VLANs 1, 20, 100, PVID 1.

 

This way network 1 (port 1 of the firewall) uses VLAN 20 assigned to SSID 1 and network 2 (port 2 of the firewall) uses VLAN 100 assigned to SSID 2.

 

Management of the EAP is possible through VLAN 1. Alternatively, you can manage the EAP through network 1 or 2. In this case set the Mgmt VLAN on the EAP, assign port 8 of the secondary switch as a tagged member of VLANs 20 and 100 only. PVID doesn't matter then, b/c you're using tagged frames only.

 

BTW: You should assign both switches IPs from the same network except it is intentional to manage one switch through network 1 and the other through network 2.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#2
Options
Re:EAP245 VLAN Problems
2020-05-02 11:47:36

@R1D2

 

I tried what you have suggest and it made no difference.

 

Given the installationa is a good few years old - I have spent the last few hours redoing all the settings, tracing all the cables to ensure everything is plugged together as 'I think it should be' and I have also factory reset the switches. I have updated the diagram as you were correct there are a couple of typos and have provided the 16 port switch config as well for the VLANs.

 

Here is what I have found out:

 

  • On the 8port switch I have to bind VLAN 1 to ALL ports else I cannot connect to any services on the main 16Port switch when jacking into the ports
    • VLAN20 and VLAN100 are tagged accoding to the 8Port switch table, if they are not tagged then nothing works - setting the untag frame to pass or drop makes no difference
    • Assigning any PVID value to any of the ports makes no difference - also - setting the 'egress frame' to pass or drop also makes no difference for any port...

 

  • On the 16Port switch I need to bind ports 5,14 & 15 to VLAN 1 to enable the 8Port switch to utilse services connected to the main 16Port switch
    • VLAN20 and VLAN100 are tagged accoding to the 16Port Switch table, if they are not tagged then nothing works when hjacking directly into the ports - setting the untag frame to pass or drop makes no difference
    • Assigning any PVID value to any of the ports makes no difference - also - setting the 'egress frame' to pass or drop also makes no difference for any port...

 

  • The EAP245 does not connect with this setup for any SSID tagged with either VLAN 20 or 100, or any other VLAN id - no DHCP or routing.
    • If I disable the VLAN tagging for an SSID (system sets it to zero) then it connects by default to VLAN 20 and it works; incidentally I have set the PVID, VLAN to everything but VLAN20 and removed all reference to VLAN20 on this port and it still defaults to VLAN20 in this case?!?!?!

 

I understood your thinking in your response and it makes logical sense, but when applied it does not seem to work for my setup ?!?!?

 

I welcome any additonal thinking on this!

 

Here is the updated diagram for both switches and includes the additional settings etc, btw you asked what the 'egree frame' is here is the help file from TPLink on their definition:

Egress Frame The solution to the egress frame."Drop Tag" indicates drop the tag header before sending the frame."Add Tag" indicates add the tag header before sending the frame."Unmodify" indicates do not modify the tag header before sending the frame.');

 

 

  0  
  0  
#3
Options
Re:EAP245 VLAN Problems
2020-05-02 15:12:07 - last edited 2020-05-02 15:17:22

@SoHoAdmin,

 

sorry, I'm not used to this particular switches, I even could not find specs or datasheets for them on the TP-Link website. Are this older switches?

 

I use business-class JetStream switches only and they don't have the notion of »add«, »drop« or »unmodify« egress rules. Frames in a managed switch are always tagged, no matter whether the arrive or leave the switch untagged. So, to force untagged frames on egress in a JetStream switch, a port is just an untagged member of the corresponding VLAN. If frames should carry the tag on egress, they are defined to be a tagged member of a VLAN.

 

I still don't get what »unmodify« means compared with »add«, since every frame inside the switch always has a tag and it can be either removed (untagged port = drop) or left intact (tagged port = add? unmodify? I don't know.).

 

This is the topology I use for VLAN-tagged Multi-SSIDs:

 

Try to implement this in your TL-SG2xWEB switches. Replace the router's trunk port P3 shown above by the two ports your firewall provides, e.g. your VLAN network starts at the main switch (not in the router/firewall as shown above) and will eventually become terminated either in the secondary switch (for unatgged frames) or in the EAP (for tagged frames).

 

Note that I don't use a »Default VLAN« or »Native VLAN« which was introduced an eternity ago to help with migration of non-VLAN-aware devices in VLAN-aware networks. My networks are always using VLAN-tagged frames from the router to the connected device ot at least to the switch's access port (which is defined as »a port which is member of exactly one VLAN and has egress rule untag«). Thus, inside my VLAN networks there is no such thing as an untagged frame.

 

You can use Default VLAN 1 if you want. But then I would assign the main SSID to this VLAN 1, too, and only assign the second SSID you want to isolate from the main network to VLAN 100. Else you have three networks (1, 20, 100) on two firewall ports – maybe this is the cause of your DHCP problem.

 

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#4
Options
Re:EAP245 VLAN Problems
2020-05-02 16:35:42

@R1D2 

 

Yes these are old SOHO switches manufacturing date circa 2008/10- the last SW update was around 6-8 years ago.

 

I have seen something similar in one of the config guides published in the support channel, works for tplink, works for you amd others -  just not set up !

 

Having pulled the network apart this morning and gone round and round thinking this through this afternoon I have a gut feeling, which I cant prove, that these switches are simply just not compatible with the EAP.

 

 

I dont know if its hardware problem (unlikley), a software compatability problem (most likley) or a software corruption problem (less likley as I have reset and reflashed the devices) - but, as they are web smart switches and not fully managed I cant get under the hood to prove or deny this which is the frustraing part?!?!?!

 

Some of the pointers are with the firmware and what it will let you do vs what you think it can do, a good example of this while the 8 port is the same family as the 16 and the same era, you get the options for add/drop/unmodify? on the egress frame - where the other switch does not, and there are other differrences in settings where you would expect them to be the same or similar.

 

Given the amount of time that I have burnt on this I have decided to bite the bullet and have ordered some Jet Stream switches to replace the entire setup; given the setup is by IT standards an antique im figuring this is the best path right now.

 

Thank you for your help this far - i will post back and let you know how I get on  with the new gear when it arrives later next week

 

 

  0  
  0  
#5
Options
Re:EAP245 VLAN Problems
2020-05-02 22:45:51

 

SoHoAdmin wrote

Thank you for your help this far - i will post back and let you know how I get on  with the new gear when it arrives later next week

 

You're welcome. I think with a JetStream switch you can easily achieve your goal. Feel free to ask for tipps on how to set up those switches.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#6
Options
Re:EAP245 VLAN Problems
2020-05-07 11:43:57

@R1D2 

 

The new Jetstreams have arrived, T2500G-10TS & T2600G-28TS they are in and configured and the EAP is talking nicely now with multi SSIDs over VLANs - success!!!  In my last post I was suspecting that the switches where the source of the problem but could not prove it, it seems that the original 8 port websmart switch was causing the vlan issues, upto yesterday when I switched it out it had frozen at least a dozen times since the weekend, i guessing it has a PSU fault - with hindsight its the right move to swap out the devices.

 

One step forward and half a step back....

 

The network is up and running, wifi access is working but theres a couple of new challenges specific to VLAN2 - the other VLAN is working correctly - I think the problems are switch config related - here is what is happening;

 

  1. When connected to Switch 1 VLAN2, I can connect to devices on both Switch 1 and Switch 2 VLAN 2 - and vice versa - this is correct behaviour, onto the problems...
  2. I  connect to Switch 1 VLAN2 and manage it via IP BUT cannot connect to or manage Switch 2 - but when I connect to VLAN 1 on Switch 1 I can manage both devices.
    • I can connect to Switch 2 VLAN2 and manage it Switch 2 via IP - I can also manage both devices via IP on VLAN1
  3. When connected via the AccessPoint I can access devices on Switch 2 but cannot access devices on Switch 1 (VLAN 2).

 

I think its how I have configured the tag/ untag on the vlans - but I cant figure out?!?!?!

 

Thoughts welcomed

 

I have taken the oppurtunity to update the network heres the updated diagram

 

  0  
  0  
#7
Options
Re:EAP245 VLAN Problems-Solution
2020-05-07 13:09:21 - last edited 2020-05-07 17:47:34

@SoHoAdmin,

 

why do you egress frames of VLAN 2 untagged from switch 1? They will end up in VLAN 1 on switch2. Can't work.

 

The rules of thumb are:

  • In a VLAN-aware network there is no such thing as untagged traffic. If a non-VLAN-aware device sends untagged traffic, it gets assigned a VLAN ID and thus it »enters« the VLAN network at this switch port. On egress to such a device the frame »leaves« the VLAN network, it's »terminated« at this port. For such devices you use access ports. For any other VLAN-aware device you always use a trunk port (switch interconnection, EAPs) and they are still part of the VLAN network as a whole, meaning the frames do neither »enter« nor »leave« the VLAN they are assigned to. The switch keeps the VLAN ID always intact and does not fiddle with it.
  • An access port is always an untagged member of exactly one VLAN. PVID is the same as the VLAN ID the port is a member of.
  • A trunk port is a tagged member of one or more VLANs. PVID doesn't matter at all, since you should never receive untagged frames on a trunk port.

 

Thus, do not mix tagged and untagged frames on the same port. Either the switch removes the tag on egress and assigns one at ingress for a given port, then a VLAN-unaware device is connected to this (access) port. Or the switch keeps the VLAN ID and doesn't assign any other, then it's a VLAN-aware device which is attached to this (trunk) port.

 

Just draw separate, unrelated network topologies for each one of the three networks (1, 2 and 12) and then combine the different routers / cables / switches / APs and servers to one device each using VLANs. Every VLAN-aware device is part of the VLAN network and uses trunks for interconnection, while every other VLAN-unaware device is a »leaf node« outside the VLAN network and assigned to only one »real« network.

 

BTW: I use the so-called system VLAN 1 only for unused ports and to discard untagged frames arriving on a trunk. So only unused ports are members of VLAN 1 until anything gets connected to them. Then I assign it a member of a »real« VLAN. My trunks are not members of VLAN 1, but have PVID 1, therefore kind of »dropping« untagged frames on cheaper switches, while more expensive ones allow to drop untagged traffic arriving on a trunk using an ingress setting (»Acceptable Frame Types« set to »Tagged only«).

 

The »system« or »native« or »default« VAN once was introduced to be able to migrate non-VLAN-aware networks to VLAN-aware networks. Once migrated, a default VLAN is obsolete. Another use case is for old HP servers, which output untagged traffic even on a trunk for specific protocols (e.g. to talk to all devices no matter in which VLANs they are members of).

 

Of course, you can use VLAN 1 as a regular VLAN much like 2 or 12 if you want. The switch just provides a mechanism which you can use in any way which makes sense to you. But if using VLAN 1 as a normal network, unused ports are always part of your network with VLAN 1.

 

I prefer to assign unused ports membership of a non-existing network which is never forwarded to any other switch, especially if switches are not under my direct control (managed by others).

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
Recommended Solution
  0  
  0  
#8
Options
Re:EAP245 VLAN Problems-Solution
2020-05-07 17:47:22 - last edited 2020-05-07 17:47:45

 

R1D2 wrote

@SoHoAdmin,

 

why do you egress frames of VLAN 2 untagged from switch 1? They will end up in VLAN 1 on switch2. Can't work.

@R1D2 

 

BOOM! obvious when you think it about - just stopped thinking about it!!

 

R1D2 wrote

 

The rules of thumb are:

  • In a VLAN-aware network there is no such thing as untagged traffic. If a non-VLAN-aware device sends untagged traffic, it gets assigned a VLAN ID and thus it »enters« the VLAN network at this switch port. On egress to such a device the frame »leaves« the VLAN network, it's »terminated« at this port. For such devices you use access ports. For any other VLAN-aware device you always use a trunk port (switch interconnection, EAPs) and they are still part of the VLAN network as a whole, meaning the frames do neither »enter« nor »leave« the VLAN they are assigned to. The switch keeps the VLAN ID always intact and does not fiddle with it.
  • An access port is always an untagged member of exactly one VLAN. PVID is the same as the VLAN ID the port is a member of.
  • A trunk port is a tagged member of one or more VLANs. PVID doesn't matter at all, since you should never receive untagged frames on a trunk port.

 

Thus, do not mix tagged and untagged frames on the same port. Either the switch removes the tag on egress and assigns one at ingress for a given port, then a VLAN-unaware device is connected to this (access) port. Or the switch keeps the VLAN ID and doesn't assign any other, then it's a VLAN-aware device which is attached to this (trunk) port.

 

Just draw separate, unrelated network topologies for each one of the three networks (1, 2 and 12) and then combine the different routers / cables / switches / APs and servers to one device each using VLANs. Every VLAN-aware device is part of the VLAN network and uses trunks for interconnection, while every other VLAN-unaware device is a »leaf node« outside the VLAN network and assigned to only one »real« network.

 

Following your advice I have gone back to basics to ensure that the access ports are exactly one member of one vlan + untagged and the PVIDs align.

 

Everything is now working as it should - a big thank you for you help yes

Recommended Solution
  0  
  0  
#9
Options
Re:EAP245 VLAN Problems
2020-05-07 19:45:30

@SoHoAdmin, you're welcome. Great that it works now!

 

Have fun with JetStream switches, they are really cool products IMO.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#10
Options

Information

Helpful: 0

Views: 3712

Replies: 9

Related Articles