Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 16 to 30 of 40
  1. #16
    Quote Originally Posted by pleased View Post
    The only thing I can think of so far is that, when the SG108e transfers a packet to my router "across PVIDs", it does something to the packet to cause the router to send a broadcast in response.
    Yes, this was my first thought, too. Any broadcast request from the router would be sent to all ports b/c they are all in VLAN 1. According to the TP-Link docs, an untagged packet on a tagged port (remember: all ports assigned to more than one VLAN are tagged ports) will get the PVID of the ingress port, but will be forwarded with the PVID of the egress port (again all ports, b/c they are also a member of the VLAN 1).* Result are blinkenlights for every broadcast of any device. Is this plausible?

    * See table below for PVID handling - it's from the first edition of T1600G's User's Guide, which has been replaced already by another version - I saved it for reference. Since the TL-SG108's UG is very sparse, I take this as reference. I think that the OS of the switches is almost the same for Easy Smart and Smart/Managed switches.

    Just guessing by my gut feeling. To proof, I would have to set up this scheme and analyze it, like you could do too. It would probably be easier to just set up a trunk port, but if I have some time tomorrow, I probably will test it if you think it makes sense. But I have Unix systems only and they don't send as much broadcasts as Windows does, so my LEDs would probably blink with somewhat slower frequency (no kidding).

    Before doing so, please could you test it with just one computer connected to the switch and the switch to the router to see if something changes (frequency of blinking, for example)?

    Name:  PVID.png
