Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Results 1 to 6 of 6
  1. #1

    trunk and vlan acces ports are not pinging

    Model :

    Hardware Version :

    Firmware Version :

    ISP : [/COLOR]

    Hey to all


    I am equipped with a 5 port TP-Link smart switch
    Model: TL-SG105E


    MY setup :

    <laptop>----access<TP link switch1>Trunk(p5)----<buffalo router1>-----5GHZ-----<Bufallo router2>---trunk(p5)<TP link switch2>access---cisco routers(4 router each having separate vlans)

    My Buffalo routers are communicating via 5GHz mesh protocol an both are connected to the trunk port of switches
    Both switches: port 1vlan11, port2:vlan12, port3 vlan 21,port4 vlan 22 and port 5 default vlan 1(trunk) (configuration of both switches are the same)
    Cisco routers: 1st router port1 , 2nd one port2, 3rd one port 3 and 4th one port 4


    The thing i am trying to investigate is to transfer vlan taging via mesh protocol . For example I can ping cisco 1 plugged to port 1 of switch2( vlan 11) form my laptop only when its connected to port 1 of the switch1 (without touching the vlaning configuration of bufallo routers).
    (for both switches)is to define 4 seperate vlans on each port (1-4) to which unaware-vlan devices like my pc are connected
    and I want to configure the 5th port as a trunk port which is connected to an AP(Buffalo) operating as a router.


    However this setup only works when the (laptop —> trunk port and bufallo—>access port ) and my laptop can no longer ping Buffalo router when the devices are swapped (laptop --> access port and Buffalo–> trunk which is what I intend to do) . any suggestions?

    I would be grateful if any one shed a light on this whether I am on the right track with trunk or access port configurations.
    Attached Images      

  2. #2
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,638
    Quote Originally Posted by arsham View Post
    For example I can ping cisco 1 plugged to port 1 of switch2( vlan 11) form my laptop only when its connected to port 1 of the switch1 (without touching the vlaning configuration of bufallo routers).

    ...

    However this setup only works when the (laptop —> trunk port and bufallo—>access port )
    Most certainly it's not VLAN 11, but Default_VLAN 1, since VLAN 1 uses only untagged frames in your setting, even on the trunk port (due to its PVID=1, which designates VLAN 1 as the native VLAN, in which all other ports are members of, too). Upgrade to latest (2018) firmware to be able to remove ports from the Default_VLAN. But I can't say wether the Bufallo passes tagged frames over a mesh WiFi.
    Last edited by R1D2; 04-10-2018 at 02:22.

  3. #3
    Quote Originally Posted by R1D2 View Post
    Most certainly it's not VLAN 11, but Default_VLAN 1, since VLAN 1 uses only untagged frames in your setting, even on the trunk port (due to its PVID=1, which designates VLAN 1 as the native VLAN, in which all other ports are members of, too). Upgrade to latest (2018) firmware to be able to remove ports from the Default_VLAN. But I can't say wether the Bufallo passes tagged frames over a mesh WiFi.
    thanks for your response . but I dont get your point what is not VLAN 11? I have updated my formware to the lates one but still the same issue. Hhow I can remove ports from the defualt-VLAN . is my configuration correct?
    Any tiny help from your side would be a huge assist .

  4. #4
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,638
    Quote Originally Posted by arsham View Post
    thanks for your response . but I dont get your point what is not VLAN 11? I have updated my formware to the lates one but still the same issue. Hhow I can remove ports from the defualt-VLAN . is my configuration correct?
    Any tiny help from your side would be a huge assist .
    If you get a connection from a trunk port to an access port, but not vice versa, it's almost certainly the famous and well-known VLAN 1 problem of those switches.

    The problem is that all ports are by default always untagged members of Default_VLAN 1. For access ports, untagged frames will get tagged by the switch on ingress using its PVID and untagged on egress. Problem with the Default_VLAN: even access ports are members of two VLANs: the one the port is assigned to as a member (say, 11, PVID 11) and the Default_VLAN 1. Therefore, even frames with VID 1 will be forwarded to any port on egress and the tag will be stripped.

    However, on trunk ports the behavior is different: tagged frames on ingress are forwarded unchanged. Untagged frames on ingress will get tagged with the primary VLAN, defined in the trunk's Primary VLAN ID (PVID). But if a frame with a tag equal to the trunk's Primary VLAN will be forwarded by the switch to the trunk port for egress, its VLAN tag will also be stripped on egress, since the trunk port is an untagged member of the Default_VLAN, which is the same as the Primary VLAN if PVID=1. This Default_VLAN is also sometimes called native VLAN and it exist to ensure that even untagged frames arriving on a trunk port will get forwarded. Nothing bad, but it often causes much confusion, especially if ports cannot be removed from such a native/default VLAN.

    In other words: all access and trunk ports are sharing the Default_VLAN 1 as the VLAN for untagged traffic arriving on trunk ports whose PVID is 1.

    If you upgraded the firmware to the latest one (December 2017, published in January 2018), you can remove ports from the Default_VLAN using the web UI of the switch (not the EZ Config Utility!). This way, no untagged frames arriving on the trunk port will be forwarded to other access ports anymore. But wether your Buffalo sends untagged frames, which then will end up in the trunk's Primary VLAN is something you still have to test. Anyway, we did fight hard for nearly one year with TP-Link to get this firmware update for Easy Smart switches finally, so try this step to see wether the effects you described will disappear.

    As for VLAN passing over WiFi links:
    Usually, WiFi routers pass VLAN tags over WiFi, at least if operating as bridges. But some WiFi adapters are well known to strip VLAN tags before encapsulating Ethernet frames in WiFi frames to avoid problems with the MTU. I never tested VLAN passing with Buffalos, so you have to find out for yourself.
    Last edited by R1D2; 04-13-2018 at 23:58.

  5. #5
    Quote Originally Posted by R1D2 View Post
    If you get a connection from a trunk port to an access port, but not vice versa, it's almost certainly the famous and well-known VLAN 1 problem of those switches.

    The problem is that all ports are by default always untagged members of Default_VLAN 1. For access ports, untagged frames will get tagged by the switch on ingress using its PVID and untagged on egress. Problem with the Default_VLAN: even access ports are members of two VLANs: the one the port is assigned to as a member (say, 11, PVID 11) and the Default_VLAN 1. Therefore, even frames with VID 1 will be forwarded to any port on egress and the tag will be stripped.

    However, on trunk ports the behavior is different: tagged frames on ingress are forwarded unchanged. Untagged frames on ingress will get tagged with the primary VLAN, defined in the trunk's Primary VLAN ID (PVID). But if a frame with a tag equal to the trunk's Primary VLAN will be forwarded by the switch to the trunk port for egress, its VLAN tag will also be stripped on egress, since the trunk port is an untagged member of the Default_VLAN, which is the same as the Primary VLAN if PVID=1. This Default_VLAN is also sometimes called native VLAN and it exist to ensure that even untagged frames arriving on a trunk port will get forwarded. Nothing bad, but it often causes much confusion, especially if ports cannot be removed from such a native/default VLAN.

    In other words: all access and trunk ports are sharing the Default_VLAN 1 as the VLAN for untagged traffic arriving on trunk ports whose PVID is 1.

    If you upgraded the firmware to the latest one (December 2017, published in January 2018), you can remove ports from the Default_VLAN using the web UI of the switch (not the EZ Config Utility!). This way, no untagged frames arriving on the trunk port will be forwarded to other access ports anymore. But wether your Buffalo sends untagged frames, which then will end up in the trunk's Primary VLAN is something you still have to test. Anyway, we did fight hard for nearly one year with TP-Link to get this firmware update for Easy Smart switches finally, so try this step to see wether the effects you described will disappear.

    As for VLAN passing over WiFi links:
    Usually, WiFi routers pass VLAN tags over WiFi, at least if operating as bridges. But some WiFi adapters are well known to strip VLAN tags before encapsulating Ethernet frames in WiFi frames to avoid problems with the MTU. I never tested VLAN passing with Buffalos, so you have to find out for yourself.
    Bunch of thanks my friend for your crystal clear explanation, I could remove the native VLAN 1 from the access ports only by using "Easy Smart Configuration Utility" as you suggested, however still dealing with the same issue. following is my new VLAN configuration.

    VLAN ID VLAN Name Member Ports Tagged Ports Untagged Ports Delete
    1 Default 2-5 5 2-4
    11 Cisco1 1,5 5 1
    12 Cisco2 2,5 5 2
    21 Cisco3 3,5 5 3
    22 Cisco4 4-5 5 4

  6. #6
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,638
    Hm, in this config ports 2-4 are still in the default VLAN (Member Ports, Untagged). Remove them from VLAN 1.

    Only port 5 should be member of all VLANs as a Tagged Port, all other ports should be only in one VLAN (11,12,21,22) as Untagged Ports. Also make sure to set their PVID to the corresponding VLAN.


 

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-2018 TP-LINK Technologies Co., Ltd. All rights reserved.