CONTACT US
1-844-4ZPE-SYS
ZPE CLOUD

Providing Out-of-Band Connectivity to Mission-Critical IT Resources

Home » Simplify Branch Infrastructure » Vendor Neutral Platform » Page 12

Cisco 2900 EOL: Replacement Options

by | Jun 9, 2023 | Application Hosting, Consolidation, Data Center Management, Edge Computing, Modernize Legacy Environments, Out of Band Management, Remote Network Management, SD-Branch, SD-WAN, Secure Access Service Edge (SASE), Simplify Branch Infrastructure, Vendor Neutral Platform

cisco 2900 eol

The Cisco ISR 2900 series of branch routers went EOS (end-of-sale) on the 9th of December 2017, and Cisco concluded support on the 31st of December 2022. In this guide, we’ll compare migration options for the Cisco ISR 2900 EOL models to help you select a solution that supports your business use case, deployment size, and future growth.

Disclaimer: This comparison was written by a third party in collaboration with ZPE Systems using data gathered from publicly available data sheets and admin guides, as of 5/12/2023. Please email us if you have corrections or edits, or want to review additional attributes: Matrix@zpesystems.com

 

Table of Contents

Cisco ISR 2900 overview

The Cisco ISR 2900 is a line of enterprise gateway routers designed for branch and edge networking. It’s a modular solution that can be expanded with optional Network Interface Modules (NIMs) and Service Modules (SMs) for more functionality. There are two primary use cases for the 2900:

Converged branch networking – The ISR 2900 easily integrates with Cisco’s SD-WAN, SD-Branch, cloud security, and DNA network management software, can be extended with optional modules for added hardware capabilities, and supports NFV (network functions virtualization) for all-in-one branch networking.

Out-of-band (OOB) management – Using serial port modules, the ISR 2900 turns into an out-of-band (OOB) serial console solution that provides remote management access to the control plane of branch infrastructure.

The ISR 2900 is officially EOL as of the 31st of December 2022. The EOL models include all 2901, 2911, 2921, and 2951 ISR product SKUs.

Looking for replacement options for your other Cisco ISR EOL products? Read our guide to Cisco ISR EOL Replacement Options.

 

Cisco 2900 EOL replacement options

The discontinuation of the Cisco 2900 has left many organizations looking for migration options. Let’s compare two direct replacements from Cisco before discussing alternative options that deliver better branch management capabilities and greater opportunities for automation.

Cisco ISR 1100

Cisco ISR 1100 is a series of enterprise branch routers, though in this comparison we’re only looking at the models that support SD-WAN and thus serve as direct replacements for the discontinued 2900 models. The capabilities of the 1100 series vary, mostly because only some of the models are modular. For example, the fixed form-factor 1100-4G/4G LTE models have cellular functionality but offer fewer networking and security features. Conversely, the 1161X-8P and 112x-8P models are modular and can be extended with optional modules (like cellular for the 1161X or terminal server ports for the 112x-8P).

Even with these expansions, the compact ISR 1100s are best suited for smaller deployments in branch offices or small, provider-managed edge data centers. If your organization uses the ISR 2900 for converged branch networking, the 1100s are the closest Cisco replacement, though it supports OOB serial modules as well.

Cisco Catalyst C8300

The Cisco Catalyst C8300 series is a modular branch and edge networking solution, though due to its large size, it’s sometimes used as a primary on-premises gateway router. There are four models to choose from – two 2RU units with 2 SM and 2 NIM slots, and two 1RU units with 1 SM and 1 NIM slot. Each chassis comes with 6 embedded Layer3 Ethernet ports (1 Gbps and/or 10 Gbps) as well as a console port and USB port. All other port configurations and capabilities come via Cisco expansion modules, including options for 5G/4G cellular.

The Catalyst C8300 is a big, robust solution that’s designed for medium to large deployments such as campuses, colocation sites, and AI/machine learning data centers. The C8300 is primarily a converged branch networking solution like the ISR 1100 series, but it provides OOB management with optional serial cards.

Cisco 2900 replacement option comparison table

 

Cisco ISR 2900 (EOL)

Cisco ISR 1100

Cisco Catalyst 8300

Nodegrid Net SR

Nodegrid Serial Console Plus

Form Factor

1-2 RU

Desktop-1RU

1-2 RU

1 RU

1 RU

Max IPsec Throughput

Not defined

Up to 18.8 Gbps

Up to 18.8 Gbps

600 Mbps – 1.2 Gbps

600Mbps

Total Onboard WAN or LAN 10/100/1000 Ports

2-3

4-6

4-6

2

2

Total Onboard WAN or LAN 10Gbps Ports

0

0

0-2

2

2

WAN Ports

2-3

0-6

2-6

1+, configurable

0-4

LAN Ports

2-3

0-6

2-6

4-84

0-4

Slots

2-3

0-1

2-4

5

0

Default Memory

512 MB

4 GB

8 GB

8 GB

4 GB

Max Memory

2 GB

8 GB

32 GB

64 GB

16 GB

Compute

–

–

UCS-E Card

On-board, Compute card

On-board

OOB Capabilities

Requires Serial Card

Requires Serial Card

Requires Serial Card

Included

Included

Environmental Monitoring

N/A

N/A

N/A

Included

Included

For users looking for a Cisco solution to replace their EOL ISR 2900, the ISR 1100 series and Catalyst C8300 are the closest direct replacements. However, both product lines suffer from a major limitation – they aren’t vendor-neutral.

While Cisco routers integrate with some third-party partners, they do not support custom or third-party applications for automation and orchestration, which limits you to the automation offered by Cisco’s software. This lack of open integrations increases the chances that a Cisco solution won’t be able to hook into all the hardware and software components of a distributed and multi-vendor network architecture.

For example, if you utilize different SD-WAN and next-generation firewall (NGFW) vendors at some of your remote sites, Cisco’s automation may not extend to these devices. That means you’ll need to send out technicians to all remote sites (which could number in the dozens or hundreds) just to set up these services when you otherwise could have deployed them automatically.

Want to learn more about breaking free of locked ecosystems? Read The Benefits of Vendor Agnostic Platforms in Network Management

When network solutions like the Cisco 2900 go EOL, it’s the perfect opportunity to look for alternative options that provide the functionality you need without locking you into an ecosystem or limiting your automation capabilities.

