The new "enterprise" switches

@TK_Liew , @sitloongs, @Keith , @Alex
My understanding from what was discussed at the last confrence was that the web gui would be limited in favor of incontrol2 development, but that the switch would support local cli config.

I also would cancel my pending orders if there is no local config options.
I don’t want the switches to become another Meraki switch nightmare.

4 Likes

Team, I’m looking into the details and preparing a response. More to come soon.

Keith

2 Likes

Hello everyone,

Background
I want to begin by giving you some background on the launch of the new Switches. As many of you know, the previous Switch product line faced significant challenges due to ongoing component shortages and extended lead times. It had come to a point we decided to transition to a completely new and different HW solution together with shiny new capabilities 2.5G ports, 10G ports and POE++ (upcoming). This was a substantial engineering effort, taking us over a year to launch the new Switch series.

Not a “Cloud Switch”
Let me clarify that this is not a “Cloud Switch”. During development, we have to make priorities on the management UIs. 1st is given to InControl2, 2nd to API/CLI, 3rd Local WebUI. We figured IC2 is likely the most important UI for this new Series. Other UIs are being developed and will be launched in the future (timeline to be communicated).

We want to emphasize that Peplink will never lock customers into a subscription-only business model. Therefore, we are pleased to announce that for all customers who purchase the New Switches (SKU PLS-) will receive lifetime free IC2 management for these devices. (Offer is subject to change in future.)

Addressing Stability Issues
As product issues/bugs are reported, we are working to address them. Peplink’s reputation is built on delivering trusted, stable, and high-quality products at affordable prices, and we are committed to meeting these expectations.

Thanks to Chris and others who have offered to replicate and assist us in addressing those issues. Our team will reach out soon. We will also expand the beta program for those interested.

Our sincere apologies for falling short with the initial launch. We are committed to working hard to restore the stable and reliable Switch products that you have come to love.

Sincerely,
Keith

7 Likes

Keith, thanks for the response and the transparency. You have proven what I already knew about Peplink: Peplink products and the Peplink team/community are awesome.

Again, I truly appreciate this transparency. I understand the SDLC and how it relates to hardware and understand the prioritization that took place, but it means a lot for you to be up front and say the team prioritized IC2.

3 Likes

Thanks @Keith for the quick response clarifying that these are not cloud switches and a local CLI/WebUI management interface will be coming.

I received my first four PLS- switches today and am looking forward to using them for a project in a few months.

3 Likes

