<
Switches
New To T1600G-28TS, need a little guidance
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
New To T1600G-28TS, need a little guidance
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
2018-01-22 13:20:25
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
New To T1600G-28TS, need a little guidance
2018-01-22 13:20:25
Tags:
Model :
Hardware Version :
Firmware Version :
ISP :
Hey All,
I'm a bit new here, as well as to the TP-Link series Smart Switches. I recently acquired 2 shiny new T1600G-28TS switches for my home network. These switches are my core switches, with a few Dlink 8-port desktop switches spread around the house for different "sub-nets". In setting up my T1600G's I have the following VLANs:
VLAN 1: General Data; 1 primary DHCP server and 1 backup DHCP server;
VLAN 10: IP Phone Intercom; 1 DHCP server provided by Dlink router (for inter-VLAN routing to VLAN 1);
VLAN 100: IPTV; 1 DHCP server provided by Telus T3200M router.
So far, most of the setup is working well. 3 of the sub-switches are DLink DGS-1100-08 desktop units, with VLANs 1 and 10 configured. All that works really well. All well and good.
Now, my issue is with the DHCP setups:
On VLAN 1 the primary DHCP is a linux box. The secondary DHCP is a Windows XP box, and is only activated when the primary is offline (power outage or maintenance, etc). On the old Dlink core switch, this was not an issue. Down the primary, start the secondary, reboot all DHCP clients, and we're off to the races. Now, however, the secondary DHCP OFFER packets are not getting back to the requesting clients. I can see the server responding to the DHCP request, but the client never receives the response. Again, the primary DHCP works fine. The secondary does not.
On VLAN 10, the DHCP is provided by an older DLink broadband router. Clients connecting directly to the router have no issue getting a DHCP lease. But through the T1600G's, forget it. This router does not supply any indication of an active lease until it becomes active. So, for the moment, all devices on VLAN 10 must be either connected directly to the router, or have static IP's to operate properly. Not desirable.
On VLAN 100, the DHCP comes from the Telus T3200M. All good here.
So, what gives? Why on VLAN 1 only the primary DHCP can do its job, and on VLAN 10, no DHCP is available? I don't have any blocking setup anywhere, in any form, especially since VLAN 100 works as well. Or are the switches determining which ports have DHCP servers hanging off them, and assuming those ports are to be the ONLY DHCP ports?:confused:
Hopefully, someone might have some insight on this one.
Cheers!
Mike
Hardware Version :
Firmware Version :
ISP :
Hey All,
I'm a bit new here, as well as to the TP-Link series Smart Switches. I recently acquired 2 shiny new T1600G-28TS switches for my home network. These switches are my core switches, with a few Dlink 8-port desktop switches spread around the house for different "sub-nets". In setting up my T1600G's I have the following VLANs:
VLAN 1: General Data; 1 primary DHCP server and 1 backup DHCP server;
VLAN 10: IP Phone Intercom; 1 DHCP server provided by Dlink router (for inter-VLAN routing to VLAN 1);
VLAN 100: IPTV; 1 DHCP server provided by Telus T3200M router.
So far, most of the setup is working well. 3 of the sub-switches are DLink DGS-1100-08 desktop units, with VLANs 1 and 10 configured. All that works really well. All well and good.
Now, my issue is with the DHCP setups:
On VLAN 1 the primary DHCP is a linux box. The secondary DHCP is a Windows XP box, and is only activated when the primary is offline (power outage or maintenance, etc). On the old Dlink core switch, this was not an issue. Down the primary, start the secondary, reboot all DHCP clients, and we're off to the races. Now, however, the secondary DHCP OFFER packets are not getting back to the requesting clients. I can see the server responding to the DHCP request, but the client never receives the response. Again, the primary DHCP works fine. The secondary does not.
On VLAN 10, the DHCP is provided by an older DLink broadband router. Clients connecting directly to the router have no issue getting a DHCP lease. But through the T1600G's, forget it. This router does not supply any indication of an active lease until it becomes active. So, for the moment, all devices on VLAN 10 must be either connected directly to the router, or have static IP's to operate properly. Not desirable.
On VLAN 100, the DHCP comes from the Telus T3200M. All good here.
So, what gives? Why on VLAN 1 only the primary DHCP can do its job, and on VLAN 10, no DHCP is available? I don't have any blocking setup anywhere, in any form, especially since VLAN 100 works as well. Or are the switches determining which ports have DHCP servers hanging off them, and assuming those ports are to be the ONLY DHCP ports?:confused:
Hopefully, someone might have some insight on this one.
Cheers!
Mike
#1
Options
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Thread Manage
Announcement Manage
9 Reply
Posts: 247
Helpful: 40
Solutions: 1
Stories: 0
Registered: 2018-07-19
Re:New To T1600G-28TS, need a little guidance
2018-01-22 19:05:59
I suggest you read the faq in tp-link website firstly, and check PVID and VID value of different vlans.
If you want, you can upload your topology and configuration of vlan also. Maybe we can find the rason.
If you want, you can upload your topology and configuration of vlan also. Maybe we can find the rason.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#2
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
Re:New To T1600G-28TS, need a little guidance
2018-01-24 12:57:35
TPTHZ, was I not clear enough in my written description of my VLAN setup and issues?:( I've spent quite a few hours using Mr. Google to attempt to locate a solution, but either this hasn't been encountered before, or I'm not using the correct search terms. I've even scoured the FAQs on the website, hoping something might stand up and bite. No such luck.
Given that all the DHCP servers are hanging off untagged ports in their respective VLANs, I would think that PVID values shouldn't matter. And that PVID values really only come into play for tagged ports, and LACP connections. I could be in error on that; this is a learning process for me. And come to think of it, I didn't set PVIDs for each VLAN, other than certain ports. I might check that on the weekend. The biggie here is that the working servers are on different switches. Which is why I am being led to believe each switch is, on its own, tagging the ports the servers are connected to and saying that only those ports are the DHCP server ports. Odd, yes, but that is what it appears to be.
I am also configuring solely through the web interface. Is there something needing to be done that maybe a console interface will be required?
At any rate, I am away from home until the weekend. While I have VPN access to the network, I cannot access the switch interfaces over the VPN link. Not sure why, as I can access other equipment fine. Once I get home I can gin up a JPG of the topology and do a print-out of the switch configs, if you like. Of course, my primary server is getting long in the tooth, so I may just turn its DHCP/DNS/NTP functions off, and teach a Raspberry Pi2 VLANs and how to be a DHCP/DNS/NTP server. :o
Cheers!
Mike
Given that all the DHCP servers are hanging off untagged ports in their respective VLANs, I would think that PVID values shouldn't matter. And that PVID values really only come into play for tagged ports, and LACP connections. I could be in error on that; this is a learning process for me. And come to think of it, I didn't set PVIDs for each VLAN, other than certain ports. I might check that on the weekend. The biggie here is that the working servers are on different switches. Which is why I am being led to believe each switch is, on its own, tagging the ports the servers are connected to and saying that only those ports are the DHCP server ports. Odd, yes, but that is what it appears to be.
I am also configuring solely through the web interface. Is there something needing to be done that maybe a console interface will be required?
At any rate, I am away from home until the weekend. While I have VPN access to the network, I cannot access the switch interfaces over the VPN link. Not sure why, as I can access other equipment fine. Once I get home I can gin up a JPG of the topology and do a print-out of the switch configs, if you like. Of course, my primary server is getting long in the tooth, so I may just turn its DHCP/DNS/NTP functions off, and teach a Raspberry Pi2 VLANs and how to be a DHCP/DNS/NTP server. :o
Cheers!
Mike
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#3
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 247
Helpful: 40
Solutions: 1
Stories: 0
Registered: 2018-07-19
Re:New To T1600G-28TS, need a little guidance
2018-01-26 15:59:36
ve7prt wrote
TPTHZ, was I not clear enough in my written description of my VLAN setup and issues?:( I've spent quite a few hours using Mr. Google to attempt to locate a solution, but either this hasn't been encountered before, or I'm not using the correct search terms. I've even scoured the FAQs on the website, hoping something might stand up and bite. No such luck.
Given that all the DHCP servers are hanging off untagged ports in their respective VLANs, I would think that PVID values shouldn't matter. And that PVID values really only come into play for tagged ports, and LACP connections. I could be in error on that; this is a learning process for me. And come to think of it, I didn't set PVIDs for each VLAN, other than certain ports. I might check that on the weekend. The biggie here is that the working servers are on different switches. Which is why I am being led to believe each switch is, on its own, tagging the ports the servers are connected to and saying that only those ports are the DHCP server ports. Odd, yes, but that is what it appears to be.
I am also configuring solely through the web interface. Is there something needing to be done that maybe a console interface will be required?
At any rate, I am away from home until the weekend. While I have VPN access to the network, I cannot access the switch interfaces over the VPN link. Not sure why, as I can access other equipment fine. Once I get home I can gin up a JPG of the topology and do a print-out of the switch configs, if you like. Of course, my primary server is getting long in the tooth, so I may just turn its DHCP/DNS/NTP functions off, and teach a Raspberry Pi2 VLANs and how to be a DHCP/DNS/NTP server. :o
Cheers!
Mike
There are two FAQ docuemnt maybe useful for you.
http://www.tp-link.com/en/faq-544.html and http://www.tp-link.com/en/faq-328.html
Your DHCP Server like router(TL-R480T+) in the FAQ
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#4
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
Re:New To T1600G-28TS, need a little guidance
2018-01-27 06:02:00
Yup, my bad. PVID's do matter on the untagged. Well, like I said, it's a learning curve for me. I will be home on Saturday, and my first considered thought on this will be to go through both switches on a port by port basis, and set the PVID's to the appropriate values. If that solves the problems (and, looking at everything from a distant perspective, it just might), then I should be good to go. I'm not going to be overly upset if the secondary DHCP on VLAN1 doesn't work; that will just give me more fuel to replace the primary with a RaspPi.
At any rate, I will post my results when I have completed the port by port sweep of both switches.
Cheers!
Mike
At any rate, I will post my results when I have completed the port by port sweep of both switches.
Cheers!
Mike
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#5
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 4334
Helpful: 1039
Solutions: 173
Stories: 3
Registered: 2015-12-05
Re:New To T1600G-28TS, need a little guidance
2018-01-27 08:21:53
ve7prt wrote
PVID's do matter on the untagged.
PVIDs also do matter on trunk (tagged) ports: since PVID is the Primary VLAN ID a port belongs to (no matter wether it is tagged or untagged), every Ethernet frame carrying the PVID forwarded to a trunk port will be untagged on egress. Also, untagged Ethernet frames on ingress will be assigned the PVID even if the port is a trunk port (this is to honor the so-called native VLAN). IIRC, the T1600G allows more specific settings regarding this behavior for the primary VLAN designated by the PVID of a trunk port. See https://supportforums.cisco.com/t5/lan-switching-and-routing/why-native-vlan-exists-on-a-trunk/td-p/1363872 for further info of the native VLAN handling using PVID on a trunk port.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#6
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
Re:New To T1600G-28TS, need a little guidance
2018-01-28 07:22:50
So an update. I was able to access the switches when I got home today. First thing I noticed was that ports 21 and 22 on both switches were members of VLAN 1, as well as the respective VLANs they link. Oops, that might explain why a client on 1 switch can't find the DHCP server on the other switch! As for the PVIDs, it appears that I
have set the proper PVIDs for each port, except the "trunk" ports, which can only have 1 PVID, which I left at 1 for all of them. So, now for the brain burner (and you'll really love this!):
For wired connections using my laptop, I can plug into any jack designated to any VLAN on either switch or sub-switch (Dlink DGS-1100-08), and I will get the appropriately assigned IP address from the DHCP server for that VLAN, even if the DHCP server is on the other switch. All well and good.
Now, for wireless, this isn't quite the case. My WAP is a TP-Link TL-WA901ND, which is multi-SSID/VLAN capable. I have all 4 SSID's going, each one assigned to the appropriate VLAN, and the 4th assigned to a VLAN I don't use. Now, for connecting, this is what I get:
SSID #1/VLAN 1: 192.168.2.X, which is correct.
SSID #2/VLAN 10: NO IP ASSIGNED!!!!! It should be 192.168.3.X for the IP Phone system.
SSID #3/CLAN 100: 192.168.1.X, which is correct.
So, for some goofy reason, SSID #2/VLAN 10 cannot find the DHCP server. Yes, the port the WAP is connected to is a tagged member of all 3 VLANs. VLAN's 1 and 100 work fine, and IPs assigned by the appropriate server. Yes, the VLAN 10 server is assigning IPs if I connect to a member port of VLAN 10 (untagged) on any switch. But, for whatever reason, the VLAN 10 DHCP server appears invisible through the WAP. Weird.:confused:
Cheers!
Mike
For wired connections using my laptop, I can plug into any jack designated to any VLAN on either switch or sub-switch (Dlink DGS-1100-08), and I will get the appropriately assigned IP address from the DHCP server for that VLAN, even if the DHCP server is on the other switch. All well and good.
Now, for wireless, this isn't quite the case. My WAP is a TP-Link TL-WA901ND, which is multi-SSID/VLAN capable. I have all 4 SSID's going, each one assigned to the appropriate VLAN, and the 4th assigned to a VLAN I don't use. Now, for connecting, this is what I get:
SSID #1/VLAN 1: 192.168.2.X, which is correct.
SSID #2/VLAN 10: NO IP ASSIGNED!!!!! It should be 192.168.3.X for the IP Phone system.
SSID #3/CLAN 100: 192.168.1.X, which is correct.
So, for some goofy reason, SSID #2/VLAN 10 cannot find the DHCP server. Yes, the port the WAP is connected to is a tagged member of all 3 VLANs. VLAN's 1 and 100 work fine, and IPs assigned by the appropriate server. Yes, the VLAN 10 server is assigning IPs if I connect to a member port of VLAN 10 (untagged) on any switch. But, for whatever reason, the VLAN 10 DHCP server appears invisible through the WAP. Weird.:confused:
Cheers!
Mike
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#7
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
Re:New To T1600G-28TS, need a little guidance
2018-01-28 07:31:05
R1D2 wrote
PVIDs also do matter on trunk (tagged) ports: since PVID is the Primary VLAN ID a port belongs to (no matter wether it is tagged or untagged), every Ethernet frame carrying the PVID forwarded to a trunk port will be untagged on egress. Also, untagged Ethernet frames on ingress will be assigned the PVID even if the port is a trunk port (this is to honor the so-called native VLAN). IIRC, the T1600G allows more specific settings regarding this behavior for the primary VLAN designated by the PVID of a trunk port. See https://supportforums.cisco.com/t5/lan-switching-and-routing/why-native-vlan-exists-on-a-trunk/td-p/1363872 for further info of the native VLAN handling using PVID on a trunk port.
Except that on my switches, I can only assign 1 PVID on a tagged (trunk) port. At any rate, I left all the "trunk" ports as PVID 1, yet the VLAN traffic is flowing as it should. I guess because the PVID value is used to tag the packets on untagged ports so that switch(es) know(s) what VLAN those packets belong to, especially for routing between switches. Am I close?
Mike
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#8
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 4334
Helpful: 1039
Solutions: 173
Stories: 3
Registered: 2015-12-05
Re:New To T1600G-28TS, need a little guidance
2018-01-28 18:30:00
ve7prt wrote
Except that on my switches, I can only assign 1 PVID on a tagged (trunk) port. At any rate, I left all the "trunk" ports as PVID 1, yet the VLAN traffic is flowing as it should. I guess because the PVID value is used to tag the packets on untagged ports so that switch(es) know(s) what VLAN those packets belong to, especially for routing between switches. Am I close?
Yes, PVID is needed to assign untagged Ethernet frames (not packets) to the Primary VLAN. Every port (be it an untagged or a tagged port) has exactly one Primary VLAN. You can think of Primary VLAN being a default VLAN for a port. If such a port is member of more than one VLAN, it becomes a trunk port.
Since there can be only one Primary VLAN per port, there needs to be just one PVID parameter per port, no matter wether it's a so-called "access" or "trunk" port (802.1Q doesn't differentiate between "access" and "trunk" ports, it even does not use those terms at all). It doesn't matter which VLAN ID you assign as a trunk port's Primary VLAN, but it is important to use the same Primary VLAN for all trunk ports of all switches in a network.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#9
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
Re:New To T1600G-28TS, need a little guidance
2018-01-29 04:15:56
So, it looks like I have managed, for the most part, to get everything working the way it should. I am not going to worrying about the secondary DHCP on VLAN1 as the primary DHCP server is slated for replacement, and I am considering a Raspberry Pi to take on DHCP, DNS, and NTP services on VLAN1. The email and file share services will be a new computer. I already have a RaspPi driving a radio/TNC setup for my APRS digi-gate and i-gate. I will simply configure the appropriate servers on it and point everyone that direction.
As for the VLAN 10 DHCP server not accessible via the wireless, I am not concerned with that either. That is mostly for convenience for the laptop if I need to log into that VLAN and update the SIP server by CLI. I could simply set up a VPN connection on the Dlink inter-VLAN router, and do it that way.
So, I'd like to pass to everyone who replied my thanks for getting me pointed properly. This has certainly been a learning curve!
Cheers! And Thanks Again!
Mike Shepherd
http://www.ve7prt.bc.ca
As for the VLAN 10 DHCP server not accessible via the wireless, I am not concerned with that either. That is mostly for convenience for the laptop if I need to log into that VLAN and update the SIP server by CLI. I could simply set up a VPN connection on the Dlink inter-VLAN router, and do it that way.
So, I'd like to pass to everyone who replied my thanks for getting me pointed properly. This has certainly been a learning curve!
Cheers! And Thanks Again!
Mike Shepherd
http://www.ve7prt.bc.ca
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#10
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
2018-01-22 13:20:25
Posts: 6
Helpful: 0
Solutions: 0
Stories: 0
Registered: 2018-01-22
Information
Helpful: 0
Views: 2265
Replies: 9
Voters 0
No one has voted for it yet.
Tags
Related Articles
VLAN T1600G-28TS
5369
0
Resetting T1600G-28TS
436
0
T1600g-28ts vlan
729
0
T1600G-28TS and IGMPproxy
1118
0
Report Inappropriate Content
Transfer Module
New message