TP-LINK Smart Switches anyone?
-
Sorry but I should rectify something.
Elsewhere on this board I posted about my experience with TP-Link switches and the Gb port changing to 100Mbit sometimes.
It appears now that the switch is not at fault, but the Ubuntu drivers for my server's Marvell nic.A few weeks ago there was a kernel update for Ubuntu 14.04.1 and since then the connection to the switch has been stable at Gb speeds.
I hate it when a product gets a bad rap due to issues that are unrelated. So here's the correction.Cheers.
-
TP-Link Smart switches got a firmware update recently, v1.0.4 Build 20140811 Rel.50404(s). Changes:
1. Improved stability of the system;
2. Optimized management of Memory usage."Updating from v1.0.3 to v1.0.4 didn't require a settings restore anymore. Tested on two TL-SG2216 boxes.
-
TL-SL2428 has no updated firmware. December 2013 is the last release.
Perhaps a newer version will be released later.I was wondering, does this switch support IPv6?
As it is a level 2 switch, it should be of no importance to the switch.
But what about the switch IP address itself? I couldn't find anything in the manual and data sheet.Cheers.
-
I agree, but in that case, it's unfair to be disappointed that there's no CLI or webif available for it.
You can use the config software with any JRE enabled system (Pure Java). See info at http://pastebin.com/DwB4uaPR
Hi,
I have checked your howto, It works, but …
On linux, the utility doesn't discover any switch.
I've done some network captures and strace and I found out why.
On linux, to receive broadcast udp packet, the application must bind INADDR_ANY, the TP utility bind the nic IP addr.
To allow discovery works, you must use a nat rule :
iptables -t nat -D PREROUTING -p udp -d 255.255.255.255 --dport 29809 -j DNAT --to <@IP your host>:29809
It would be nice if you add this information in your howto ... -
hey derelic, i have a question which arises from the approach to configure an VLAN on the tp-link easy smart switch 1016de
you wrote here :
@Derelict:…
2. tagged, or trunk port - traffic arriving on the port should be tagged with a configured VLAN else dropped. It's possible to configure a port to accept traffic for any VLAN. Traffic for a configured VLAN on the port is sent out with the VLAN tag intact (tagged). Traffic received for an unconfigured VLAN should be dropped.and the tp-link has the option to set a pvid. what is this for?
i can not set a pvid for unexisiting vlans.
i must chose a port as tagged or untagged to create a vlan.
after that i can set a pvid to that port.
and what for?i assume now, that as i additionaly to the creation of the vlan change the pvid on an port to the same vlan-number on this port, that all (unconfigured?) traffic (or for unconfigured vlans?) is NOT dropped, but instead pushed into that vlan of the pvid-number.
The default pvid number on all ports is 1, which is the undeletable default-vlan for all ports..
my assumtion seems to make sense to me, but i am a real beginner with that vlan..
every help appreciated…(besides this thread is a great pleasure in explaining this new easy-smart switches. ...)thanks for attention,
ozett
-
I would want to tell the switch to drop untagged traffic on my tagged ports. It doesn't look like that's possible with that gear.
That manual page you posted tells you exactly what the PVID is.
-
You could presumably set an unused PVID on the 'trunk' port to effectively drop untagged packets?
Edit: Except that you can't use a PVID for a VLAN that doesn't exist.I've stumbled my way through VLANs on several occasions but I've always come away with the feeling that either the setup is massively more complex than in needs to be or I'm just scratching the surface. I have a feeling it's the latter. ;)
Steve
-
Sorry to jump in here but perhaps someone can clear this up for me. The thing that has always confused me is the PVID setting. I understand what it does but it seems to be a superfluous setting, it's value could be assumed from the other settings. If you mark a port as untagged for a particular VLAN then it should also carry the PVID of that VLAN. Conversely that's the only time it should have that PVID. You wouldn't want untagged packets being tagged with a VLAN ID where a reply was impossible.
I can't see any situation where that sort of asymmetric tagging/untagging would be anything but bad. Am I missing something? :-\Steve
-
No. You're not missing anything.
If that was my gear I would make a throwaway VLAN for every trunk port and set every trunk port's PVID different, effectively dropping untagged frames.
-
as i am struggling with that "easy smart" !!yes/no!!-Switches, all that you mentioned for their pvid settings seems sensible to me.
only one thought about that default pvid/vlan of 1 for this easy-smart-TP-Link-switches: maybe tp-link wants also on every port, which could be a trunk-port, that there is a 'somehow' collector-vlan for 'untagged' packets. So that these not get dropped (over a throwaway vlan) but instead put into this default vlan.
the risk seems to be, that if you have clearly defined vlans for all ports, under circumstances somehow untagged packets from any untagged port with a default pvid is send into this default vlan and are transfered to the other untagged port, wich also still have the default pvid set.
i did not test this, because my tp-links are under fire.. but one should check sometimes, if this theory is correct ?
regards,
ozett -
If you've set the PVID to something other than 1 you shouldn't have an issue. Testing to find out for sure is a good idea though. :)
Steve
-
It all depends on how the manufacturer implements (maybe "presents" is better suited here) the 802.1q standard.
PVID (Port VLAN ID) is a default VLAN id assigned to frames arriving on the port.
In case of a 'trunk', it marks outgoing frames with the appropriate ID (vlan ID) from which vlan it originates on the switch.
For incoming frames, it is the same behavior: the vlan ID -gets stripped but- dictates on which vlan the frame is put (which broadcast domain it shares)Yet, a trunk always continues to support untagged frames as well. To my knowledge, untagged frames don't get dropped, but are placed on the switch'es 'native' vlan. And this is (among others) a reason why one should avoid the default vlan 1 as native vlan.
Hope this makes sense…
-
yop, that makes sense… but one never knows, if tp-link is doing this with the easy smart switches like theory -- if one never wiresharked and checked. i guess...
but for now i found the theory for this strange pvid well explained... thanks...ozett
-
a last post, because i found another default VLAN no 1 on openwrt.
if you change there the untagged to tagged value of an connected lan-port, traffic would go in the easy-smart switch default vlan.
to prevent this, one has to undertake some more steps. as mentioned before unter 'throwaway' vlan. first create a weired nr vlan for discarding all traffic on all used easy-smart-swiches, set all ports untagged to this pvid. than create and only allow vlan-numbers you want to allow. (take care with vmware vswitch, it uses 4095 as vlan-no. for all traffic…) on desired ports...
it took me some days of testing and understanding...
but thanks again for all explantions in this thread here.
ozett
-
Merci de l'info.trop bien etui samsung galaxy tab housse samsung galaxy tab 4
-
It all depends on how the manufacturer implements (maybe "presents" is better suited here) the 802.1q standard.
PVID (Port VLAN ID) is a default VLAN id assigned to frames arriving on the port.
In case of a 'trunk', it marks outgoing frames with the appropriate ID (vlan ID) from which vlan it originates on the switch.
For incoming frames, it is the same behavior: the vlan ID -gets stripped but- dictates on which vlan the frame is put (which broadcast domain it shares)Yet, a trunk always continues to support untagged frames as well. To my knowledge, untagged frames don't get dropped, but are placed on the switch'es 'native' vlan. And this is (among others) a reason why one should avoid the default vlan 1 as native vlan.
Hope this makes sense…
That seems like non-intuitive way to design a switch. My HP just lets me not assign a default VLAN. If no VLAN is assigned and an untagged frame comes in, it just blackholes it. poof. As I would naturally expect. My switch has no notion of a "default/native" VLAN. My desktop's port has a PVID of "none". It has access to all VLANS via tags, but there is no untagged VLAN.
At least in my case, the term "Trunk" is used to indicate if LACP is being used. VLAN wise, all ports are capable of being trucks if you tag all of the VLANs to a port.
Having an automatic "native" VLAN for untagged traffic sounds like a security nightmare.
-
Keep in mind though that the price tag of these switches is very low compared to any HP or other corporate-ready switch series. They're intented for SOHO applications, thus the effort put into developing their software is scaled accordingly.
There are higher-class TP-Link models (L2 and L3), which can be configured almost as easily as an HP.
-
That seems like non-intuitive way to design a switch. My HP just lets me not assign a default VLAN. If no VLAN is assigned and an untagged frame comes in, it just blackholes it. poof. As I would naturally expect. My switch has no notion of a "default/native" VLAN. My desktop's port has a PVID of "none". It has access to all VLANS via tags, but there is no untagged VLAN.
At least in my case, the term "Trunk" is used to indicate if LACP is being used. VLAN wise, all ports are capable of being trucks if you tag all of the VLANs to a port.
Having an automatic "native" VLAN for untagged traffic sounds like a security nightmare.
Well, newer sw implementations give more possibilities, also concerning the native vlan thing.
Google is your friend in this, just search for "native vlan", it is explained in so many ways there is really no point in repeating that here.
In most books I read, trunk = vlan trunk or dot1q trunk. (http://en.wikipedia.org/wiki/IEEE_802.1Q)
What you refer to, LACP (link aggregation), is called Etherchanneling aka 802.3ad. (http://en.wikipedia.org/wiki/EtherChannel)Though some vendors take different approaches in the terminology, so depending on your real-life experience you might be used to other 'slang' than me….
Now this was a total give-away on how I'm biased ::) (brainwashed)
-
That seems like non-intuitive way to design a switch. My HP just lets me not assign a default VLAN. If no VLAN is assigned and an untagged frame comes in, it just blackholes it. poof. As I would naturally expect. My switch has no notion of a "default/native" VLAN. My desktop's port has a PVID of "none". It has access to all VLANS via tags, but there is no untagged VLAN.
At least in my case, the term "Trunk" is used to indicate if LACP is being used. VLAN wise, all ports are capable of being trucks if you tag all of the VLANs to a port.
Having an automatic "native" VLAN for untagged traffic sounds like a security nightmare.
Well, newer sw implementations give more possibilities, also concerning the native vlan thing.
Google is your friend in this, just search for "native vlan", it is explained in so many ways there is really no point in repeating that here.
In most books I read, trunk = vlan trunk or dot1q trunk. (http://en.wikipedia.org/wiki/IEEE_802.1Q)
What you refer to, LACP (link aggregation), is called Etherchanneling aka 802.3ad. (http://en.wikipedia.org/wiki/EtherChannel)Though some vendors take different approaches in the terminology, so depending on your real-life experience you might be used to other 'slang' than me….
Now this was a total give-away on how I'm biased ::) (brainwashed)
I learned a bit about terms today. "Trunk" seems to have not official definition besides the old usage for an "uplink" port, enabling 803.1Q(Multiple VLAN Registration Protocol) enables "Native VLAN" for many switches, Wiki says that "trunking" is "Link aggregation", but mentions "Cisco use the term Ethernet trunking to mean carrying multiple VLANs through a single network link through the use of a trunking protocol". Kind of funny, because Cisco uses the phrase "trunking protocol", but when you look at 803.1Q, the term "trunking" doesn't even show up expect in reference to Cisco's term.
Even though not official, "trunking" seems to make good sense when talking about VLANs since there are few other things useful for it to mean.
-
Link aggregation is really more like "inverse multiplexing." Trunking where VLAN tags are concerned is more like TDM multiplexing, or "Trunk" lines, to go back to telco terminology.