@Keith: I join the others in thanking you for your response. However, I wish to reemphasize an important point: No product should ever be exclusively “cloud-based” even if there is no cost associated therewith. In some customers’ environments and applications this must not and cannot happen. IC2 may be a panacea and strategic product for Peplink but it is a “show stopper” for certain customers. Period. (I’d be pleased to elaborate on our security concerns but certain other direct messages to Plover Bay’s management have not been answered, or have not been answered satisfactorily (e.g., "kicking the can down the road,) so one can only assume there are other “issues” that suggest silence on Plover Bay’s part.)

Our access priorities: (1) local config via GUI, (2) local config via CLI, and a very distant (3) maybe IC2.

6 Likes

@Keith Thanks! I’m up for trying some beta switches. I appreciate the full response.
I appreciate the offer of the free IC2 management.
I recommend the offer of free IC2 management for life for the first 90 days of orders for early adopters.
I think most of us are looking forward to be able to locally manage them even via api/cli as soon as possible. I would be happy to lend my time and experience in assisting peplink engineers on this.
Since a switch and configuring vlans can be core to accessing the internet it’s key to be able to manage it locally.

3 Likes

When you said you have concerns and sent to Plover Bay but were not answered. Can you send those to me? [email protected].

Acknowledged that no products should be made exclusively as cloud managed for various reasons.

2 Likes

@Keith thank you again for jumping in and helping get us some answers. I will echo @Rick-DC 's access priorities, which look to be shared my most of us: #1 is local/RWA GUI config, #2 is the local CLI, and the absolute least important #3 is IC2 config.

Look, if we wanted cloud-first switches, we have 3 other brands to choose from that we use. We’ve been buying Peplink’s original switches specifically because of the local/RWA config GUI; that was what made them unique and special.

We have a number of orders in for these switches, and may still have to cancel all of them by the end of the week. Have to ask a few hard questions first:

  1. It’s now been emphasized the new models are “not a Cloud Switch”, yet followed by a statement about development being prioritized to InControl2 and the local WebUI last…it’s very conflicting. Can you walk us through the logic on this?
  2. This major design departure wasn’t announced or communicated to partners in any tangible way. If it were communicated early on, we might have been able to head this off. This is coming off the Balance 310 5G’s freezing issues that went on for months without any public acknowledgement or partner communications sent out. What is Peplink doing to improve communication with partners going forward?
  3. I know its “(timeline to be communicated)”, but launching these “not a Cloud Switches” without the local/RWA WebUI included feel like at best launching a very incomplete product. Not worrying about the “other UIs”, we do actually need a timeline for when the local WebUI will be added back to the firmware, so that the switch can be delivered as a complete product on deployment. Can you give us the timeline for just the WebUI?

Don’t get me wrong. We love Peplink products, we buy a ton of them, and I have 5 more devices in the truck to deploy just this week.

We are Peplink partners, please utilize us as such to help direct product development where our clients need it most. And please communicate more and better with us, we don’t like surprises.

6 Likes

Noah, thanks for your honest and constructive feedback.

I understand the frustration this has caused. In practice, we are constantly balancing resources and have to make choices on priorities from time to time.

Customers also have different preferences. I have heard many have appreciated this decision (IC2 first), but we recognize others see the lack of a local UI as a major drawback.

I do agree that we haven’t done a good job of communicating the “limitations” or “changes” in the core feature set. That is an oversight on our part. We should have been upfront and made it clear that these Switches currently only support IC2 management, to set up the right expectations. We should also explain how they differ from the previous generation of Switches.

Moving forward, we recommend customers make purchase decisions of the Switches based on the features available today. We will provide the updates on timelines as soon as possible.

Thank you.

4 Likes

I would love to be a part of the BETA for switches. We just got our first new switch,h and my team is starting to play with it.

I would love to see a 24-port fiber switch and DIN rail-mounted switch options.

2 Likes

Update: Introducing the Switch Controller

The product and engineering teams have been hard at work, and I’m excited to share a new, enhanced approach to local management for our Switches: the Switch Controller.

What is the Switch Controller?
The Switch Controller will be a built-in feature within Peplink routers, designed to manage multiple Switches from a centralized, local interface. It’s similar to the AP Controller that many of you already use for Access Points. Essentially, it acts as a (mini) local IC2, offering robust and offline management capabilities directly on-site.

Why this approach?
The Switch Controller offers several key advantages:

  1. Multi-Switch Management: Seamlessly manage multiple Switches from a single interface. Easy config backups and restores.
  2. Faster Product Rollout: This approach creates a powerful HW abstraction layer, allowing Peplink to develop and release more Switch models faster, with consistent quality and stability.

What does this mean for you?
To use the Switch Controller, customers will need a Peplink router. The upside? You get offline, local management without any reliance on an IC2 subscription. This solution is ideal for those who prefer local control while still benefiting from advanced Peplink features. To clarify, this is an additional management option. Eventually, the new Switch series can be managed via IC2 or the Switch Controller.

What’s next?
We plan to launch the Switch Controller in beta around the end of Feb for x86-based router models (e.g., 380, 580, SDX, etc.). Support for other models will follow (timeline TBD).

We’re confident this approach will deliver the local management flexibility many of you have been asking for, while paving the way for a more scalable and robust Switch ecosystem.

As always, thank you for your feedback and support.

6 Likes

@Keith: This seems like an excellent solution – tightens up the “eco-system” while meeting the requirements of (exclusive) local control. If it works as well as the AP controller does, and the UI is as clean and functional, that’d be excellent as we consider the AP controller to be a real “force multiplier.”

Looking forward to hearing exactly which router models will be enabled and if L3 (like at the other end of a SF tunnel) will be enabled.

Kudos! – and, thanks for getting involved in this. :<) Thanks also to other members of the management team who listen to their customers and the brilliant engineers who will make it happen.

3 Likes

That’s a crazy awesome solution, way to go! Super excited to see it in action.

3 Likes

@Keith Will the 310X and 380X be included in initial rollouts of the switch controller?

1 Like

I’m on board with the switch controller, will need to be supported in smaller models like the b-one , br1 pro 5g ,310 fiber 5g for small branch offices.
We would like to deploy a b one 5g and a 8 port switch as an example.
Today we use a unifi 8 or 24 port switch with our installs, but would love to have it all managed from the b-one or br1 pro5g interface.

2 Likes

The 380X is x86-based, so yes, it will be among the first to have the Switch Controller. 310X will follow afterwards.

1 Like

Switch controller on the routers is mildly interesting, but not sure if it’s really an adequate solution in the long run. A few follow-up questions along that development line:

  1. How does the switch controller on the router help us for sites where we use peplink switches, but are not using a peplink router to control the network?
  2. Are there going to be improvements made to device discovery between switches and routers? We have issues with the AP’s even when there is a peplink router, if the router doesn’t have DHCP enabled. Also if for some reason we update the router IP, we need the switches to be able to seamlessly re-locate the switch controller on the router without having to login to every device and update manually. One or 2 devices is fine, but larger networks add up fast.
  3. When the switch loses connectivity to the router based controller, is there an auto config rollback with a configurable time to rollback if unreachable?
  4. When the switch loses connectivity with the router, is there there a local webUI on the switch to correct the port settings, rollback the config, view the MAC table, cycle PoE, etc basically an onboard emergency toolkit?
  5. Thinking about scenarios where we use peplink switches, but not a peplink router in certain networks, can you add the switch controller to the switches also, so that one of them can act as a “master”? (solves question #1’s problem)
  6. How is controller migration handled? For instance, in any scenario where we swap a peplink router out for a different model, the config files are never compatible. How then do we “export” the switch and AP controller configs so that they can be easily imported into the new device and the existing switches and AP’s will seamlessly reconnect to the new routers controllers with the existing configs?

If any of those questions are unclear, let me know.

Thank you!

3 Likes

Hi Noah,

Thank you for your detailed feedback and thoughtful questions.

With the new Switch Controller, a local Peplink router will indeed be a mandatory requirement. We understand this may not work for every scenario, but given the diverse needs and priorities discussed earlier, this approach strikes the best balance we can achieve at this time.

This is valid and logical, but this would be a significant engineering effort and negate many of the benefits of the HW Abstraction Layer. At this point, we don’t have plans for it but this is noted for future discussions.

For 2-4 & 6: These are excellent design considerations, and were passed to the Product and Engineering teams for their review and reference.

Thank you again for taking the time to share your insights. Your feedback is incredibly valuable in helping us shape our solutions to better meet customer needs.

2 Likes

I’ll reply to this thread because I was one of the people that made comments last week.

I only use Peplink switches alongside x86 Peplink routers so the switch controller option works for me. In my mind something like the switch controller would have been a much larger endeavor than a local cli/webui, but I guess that’s not the case!

Thanks for the switch controller information @Keith

1 Like