Cisco 2900 direct replacement options from ZPE Systems

ZPE Systems provides a line of vendor-neutral solutions for branch and edge networking called Nodegrid. The Nodegrid Net Services Router (NSR) and Nodegrid Serial Console Plus (NSCP) serve as direct replacements for Cisco 2900 EOL products.

Nodegrid Net Services Router (NSR)

The Nodegrid NSR is a modular branch networking solution that you can customize to increase your terminal server ports, storage space, processing power, or switch ports. The NSR delivers converged branch networking capabilities like SD-WAN, SD-Branch, and NFVs, plus it can host your choice of custom and third-party applications for automation, security, and more.

While the NSR is the perfect converged branch solution to replace the Cisco ISR 2900, it also provides 3rd generation (or Gen 3) OOB management. That means Nodegrid’s OOB network is completely vendor-neutral and can extend automation capabilities to all your legacy and mixed-vendor infrastructure for efficient deployments, management, and orchestration.

Want to see the Nodegrid converged branch networking solution in action? Watch a Demo

Nodegrid Serial Console Plus (NSCP)

The NSCP is a robust, scalable branch networking and out-of-band serial console solution. The NSCP comes in 16-, 32-, 48-, and 96-port models, so you can choose the solution that’s right-sized to your deployment and use case. Plus, you can get built-in 5G/4G LTE and Wi-Fi options for failover and out-of-band.

Like the NSR, the NSCP is also an open platform that can run your choice of software to expand your capabilities and reduce your tech stack. Like the NSR, the NSCP delivers Gen 3 OOB management of all connected infrastructure, enabling true end-to-end automation in data centers, branches, and other remote sites. The NSCP is the perfect replacement for enterprises utilizing the Cisco 2900 for out-of-band management, though it also provides converged branch networking capabilities at any scale.

All Nodegrid devices run the open, Linux-based Nodegrid OS which can host your choice of third-party or custom applications, freeing you from vendor lock-in. You can even integrate infrastructure orchestration tools like Puppet, Chef, and Ansible to extend automation to end devices, regardless of vendor. This is what makes Nodegrid the world’s first Gen 3 branch networking solution.

Want to see how Nodegrid stacks up against Cisco’s replacement options? Click here to download the services routers comparative matrix.

Global support and supply chain

Leaving a trusted ecosystem behind to adopt alternative options can be risky, so it’s important to find a vendor that offers the support you need to make the transition and keep your operations running smoothly. ZPE Systems offers global product support using the “follow the sun” model, which means you get support when you need it, regardless of your timezone. You also won’t have to worry about supply chain issues causing stock shortages – ZPE supplies hyperscalers in 10K+ units per quarter and has great, consistent supply chain control.

Need to replace your Cisco 2900 EOL?

To learn more about replacing your Cisco 2900 EOL solution with the vendor-neutral Nodegrid platform and our shipping in as little as two weeks, contact ZPE Systems today. Contact Us

Cisco 2900 EOL product tables with migration SKUs

Cisco 2900 EOL Model

In Scope Features

Replacement Product (modular form factor)

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 16 serial ports

ZPE-NSR-816-DAC with 1 x 16 port serial module 1 x ZPE-NSR-16SRL-EXPN

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 32 serial ports

ZPE-NSR-816-DAC with 2×16 port serial module 2x ZPE-NSR-16SRL-EXPN

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 48 serial ports

ZPE-NSR-816-DAC with 3×16 port serial module 3x ZPE-NSR-16SRL-EXPN

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 60 serial ports

ZPE-NSR-816-DAC with 4×16 port serial module 4x ZPE-NSR-16SRL-EXPN

80 serial port option – no Cisco equivalent

Serial Console Module, Routing, 80 serial ports

ZPE-NSR-816-DAC with 5×16 port serial module 5x ZPE-NSR-16SRL-EXPN

 

Cisco 2900 EOL Model

In Scope Features

Replacement Product (fixed form factor)

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 16 serial ports

ZPE-NSCP-T16R-STND-DAC

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 32 serial ports

ZPE-NSCP-T32R-STND-DAC

Cisco ISR 2901

Cisco ISR 2911

Cisco ISR 2921

Cisco ISR 2951

Serial Console Module, Routing, 48 serial ports

ZPE-NSCP-T48R-STND-DAC

96 serial port option – no Cisco equivalent

Serial Console Module, Routing, 96 serial ports

ZPE-NSCP-T96R-STND-DAC

Want to see how Nodegrid compares to other serial console solutions?

What Is a Zero Trust Gateway?

by | Apr 25, 2023 | Micro-segmentation, Network Automation, Remote Network Management, SecOps, Vendor Neutral Platform, Virtualization, Zero Touch Provisioning (ZTP), Zero Trust Security

What Is a Zero Trust Gateway(2)
The constant threat of cyberattacks has made network security a top priority for companies in every sector, with Gartner predicting that global cybersecurity spending will reach $188 billion in 2023. However, security continues to get more challenging due to factors like a rise in remote work, an increasing reliance on touchless internet of things (IoT) devices, and the overall decentralization of enterprise networks. It’s hard to create a secure perimeter around the enterprise when its users, devices, applications, and data could be anywhere in the world.

The zero trust security methodology addresses this challenge by shrinking the focus from one large security perimeter and instead creating smaller “micro-perimeters” around each individual resource that needs defending. It’s called zero trust because it follows the principle of “never trust, always verify.” That means each user and device needs to verify its identity and prove its trustworthiness before it can penetrate the micro-perimeter. So, for example, if a cybercriminal uses stolen credentials to log into the enterprise network, they have to pass through many different security checkpoints to see or access any sensitive resources, which increases the likelihood they’ll get caught before excessive damage is done.

One way to implement micro-perimeters and apply zero trust security policies is with a device called a zero trust gateway. This post discusses the technologies that make up a zero trust gateway and explains how they work together to defend enterprise networks.

Table of contents:

What is a zero trust gateway?

A zero trust gateway is a device that sits at the edge of the network – or at the top of the rack – and applies zero trust security policies and controls to traffic flowing in either direction. The gateway can be a dedicated security appliance, but it’s often more cost- and space-effective to use a multi-functional device that combines security, networking, and infrastructure management in a single box.

