|
Vector Routing vs BGP By ZeroOutages In this document we will be discussing the different methods for deploying Internet/WAN redundancy for customers looking to increase reliability and obtain automated failover in the event of an Internet/WAN failure. Background In computer networks, such as the Internet, preventing a smaller portion of the network, or local network (one with only several connections to the rest of the network), from losing connectivity to the rest of the network can be accomplished by providing redundant paths to various points within the larger network. The Internet as a whole is based on a routing scheme that uses IP address information in order to determine where a packet of information needs to be sent. Vector Routing (by ZeroOutages) ensures redundancy by mitigating, and even eliminating network downtime by employing non-BGP multi-homing. The term “multi-homing” is used to describe a network that utilizes multiple connections to one or more Internet Service Providers (ISPs). Provisioning two or more connections to the Internet has become the primary means by which organizations build high availability into their access points. It used to be that only by implementing a routing protocol, known as Border Gateway Protocol (BGP), could an organization deploy a multi-homed solution. However, deploying BGP is costly, complex, and requires the cooperation of each of your ISP(s). In addition, network congestion is not something which is monitored by BGP and since it is congestion which causes over 50% of network traffic to be sent over sub-optimal routes, this is a significant limitation. Another significant disadvantage of BGP is that it is incapable efficiently load balancing traffic across multiple links, BGP is primarily a backup only solution. So when deploying a BGP-based multi-homed solution, the customer is not able to effectively use their secondary circuits, thus making this solution less cost effective. While there are a number of products today are capable of providing multi-link connectivity across two or more diverse paths, the problem with these solutions is that they do not do a good job of determining when a link has failed, or determine that a link has failed when in reality it only has momentary high latency. This failover still caused applications to stop and requires them to be reset, something that the ZeroOutages solution avoids using intelligent link outage detection, as part of our Multi-Level Outage Detection module. ZeroOutages Advantages Over BGP There are a number of advantages that the ZeroOutages service has over BGP. Our EdgeXOS enabled switching appliances are placed onsite at the customers’ location and without BGP are able to perform both automated failover and unlike BGP, they are also able to perform full link load balancing for inbound and outbound network traffic. Like BGP, Vector Routing is able to quickly failover, in fact Vector Routing along with our ActiveDNS technology is able to failover traffic within 30 seconds or less. Our ActiveDNS technology is even able to instantly cut over inbound server connections when in load balancing mode, whereas BGP requires a propagation time which could take up to several minutes to complete. When combined with our Best Path Routing technology the EdgeXOS switching appliances can also provide network specific route optimization, i.e. route traffic across the most efficient link based on its destination. BGP is capable of this, but it must be specifically configured and is generally not something which is done. Vector Routing uses a number of metrics to determine how to best balance traffic between links, including link usage, latency, sessions per link, and packet loss whereas BGP only basis its decisions on and up/down metric. Vector Routing also takes into account weighting assigned by the administrator for each link. Finally, unlike BGP, Vector Routing uses intelligent outage detection to determine if an outage has technology occurred due to high latency and/or packet loss. Technical Overview The EdgeXOS platform by ZeroOutages utilizes Vector Routing, which is a method for efficiently and accurately redirecting end-to-end communications sessions over the most appropriate network path when two or more diverse network paths are available without adding unneeded delay. This ensures a lower cost of total ownership and thus a higher ROI. Vector Routing’s diverse path selection is based on the continued measurement of multiple predefined remote nodes via two or more diverse network paths to a larger external network. This is accomplished via Multi-Path Probing, and Real World Monitoring. By monitoring these remote nodes and gathering specific data measurements via each diverse network path, the Vector Routing module (software code) running on the EdgeXOS platform can determine which diverse path traffic should sent. If the Vector Routing module determines that all paths are operating normally, local network traffic is equally distributed across the multiple network paths. Load balancing can be applied via Vector Routing’s Flexible Bandwidth Management. Using our flexible bandwidth manager, network administrators can determine what percentage of traffic they wish to forward over each of their diverse network paths. Unique to the EdgeXOS platform, these percentages can be applied per “critical network” (see Best Path Routing – White Paper). In accord with the path selection by the Vector Routing module our ActiveDNS daemon running on the EdgeXOS platform can also be updated so that only those IP addresses of the network interfaces which a associated with the active network paths are provided in DNS responses to request made from external DNS clients. The purpose of using diverse network path monitoring and route selection based on the analysis of the monitoring is to replace the existing complex and costly routing protocols used by many network routers today while still providing a more detailed status of the overall network path that many routing protocols do very well. At the same time, the reduced complexity ensures the lower overall cost of the Vector Routing enabled products. Technical Details The following is a detailed diagram of how Vector Routing technology works with both outgoing and incoming Internet connections. As shows how outbound connectivity can be load balanced across multiple links and how inbound communications from remote clients can be automatically redirected in the event of a link failure.
Reference is now made to FIG. 1 that provides the general flow of vector routing. Vector Routing in this diagram consists of two diverse network paths connected to the XRoads Edge which is running the Vector Routing module (software code). The two networks paths consist of broadband connection devices 13 and 14, logical broadband data connections 16, their associated networks 20 and 21 and the larger external network (in this case the Internet) 24. To ensure that the local network 11 has the is optimally using the two diverse network paths, the XRoads Edge 12 sends probes via ICMP to multiple remote nodes 25, and 26 via both networks 20 and 21 to gather network measurements for those remote nodes via each network path, including latency, packet loss, and calculated jitter. These measurements are then stored within the XRoads Edge for later comparison and manipulation by the Vector Routing algorithm to determine whether each diverse network path is still within the acceptable range and whether the route for that path should remain in the apparatus’ routing table and DNS daemon. Assume that for some reason the network path through ISP B 21 is unable to provide connectivity from vector router 12 to the remote nodes 25 and 28. The vector router 12 would detect this via its probing and algorithm and change its routing table to reflect this change. The Vector Routing module within the XRoads Edge 12 would also set all IP addresses assigned to the Edge’s network interface card of the associated non-acceptable network path within the DNS daemon to inactive thus causing DNS responses to no longer provide those IP addresses to DNS clients. During the next interval that the client 32 requests the DNS information for the remote server 10, the address has been updated and now the client 32 will use the secondary inbound connection 18 through ISP A 20 to maintain the communication session(s).
Visit ZeroOutages at the Channel Partners Trade
Show ZeroOutages will be sponsoring the Educational Training Track at the trade show Click here to become an agent for ZeroOutages.com
or contact Daren French at
|
