In Part 1, I talked about how OpenFlow could commoditize hardware in the network visibility fabric market. In this post, I’ll focus on intelligent network load balancing.
Intelligent Network Load Balancing
I’m not quite sure where these products fit in terms of industry analysts and product market share, but I’m referring to companies such as FatPipe and Talari. You may have heard of them or even deployed them. Sales pitches are usually about optimal load balancing, intelligent load balancing, virtual WAN topology, aggregating multiple ISP/WAN circuits, and increased traffic utilization without the need for complex routing protocols such as BGP and OSPF. All good stuff.
It seems they are doing flow analysis and choosing a next hop gateway to send the traffic to based on source IP, dest IP, port, proto, etc. Like with network visibility fabrics mentioned in Part 1, these devices are allowing an admin to define traffic types in the form of ACLs, maybe even with SLAs around them, and then defining where to forward that traffic. For example, if you deploy these black boxes in a HQ data center and a remote site (most need a pair of boxes to get started- 1 per site), and in between them there are a few circuits (Internet + WAN), there is some communication between the boxes (communication channel and some use an overlay) calculating bandwidth and latency characteristics such that low latency traffic or traffic deemed important can be sent to a WAN while other traffic is distributed out the one or more ISPs with rapid failover. These devices can sit in front of a bank of WAN routers or firewalls to distribute load as well going out to the Internet. Not having NAT in these deployments further simplifies things. The intelligence being gathered and actions being taken by these boxes seems perfect for OpenFlow controller based solutions.
What can be done here with OpenFlow, controllers, and the world of SDN?
Well, I actually came across this part of the market and the companies mentioned above after I had an idea of my own for a company and did some research, so here is a brief summary of my thought process along with the slides I created several months ago.
One thing is for sure and that is we haven’t even scratched the surface with what can be done with a centralized view and topology of the network.
Here are my slides that I mentioned above that I created a few months back when I first had this idea not realizing there were black boxes doing this sort of thing on the WAN/Internet edge today.
I’m not quite sure where these products fit in terms of industry analysts and product market share, but I’m referring to companies such as FatPipe and Talari. You may have heard of them or even deployed them. Sales pitches are usually about optimal load balancing, intelligent load balancing, virtual WAN topology, aggregating multiple ISP/WAN circuits, and increased traffic utilization without the need for complex routing protocols such as BGP and OSPF. All good stuff.
It seems they are doing flow analysis and choosing a next hop gateway to send the traffic to based on source IP, dest IP, port, proto, etc. Like with network visibility fabrics mentioned in Part 1, these devices are allowing an admin to define traffic types in the form of ACLs, maybe even with SLAs around them, and then defining where to forward that traffic. For example, if you deploy these black boxes in a HQ data center and a remote site (most need a pair of boxes to get started- 1 per site), and in between them there are a few circuits (Internet + WAN), there is some communication between the boxes (communication channel and some use an overlay) calculating bandwidth and latency characteristics such that low latency traffic or traffic deemed important can be sent to a WAN while other traffic is distributed out the one or more ISPs with rapid failover. These devices can sit in front of a bank of WAN routers or firewalls to distribute load as well going out to the Internet. Not having NAT in these deployments further simplifies things. The intelligence being gathered and actions being taken by these boxes seems perfect for OpenFlow controller based solutions.
What can be done here with OpenFlow, controllers, and the world of SDN?
Well, I actually came across this part of the market and the companies mentioned above after I had an idea of my own for a company and did some research, so here is a brief summary of my thought process along with the slides I created several months ago.
- Develop a solution that leverages commodity hardware and OpenFlow controllers that does what some of the commercial solutions do today that are using black boxes. Sell this to whoever needs a scale out solution for WAN routers, VPN gateways, Internet routers, etc. Solution also fits well for “Lead IT” shops that do not want to be bothered configuring routing protocol metrics, or want to use more source based routing techniques on the edge. Goal: keep current routers and network devices in place, but seamlessly insert these new middle commodity boxes to get more intelligent with how traffic is distributed.
- In that model, the existing network is unaffected, i.e. FWs and WAN/ISP routers stay right where they are. The next phase would be integrating with something like RouteFlow and an ACL/FW application that could offer the ability to not just sit in the middle of WAN routers and the core network anymore, but possibly they commodity switch + OF controller becomes the WAN router. When it came time for an upgrade, maybe a license is sold to enable BGP and a traditional router wouldn't be needed anymore. All about a phased approach with an end goal to simplify the deployment while adding more central intelligent.
- Speaking of edge, the same platform could be used to connect to L4-L7 network services, both physical and virtual, as long as they connect to OpenFlow switches. After all, the solution is all about intelligent load balancing. In this part of the network, there could be banks of load balancers or firewalls or VPN servers, IPSs. Doesn't matter, some of the same device type could even share the same IP Address. Maybe all traffic destined to social media sites goes through FW A with IP A, but traffic coming from executives go through FW A with IP A, etc. Assigning the same IP doesn’t have to be done of course, but as you can see, you can have a scale out FW platform with intelligent traffic distribution, not just packet spray across them or have to create VRFs to get traffic to a certain VRF. This also gives the option to create a multi-vendor FW cluster, maybe DPI with Palo Alto for certain traffic and then a Cisco ASA for other types of traffic. How would you do this today? Would you be stuck with destination based routing and large quantities of load balancers?
One thing is for sure and that is we haven’t even scratched the surface with what can be done with a centralized view and topology of the network.
Here are my slides that I mentioned above that I created a few months back when I first had this idea not realizing there were black boxes doing this sort of thing on the WAN/Internet edge today.
RSS Feed