Some of the key features used in an all-in-one zero trust gateway include network micro-segmentation, identity and access management, context-aware monitoring, and secure out-of-band management. There are a small number of mature solutions that deliver all of these features off-the-shelf, but they lock you into their small solution ecosystem and limited feature roadmap. A better approach is to start with a vendor-neutral platform that lets you host and integrate your choice of security applications to create a fully customized zero trust gateway. Let’s walk through how each of these security technologies works and how to combine them into a bespoke zero trust gateway solution.

To see an example of a vendor-neutral zero trust gateway at work, request a demo of the Nodegrid solution from ZPE Systems.

Request a Demo

Network micro-segmentation

A zero trust micro-perimeter is made up of granular access control policies and security controls that are custom-tailored to the specific vulnerabilities and requirements of resources they’re defending. For example, an on-premises database containing sensitive financial records needs different policies than a cloud-based application that doesn’t process any personal information. To implement micro-perimeters, resources first need to be logically organized based on their sensitivity level, who needs access to them, and what their interdependencies are.

Network micro-segmentation is used to separate resources based on these criteria so that micro-perimeters can then be applied. For a device to be considered a zero trust gateway, it must support VLAN micro-segmentation and be able to apply access control rules consistently across all micro-segments.

Identity and access management

In a zero trust architecture, user and device permissions should be limited to only what’s necessary to perform their job role. For example, an HR account used to manage employee records shouldn’t have access to customer financial data, and vice versa. Access policies should be specific to individual micro-segments and resources and need to be applied to all users and devices consistently, no matter where they’re logging in from. That means a remote user should follow the same authentication steps and have the same permissions as they would if they logged in at the office.

For a large enterprise network, this is only achievable with a centralized identity and access management (IAM) solution. An IAM provides a single platform from which to create, manage, and apply security policies. A zero trust IAM also enables best practices like single sign-on (SSO) and two-factor authentication (2FA).

A zero trust gateway needs to integrate with your chosen IAM provider to ensure that policies are applied to both production traffic and management traffic. Some vendor-neutral gateway solutions can even directly host and run third-party IAM solutions, providing a more integrated experience and saving rack space.

Context-aware monitoring

Many successful cyberattacks use stolen credentials gained through phishing schemes and other social engineering tactics. For example, Mailchimp was recently attacked by malicious actors using credentials stolen from employees through social engineering. It’s difficult to detect and contain such an attack because the criminal looks like an authorized user. However, careful monitoring often reveals suspicious behavior, such as logging in from an unusual IP address or time zone, making multiple access requests to areas of the network they don’t usually visit, or transferring abnormally large quantities of data.

User and entity behavior analytics, or UEBA, uses machine learning technology to monitor and analyze account activity on the enterprise network. UEBA creates a baseline of “normal” behavior for individual accounts so it can detect any anomalous activity. UEBA integrates with other security and monitoring solutions, such as IAM and firewalls, so it can compare data from various sources to make more informed decisions. This is one of the ways that zero trust security verifies the trustworthiness of accounts trying to access sensitive resources, making UEBA a critical component of zero trust gateways.

Secure out-of-band (OOB) management

Admins need a fast and reliable way to access remote infrastructure for management, troubleshooting, and recovery. For example, it’s common for a single data center management team to be responsible for customer equipment in multiple DCs distributed around the world for redundancy. These admins can’t physically go on-site every time a firmware update fails or a device loses its IP address. That’s why they rely on remote out-of-band (OOB) management; remote OOB management creates a separate network just for management traffic that doesn’t rely on the production LAN. Admins access the OOB network using a dedicated management device, like a jump box or a serial console server.

This management device is a tempting target for cybercriminals, as gaining control of that device will give them complete control over the connected infrastructure. One way to protect the OOB network is by using a zero trust gateway with integrated management ports. For example, the Nodegrid Net Services Router (NSR) is a modular zero trust gateway that can be customized to connect to any type of device that needs to be managed or secured. The NSR comes with gateway routing and switching capabilities, an embedded firewall, and hardware security features like secure boot and a self-encrypted disk. Nodegrid is also completely vendor-neutral, which means it can directly host or integrate with your choice of third-party security solutions, including next-generation firewalls (NGFWs) and zero trust technologies like identity and access management and UEBA.

The NSR is a modular, open platform upon which to build a fully customized zero trust gateway for large data center deployments. The Nodegrid product line from ZPE Systems also includes a variety of serial console solutions and integrated all-in-one gateway routers to support other use cases, such as edge computing sites, branches, and automated IoT deployments.

A zero trust gateway helps organizations implement micro-perimeters of specific policies and controls to defend sensitive data and other valuable resources. A vendor-neutral, integrated solution like the Nodegrid Serial Console Plus from ZPE Systems makes it possible to combine zero trust security with networking and management functionality to create a streamlined, cost-effective zero trust gateway deployment.

Ready to learn more about Zero Trust Gateway?

To learn more about deploying Nodegrid as a zero trust gateway in your enterprise, contact ZPE Systems today.

Contact Us

Zero Touch Deployment Cheat Sheet

by | Apr 19, 2023 | Consolidation, Data Center Management, DevOps, EdgeOps, Failover Connectivity, Network Automation, Remote Network Management, Scripting, SD-WAN, Secure Access Service Edge (SASE), Security Service Edge (SSE), Simplify Branch Infrastructure, Streamline Deployments, Vendor Neutral Platform, Virtualization, Zero Touch Provisioning (ZTP)

A zero touch deployment cheat sheet is visualized as a literal cheat sheet used by a student during an exam

Zero touch deployment is meant to make admins’ lives easier by automatically provisioning new devices. However, many teams find the reality of zero touch deployment much more frustrating than manual device configurations. For example, zero touch deployment isn’t always compatible with legacy systems, can be difficult to scale, and is often error-prone and difficult to remotely troubleshoot. This post provides a “cheat sheet” of solutions to the most common zero touch deployment challenges to help organizations streamline their automatic device provisioning.

Zero touch deployment cheat sheet

Zero touch deployment – also known as zero touch provisioning (ZTP) – uses software scripts or definition files to automatically configure new devices. The goal is for a team to be able to ship a new-in-box device to a remote branch where a non-technical user can plug in the device’s power and network cables, at which point the device automatically downloads its configuration from a centralized repository via the branch DHCP server.

In practice, however, there are a variety of common issues that force admins to intervene in the “zero touch” deployment. This guide discusses these challenges and advises how to overcome them to achieve truly zero touch deployments.

