Local Broker Best Practices and FAQs
Local Broker Best Practices and FAQs
Best Practices
- Using at least a pair of Local Brokers per site/DC is recommended so they can provide high-availability access.
- Admin credentials for managing Local Broker(s) should only be granted to authorized users.
- Utilizing Dynamic Steering, it is recommended to select specific private apps when on-premises to steer via Local Broker.
- DNS resolution for the Local Broker Hostname must be carefully planned. If a Local Broker is intended to be internet facing, ensure that split DNS is configured so remote users can connect using a Public IP.
- A separate set of Publishers are required for Local Broker and Public Stitcher.
- Use Advanced High Availability & scalability based on dynamic DNS/GSLB
GSLB provides dynamic DNS response based on:- Resource Availability
- Geolocation
- Latency
FAQs
What is the migration plan from Ubuntu OS 20 to Ubuntu OS 22 Local Brokers?
Starting with release R123, Local Broker OVAs are built on Ubuntu OS 22.04. To migrate existing Local Brokers deployed on Ubuntu OS 20, you will need to re-deploy them using the Ubuntu OS 22 OVA. Please note that an in-place (manual) upgrade is not supported.
Does the Local Broker Support a Disaster Recovery Use Case?
Yes, the Local Broker does support a disaster recovery use case. The solution involves deploying Local Brokers as hot-standby that are inaccessible from the internet or external networks. In scenarios where remote users experience performance degradation, administrators can enable connectivity to the Local Broker by operationalizing the standby Local Brokers. When clients reconnect, they will connect to the Local Broker instead of the Cloud.
How does the Local Broker operate when there is loss of internet connectivity?
Local Broker Behavior During Internet Connectivity Loss
The Local Broker requires outbound internet connectivity to communicate with the NPA Management Plane for monitoring, maintenance, and policy updates.
In scenarios where the Local Broker loses internet access, the expected behavior is as follows:
New Enrollments
Local Brokers will not have Management Plane connectivity, which results in the following behavior:
- New enrollment attempts for both Clients and Publishers will be unsuccessful.
- New connections to the Local Broker cannot be established.
Existing Client Behavior
- Active Connections
- Existing outbound NPA tunnels from the Clients will remain functional.
- Local Broker continues to operate based on its most recent configuration, which was retrieved during the last successful connection to the Management Plane.
- End-users can access private applications via existing NPA tunnels.
- New Connection Attempts
- No new outbound NPA tunnels from the Clients are permitted, even for enrolled users.
- Connection attempts after client restart or re-enable will fail.
- Successful authentication and configuration updates require Management Plane communication.
Upgrade and Re-authentication
- Upgrading from the Local Broker wizard will not succeed.
- Periodic re-authentication for the NPA tunnel connected to the Local Broker will not be successful.
Publisher State Impact
Local Brokers will not have Management Plane connectivity, which results in the following behavior:
- When a Publisher experiences a disconnection and subsequently reconnects to a different local broker, other local brokers in the environment remain unaware of this change.
- When an active Publisher becomes unavailable, the information is not propagated to the Local Broker gateway.
WebUI Status
- The Local Broker WebUI status will display as disconnected after 10 minutes.
- The Publisher WebUI status will show as disconnected after 30 minutes.
- The Local Broker can store up to 100,000 events in the buffer or until a gateway restart occurs. After connectivity to the NPA Management Plane is reestablished, the stored events will be forwarded and will appear in the WebUI.