Views: 0
Size:  185.0 KB
    Last edited by R1D2; 01-05-2017 at 03:45.

  2. #17

    Smile

    This seems definitive: "The packet will be forwarded after removing its VLAN tag," no matter whether the packet's destination port had the same PVID or not. I am not clear on your statement, "remember: all ports assigned to more than one VLAN are tagged ports". According to my SG108e VLAN configuration, all ports are untagged. Please explain.

    I'm racking my limited networking understanding and I can't see how this is a network problem.

    I don't understand your trunk experiment and am hesitant to investigate that option at present. Perhaps if you clarified the configuration so I could think about it, I would like to try it as well.
    Last edited by pleased; 01-05-2017 at 04:12. Reason: Completed reply

  3. #18
    Would you like me to connect just the server with the torrent client or something just running a browser? I confess I don't understand your purpose since I see the difference (between having the same PVID and having different PVIDs) in the other connected ports.

  4. #19
    Trunk is not an expirement, it's the only way to connect two or more VLAN networks to a third network outside of the TL-SG108E.
    I will test tomorrow (or better: today, it's already Tuesday here) with my switch and we'll see whether I can reproduce this behaviour.

    Yes, the PVID handling seems confusing a bit, but it is what this switch does according to the docs.
    For configuration, I would just set up the switch like you described.
    Last edited by R1D2; 01-05-2017 at 04:34.

  5. #20
    I believe if I trunked the VLANs to my cheap router it would reject the traffic.

    I'm wondering what could be causing it to broadcast ... is the router's request for info never answered when the destination does not have the same primary VLAN? Why the hell would that be?
    Last edited by pleased; 01-05-2017 at 04:45. Reason: Added query on speculation that router broadcasts are cause of blinkenlights.

  6. #21
    Thanks, R1D2. You are in Germany?

  7. #22
    Yes, I am in Germany. Where are you from?

  8. #23
    Here are my quick & dirty test results with original firmware as delivered when I bought the switch last year (Build 20160108 Rel.57851).

    First of all: you were right, I was wrong. This switch indeed supports overlapping VLANs in a similar manner as PVLANs. I'm really surprised that the TL-SG108E for such a favourable price does support this kind of setup. Truly amazing!

    Now the bad news: In my network the LEDs blinked more or less synchronously, but at a very low rate. I had to flood the switch with ARP requests using tomw's cool arpflood script to get blinkenlights like in a discotheque. During this ARP attack I did a speed test simultaneously, but since I have only stone-age speed of 12 Mbit/s downstream here in underdeveloped Germany it performed well with almost no degradation. The setup was as you described with PVID 1 for port 1, PVID 2 for ports 2-6 and PVID 3 for ports 7+8 and following VLANs:
    Name:  setup1.png
Views: 0
Size:  10.6 KB

    This is the captured traffic, ARP requests highlighted:
    Name:  capture1.png
Views: 0
Size:  120.1 KB

    Statistics show that data to port 1 goes to both VLANs 2 and 3 as expected and vice versa:
    Name:  stats1.png
Views: 0
Size:  24.7 KB

    While I'm at it, I did also the same test using old-fashioned, classic VLAN setup. For this I did setup a TL-WDR4300 with OpenWRT, configured one LAN port as a VLAN trunk, created two additional private subnets and installed the usual forwarding rules to the WAN. Since for the WAN VLAN we use VLAN 2 already on this router, I changed the switch's VLAN IDs to 3 and 4, but it is basically the same setup except for the fact that I now have two broadcast domains and a tagged VLAN trunk to the WDR, which connects to the ISP's modem. The TL-SG108E config is as follows (PVID same as before + 1 for the new VLAN IDs), only remarkable difference here is port 1 being a tagged (trunk) port now instead of untagged:
    Name:  setup2.png
Views: 0
Size:  10.8 KB

    Same test conditions (ARP flood & simultaneous speed test):
    Name:  capture2.png
Views: 0
Size:  135.6 KB

    Here are the result of the dslreports speed test (1 & 2 was the "PVLAN" without and with ARP flooding, 3 was classic VLAN without ARP flooding, no big difference):
    Name:  speedtest.png
Views: 0
Size:  21.3 KB

    Unfortunately, this doesn't help you much - you have to find out what causes the broadcast flood in your network. Probably it's coming from the cable network? I don't know. I'm always trying to keep traffic in my networks as low as possible despite the fact that we have big bandwidth nowadays - when I started we had serial lines with roughly 9,600 bps (bit per second) in local networks - unbelievable today, isn't it?

    So you will have to use tcpdump / wireshark and find out what causes your switch to perform such a light show - if it's a bug in the switch, I couldn't trigger it with my systems. But you certainly see the difference of classic VLANs versus overlapping ones even at this low traffic utilization.

    Nevertheless I hope this helps somewhat - and be it only to think about such a setup to create different broadcast domains while maintaining the same functionality as with overlapping VLANs and a single subnet. It was really great fun to do the tests and to learn something new about the TL-SG108E!
    Last edited by R1D2; 01-05-2017 at 10:46.

  9. #24
    You can't remove ports from vlan1, so anything coming in on vlan1 will go out on all ports, regardless of all other settings. If your modem is on port 1, having pvid 1, all that traffic will always go out on all ports. To avoid this you should not use vlan 1, meaning no pvid=1 on any port.

  10. #25
    Nice. However, I don't understand why you can see the ARP flood in the first test but not the second so I'm not sure what difference I'm seeing. You are doing the ARP flood from a machine on the Apartment VLAN while the Wireshark monitor is on the Home VLAN (or vice-versa)? If so, then this is an indication that the router in the first test is reflecting ARP broadcasts back into both Home and Apartment? I am confused.

    I suppose I could flash the router I have to DD-WRT (haven't checked other options) and set up your "classic" VLANs. OTOH, maybe new firmware would fix my blinkenlights problem.

    Last night I tested whether all connected ports are flashing - it appears that only all the ports in the primary VLAN of the router port are flashing (of course, only when the SG108e sends a packet "across VLANs").. I suppose I could mirror the router port and monitor that with Wireshark ...

    If the packet "crossing VLANs" and sent to the router is triggering broadcasts, how could that come from the cable modem or cable network? The router is doing NAT and I don't understand why it would incite that response.

    Back to your trying to duplicate my blinkenlights, I don't see that you tried a speed test from Home, for example, to see if Apartment blinked along. If it didn't, that would implicate my router (though the root cause still would be the SG108e, as I understand).

    I am in the US at an also underdeveloped location. HA.
    Last edited by pleased; 01-05-2017 at 15:32.

  11. #26
    Yes, tomw. Last night I made the router port's PVID=2 so I could isolate some connected ports to see if they would stop blinking. They did.

  12. #27
    Quote Originally Posted by tomw View Post
    You can't remove ports from vlan1, so anything coming in on vlan1 will go out on all ports, regardless of all other settings. If your modem is on port 1, having pvid 1, all that traffic will always go out on all ports. To avoid this you should not use vlan 1, meaning no pvid=1 on any port.
    Yes, that's right. In my regular network setup I don't use PVID=1 at all. For the test I just waned to be as near as possible to pleased's setup.

    Quote Originally Posted by pleased View Post
    Nice. However, I don't understand why you can see the ARP flood in the first test but not the second so I'm not sure what difference I'm seeing. You are doing the ARP flood from a machine on the Apartment VLAN while the Wireshark monitor is on the Home VLAN (or vice-versa)?
    No, I connected port 1 to my local network and used a more or less fast server to generate the broadcasts. Cocoa Packet Analyzer did run in the Home VLAN for some tests and for comparison/screenies in the Apartment VLAN. Since I have no cable modem, it's not a real WAN I connected the switch to, but my small office network with several servers I can use to simulate incoming traffic on port 1.

    I couldn't see the ARP flood in my second test, because with a trunk ports the Home and Apartment are different subnets and therefore different broadcast domains - what is the main reason VLANs have been invented for.

    I suppose I could flash the router I have to DD-WRT (haven't checked other options) and set up your "classic" VLANs. OTOH, maybe new firmware would fix my blinkenlights problem.
    I would recommend to find out what causes the massive traffic and then try to resolve the problem at the root of the cause. Only if the switch itself causes additional broadcast traffic not coming in to port 1 from somewhere or being forwarded from remaining ports, the switch's software deserves to be fixed.

    If the packet "crossing VLANs" and sent to the router is triggering broadcasts, how could that come from the cable modem or cable network? The router is doing NAT and I don't understand why it would incite that response.
    So, do you have a cable modem or a router before the cable modem? That can make a big difference depending on the ISP's setup. Back in time where I had a direct leased line into the CIX, we had to take measures to isolate my local network at the ISP, not at my office. But I'm no longer in ISP business, don't know what they do today.

    Back to your trying to duplicate my blinkenlights, I don't see that you tried a speed test from Home, for example, to see if Apartment blinked along. If it didn't, that would implicate my router (though the root cause still would be the SG108e, as I understand).
    Of course, yes. The laptop I did run the speed tests and the analyzer on was connected to the Apartment VLAN and I got blinkenlights just as you described in your first post, synchronously on all ports. It's no wonder - since it is a common broadcast domain.

    To summarize:

    Splitting up broadcast domains into smaller ones and feeding traffic for several logically separated subnets over one cable are the main reasons to use VLANs at all, client isolation is another one. Therefore I really wondered what advantage it has to use only a single subnet over several VLANs other than to have a common uplink and to isolate clients, but at the expense of having duplicate broadcast traffic coming in on the uplink port.
    Last edited by R1D2; 01-05-2017 at 18:03.

  13. #28
    Ah, but if you were generating ARP packets without VLAN tags, then wouldn't the SG108e broadcast them on all remaining ports, even though the port 1 uplink is tagged?

    I would recommend to find out what causes the massive traffic and then try to resolve the problem at the root of the cause.
    I am in communication with TP-Link "engineering". At their request, I have tried another (cheap) router and the same problem occurs - packets "crossing VLANs" cause all connected ports on the primary VLAN of the router port to flash.

    Internet bound packets go though SG108e, then (cheap) router, then cable modem, then ... As I understand the router isolates my LAN so that any IP packets outbound should only incite IP packets inbound on my LAN. So ... may there be a broadcast coming through my router (issued from beyond my router) in response to an outbound packet "crossing VLANs"?

    It's no wonder - since it is a common broadcast domain.
    You mean, the ARP flooding is to be expected to cause blinkenlights. However, did you determine if the speed test alone, without ARP flooding, caused blinkenlights? Is your "stone-age speed of 12 Mbit/s downstream" through a modem/router? I.e.. blinkenlights on speed test alone means it's not just my (cheap) router at fault.

    what advantage [...] to use only a single subnet over several VLANs [...] at the expense of having duplicate broadcast traffic coming in on the uplink port
    Well, the containing net has to communicate with them somehow, so some broadcasts are required (unless you would manually configure the routing tables!)

  14. #29
    Not so pleased. I installed Wireshark and viewed the traffic on an "Apartment" port. It appears that when the destination of a packet coming from the router port is on a port whose PVID matches the router port's, the packet is sent out that port only. Otherwise, the packet is broadcast to all ports on the router port's primary VLAN. Thus my blinkenlights.

  15. #30
    Quote Originally Posted by pleased View Post
    Ah, but if you were generating ARP packets without VLAN tags, then wouldn't the SG108e broadcast them on all remaining ports, even though the port 1 uplink is tagged?
    Yes. Usually on cheap SOHO switches there is a fixed default VLAN which can't be changed or turned off. It's a real mess if you ask me, since we have more than 1,000 WiFi routers in the field, which use VLAN 1 as the WAN on routers with only a single built-in switch such as the TL-WDR4300 (it's the default VLAN for WAN ports in OpenWRT and most of its clones). But this VLAN 1 is a "normal" VLAN as any other and it can be disabled or used for anything else. Likewise untagged packets can be assigned to any other VLAN. In my opinion this is how things should be according to the standard in 802.1Q. TP-Link's way to assign a fixed VLAN as default VLAN all ports are always members of will make problems connecting TL-SG108E or even EAP WiFi APs with VLANs to our WiFi routers without re-configuration, that's why I don't like this idea of a fixed default VLAN 1.

    Bigger switches have a non-fixed default VLAN and it can be disabled as well as ports being removed from it. Also, on VLAN trunks (ports using tagged packets) one can define to discard untagged ingress packets instead of accepting them. Furthermore, any router or server can be configured to only send tagged packets and this is what I did. So, every packet coming into the switch always has a VLAN tag, there can be no untagged packets on the trunk port in my setup. Therefore, default PVID=1 is not only unused in such setups, but also unusable, which outweighs the first point.

    BTW: To avoid mis-understandings: In TL-SG108E docs and the web UI up to V2 TP-Link uses the term "Trunk" for Link Aggregation. Starting with V3 docs/web UI they now call it LAG (Link Aggregation Group). LAG has nothing to do with VLAN trunk ports - just to clarify the terms.

    As I understand the router isolates my LAN so that any IP packets outbound should only incite IP packets inbound on my LAN. So ... may there be a broadcast coming through my router (issued from beyond my router) in response to an outbound packet "crossing VLANs"?
    If things have not changed meanwhile (I'm not up-to-date in every aspect), only multicasts should come through, e.g. TV streams over cable, but not regular broadcasts. However, all this depends on setup of the router and ISP policies.

    You mean, the ARP flooding is to be expected to cause blinkenlights.
    ARP flooding was the only way for me to test wether any broadcasts on the uplink port 1 will really cross VLAN borders and therefore light all LEDs. I couldn't imagine that a cheap switch allows this. Most switches I know don't allow a subnet spanning different VLANs - except if PVLANs are supported - and thus always require separate subnets if VLANs are being used. That was what I learned about TL-SG108E - that it allows one subnet spanning different VLANs. It does not mean that ARP flooding is the reason of the effect you are observing at your device, it just is a presumption that some kind of broadcasts are causing the effect. Without ARP flooding I could not observe any unusual LED activity.

    However, did you determine if the speed test alone, without ARP flooding, caused blinkenlights? Is your "stone-age speed of 12 Mbit/s downstream" through a modem/router? I.e.. blinkenlights on speed test alone means it's not just my (cheap) router at fault.
    No, speed test alone from within one of the VLANs did not light up all LEDs, but only LEDs of the ingress/egress ports as it should be. There were some regular broadcasts (ARP, SMB multicast), but in usual (long) intervals only. Yes, I use a router connected to an ADSL modem, not a cable modem.

    Well, the containing net has to communicate with them somehow, so some broadcasts are required (unless you would manually configure the routing tables!)
    That's what a router is for and no, routes do not have to be set up, since most routers establish a default route for LAN devices and forwarding from LAN to WAN automagically, together with standard firewall rules to secure the LAN from outside access.
    Last edited by R1D2; 01-06-2017 at 04:33.


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Copyright 1996-2017 TP-LINK Technologies Co., Ltd. All rights reserved.