Zero touch deployment challenge: The solution:
Legacy systems don’t have native support for zero touch Extending zero touch to legacy systems using a vendor-neutral platform
Deployment errors result in costly truck-rolls Recovering from errors remotely with Gen 3 out-of-band (OOB) management
Securing remote deployments causes firewall bottlenecks Moving security to the edge with Zero trust gateways and Secure Access Service Edge (SASE)
Automating deployments at scale increases management complexity Maintaining control through centralized, vendor-neutral orchestration with version control

Extend zero touch to legacy systems with a vendor-neutral platform

Challenge Solution

While many new systems and networking solutions support zero touch deployment, sometimes there’s still a need to repurpose or reconfigure legacy systems that don’t come with native ZTP support.

Pre-staging these devices before shipping them to the branch is a security risk because the system could be intercepted in transit; plus, they’re likely already deployed at remote sites and need to be reconfigured in place. Without a way to extend zero touch deployment capabilities to those legacy systems, companies often have to pay for admins to travel to remote branches, negating any cost savings they were hoping to gain from reusing older devices.

One way to extend zero touch to legacy systems is with a vendor-neutral management platform. For example, a vendor-neutral serial console switch with auto-sensing ports can connect to modern and legacy infrastructure solutions in a heterogeneous branch deployment so they can all be managed from a single place.

From that unified management platform, admins can write and deploy configuration scripts to connected devices, including legacy systems that don’t support zero touch. Technically, this isn’t zero touch deployment because the system doesn’t automatically download and run its configuration file, but it’s still a way to turn an on-site, manual process into one that’s remotely activated and mostly automated.

Recover from deployment errors with Gen 3 OOB management

Challenge Solution

A new branch deployment almost never goes completely according to plan, and this is especially true when teams are using zero touch for the first time, or aren’t completely comfortable with software-defined infrastructure and networking. In the best-case scenario, when there’s a configuration error, the zero touch deployment aborts, and an admin is able to correct the problem and restart the process.

However, sometimes the deployment hiccup causes the device to hang, freeze, or get stuck in a reboot cycle. Or, even worse, an unnoticed error in the configuration could allow the deployment to finish successfully but then go on to affect other production dependencies and bring the entire branch network down. Either way, organizations must again deal with the expenses involved in sending a tech out to troubleshoot and fix the problem.

The best way to ensure continuous access to remote infrastructure is with out-of-band (OOB) management. An OOB solution, such as a serial console or all-in-one branch gateway, connects to the management ports on infrastructure devices so admins can remotely monitor and control every device from a single place without IP addresses.

This creates a separate (out-of-band) network that’s dedicated to management and troubleshooting, making it possible for teams to remotely recover devices that have failed the zero touch deployment process or brought down production LAN dependencies. Plus, the OOB gateway uses independent, redundant network interfaces to ensure admins still have remote access even if the production WAN or ISP link goes down.

To ensure full OOB management coverage of a heterogenous, mixed-vendor environment, the out-of-band solution should be completely vendor-neutral. An open OOB device also supports integrations with third-party solutions for automation, orchestration, and security. This kind of out-of-band platform is known as Gen 3 OOB. Gen 3 OOB management ensures that teams can remotely recover from zero touch deployment errors no matter what device is affected or how the production network is impacted.

Secure remote deployments with zero trust gateways and SASE

Challenge Solution

Organizations need to secure all devices at all remote sites using consistent policies and security controls. However, for smaller branches and IoT sites, it usually isn’t cost-effective to deploy a security appliance in each location.

Plus, adding more firewalls also adds more management complexity. That means traffic is usually backhauled through the main data center firewall, creating bottlenecks and causing network latency for the entire enterprise.

Using zero trust gateways and cloud-based security services, companies can move security to the branch without the cost and complexity of additional firewalls. An all-in-one, zero trust gateway solution combines SD-WAN, gateway routing, and OOB management in a single device. It also supports zero trust authentication technologies like SAML 2.0 and 2FA. A zero trust gateway also needs to support network micro-segmentation, which will allow the use of highly specific security policies and targeted security controls. Plus, by enabling software-defined wide area networking (SD-WAN), a zero trust gateway facilitates the use of SASE.

Secure Access Service Edge (SASE) is a cloud-based service that combines several enterprise security solutions into a single platform. Zero trust gateways use SD-WAN’s intelligent routing capabilities to detect branch traffic that’s destined for the cloud or web. This traffic is directed through the SASE stack for firewall inspection and security policy application, allowing it to bypass the main security appliance entirely. SASE helps reduce the load on the enterprise firewall, reducing bottlenecks and improving performance without sacrificing security.

Scale zero touch deployments with centralized orchestration

Challenge Solution
Zero touch deployments occur (at least in theory) without any admin intervention, but they still need to be monitored for failures. Keeping track of a handful of automatic deployments may seem easy enough, but as the number and frequency increases, it becomes more challenging. This is especially true when companies kick off large-scale expansions, deploying dozens of devices at once, all of which could be plugged in at any time to begin the automated provisioning process. Plus, different devices need different configuration files, and admins need a way to work together without overwriting each other’s code or duplicating each other’s efforts. A vendor-neutral orchestration platform provides a central hub for network and infrastructure automation across the entire enterprise. This platform uses the serial consoles and OOB gateways in each remote location to gain control over all the connected devices, so network teams can monitor and deploy all their zero touch configurations from one place. An orchestration platform is the single source of truth for all automation, so it needs to support version control. This ensures that admins can see who created or changed a configuration file and revert to a previous version when there’s a mistake.

Simplifying zero touch deployment with Nodegrid

Zero touch deployment can be a hassle, but using vendor-neutral management systems, Gen 3 OOB management, zero trust gateways, and centralized orchestration can help organizations overcome the most common hurdles. For example, a vendor-neutral Nodegrid branch gateway deployed at each remote site helps you extend automation to legacy systems, provides fast and reliable out-of-band access to recover from issues, enables zero trust security & SASE, and gives you unified orchestration through the Nodegrid Manager (on premises) and ZPE Cloud software.

Ready to learn more about zero touch deployment?

Nodegrid has a solution for every zero touch deployment challenge. Schedule a demo to see how Nodegrid’s vendor-neutral platform can simplify zero touch deployment for your enterprise.

Contact Us

Streamlining Remote Data Center Management

