DGS-1100-16v2 loses eth1 settings, even after saving
-
Hello,
I am new to Smart Switches, and I have read through the manual for mine, as well as some tutorials online. I've posted this question on D-Link's forums but nobody there has replied. I'm hoping someone here can help
I'm using a D-Link 1100-16v2 switch; the firmware is up-to-date. The switch sits on the IGB1 (LAN) port of my pfSense Router (SG-5100) with three VLANS on one port:
VLAN 0 (no VLAN) - Main LAN
VLAN 10 - Guest Network
VLAN 20 - IoT NetworkThe Guest and IoT network are offered only on Wi-Fi, via Unifi AP/AC Pro units. This configuration is currently working on an older pfSense box which has a built-in Marvel 4-port switch. The newer pfSense box I am now using has no such switch, hence the acquisition of the 1100-16v2.
The problem I am having is with eth1, which is configured as the trunk line that goes back to pfSense. It is configured to have VLAN1 untagged and VLANS 10 & 20 tagged. I have saved the config files as XML (and in the Web GUI before I unplug the switch to move it from my test bench to production).
Every time I unplug it, eth1 reverts to TAGGED for VLAN1, which means it no longer removes the VLAN 1 tag from outbound packets, and pfSense drops those because there is no VLAN 1; net result -- no Main LAN! There are many devices hanging off of the Main Office LAN that do not know about VLANs, so I do not have the option of setting VLAN 1 for the Main Office LAN. FWIW, the Unifi APs also strip VLAN packets off before sending packets out over their radios, and add them back before sending packets back through their ethernet ports to the switch / router.
To test that I'd saved the right config on HTTP backup, I reset eth1/VLAN1 to untagged, Saved in the GUI, exported the config via HTTP and did ran a diff on this new backup vs. the one I made just before unplugging the switch to move it to production. They are identical.
I currently have the config below running my network. My gear is connected to a UPS, so if there is a power glitch, the switch will still be ok. If I have an extended outage, then the config will reset when power comes back, and my network will be down until I take a laptop into the networking closet and reprogram the switch manually.
Here are some images of my configuration, with eth1 set properly:
802.1q VLANs
Management VLAN Setting
I tried setting this to ENABLED for VLAN 1, but that did not work either.VLAN 1 Details
VLAN 10 Details
VLAN 20 Details
QUESTION: What am I doing wrong? Seems like SAVEing the config would persist all eth1 (and other port) settings.
Thanks!
-
The first thing to realise is that the terms used here can be confusing and used differently by different manufacturers.
VLAN 0 and VLAN 1, packets actually tagged as 0 or 1, are not the same as untagged packets but you will find people using those terms interchangeably. (and incorrectly
)VLAN 0 is not a valid VLAN in the 802.1q spec but it can sometimes be found in use by some manufacturers. pfSense will not allow you to use VLAN 0 without considerable workarounds.
VLAN 1 (packets actually tagged 1) should be avoided if at all possible because it is often used as the internal default VLAN in many switches.
https://docs.netgate.com/pfsense/en/latest/vlan/security.html#using-the-default-vlan1I have not used that particular switch but....
The default configuration of the switch should be to act as an unmanaged switch and that's normally every port as untagged in it's default VLAN. Usually 1 internally but it may not expose that to the user.
Have you added VLAN 1 there or was it already present?One issue I'm seeing in the screenshot for the VLAN1 config is that port 1 is configured as a trunk port and that generally means tagged traffic only. Since you are using it for tagged and untagged traffic you probably need to configure it as a hybrid port. That is probably why it's reverting to tagged.
An alternative here is to set the Main LAN interface in pfSense to be on a different VLAN and then use that in the switch instead of VLAN1. Doing that avoids mixing tagged and untagged on the link between pfSense and the switch which is a more secure setup. Far more difficult to make a mistake that puts traffic onto the main LAN.
Steve
-
VLAN 0 and VLAN 1, packets actually tagged as 0 or 1, are not the same as untagged packets but you will find people using those terms interchangeably. (and incorrectly
)Understood. I used VLAN 0 as a way to state that no VLAN is set. If that is inaccurate, my apologies.
VLAN 1 (packets actually tagged 1) should be avoided if at all possible because it is often used as the internal default VLAN in many switches.
True for my switch as well; it is also called PVID (default VLAN) and is the default management VLAN. As you know, leaving it untagged means that VLAN 1 is assigned to the packet on switch ingress, and stripped on switch egress -- exactly the behavior I want.
The default configuration of the switch should be to act as an unmanaged switch and that's normally every port as untagged in it's default VLAN. Usually 1 internally but it may not expose that to the user.
Have you added VLAN 1 there or was it already present?As noted above, VLAN 1 is the default VLAN on this switch -- also called PVID (the VLAN assigned on ingress for internal switch routing). It can be changed, but that is the default. That's why I used it.
One issue I'm seeing in the screenshot for the VLAN1 config is that port 1 is configured as a trunk port and that generally means tagged traffic only. Since you are using it for tagged and untagged traffic you probably need to configure it as a hybrid port. That is probably why it's reverting to tagged.
Umm, if the configuration is not legit for a Trunk (and everything I've read says it is), why would the switch allow me to assign it, but not SAVE it? Quoting from a Cisco article titled, "Fundamentals of 802.1Q VLAN Tagging":
While a link may successfully establish as up with mismatched allowed or native VLAN's, it is best practice to have both sides of the link configured identically. Mismatched native VLAN's or allowed VLAN's can have unforeseen consequences.
In this instance, they are talking about a trunk between two switches. I interpreted this and other examples to mean that untagged traffic on a Trunk port is fine, and the default case for this means that VLAN 1 should be untagged on the Trunk. Have I misconstrued this?
I don't think Hybrid would work. The eth1 port would then look identical to eth9 - eth11, and there would be no clear Level 2 path "out" of the switch to the router. That is what, insofar as I understand, Trunk lines do, essentially tell the Switch - here is the outbound port for this VLAN or these VLANs. I've seen this mixed configuration used in other examples, but I am a newbie at this...
An alternative here is to set the Main LAN interface in pfSense to be on a different VLAN and then use that in the switch instead of VLAN1. Doing that avoids mixing tagged and untagged on the link between pfSense and the switch which is a more secure setup. Far more difficult to make a mistake that puts traffic onto the main LAN.
No joy there. My Unifi AP's need to send untagged and tagged traffic to the switch work with my current pfSense config, and untagged = default network. I am porting a 3100 config (due to a nasty PHP bug in PLus that crashed my 3100 when running pfBlockerNG), so am trying to replicate the functionality of the internal Marvel switch in the 3100. I could try to redo everything to work as you suggest, but would rather avoid that effort IF I can get the switch to work as configured. It would also involved reconfiguring the default network on my Unifi AP's, which is a pain because the Unifi Controller only manages things on the native network (no VLAN).
The fact that my current config does work perfectly for the network (just does not save) leads me to believe that either (a) there is a bug in the switch firmware/GUI, or (b) there is some other configuration setting to be made in concert with this that I do not know of.
Perhaps your Hybrid suggestion for eth1 is that setting, but that does not jibe with all of the information I've read/configuration examples I studied. If nothing else comes up, I'll try it (reluctance stems from needing to sit in the gear closet with an old laptop to fix things if changing eth0 to Hybrid breaks my network, and figuring out how to manage the Unifi APs, which I can do just fine with no VLAN on my main network).
Thanks...!
-
Switch manufacturers use these terms differently. You can't expect a Cisco guide to apply directly to a D-Link switch.
Switches don't route traffic, they use MAC tables to know where to send packets. Setting port 1 as hybrid will probably solve this. Try it.
The Port VLAN ID simply defines what VLAN untagged packets arriving at the port are given. Usually the default VLAN but can be anything. For ports that are untagged on other VLANs it must be set to match or you will have one way traffic. Since you only have VLAN 1 untagged on any port it is correctly set there.You could still use a VLAN for Main LAN. It can be tagged between pfSense and the switch over the trunk but untagged to the APs. That's not a problem, no change required on the APs.
BTW there is now a solution to the PHP issue on arm32:
https://redmine.pfsense.org/issues/11466#note-32You should be able to replicate the Marvel switch config exactly. Note though that the Marvel switch has no concept of trunk/access ports. All ports there are effectively hybrid. The traffic sent is defined only by the member vlans and where there are tagged or untagged. Which seem clearer to me.
Steve
-
@stephenw10 Well I do own being a newbie ...
Thanks for clarifying things around trunks, and Marvel configuration. I've set things as Hybrid on eth1 and traffic still flows. I'll wait until I have a block of time to take the network down, and see if it persists after reboot.
Interesting side effect on this switch of switching to Hybrid on eth1: it also changed VLANs 10 and 11 to Untagged. Easy enough to fix that though.
As for the resolution of 11466 - glad they finally found a work-around. Wish it would've come before I replaced all of my networking hardware... c'est la vie!
Thanks again your help with my switch!
-
@stephenw Reboot successful. All settings preserved, and I learned something about managed switches
-
Ah, nice.
Yeah that is some slightly unexpected behaviour in my opinion. I would not expect the port type to change the member vlans. Especially from tagged to untagged which could be nasty if you didn't notice.
The interesting thing is that you don't need to define the port type when you can set how each VLAN behaves on every port. Often switches will use one or other method for defining the ports but yours appears to have both.
Steve
-
EDIT: that s.b. VLAN ports 10 and
1120 -
@stephenw10 I am going to call D-Link biz support at my leisure to ask them about this. If untagged is ok on a trunk port, then why doesn't it save? If untagged isn't ok, then why does it allow the setting (and work as expected)? My guess is it is a GUI/Save bug. If it was not allowed, then it is unlikely it would have worked, saved or otherwise.
As for changing the tagged ports to untagged -- yeah, I'll try to remember to mention that too.
