All use cases result in big benefits in operating efficiency and reduced CAPEX costs
When implementing a load balancing mechanism in your network architecture, here are some of the questions that should be be addressed:
What is being balanced and how (and what are the load balancing rules)?
Should the load balancing mechanism be combined with filtering to achieve better results? For example, first filter by the HTTP traffic, and then only load balance that filtered traffic?
Load balancing mechanism is an end to a means and not an end in-and-of-itself. Since multiple network tools participate in the load balancing process, the network manager should look at the implementation as a whole:
And of course, how to handle the reverse, recovery process: detecting that the network tool is back online, and what traffic if any to send to it? Also, whether any of these processes should be automatic or only enabled by user intervention?
❕For example, in case of network tool failure, you may want to automatically re-distribute traffic to the remaining tools, or to perhaps decide not to handle that traffic, because the remaining tools cannot handle the extra capacity, and diverting more traffic to them will reduce their performance efficiency. This decision may also be impacted by whether the load balance mechanism is for in-line cybersecurity tools or for out-of-band monitoring tools. In case of inline tools being load balanced, you may prefer to send the traffic that was going to the failed tool, to be rerouted (bypassed) to the network.
At Niagara Networks, we understand that your ability to quickly and easily implement an efficient and flexible load balancing policy can be the key to a successful deployment of cybersecurity & monitoring tools on the visibility layer.
Sophisticated load balancing capabilities are available as standard on all Niagara Network Packet Brokers and at all network interface speeds.
A load balance policy can be configured per device. This means that any group of ports and multiple groups of ports can be assigned this same device policy. In addition to the device policy, a separate custom policy can be defined, allowing multiple different load balance policies to be supported at the same time.
Given the increasing port density of Network Packet Brokers and the increasing support of different speeds and feeds ranging from 1/10Gb to 40/100Gb, the ability to support concurrently different load balance policies affords the network manager and security architect unparalleled flexibility.
Implementing and configuring load balance flows, as well as the desired action in case of an appliance failure in the load balance port group can be a very complex, error-prone, and time-consuming endeavor.
At Niagara Networks, options are available with a click of a button, and setting-up complex load balance implementation on inline appliances is made easy and intuitive.
At Niagara Networks, we understand that setting up a successful load balance implementation is not only about the policy on what parameter to use in load balancing the traffic. In an integrated approach, we also enable the definition and setup of heartbeat packets.
Heartbeat packets are proactively generated on the connected appliance port to determine its availability.
In an integrated approach, we also enable the definition of whether to re-distribute traffic to the remaining available appliances in the port group. In case of failure, traffic will be automatically re-distributed without manual user intervention or setup, thus increasing service availability and optimizing resource usage and uptime.
Combine device and multiple custom policies in a platform
- Monitoring and Inline ports
- Interval settings
- Port bypass
- Traffic distribution
- Traffic re-distribution
- Includes traffic- steering, load balancing, routing traffic via different ports, deactivating links, performing fail-over of traffic, and more
- Multiple headers support
- XOR option between selected headers
Today, enterprises are utilizing the advanced features found in superior NPBs. investing in additional solutions such as public cloud and virtual fabric technologies is not only the norm, it’s a necessity.
Download our white paper for an in-depth look at current usage and emerging best practices for network visibility fabrics and network packet brokers.