by | Apr 14, 2023 | Consolidation, Data Center Management, Failover Connectivity, SD-WAN, Secure Access Service Edge (SASE), Simplify Branch Infrastructure, Vendor Neutral Platform, Virtualization

Streamlining Remote Data Center Management

With the tech industry in turmoil and an ongoing recession forcing cutbacks, many sysadmins and engineers are struggling to efficiently manage their data center infrastructure. Overworked admins are more likely to make mistakes and issues are more likely to fall between the cracks, making the enterprise network less resilient. In the current economy, businesses can’t afford to lose revenue due to data center outages, and that’s why it’s crucial to invest in the tools teams need to efficiently manage and monitor remote infrastructure.

This blog explains how to streamline remote data center management using technologies like out-of-band (OOB) management, automation, orchestration, and AIOps to ensure network resiliency.

Table of Contents

How to streamline remote data center management

Out-of-band management

Organizations commonly deploy redundant internet connections at their data centers to provide network failover, ensuring business continuity in case the primary ISP suffers an outage. However, if the data center WAN or LAN goes down due to an equipment failure, configuration mistake, or security breach, network failover won’t help admins solve the problem. If remote data center devices are unable to get an IP address, then they’ll be unreachable on the production network, leaving remote teams without a way to diagnose and fix the issue. That means expensive truck rolls or on-site managed services, plus the revenue and reputation costs of extended downtime.

What’s needed to ensure business continuity and reduce the cost of outages is an out-of-band (OOB) management network that doesn’t rely on any production infrastructure. The most efficient way to accomplish this is with Gen 3 OOB serial consoles. These systems include redundant network interfaces – often using cellular – to ensure continuous remote access even if the production ISP or MPLS link goes down. An OOB serial console directly connects to data center infrastructure devices via the serial port, which means remote admins can access and manage them without an IP address. The result is that remote data center management teams can diagnose and fix problems without traveling on-site, saving money on recovery costs as well as reducing the duration and business impact of outages.

Plus, an OOB management network can be used to execute resource-intensive automation and orchestration workflows without using valuable MPLS bandwidth or affecting production network performance. Gen 3 serial consoles are vendor-neutral and support the use of third-party automation scripts and playbooks, giving remote data center teams a centralized orchestration platform for more streamlined infrastructure and network management.

Infrastructure and network automation

Staff cutbacks have left data center teams stretched paper-thin, and reduced budgets mean they’re being asked to do more with less. When admins are overworked with many tedious, manual tasks, they’re more likely to make mistakes. These mistakes are a major cybersecurity threat, with Microsoft estimating that up to 80% of ransomware attacks are caused by misconfigured devices, applications, and security systems.

Automation helps remediate human error by taking over the repetitive, tedious workflows that computers are best at, leaving admins and engineers free to handle the creative, intuitive work that only humans can accomplish. For example, teams can use infrastructure as code (IaC) and zero touch provisioning (ZTP) to turn data center device configurations into software scripts that are deployed and executed automatically. Automated configuration management tools can then monitor these devices for changes that might introduce a security vulnerability and then automatically roll-back to the last known good configuration. Teams can also use software-defined networking (SDN) and software-defined wide area networking (SD-WAN) to automate traffic management and optimization, load balancing, access control list (ACL) updates, and other network management workflows.

Automation makes it possible for small network operation centers (NOCs) and data center teams to efficiently control large and distributed enterprise deployments. While network automation hasn’t quite caught up to infrastructure automation in terms of adoption and tool maturity, the use of vendor-neutral devices and platforms allows teams to use their existing IaC and configuration management tools to deploy and control network devices like routers, switches, load balancers, and security appliances. Vendor-neutral solutions also make it easier to implement centralized orchestration to manage automation workflows across the entire network architecture.

Centralized orchestration

Automation’s goal is to streamline data center management, but when it’s not handled correctly, it can easily wind up overcomplicating things instead. If admins aren’t monitoring their automated workflows, there could be changes occurring without any human oversight, leading to potential security risks and making it harder to perform root-cause analysis (RCA) when issues arise. In addition, without an organized, centralized repository for network automation scripts and configurations, engineers could end up duplicating each other’s work and negating any productivity gains. Plus, having a fragmented automation architecture makes it impossible for admins and security analysts to holistically monitor and manage the enterprise network.

Centralized orchestration provides a single platform from which to deploy, monitor, and manage automation across data center deployments and distributed network architectures. A data center infrastructure orchestration platform should include:

  • ⮕ Source code version control – A centralized repository for automation scripts that tracks changes and acts as a single source of truth for the entire automated infrastructure.
  • ⮕ Vendor-neutral orchestrator – A tool that controls all of the automated workflows in a data center deployment, essentially automating the automation.
  • ⮕Visibility & analytics – Dashboards where admins can monitor automated workflows, view current device health and network performance, and gain insights from their AIOps and big data tools.

To ensure optimal coverage and efficiency, the source code repository must be compatible with the chosen scripting language(s), the orchestrator must support any IaC playbooks, and the visibility tools must be able to hook into all systems, applications, and devices in the data center. That means the orchestration platform should be vendor-neutral.

AIOps

Data center infrastructure, and the platforms used to monitor and manage it, all generate a lot of logs. The data contained in these logs can provide valuable insights about the health, performance, and security of that infrastructure, but only if teams have the ability to collect and analyze it. Unfortunately, human beings aren’t very adept at parsing vast quantities of data to spot and predict patterns. However, humans have designed artificial intelligence to pick up the slack.

Artificial intelligence for IT operations – or AIOps – uses technologies like machine learning (ML) and natural language processing (NLP) to analyze logs from data centers and network infrastructure. AIOps pulls data from sources such as monitoring and orchestration platforms, environmental monitoring sensors, and firewall logs, then utilizes that data to provide business insights, predict future outcomes, and make decisions to solve problems.

AIOps is a relatively new technology and as such its capabilities continue to evolve. However, data center teams are currently using AIOps for things like enhanced threat modeling, automatic root cause analysis, and intelligent performance monitoring. For overworked and understaffed data center teams, AIOps essentially acts as an extra brain devoted to the monitoring and analysis of automated infrastructure.

Streamlining remote data center management with ZPE Systems

