2.5 Multigig gigabit switch ports and beyond

Product Discussion Feature Requests
, ,
21

Hi Peplink Team,

I would love a much smaller 2.5 GbE switch w/ POE, to support multiple WiFi-6 access points in RV/boat installations that support traveling gamers and content creators, who have multiple local gaming systems, local NAS, etc. Typical usage scenario would be a MAX Pro router (e.g. BR2 Pro 5G connected to starlink and marina/resort WiFi), with the local LAN containing 2 or more AP One AX. Ideally, I’d be looking for an 8- port PoE switch with all ports at least 2.5 GbE, and preferably with at least 2 multi-gig ports that can do 1/2.5/5/10.

2 Likes
22

Building on the local control issues with the 24 PoE 2.5G Switch. I too use the Balance 310 router switch controller to configure my 24 PoE 2.5G Switch Ports.

Big problem is, if the switch subsequently looses power, or I reboot the Balance 310 Router, the entire switch configuration is lost.

Question, for now, again for local control, what are mitigation strategies to not loose the 24 PoE 2.5G Switch configuration when it or the Balance 310 switch controller reboot?

Alan- Frustrated in Michigan

1 Like
24

@a.alan.blind I see there is a support ticket submitted via a partner today. Let’s follow up on the case with our team on the ticket to resolve the reported issue.

1 Like
25

I need community help. PepWave opened a ticket to investigate my issue as described above. We agreed the issue of loosing the port confirmations for the new line of PepWave Switches, when configured locally with a Balance Router Switch Configuration, occurs only when the Balance Router is rebooted.

PepWave supported wanted me to be their lab for testing and I declined as it is a working business and I cannot take the downtime…and PepWave said they need the data to confirm my issue.

Here is where I need help, can other participants in this community add their own experiences with the local router switch configuration, and how the new style switches respond when the router is rebooted.

Hoping this will help the PepWave engineers to look into this issue, without my business becoming a test bed laboratory.

Alan

1 Like
26

Update

I was away from my home base and lost power. I use PepVPN to maintain a link to my home LAN…and Switch Controller to configure the switches. I cannot afford to maintain the yearly subscription fees for all my switches…so InControl is not an option.

The power outage outlived my UPS and the Balance 310 Router/Switch Controller re-booted when power was restored…but, again, all of the switch configurations returned to factory default. So, no access to my home via the PepVPN until I could travel 600 miles and rebuild the configurations.

A diagnostic report of the failure was sent to PepWave for their engineering efforts.

In the meantime, I have now removed all my pep link switches from the Balance 310 Switch Controller and configured them all locally via the management port…except the new style switches…that do not allow port configuration via the management port. Those have been removed and are sitting on the shelf awaiting PepLink to provide local management port configuration…or to EBay if PepLink remains with their current policy of not allow local management port configuration.

Alan

2 Likes
27

@a.alan.blind understood the challenges you have encountered. And appreciate your patience in working with us by sharing more information (eg. diagnostic reports) with us, as we are eager to identify the root cause of this very strange behavior.

Our team will carefully go through the fault simulation process, and hopefully, we can get to the bottom of it, then report back to you (and update the ticket) of our findings.

2 Likes
28

Update – Root Cause Identified and Mitigation Confirmed

I want to close the loop on this issue and share what I believe is an important finding for anyone using local switch control with a Balance router.

Original Problem:
When using the Balance 310 Switch Controller (local control, not InControl), the 24 PoE 2.5G switch would lose connection with the controller after a Balance reboot. In some cases, this resulted in loss of configuration visibility and required physical intervention to restore operation. In my situation, this caused a complete loss of remote access after a power event and required a 600 mile trip to recover the site.

Current Status:
The issue is now resolved and the system is stable through switch reboots, router reboots, and full power loss scenarios.

What Fixed It:

  1. Set the switch External Access to Static instead of DHCP
    Switch Web UI, Uplink Configuration, External Access, Custom, Static
    Used the same IP, subnet, and gateway previously assigned via DHCP

