Patent Application
20210392074
A wide area network (WAN) may extend across multiple network sites (e.g. geographical, logical). Sites of the WAN are interconnected so that devices at one site can access resources at another site. In some topologies, many services and resources are installed at core sites (e.g. datacenters, headquarters), and many branch sites (e.g. regional offices, retail stores) connect client devices (e.g. laptops, smartphones, internet of things devices) to the WAN. These types of topologies are often used by enterprises in establishing their corporate network.
Each network site has its own local area network (LAN) that is connected to the other LANs of the other sites to from the WAN. Networking infrastructure, such as switches and routers are used to forward network traffic through each of the LANs, through the WAN as a whole, and between the WAN and the Internet. Each network site's LAN is connected to the wider network (e.g. to the WAN, to the Internet) through a gateway router. Branch gateways (BGs) connect branch sites to the wider network, and head-end gateways (also known as virtual internet gateways) connect core sites to the wider network.
Often, WANs are implemented using software defined wide area network (SD-WAN) technology. SD-WAN decouples (logically or physically) the control aspects of switching and routing from the physical routing of the network traffic. In some SD-WAN implementations, each gateway (BGs and head-end gateways) controls certain aspects of routing for their respective LAN, but a network orchestrator controls the overall switching and routing across the WAN.
For a more complete understanding of the present disclosure, examples in accordance with the various features described herein may be more readily understood with reference to the following detailed description taken in conjunction with the accompanying drawings, where like reference numerals designate like structural elements, and in which:
certain examples have features that are in addition to or in lieu of the features illustrated in the above-referenced figures. Certain labels may be omitted from certain figures for the sake of clarity.
In a software-defined wide area network (SD-WAN), gateways between site local area networks (LANs) and the broader SD-WAN may be single points of failure for portions of the SD-WAN. For example, a single branch gateway (BG) for a large branch site LAN may disrupt SD-WAN access for many client devices (e.g. laptops, cell phones, servers, IoT devices) of the branch site LAN, and access by client devices across the SD-WAN to services provided from the branch site LAN. To combat a single point of failure, multiple redundant gateways may be deployed in a high availability (HA) configuration to preserve network functionality when a gateway fails.
When BGs are deployed in a HA configuration, they are commonly deployed in an “Active-Standby” configuration where one of the BGs (“Active”) routes data traffic between its branch site LAN and other site LANs of the SD-WAN, and another of the BGs (“Standby”) is idle as long as the Active BG is functioning properly.
In some other HA deployments, BGs are deployed in an “Active-Active” configuration where each of the BGs routes some portion of data traffic between the branch site LAN and other site LANs of the SD-WAN. Certain client devices may be assigned to a first BG of the branch site LAN and other client devices may be assigned to a second BG of the branch site LAN. In many such deployments, default gateway parameters of each client devices' network configuration may be configured to the respective assigned BG.
In some such deployments, client devices are organized into virtual local area networks (VLANs), and each VLAN is assigned to a respective BG. For example, a branch site LAN with VLANs 1-10 may assign even numbered VLANs (2,4,6,8,10) to a first BG of the branch site LAN, and assign odd numbered VLANs (1,3,5,7,9) to a second BG of the branch site LAN. Often, these VLAN assignments required large amounts of manual configuration by a network administrator to ensure that data traffic from client devices in a certain VLAN was routed through the branch site LAN to the correct BG.
However, some HA deployments may use virtual router redundancy protocol (VRRP) to reduce the amount of configuration required across multiple devices on the branch site LAN. VRRP, in essence, creates a virtual router (in this case, a virtual branch gateway) with an IP address that client devices use as the default gateway in their network configurations. Then, based on the configurations of the BGs, packets sent to the virtual router are routed through a master BG (which, in “Active-Standby” configurations, is the active BG). In order to establish virtual routing in an “Active-Active” configuration, multiple virtual routers (aka “VRRP instances”) may be created on a per-VLAN basis, and a master BG is assigned for each VLAN. Similar to how it is mentioned above, VLANs may be assigned to BGs in a round-robin format (even numbered VLANs to a first BG, odd numbered VLANs to a second BG), or using any methodology appropriate to the context.
Even though this rudimentary assignment of VLANs to BGs can roughly balance network traffic load across the BGs of the branch site LAN, there is no guarantee that each VLAN will include the same number of client devices, nor that each client device will have similar network usage requirements and patterns. For example, VLAN 2 may include multiple edge compute devices that transceive large amounts of network traffic, but VLAN 7 may include multiple personal mobile phones that only occasionally transceive more than a trivial amount of network traffic. In a topology where even numbered VLANs are deployed to a first BG and odd numbered VLANs are deployed to a second BG, the first BG may be overloaded (due, in part, to devices on VLAN 2) and the second BG may have spare capacity (due, in part, to devices on VLAN 7).
In this disclosure, such imbalances are detected, and VRRP instances for certain VLANs are reconfigured so that traffic for those certain VLANs are routed through another BG. Extending the previous example, VRRP instances for VLANs 4 and 6 may be reconfigured so that the master BG for those VRRP instances is the second BG. Then, network traffic load may be more evenly balance between the master BG and the second BG. In some situations, the load imbalance between the BGs may be due to a temporary phenomenon (e.g. a group of client devices on a certain VLAN each temporarily engaging in certain network traffic heavy activities). In such situations, the assignments of VLANs to BGs may be re-adjusted to a baseline configuration after the temporary phenomenon ceases.
Certain network infrastructure devices (e.g. switches, access points) of the branch site LAN may include the capability to adjust assignment of devices to VLANs when notified that they are operating in a HA network. For example, the network infrastructure devices, when notified of the HA topology of the network, may assign each successively added client device a VLAN from a pool of VLANs in a round-robin fashion. This prevents an imbalance of assigned clients between VLANs, which could cause load imbalance issues between the BGs.
Each BG, beyond just routing packets, may include packet services. For example, BGs may execute content classification and deep packet inspection services. While a BG may have the bandwidth required to simply route the network traffic passing through, it may not have the resources available to perform the content classification and deep packet inspection services on the network traffic. Network traffic load for a BG takes into account the load imparted on all resources of the BG, including on the resources that provide packet services.
Although the network infrastructure devices are made aware of the HA topology of the network, individual clients may cause more load on the BG than others. In such situations, even though clients have been allocated in a round-robin (or other appropriate) fashion, certain VLANs may still have an outsized impact on the network traffic load of a certain BG. In such situations, the network infrastructure devices may be given instructions to attempt to alleviate the load imbalance in particularly outsized VLANs. For example, network infrastructure devices may be instructed to temporarily cease adding new clients to a certain VLAN. As another example, network infrastructure devices may be instructed to move certain existing clients from a first VLAN to a second VLAN.
In some examples, the network traffic load for each BG may be determined on each respective BG. In some other examples, network traffic load information is forwarded to a network orchestrator that calculates network traffic load factors for each BG. In yet other examples, one of the BGs collects network load information from all BGs of the branch site LAN and calculated network traffic load factors for each BG. Once network traffic load factors are calculated for each BG, a network traffic load skew is determined. If the skew is greater than a certain threshold, remediation measures, as discussed in the previous paragraphs, are implemented to reduce the skew and balance the load across the BGs. Depending on the specific network topology, the remediation measures may be determined and executed by the network orchestrator, a master BG, each BG, or any combination thereof. In some examples, the BGs may include network controllers that, while logically separated from the datapath routing components of the respective BGs, may be collocated in the same BG device. In certain such examples, management of the branch site LAN may be reserved for these network controllers. In certain other such examples, management of the branch site LAN may be orchestrated by a network orchestrator of the SD-WAN in conjunction with the network controllers of the BGs.
The features of this disclosure improve the performance of SD-WANs by rerouting network traffic to take advantage of available BG bandwidth. The resulting improved performance may reduce jitter, latency, and other measures of degrading network efficiency, as well as improve quality of service for time sensitive applications, such as voice over IP.
In some examples, each VLAN 114 is assigned to a certain infrastructure device 112 so that only client devices of the infrastructure device 112 are assigned to VLANs 114 of the infrastructure device 112. In some other examples, each VLAN 114 is independent of infrastructure devices 112, and client devices are assigned to a VLAN 114 based on some criterion or combination of criteria. Some example criteria include selection of VLAN for each successive client device by round-robin format, assignment to VLAN by network role (e.g. employee personal device VLAN, point of sale VLAN), assignment to VLAN by expected network bandwidth usage (e.g. large network bandwidth users are separated into different VLANs).
Client devices of branch site LAN 102 can communicate with one another through infrastructure device 112 (including ones not shown but implied in the branch site LAN 102 cloud). Client devices of branch site LAN 102 can also communicated with devices outside of branch site LAN 102. Any data traffic transceived between a client device of branch site LAN 102 and a device outside of branch site LAN 102 passes through a BG 104. SD-WAN 100 includes two BGs 104a and 104b in branch site LAN 102. BGs 104a and 104b may serve multiple purposes, including high availability (HA), such as uninterrupted failover when one of the BGs fails, and load balancing. The BGs may be configured to enable virtual router redundancy protocol (VRRP), which is a protocol for implementing HA across two routers (or branch gateways). VRRP generates a virtual gateway 116 associated with a virtual IP (VIP) address. Client devices set their default gateway in their network settings to point to the VIP, and the packets are forwarded to the appropriate BG 104 depending on the VRRP configuration. A VRRP instance, once configured, establishes ones of the BGs 104 as a master. The master routes all traffic sent to the VIP. For example, if a VRRP instance is established between BG 104a and BG 104b assigning the VIP 192.168.100.4 to the instance and assigning BG 104a as the master. All client devices configured with their default gateway as 192.168.100.4 have their traffic routed through SD-WAN 100 by BG 104a.
In many SD-WANs, redundant BGs configured with a VRRP instance are deployed in an “Active-Standby” mode, where the active BG (e.g. the VRRP master) routes all inbound and outbound traffic for the entire branch site LAN, and the standby BG sits idly until the active BG (or its connectivity to either the wider network or to the branch site LAN) fails. This is sufficient for the HA needs of the SD-WAN, but is inefficiently using the resources of the BGs. A network administrator could disable VRRP and manually configure each client device to point to BG 104a or BG 104b, but this solution is not scalable to larger deployments and does not adapt to changing network conditions.
In some SD-WANs, redundant BGs can be deployed in an “Active-Active” mode, where each BG 104 routes a portion of inbound and outbound traffic for branch site LAN 102. However, a VRRP instance cannot balance load between its master gateway and its backup gateway. All traffic sent to the VIP of a VRRP instance is sent to the master gateway of the instance. Alternatively, to enable “Active-Active” mode, multiple virtual gateways 116 can be created from multiple simultaneously running VRRP instances, and each VLAN 114 can have a different VIP assigned as default gateway. For example, VLAN 114a can point to a first VIP that routes network traffic through BG 104a, VLAN 114b can point to a second VIP that routes network traffic through BG 104b, VLAN 114c can point to a third VIP that routes network traffic through BG 104a, and VLAN 114d can point to a fourth VIP that routes network traffic through BG 104b. In some examples, VLANs are created, numbered, and populated sequentially, and even numbered VLANs are assigned to a first BG (BG 104a) and odd numbered VLANs are assigned to a second BG (BG 104a).
Although these multiple VRRP instances shift a large portion of the overall network traffic load from one BG to another, it is still possible that the load on BG 104a is greater than the load on BG 104b or vice versa. Not all client devices use network bandwidth in the same way. For example, edge compute devices may use large amounts of bandwidth on a generally constant basis to synchronize data with compute devices in other LANs, such as core site LAN 108. Employee laptops may instead make occasional data transactions with other LANs, but more consistently use bandwidth to access sites and services on Internet 106. Point of sale devices and kiosks, as another example, may mostly use bandwidth in the branch LAN and only occasionally use broader network bandwidth. As such, even though VLANs have been distributed between BG 104a and BG 104b, network performance may degrade when devices of a certain VLAN use a disproportionate amount of bandwidth.
BGs 104 each monitor the load on their hardware and logical resources due to the network traffic routed by the respective BG 104 and occasionally transmit network traffic load information to network orchestrator 110. In some examples, BGs 104 transmit the raw load information to network orchestrator 110, which calculates network traffic load factors from the load information. In some other examples, BGs 104 calculate network traffic load factors based on the network traffic load information and transmit the network traffic load factors to network orchestrator 110. Network orchestrator 110 then compares the network traffic load factors for each BG 104 to a network traffic load threshold (either a universal threshold or a custom tailored threshold for each BG 104). If, for example, the network traffic load factor for BG 104a is greater than the network traffic load threshold, then network orchestrator 110 may begin remediation of the overload of BG 104a. Next, network orchestrator 110 may calculate a network traffic load skew between BG 104a and BG 104b. The network traffic load skew represents the relative loading of each BG 104. For example, if all VLANs are assigned to BG 104a and BG 104b is idle (Active-Standby configuration), the network traffic load skew between BG 104a and BG 104b will be quite large. On the other hand, if VLANs are distributed evenly between BGs 104a and 104b, and client devices on each VLAN have roughly the same usage as client devices of the other VLANS, the network traffic load skew will be small. Network orchestrator 110 may compare the network traffic load skew between BG 104a and BG 104b to a skew threshold. If the skew is above the threshold, then network orchestrator 110 will proceed to remediate the overload of BG 104a.
In some examples, network orchestrator 110 may determine the network traffic load factor based on the respective numbers of devices in each VLAN. For example, BG 104a may be considered overloaded when the number of devices in the VLANs assigned to BG 104a are greater than a threshold.
Network orchestrator 110 may have multiple tools at its disposal to remediate the overload of BG 104a. Although these tools are described as network orchestrator 110 issuing reconfiguration commands to various network infrastructure devices of SD-WAN 100, in some examples, network orchestrator 110 transmits commands to a network controller (residing on branch gateway 104a or 104b) of branch site LAN 102, and the network controller issues a separate command to the respective network infrastructure devices.
One such tool reassigns the master BG of a VRRP instance. For example, network orchestrator 110 may determine that the network traffic loads of BG 104a and BG 104b will be better balanced by moving traffic from VLAN 114a from BG 104a to BG 104b. Network orchestrator 110 will then issue a command to BG 104a and BG 104b to alter the VRRP instance associated with VLAN 114a to change the master BG from BG 104a to BG 104b. Later, if network orchestrator 110 determines that the network conditions that required VLAN 114a to be moved from BG 104a to BG 104b have ceased, network orchestrator 110 may transmit a command to BG 104a and BG 104b to alter the VRRP instance associated with VLAN 114a to change the master BG from BG 104b to BG 104a.
Another such tool alters the way that client devices are assigned to VLANs by certain infrastructure devices 112 that support receiving such commands. Certain access points and switches may support receiving messages that indicate that BGs 104 are operating in a HA configuration, and may further support receiving messages that cause the infrastructure device 112 to alter the method for assigning new client devices to VLANs and/or reassign existing client devices to different VLANs. For example, network orchestrator 110 may instruct infrastructure device 112b to no longer assign new client devices to VLAN 114c because VLAN 114c uses a disproportionately large amount of the bandwidth of BG 104a. As another example, network orchestrator 110 my instruct infrastructure device 112a to move a kiosk device from VLAN 114a to VLAN 114b because the kiosk device, in combination with other kiosk devices, is using a disproportionately large amount of the bandwidth of BG 104a. In yet another example, network orchestrator 110 may notify infrastructure devices 112 that BGs 104a and 104b are operating in a HA configuration, and infrastructure devices 112 may alter their client assignments to VLANs 114 based on that notification.
Although
Since BG 104a has a network traffic load factor greater than threshold 202a, BGs 104 may determine a network traffic load skew between BG 104a and BG 104b. The skew is compared to a load skew threshold to determine whether remediation of the overload of BG 104a can be achieved. If, for example, BG 104a were overloaded and BG 104b were only slightly less than overloaded (thus resulting in a low skew), shifting load from one BG to another may only shift the overload from BG 104a to BG 104b. However, if BG 104a is overloaded and BG 104b has significant available bandwidth (thus resulting in a high skew), shifting load from BG 104a to BG 104b may improve network performance. Since the network traffic load skew between BG 104a and BG 104b is high (not shown), SD-WAN 100 remediates the overload of BG 104a.
In
In block 402, network traffic load information is collected for a first branch gateway and a second branch gateway. In some examples, network traffic load information is a set of device counts for each VLAN assigned to the first gateway and a set of device counts for each VLAN assigned to the second gateway. In some other examples, network traffic load information can include branch gateway usage information, such as packet buffer usage, cpu usage, packet service resource usage, etc.
In block 404, network traffic load factors are calculated for the first branch gateway and the second branch gateway, based on the respective network traffic load information collected in block 402. In some examples, the network traffic load factor is a sum of the set of device counts for each VLAN assigned to the respective gateway. In some other examples, the network traffic load factor is determined using a weighting algorithm to weight various branch gateway usage measurements for each branch gateway.
In block 406, it is determined whether the network load factor of the first BG is greater than the network traffic load factor of the second BG. If yes, then method 400 proceeds to block 408. If no, then method 400 terminates. In some examples, the network load factor of the first BG is also compared to a network load factor threshold, so that the method does not proceed unless the network load of the first BG is not above a certain critical level.
In block 408, it is determined whether a network traffic load skew between the first BG and the second BG is greater than a threshold. In some examples, the network traffic load skew is the difference between the network traffic load factor of the first BG and the network traffic load factor of the second BG. For example, if both the first BG and the second BG are experiencing high network traffic loads, the network traffic load skew may be low even though the determination of block 406 may be “yes”.
In block 410 a first virtual local area network (VLAN) is selected from a set of VLANs of a local area network (LAN). The first VLAN may be chosen due to network load characteristics (e.g. user count, latency, jitter, QoS requirements, etc.) The first VLAN may be chosen also due to being assigned to the first BG. In some examples, the first VLAN may be selected because moving the first VLAN from the first BG to the second BG may resolve overutilization of BG resources.
In block 412, a message is transmitted to the first and second BGs (or, alternatively, to an assigned leader BG) that assigns the master role for the first VLAN to the second BG. In some examples, the message is sent from a network orchestrator on a cloud device to the BGs of the LAN. The message may be a VRRP reconfiguration message the causes the VRRP instance for the first VLAN to be reconfigured with different costs such that the second BG becomes master of the VRRP instance.
In block 502, network traffic load information is collected for a first branch gateway and a second branch gateway. In some examples, network traffic load information is a set of device counts for each VLAN assigned to the first gateway and a set of device counts for each VLAN assigned to the second gateway. In some other examples, network traffic load information can include branch gateway usage information, such as packet buffer usage, cpu usage, packet service resource usage, etc.
In block 504, network traffic load factors are calculated for the first branch gateway and the second branch gateway, based on the respective network traffic load information collected in block 502. In some examples, the network traffic load factor is a sum of the set of device counts for each VLAN assigned to the respective gateway. In some other examples, the network traffic load factor is determined using a weighting algorithm to weight various branch gateway usage measurements for each branch gateway.
In block 506, it is determined whether the network load factor of the first BG is greater than the network traffic load factor of the second BG. If yes, then method 500 proceeds to block 508. If no, then method 500 terminates. In some examples, the network load factor of the first BG is also compared to a network load factor threshold, so that the method does not proceed unless the network load of the first BG is not above a certain critical level.
In block 508, it is determined whether a first network traffic load skew between the first BG and the second BG is greater than a threshold. In some examples, the first network traffic load skew is the difference between the network traffic load factor of the first BG and the network traffic load factor of the second BG. For example, if both the first BG and the second BG are experiencing high network traffic loads, the first network traffic load skew may be low even though the determination of block 506 may be “yes”.
In block 510 a first virtual local area network (VLAN) is selected from a set of VLANs of a local area network (LAN). The first VLAN may be chosen due to network load characteristics (e.g. user count, latency, jitter, QoS requirements, etc.) The first VLAN may be chosen also due to being assigned to the first BG. In some examples, the first VLAN may be selected because moving the first VLAN from the first BG to the second BG may resolve overutilization of BG resources.
In block 512, a message is transmitted to the first and second BGs (or, alternatively, to an assigned leader BG) that assigns the master role for the first VLAN to the second BG. In some examples, the message is sent from a network orchestrator on a cloud device to the BGs of the LAN. The message may be a VRRP reconfiguration message the causes the VRRP instance for the first VLAN to be reconfigured with different costs such that the second BG becomes master of the VRRP instance.
In block 514, updated network traffic load factors are calculated for the first branch gateway and the second branch gateway, based on updated network traffic load information. In some examples, the updated network traffic load factor is a sum of the set of device counts for each VLAN assigned to the respective gateway. In some other examples, the updated network traffic load factor is determined using a weighting algorithm to weight various branch gateway usage measurements for each branch gateway.
In block 516, it is determined whether the updated network load factor of the first BG is greater than the updated network traffic load factor of the second BG. If yes, then method 500 proceeds to block 518. If no, then method 500 terminates. In some examples, the updated network load factor of the first BG is also compared to a network load factor threshold, so that the method does not proceed unless the updated network load of the first BG is not above a certain critical level.
In block 518, it is determined whether a second network traffic load skew between the first BG and the second BG is greater than a threshold. In some examples, the second network traffic load skew is the difference between the updated network traffic load factor of the first BG and the updated network traffic load factor of the second BG. For example, if both the first BG and the second BG are experiencing high network traffic loads, the second network traffic load skew may be low even though the determination of block 516 may be “yes”.
In block 520, a message is transmitted to the first and second BGs (or, alternatively, to an assigned leader BG) that assigns the master role for the first VLAN to the first BG. In some examples, the message is sent from a network orchestrator on a cloud device to the BGs of the LAN. The message may be a VRRP reconfiguration message the causes the VRRP instance for the first VLAN to be reconfigured with different costs such that the first BG becomes master of the VRRP instance.
Network orchestrator 602 includes instructions 610a in memory 608a that, when executed by processor 606a, cause network orchestrator 602 to undertake certain actions. For example, instructions 610a may include instructions to monitor a first set of load parameters for branch gateway 604a, including a utilization factor for a deep packet inspection service provided by BG 604a and a utilization factor for a content classifier service of BG 604a. In some examples, the utilization factors for the services are weighted hardware usage metrics for each service (e.g. CPU usage, network interface card usage).
Instructions 610a may also include instructions to monitor a second set of load parameters for branch gateway 604b, including a utilization factor for a deep packet inspection service provided by BG 604b and a utilization factor for a content classifier service of BG 604b. In some examples, the utilization factors for the services are weighted hardware usage metrics for each service (e.g. CPU usage, network interface card usage).
Instructions 610a may also include instructions to periodically calculate a network traffic load for BG 604a based on the first set of load parameters and a network traffic load for BG 604b based on the second set of load parameters. The network traffic loads for BGs 604a-b may be load factors (i.e. numerical indications of the load on each BG 604).
Instructions 610a may also include instructions to update a network traffic load skew indicating a difference in traffic loads between BG 604a and BG 604b. In some examples, the network traffic load skew is the numerical difference between the traffic loads. The greater the inequality of loading between BG 604a and BG 604b, the larger the network traffic load skew.
Instructions 610a may also include instructions to determine that the network traffic load for BG 604a is greater than an overload threshold. Even though loads may be imbalanced between BG 604a and BG 604b, if neither BG 604 is overloaded, there may not be performance improvement by rebalancing clients across the BGs 604. Therefore, if BG 604a is not overloaded, network orchestrator 602 may not attempt to alleviate the load on BG 604a by transferring some clients to BG 604b.
Instructions 610a may also include instructions to determine that the updated network traffic load skew is greater than a skew threshold. Even though BG 604a may be overloaded, BG 604b may also be overloaded, and there may not be performance improvement by rebalancing clients across the BGs 604. Therefore, if the updated network traffic load skew is less than the skew threshold, network orchestrator 602 may not attempt to alleviate the load on BG 604a by transferring some clients to BG 604b.
Instructions 610a may also include instructions to transmit a message to BGs 604, who may forward the message to a switch, AP or other infrastructure device communicatively couple with a client device of a first VLAN. The first VLAN may be configured to route traffic through BG 604a. The message may instruct the infrastructure device to reassign the client device to a second VLAN. The second VLAN may be configured to route traffic though BG 604b. The message may also or alternatively instruct the infrastructure device to cease assigning new client devices to the first VLAN, thus avoiding exacerbating an imbalance in network traffic load generated by the first VLAN in comparison to the second VLAN (and other VLANs).
Branch gateway 604a includes instructions 610b in memory 608b that, when executed by processor 606b, cause branch gateway 604a to undertake certain actions. Instructions 610b may include instructions to enable VRRP and to establish VRRP instances for each VLAN of the branch LAN. Instructions 610b may also include instructions to gather load parameters, including user count per assigned VLAN, jitter, dropped packets, and latency for data packets routed through BG 604a, hardware device usage (e.g. CPU usage, NIC usage, etc) of BG 604a, and service utilization for packet services (e.g. DPI, content classification, etc.) of BG 604a. Instructions 610b may also include instructions to alter VRRP instances for a certain VLAN based on a message from network orchestrator 602 so that the master of the VRRP instance toggles from BG 604a to BG 604b or from BG 604b to BG 604a.
Branch gateway 604b includes instructions 610c in memory 608c that, when executed by processor 606c, cause branch gateway 604b to undertake certain actions. Instructions 610c may include instructions to enable VRRP and to establish VRRP instances for each VLAN of the branch LAN. Instructions 610c may also include instructions to gather load parameters, including user count per assigned VLAN, jitter, dropped packets, and latency for data packets routed through BG 604b, hardware device usage (e.g. CPU usage, NIC usage, etc) of BG 604b, and service utilization for packet services (e.g. DPI, content classification, etc.) of BG 604b. Instructions 610c may also include instructions to alter VRRP instances for a certain VLAN based on a message from network orchestrator 602 so that the master of the VRRP instance toggles from BG 604a to BG 604b or from BG 604b to BG 604a.
Although
Branch gateways are network infrastructure devices that are placed at the edge of a branch LAN. Often branch gateways are routers that interface between the LAN and a wider network, whether it be directly to other LANs of the WAN via dedicated network links (e.g. MPLS) or to the other LANs of the WAN via the Internet through links provided by an Internet Service Provider connection. Many branch gateways can establish multiple uplinks to the WAN, both to multiple other LAN sites, and also redundant uplinks to a single other LAN site. Branch gateways also often include network controllers for the branch LAN. In such examples, a branch gateway in use in a SD-WAN may include a network controller that is logically partitioned from an included router. The network controller may control infrastructure devices of the branch LAN, and may receive routing commands from a network orchestrator.
A network orchestrator is a service (e.g. instructions stored in a non-transitory, computer-readable medium and executed by processing circuitry) executed on a computing device that orchestrates switching and routing across a SD-WAN. In some examples, the network orchestrator executes on a computing device in a core site LAN of the SD-WAN. In some other examples, the network orchestrator executes on a cloud computing device. The network orchestrator may be provided to the SD-WAN as a service (aaS). The network orchestrator gathers network operating information from various network infrastructure devices of the SD-WAN, including network traffic load information, network topology information, network usage information, etc. The network orchestrator then transmits commands to various network infrastructure devices of the SD-WAN to alter network topology and network routing in order to achieve various network efficiency and efficacy goals.
A virtual local area network (VLAN) is a logical partition of a portion of a WAN. A VLAN may be contained within a certain LAN of the WAN or it may span across multiple LANs of the WAN. VLANs are implemented in layer 2 of the OSI model (the data link layer) and, among other benefits, improve network configurability as the size of the network scales. VLAN capable infrastructure devices may allocate VLANs on a per-port basis or may tag certain data frames with information associating the frames with their respective VLANs. VLANs may be used to group related devices, balance load on certain network infrastructure devices, apply security and routing policies on a broad basis, implement quality of service (QoS), etc.
A network infrastructure device is a device that receives network traffic and forwards the network traffic to a destination. Network infrastructure devices may include, among other devices, controllers, access points, switches, routers, bridges, and gateways. Certain network infrastructure devices may be SDN capable, and thus can receive network commands from a controller or an orchestrator and adjust operation based on the received network commands. Some network infrastructure devices execute packets services, such as application classification and deep packet inspection, on certain network traffic that is received at the network infrastructure device. Some network infrastructure devices monitor load parameters for various physical and logical resources of the network infrastructure device, and report load information to a controller or an orchestrator.
The features of the present disclosure can be implemented using a variety of specific devices that contain a variety of different technologies and characteristics. As an example, features that include instructions to be executed by processing circuitry may store the instructions in a cache of the processing circuitry, in random access memory (RAM), in hard drive, in a removable drive (e.g. CD-ROM), in a field programmable gate array (FPGA), in read only memory (ROM), or in any other non-transitory, computer-readable medium, as is appropriate to the specific device and the specific example implementation. As would be clear to a person having ordinary skill in the art, the features of the present disclosure are not altered by the technology, whether known or as yet unknown, and the characteristics of specific devices the features are implemented on. Any modifications or alterations that would be required to implement the features of the present disclosure on a specific device or in a specific example would be obvious to a person having ordinary skill in the relevant art.
Although the present disclosure has been described in detail, it should be understood that various changes, substitutions and alterations can be made without departing from the spirit and scope of the disclosure. Any use of the words “may” or “can” in respect to features of the disclosure indicates that certain examples include the feature and certain other examples do not include the feature, as is appropriate given the context. Any use of the words “or” and “and” in respect to features of the disclosure indicates that examples can contain any combination of the listed features, as is appropriate given the context.
Phrases and parentheticals beginning with “e.g.” or “i.e.” are used to provide examples merely for the purpose of clarity. It is not intended that the disclosure be limited by the examples provided in these phrases and parentheticals. The scope and understanding of this disclosure may include certain examples that are not disclosed in such phrases and parentheticals.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2019/027444 | 4/15/2019 | WO | 00 |