A resilient enterprise network uses out-of-band (OOB) management, automation, orchestration, and AIOps to streamline remote data center management and ensure business continuity. The backbone of such an architecture is vendor-neutral solutions, such as the Nodegrid platform from ZPE Systems. Nodegrid serial consoles provide Gen 3 OOB management with complete vendor freedom, so you can control any device, deploy your choice of automation scripts and playbooks, host third-party security and AIOps solutions, and unify the management of all of the above with a single orchestration platform.

Ready to learn more about data center management?

To learn more about remote data center management with Nodegrid, contact ZPE Systems today.

Contact Us

Need an in-depth guide to building a more resilient network infrastructure? Fill out the form below to download the Network Automation Blueprint from ZPE Systems.

Cloud-Delivered Branch: Simplifying Remote Management

by | Apr 6, 2023 | Consolidation, Failover Connectivity, Out of Band Management, SD-WAN, Secure Access Service Edge (SASE), Simplify Branch Infrastructure, Vendor Neutral Platform, Virtualization

BranchDiagram
Modern enterprises must grow to remain competitive, but this expansion makes WAN management more challenging. Spinning up a new branch or edge computing site with traditional WAN infrastructure can be time-consuming and expensive, with network solutions needing to be purchased and installed and new MPLS links taking weeks or even months to activate. Each branch has infrastructure that admins need to manage remotely, which means accessing many different jump boxes and remembering many different configuration schemas. Essentially, it’s like each branch has its own unique toolkit. That means every additional branch increases the management complexity, making it more likely that mistakes or inefficiencies will occur.

The cloud-delivered branch is a relatively new concept that provides branch networking, security, and management solutions as a cloud-based service. The idea is to simplify remote management by reducing the number of individual solutions deployed at each branch and allowing admins to monitor and control all of their branches from a single place. This is like giving teams one single toolkit that can service every branch.

This post describes the three cloud-based services involved in a cloud-delivered branch, and gives an example of how to implement a cloud-delivered branch using the Nodegrid platform from ZPE Systems.

Table of Contents

To see examples of a cloud-delivered branch in action, request a free demo of the Nodegrid platform.

Request a Demo

How a cloud-delivered branch simplifies remote management

There are three key components of a cloud-delivered branch: cloud-based infrastructure management, cloud-based network management, and cloud-based cybersecurity. Let’s discuss the technologies used in each component.

Cloud-managed branch gateways

A branch gateway is a networking device that lives in the branch and provides access to the enterprise WAN as well as cloud resources and the internet. A gateway that’s optimized for branch networking will usually combine multiple network functionalities in one to save rack space and reduce complexity. For the purposes of the cloud-delivered branch, one of these features should be device management, i.e. serial console/console server technology. This functionality means that any infrastructure component connected to the gateway, whether it’s via RJ-45 or Wi-Fi, can be remotely managed by simply logging into the gateway’s software, reducing the need for a jump box or dedicated management hardware. Of course, what makes it a cloud-managed branch gateway is that admins manage it (and all connected infrastructure) from a cloud platform instead of directly connecting to the gateway over the WAN. This means that admins have management access from anywhere in the world, without needing to be on the enterprise network.

Software-defined wide area networking (SD-WAN)

SD-WAN, or software-defined wide area networking, simplifies WAN management by decoupling control functions from the underlying hardware and making them available as software. Essentially, SD-WAN splits a WAN architecture into two layers: the physical hardware that connects branches to the enterprise network (e.g., cloud-managed branch gateways), and the networking logic that orchestrates WAN traffic (e.g., routing rules and load balancing). In a cloud-delivered branch, SD-WAN’s software lives in the cloud, giving network teams a centralized place from which to monitor and control the entire WAN architecture, no matter how many branches are involved.

Secure Access Service Edge (SASE)

SASE (pronounced “sassy”) is a solution that combines multiple enterprise security technologies into a single stack that’s delivered as a cloud-based service. SASE uses SD-WAN technology to directly connect branch users and devices to enterprise resources in the cloud, first passing that traffic through the SASE stack to ensure that security policies and controls are applied. That means this traffic doesn’t need to go through a traditional firewall, which reduces bottlenecks at the central data center without requiring a security appliance at each branch. Eliminating firewalls at most branches decreases management complexity for network admins, and reducing the load on a centralized data center firewall improves performance for the entire enterprise.

How to implement a cloud-delivered branch with Nodegrid

A cloud-delivered branch uses cloud-based infrastructure management, network management, and security to simplify remote branch management. The best practices for building infrastructure to support a cloud-delivered branch include:

Best practices: Benefits:
Using vendor-neutral hardware and software solutions Reduces the number of infrastructure devices that need to be deployed

Enables unified, centralized infrastructure management

Supports third-party apps and automation
Implementing out-of-band (OOB) management at each site Provides an alternative path to critical remote infrastructure during WAN/LAN outages

Reduces the frequency and cost of truck-rolls

Ensures that resource-intensive automation workflows don’t cause production latency
Incorporating branch LAN management into the cloud-management umbrella Extends software-defined networking control into the branch LAN

Unifies branch WAN and LAN management behind a single pane of glass

Increases efficiency and ensures holistic coverage

Let’s walk through an example of how these best practices are implemented using the Nodegrid platform from ZPE Systems.

Vendor-neutral branch gateways and cloud management

A Nodegrid branch gateway such as the Bold Services Router is installed at each branch to provide WAN and internet access. These all-in-one networking solutions provide routing, switching, and console server management functionality, reducing the number of infrastructure devices that need to be deployed. All Nodegrid devices are completely vendor-neutral, which means you can use them to host your SD-WAN, SASE, or edge computing applications, saving you from buying and installing additional hardware. In addition, vendor-neutral Nodegrid gateways unify branch infrastructure management through the ZPE Cloud software. Any infrastructure connected to a Nodegrid device at any branch is available to manage through ZPE’s centralized, cloud-based platform, simplifying remote management and providing greater opportunities for optimization and automation. Plus, ZPE Cloud software is also vendor-neutral, meaning you can integrate third-party apps and tools to create a fully customizable infrastructure and network orchestration platform.

Gen 3 out-of-band management

