I will give it a shot, but there is one device (Xbox #2) attached to the switch that I want to replace that will need to send untagged traffic. I only have one wire run from my living room to my office / network room / Christmas decoration storage area.
Basically, I think the “lack of a trunk that allows untagged traffic on the Balance 30” will be a showstopper. If it wasn’t for the “UPnP only works on LAN issue when creating port forwards” and the “UPnP discovery won’t work because of TTL from device is set to 1” issue - I wouldn’t need to have anything on the actual LAN IP space. The biggest advantage to VLans is keeping worthless chatter from flooding the broadcast domain - because it allows some sort of management point to block superfluous traffic. Many “Plug and Play” implementations on my consumer electronics leaves a lot to be desired.
At least with my Peplink stuff, I have a greater than a “snowballs chance in hell” at getting my network exactly how I want it without buying enterprise level hardware and running anymore wires under my house. The three that are down there were fun enough to run. Too many spiders and other crawly things. I feel that I am only a few firmware releases away from having these things addressed.
Here is my “wishlist” (all of which have been mentioned and are being discussed"
PnP port forwards from devices on VLan - if the VLan default gateway is the same device as the WAN gateway, fulfill the request. It should be easily accomplished by binding to the IPv4.Any address and setting some “under the hood firewall rules” if someone wishes to disable PNP on a specific VLan. You could move PNP enable option to the VLan/LAN configurations. My other option is to hope that Microsoft changes the TTL of their request (most likely not going to happen)
Custom trunk with ability to add “untagged” to the list on the Balance 30. I truly hope that this was just an oversight (which is totally understandable). If it was a “business” decision - that stinks - but, I am sure that I will survive. It is a potential show stopper to turning the power on another device. Poor router just sits under my desk. “Won’t you help?” (Picture a cute dog in a cage when you read that last bit)
UPnP Discovery across VLans even when the TTL is set to 1 by the sender. This one will take some clever engineering. I think the engineers are up for the challenge. If they got a bonjour service forwarder to work, this should be a breeze by comparison. I think it would be best/most easily solved by creating internal bridges for multicast addresses that the router is privy to. Again, a enable/disable option on the LAN/VLan could work for something like “join to LAN multicast groups”. If an app or device designer refuses to respond to packets that originate outside of their “LAN” - there is nothing that Peplink can do about that, but the entire notion of LAN has changed (which ssdp thought of) - but some app developers forgot the part where the TTL is supposed to be configurable per client or service. Since they broke the rules (IMO), I feel it is OK to “break standard” networking principles - as long as the network admin can configure it (at least enable/disable the feature and/or create firewall rules to manage it). There could also be an option to “forward multicast to WAN” option - just for those of us with multiple devices around that could use a WAN to LAN connection (or mesh) to provide multiple paths to multiple WANs without losing the ability to set up port forwarders and discover secondary monitors, etc.
This got more long winded than planned. If you are still reading - you are awesome and you deserve a cookie. I just really want to use my second router in my network, but I keep getting so close only to find that there is one more little problem that just bugs me to no end. Yes, I agree that I am very nit-picky, but I know what I want and I know the reasons why I can’t have it. I am just hopeful that my Peplink products will get me to where I want to be. Networking stuff is cool