This appears to be the primary fix.

  1. Added a DHCP reservation on the Balance 310
    This ensures the same IP is not reused elsewhere and keeps the network consistent
  2. Updated firmware on both the Balance and the switch using files provided directly by Pepwave
    Balance 310 - fw-epx_mbx_sdx-8.5.4-build6253.bin
    Switch - fw-pls_24h2g_48h2g_r24h2g-2.1.0-build1101.bin

I do not have visibility into what changes were included in these builds. I have asked Pepwave to clarify what was modified and whether those changes will be included in a public firmware release. At this point, it is not clear whether the firmware alone would have resolved the issue without the change to static IP addressing.

Technical Observation:

The behavior strongly suggests that when the switch is using DHCP, the Balance Switch Controller cannot reliably re-establish control after a router reboot. The switch itself remains reachable on the network, but the controller loses association with it.

Setting a static IP removes that dependency and allows the controller to reconnect consistently.

In practical terms, this means the system was dependent on DHCP timing and rediscovery behavior, which is not robust for remote or unattended deployments.

Concern:

This behavior is not obvious and is not currently documented. For those of us not using InControl, this creates a real operational risk. In my case, it resulted in a total loss of remote connectivity after a routine power event.

It also means that out-of-the-box default behavior using DHCP may not be reliable when using the Balance Switch Controller for local management.

Request to Pepwave:

I would ask Pepwave to clarify the following for the community:

Is this expected behavior when using DHCP for switch management with the Balance Switch Controller

Was this influenced by firmware, or is static addressing required for reliable operation

Will this be documented as a best practice for local control users

Are there plans to improve controller rediscovery so DHCP-based configurations are reliable after reboot

Closing:

I appreciate the support team working through this, but I want to make sure others are aware of the risk and the mitigation.

If you are using local switch control without InControl, I strongly recommend moving your switch management to static IP addressing.

Alan

3 Likes
29

Update – Interpretation of Pepwave Response and Firmware 2.1.0

I wanted to provide an update based on Pepwave’s latest response and my review of the 2.1.0 firmware release notes.

Pepwave Explanation:

Pepwave indicated that when the switch is set to External Access = Auto (DHCP), it will attempt to obtain a management IP from other available VLANs if it detects a loss of connectivity on its primary uplink.

In my case, I have a Starlink terminal connected to one of the VLANs. During a Balance router reboot, the switch may temporarily lose connectivity to its intended management network and then attempt to obtain an IP address from another VLAN, such as the Starlink network.

This means the switch can effectively change its management network during a reboot event.

From the controller perspective, this looks like the switch has disappeared, even though it is still operating and reachable somewhere else on the network.

Release Notes Review:

I reviewed the 2.1.0 release notes and there are several items that appear directly related to this behavior.

Notably:

  • A fix where the management IP obtained via DHCP was not automatically renewed when the uplink device or subnet changed
  • A fix where uplink configuration was incorrectly applied instead of External Access
  • Multiple fixes related to switch connectivity, status reporting, and configuration synchronization

These items suggest there were known issues in how the switch handled DHCP-based management addressing and uplink transitions.

Interpretation:

Putting these together, the behavior I experienced appears to be a combination of two factors:

  1. Design behavior
    When set to Auto, the switch is allowed to obtain a management IP from alternate VLANs if connectivity changes
  2. Firmware limitations or bugs
    The release notes indicate there were issues with DHCP renewal, uplink handling, and management IP stability

The result is that during a router reboot, the switch may move its management IP to a different VLAN, and the controller does not successfully rediscover it.

Key Takeaway:

This is not just a simple DHCP timing issue. It is a combination of:

  • Multi-VLAN management behavior under External Access Auto
  • DHCP-based IP reassignment
  • Controller rediscovery limitations

Setting the switch to a static IP prevents all of these variables and keeps the management plane stable.

Open Question:

It is still not fully clear whether firmware 2.1.0 alone would prevent this behavior in all cases, or whether static IP configuration should be considered required when using local switch control.

Alan

2 Likes