One of the most challenging aspects of remote branch management is recovering from network outages without any technical staff on-site to reboot devices or refresh IP addresses. Out-of-band (OOB) management solves this problem by providing an alternative path to critical remote infrastructure that doesn’t rely on the production WAN or LAN. Teams use OOB management to troubleshoot and fix problems and recover from outages, reducing the need for costly truck-rolls. Nodegrid branch gateways provide Gen 3 OOB management capabilities, the most advanced form of OOB technology. Nodegrid gateways are considered Gen 3 because they support third-party infrastructure and network automation via the OOB network. That means teams can use their preferred scripting languages and tools to execute resource-intensive automation workflows on a management network that’s completely separate from the production network. For example, admins can run AIOps root-cause analysis tools to fix problems, or orchestrate automation device provisioning, without taking up valuable MPLS bandwidth or creating additional latency on the production LAN. Additionally, companies typically need a jump box at every branch to host all their troubleshooting, remediation, and automation tools. The benefit of vendor-neutral Nodegrid devices is that they become a one-stop shop for OOB as well as all the services and tools you’d normally install on a jump box. This eliminates the need for separate out-of-band management and jump box appliances.

Branch LAN management with SD-Branch

SD-WAN provides software abstraction and cloud management for WAN architectures, but it typically stops at the edge of the branch, meaning admins use a different solution to manage the internal branch LANs. Nodegrid gateways extend software-defined networking control into the branch LAN using technology called SD-Branch. That means teams can use the same ZPE Cloud platform to control every aspect of branch networking, creating a streamlined management environment that increases efficiency and ensures holistic coverage. Using a Nodegrid device for your cloud-delivered branch reduces the number of network solutions deployed at each site, standardizes branch network management, and increases your automation and orchestration capabilities. Deploying fewer boxes decreases the cost to spin up a new branch, while standardization and automation helps to reduce operating expenses and increase operational efficiency.

Ready to learn more about implementing a cloud-delivered branch?

To learn more about implementing a cloud-delivered branch with Nodegrid, contact ZPE Systems today.

Contact Us

A Guide to SD-WAN Deployment Models

by | Apr 3, 2023 | Consolidation, Failover Connectivity, Out of Band Management, SD-WAN, Secure Access Service Edge (SASE), Simplify Branch Infrastructure, Vendor Neutral Platform, Virtualization

SD-WAN

Software-defined wide area networking, or SD-WAN, uses software abstraction to create a virtual overlay network that sits on top of the underlying WAN infrastructure. This gives organizations greater control over distributed network architectures and enables a high degree of automation. SD-WAN can be deployed in a hub-and-spoke model or a variety of mesh topologies depending on the organization’s requirements and capabilities.

In this guide are the most common SD-WAN deployment models with diagrams, pros and cons, and best practices to help organizations choose the right topology.

Table of Contents

Hub-and-spoke SD-WAN deployment models

In the hub-and-spoke model, large data centers serve as centralized hubs that all SD-WAN traffic must flow through. The spokes are the campuses, branch offices, and edge sites that connect to each hub in order to access the enterprise WAN.

Hub & Spoke

The hub-and-spoke SD-WAN deployment model can be executed in a couple of different ways:

Spoke-to-hub only

In this SD-WAN deployment model, the spokes for a particular hub are unable to communicate with each other, they can only interact with the central hub. The networking logic for this deployment model is relatively simple compared to the others. It’s also useful when spoke sites need to be isolated from each other for security, privacy, or regulatory reasons.

Spoke-to-spoke via hub

In this deployment, spoke sites can communicate with each other, but all of their traffic must pass through the central hub first. Again, this makes SD-WAN networking logic a little simpler than allowing direct communication between sites. It also allows spoke traffic to pass through a centralized firewall first so that traffic can be inspected and security policies can be applied without needing to deploy firewall appliances at each spoke site.

Hub-and-spoke pros and cons

The hub-and-spoke approach is relatively easy to deploy and manage because all SD-WAN traffic must flow through a limited number of hub data centers. There’s no need to configure, secure, and load-balance network traffic between the numerous spoke sites that comprise an enterprise network, so organizations that are adopting SD-WAN for the first time tend to favor this approach.

However, since all spoke traffic needs to pass through a centralized hub, this creates bottlenecks that can impact network performance for all connected sites. Centralized hubs also represent single points of failure for the spokes that rely on them for enterprise network access – if a hub goes down due to a cybersecurity breach, ISP outage, or equipment failure, then spokes will lose their ability to communicate with each other or access enterprise network resources. Plus, since all traffic and data are aggregated in centralized hubs, they present attractive targets to cybercriminals, who can easily get all the valuable data they want in a single location instead of needing to move around the network.

Hub-and-spoke best practices

If you’re considering the hub-and-spoke approach, it’s important to have a business continuity plan that accounts for hub failures. For example, you should have some sort of network failover option (such as cellular LTE) in case the ISP connection goes down. You should also be able to redirect traffic from one hub to another if the first hub gets overloaded or experiences a failure. In addition, hubs should be deployed with out-of-band (OOB) management so network admins have 24/7 management access even if the SD-WAN connection goes down.

Learn more about Out-of-band (OOB) management.

Mesh SD-WAN deployment models

In the mesh deployment model, campuses, branch offices, and edge sites have some ability to communicate with each other directly, without their traffic needing to pass through a hub first. The degree to which sites can interact with each other depends on the type of mesh topology that’s deployed.

Full mesh deployment

In a full mesh deployment, there is any-to-any communication between edge and branch sites using overlay tunnels. There are often still hub data centers to handle requests for centralized enterprise resources, but most other requests are handled by services deployed at the network edge (either at the sites themselves or in the cloud).

Mesh

Full mesh pros and cons

The full mesh topology enables faster communication between sites. It also allows organizations to deploy applications and services at the edge of the network where data is being generated and used, which is known as edge computing. There are also no single points of failure in the full mesh SD-WAN architecture, which reduces the risk of an outage and shortens the duration of outages that do occur. In addition, data and applications are distributed across many different locations, which can limit the damage caused by security breaches – instead of finding all your valuable data in a single server, cybercriminals have to jump around the network, increasing the chances they’ll be caught.

However, the full mesh topology is the most challenging to implement, manage, and optimize because there are so many moving parts involved. Each site needs a full stack of networking and security solutions because they aren’t relying on a centralized hub. Increasing the complexity of the SD-WAN architecture also increases the risk that mistakes will be made during configurations, deployments, and updates.

Partial mesh deployment

In this topology, some spokes can directly communicate with each other, and some services are deployed at the edge. However, there isn’t a full decentralization of applications and security, so some traffic still needs to pass through a hub.

Partial mesh pros and cons

Many organizations arrive at a partial mesh deployment on their journey from a hub-and-spoke deployment to a full mesh. A partial mesh topology reduces some of the load on centralized hubs and firewalls by moving certain services to the edge and allowing some direct site-to-site communications, which can improve performance. The organization can still rely on some centralized security functionality, reducing the number of security appliances or cloud-based services needed to protect the edge.

However, a partial mesh doesn’t completely address the limitations of a more centralized hub-and-spoke deployment. Hubs still represent potential bottlenecks and points of failure in the SD-WAN architecture. Plus, there’s still a lot of data centralization, meaning that storage and data processing servers in hubs will make attractive targets to hackers.

Hybrid mesh deployment

In a hybrid mesh, many hubs are deployed in a mesh topology, which means there is frequent communication and a high level of redundancy. However, branch and edge sites are still deployed as spokes, which means all their traffic goes through the hub mesh.

Hybrid Mesh

Hybrid mesh pros and cons

A hybrid mesh deployment ensures that no single hub acts as a single point of failure, enabling a high degree of redundancy and load balancing. Spoke sites can’t directly interact with each other, which reduces the complexity of the SD-WAN topology and decreases the number of security appliances to purchase and manage. Bottlenecking is also less of an issue because traffic from spokes doesn’t have to pass through a single designated hub, and can instead be distributed across multiple hubs.

However, a hybrid mesh topology is still fairly centralized, so you don’t get all the security and performance benefits of a decentralized full mesh deployment. Hubs are still valuable targets for cybercriminals, edge sites still need to send data to hubs for processing, and spokes cannot access enterprise network resources without going through the hub mesh. If that hub mesh is unavailable for any reason, spoke sites will be completely cut off.

Regional mesh

A regional mesh allows organizations to implement different deployment models for different regions. For instance, one region may have a spoke-to-spoke deployment, while another has a partial mesh. When traffic from one region needs to go to another, it must pass through a regional hub first.

Regional mesh pros and cons

The regional mesh model gives large or highly distributed organizations the flexibility to use deployments that meet the specific requirements of each region. For example, there may be a cluster of branch offices that process classified data for the defense industry, so the organization uses the spoke-to-hub-only deployment to isolate those sites from the rest of the enterprise network. In another region, the org may run a lot of edge computing for machine learning applications and need there to be fast and seamless communication between edge data centers. In that case, they might deploy a full mesh topology in that specific region.

However, this flexibility can also create a lot of management complexity. Admins need to learn, manage, and troubleshoot different configurations, network logic, and security rules for different regions. Plus, each region is subject to the downsides and limitations of whichever deployment model is used there. In addition, regional hubs often still act as potential bottlenecks and points of failure between each region and the enterprise network.

Mesh best practices

All of the best practices for the hub-and-spoke model also apply to mesh SD-WAN deployments. There are a couple of additional considerations for organizations considering a more decentralized deployment, including:

Cloud-delivered security – Mesh deployments typically require security solutions deployed at the edge, so that traffic doesn’t need to pass through a centralized firewall. However, purchasing appliances for each location is expensive and adds to the complexity of the architecture. Solutions like SSE (Security Service Edge) allow you to use your SD-WAN technology to send edge traffic through security services in the cloud. SSE takes many of the capabilities of traditional security appliances and combines them into a cloud-delivered stack, so organizations can get enterprise-level protection without needing to deploy additional hardware or route traffic through a central bottleneck.

Network automation – Manually configuring and controlling a complex mesh network increases the risk of human error. Luckily, SD-WAN’s software abstraction makes it easier to use automated scripts and playbooks to handle a lot of the tedious, repetitive tasks that are prone to mistakes such as device configurations and ACL (access control list) updates. Automation also means that work can get done faster and without putting additional pressure on overworked network teams.

Centralized orchestration – Mesh topologies have so many moving parts, and needing to manage each one of them separately makes it impossible to holistically control, optimize, and secure the deployment. Centralized orchestration gives network teams a common interface they can use to create, organize, deploy, monitor, and troubleshoot automated and manual SD-WAN workflows. That means the orchestrator should be vendor-neutral so it can dig its hooks into every device, application, and service in every SD-WAN site in your deployment.

Vendor neutrality – On that note, vendor neutrality is also a best practice because of how it simplifies and strengthens automation infrastructure. Many vendors lock you into using specific tools, applications, and devices, which makes automation pipelines more complicated and brittle — if one component breaks, the whole infrastructure goes down. Using vendor-neutral tools and orchestration platforms means you don’t have to inflate your toolkit or overcomplicate your automation pipeline, improving resiliency.

Choosing the right SD-WAN deployment model

Every SD-WAN topology comes with its own advantages and limitations, so organizations must assess their requirements and capabilities to determine which one to deploy. For example, if your team doesn’t have any SD-WAN experience, then jumping right into a full mesh deployment may not be practical. If you need your edge sites to have real-time data processing abilities (for example, in healthcare applications), then you may want to consider a less centralized mesh topology.

  Pros Cons
Hub-and-spoke
  • Easy to deploy
  • Reduced management complexity
  • Creates bottlenecks
  • Hubs are single points of failure
  • Centralized data is a target for hackers
Full mesh
  • Enables edge computing
  • No single points of failure
  • Decentralized data limits the blast radius of breaches
  • Complex implementation and management
  • Increases risk of human error
  • Requires edge or cloud-delivered security solutions
Partial mesh
  • Reduces some load on centralized hubs
  • Easier to deploy than a full mesh
  • Enables edge computing
  • Hubs can still create bottlenecks
  • Hubs are still potential points of failure
  • There is still some data centralization
Hybrid mesh
  • Enables a high degree of redundancy among hubs
  • Not as complex as a full mesh
  • Reduces bottlenecks
  • There is still some data centralization
  • There is still some bottlenecking
  • Hub mesh is still a point of failure
Regional mesh
  • Flexible and customizable
  • Addresses specific needs of individual sites and regions
  • Each regional hub is a potential point of failure
  • Variety of topologies creates a lot of management complexity
  • Subject to the downsides and limitations of all the deployment models in use

Ready to learn more about SD-WAN deployment models?

For more guidance on how to choose and implement SD-WAN deployment models, contact the experts at ZPE Systems. Contact Us