202A can send traffic over the directly attached Cellular-1 via WAN A 204A for cellular communications over the AT&T cellular network as well as over the Cellular-2 on Device-B 202B via WAN B 204B by utilizing a port pair as shown at 210 and Cellular-2 (e.g., using cellular bypass pair 210 and 214 as similarly described above).

Specifically, Device-B 202B, having a local cellular modem shown as Cellular 2 for WAN B 204B, controls cellular capabilities (for Cellular-2) including, for example, the following: (1) starting a data session; (2) gathering geolocation (e.g., GPS) information; (3) monitoring radio resources, such as signal strength, noise, cell tower switches; and/or (4) managing SIM switches when two SIMs are available. More specifically, these capabilities are extended from Device-B 202B to Device-A 202A using a new cellular extension for WAN synchronization protocol as shown at 218. As shown at 218, the disclosed cellular extension for WAN synchronization protocol facilitates sharing of various cellular modem and related information including the following: (1) connectivity details, such as IP addresses; (2) DNS information; (3) derived signal-strength metrics; (4) active/inactive status; (5) geolocation (GPS) information; (6) application/network reachability; and/or (7) other information/metrics. Synchronization of this cellular related information facilitates the disclosed techniques for extending local cellular WAN capabilities to a connected device so that, for example, Device-A 202A can utilize the information associated with Cellular-2 (i.e., the cellular modem of Device-B 202B and its own SIM card), which results in a solution that allows Device-A 202A to behave as it includes two cellular modems, both Cellular 1 that is native to Device-A 202A as well as Cellular-2 that is actually native to Device-B 202B. In an example implementation, an SDK and application programming interfaces (APIs) can be utilized to obtain this cellular information from the respective SIM cards that can then be extracted and synchronized between Device-A 202A and Device-B 202B using the cellular extension for WAN synchronization protocol as shown at 218.

In the case of an HA switchover, the disclosed techniques can then be efficiently applied to bypass the traffic on Device-A using the above-described techniques and the disclosed synchronization protocol to share the similar information/metrics for Cellular 1 and the SIM of Device-A 202 with Device-B 202B. As such, HA failover is effectively and efficiently performed for an SD-WAN router that has only a single cellular modem but is extended to the remote cellular modem of another standby device to become the active device, such as if/when the previously active device suffers a failure, cellular network connectivity degradation/loss, or other triggering event, using the above-described techniques (e.g., without the delay of, for example, having to download the firmware of another cellular service provider/carrier to its only cellular modem).

FIG. 3 is a system diagram that illustrates components for extending local cellular WAN capabilities to a connected device with a Device-B without a cellular modem using the cellular capability of a Device-A in accordance with some embodiments. In this second example use case, Device-A 302A includes a Cellular 1 modem for communication (shown as currently inactive) with a cellular service provider/carrier for WAN A as shown at 304A (e.g., AT&T cellular network, in which case WAN A includes an AT&T SIM), and Device-A 302 also includes a Cellular 2 modem that is shown in active communication with a cellular service provider/carrier for WAN B as shown at 304B (e.g., Verizon cellular network, in which case WAN B includes a Verizon SIM). As also shown in FIG. 3, a Device-B 302B includes a Wired WAN as shown at 306 for communications with a non-cellular, wired network, such as DSL, Fiber, broadband, etc. In this example use case, Device-A 302A and Device-B 302B are connected via network communication cables (e.g., Ethernet cables and/or other high speed Internet network cables) as shown at 310 and 314 as well as 312 and 316 (e.g., cellular bypass pairs, such as similarly described above with respect to FIG. 2).

In this example implementation, Device-A 302A, having a local cellular modem, controls cellular capabilities to provide WAN A 304A and WAN B 304B connectivity. Such capabilities can include the following: (1) starting a data session; (2) gathering geolocation (e.g., GPS) information; (3) monitoring radio resources, such as signal strength, noise, etc.; (4) cell tower switches; and/or (5) managing SIM switches when two SIMs are available.

Further, in this example implementation use case scenario, Device-B 302B is connected physically to Device-A 302A as described above, and intends to use cellular connectivity extended by Device-A 302A. Upon certain cellular connectivity triggers (e.g., starting/stopping data session, learning GPS location, change in signal strength, etc.), Device-A 302A synchronizes cellular information to Device-B 302B. Device-B 302B can now configure its local interface using this information and start using it for, for example, Device-B 302B connectivity. Also, since Device-B 302B is the one that is actively using the connection for data traffic, it can determine application/network reachability over this link. Thus, such information is synchronized back to the Device-A 302A via the cellular extension for WAN synchronization protocol as shown at 318, which can use it to determine whether the other SIM (e.g., different cellular service provider/carrier) should be used, and if so, it starts the new data session and synchronizes new information to Device-B 302B accordingly.

More specifically, in this example use case scenario, cellular bypass pairs 310 and 314 and/or 312 and 316 can be used to provide redundant cellular connectivity for Device-B 302B using the dual SIM cellular capability of Device-A 302A. Specifically, in response to certain cellular connectivity triggers (e.g., starting/stopping a data session, learning a GPS location, a change in signal strength, a failure of a SIM, a loss of cellular connectivity or other network performance degradation, etc.), Device-A synchronizes (sync) cellular information to Device-B using the cellular extension for WAN synchronization protocol as shown at 318, such as similarly described above with respect to FIG. 2 (e.g., using an SDK and application programming interfaces (APIs) to obtain this cellular information from the respective SIM cards that can then be extracted and synchronized between Device-A 302A and Device-B 302B using the cellular extension for WAN synchronization protocol as shown at 318).

As such, Device-B 302B utilizes this synchronized cellular related information for determining an application/network reachability for performing SD-WAN path selection. Also, Data Policy information is synchronized back to Device-A 302A, which can use it to determine whether a second SIM (e.g., a different cellular service provider/carrier, such as detecting that Microsoft Office 365 SaaS traffic over Verizon Wireless℠ over WAN B 304B is not reachable, then SD-WAN path selection can be performed by Device-A 302A to switch over to the AT&T network over WAN A 304A) should be used, and if so, then Device-A 302A starts the new data session and syncs new information to Device-B 302B accordingly.

FIG. 4 is a screen diagram that illustrates an example scenario for extending local cellular WAN capabilities to a connected device in accordance with some embodiments. Referring to FIG. 4, the network connection activities of a Device-A are shown on the left side of the screen at 402, and the network connection activities of a Device-B are shown on the right side of the screen at 404. In this example scenario (e.g., which is similar to the first use case discussed above with respect to FIG. 2), pings to IP address 1.1.1.1 are sent directly over the attached cellular link on Device-A. In contrast, pings to IP address 8.8.8.8 are directed by Device-A to be sent over interface 2 to Device-B's interface 1 based on a path policy configured in this example scenario (i.e., configured SD-WAN path selection policy/rules). Specifically, in this example scenario, Device-B has a cellular bypass-pair between interface 1 and its own cellular link. As such, pings to 8.8.8.8 coming in on interface 1 of Device-B traverse the bypass-pair and come out of the cellular link attached to Device-B. Moreover, Device-A is able to use its own cellular link as well as the cellular link of Device-B simultaneously.

As will now be apparent to one of ordinary skill in the art in view of the disclosed embodiments, various other topologies can be similarly provided using the disclosed techniques for extending local cellular WAN capabilities to a connected device (e.g., and using the cellular extension for WAN synchronization protocol) to facilitate effective and efficient SD-WAN solutions.

Moreover, in both of the above-described use cases in FIGS. 2 and 3, the synchronization between the different WANs is mutual to facilitate SD-WAN path selection based on various network capacity, bandwidth, application/network reachability, and/or other metrics/criteria as similarly described above with respect to various embodiments.

Accordingly, the disclosed system embodiment facilitates various advantages. For example, this allows a device to use another device's cellular modem with many native cellular features, as if the modem is present on the local device. Also, when used in high availability (HA) settings, this solution allows the use of two cellular carriers simultaneously even though a single device only has one radio (e.g., it allows for reusing existing SKUs and the software instead of investing in a new platform with a dual radio). Further, SD-WAN routers on the branch network can take advantage of this mechanism to improve WAN redundancy.

An embodiment of a network gateway 500 is shown in FIG. 5A (e.g., such as network gateways/SD-WAN edge devices shown at 102A-C in FIGS. 1A-1B). The example shown is a representation of physical components that can be included in network gateways/SD-WAN edge devices shown at 102A-C in FIGS. 1A-1B if the network gateway is implemented as a data appliance, in various embodiments. Specifically, the data appliance includes a high-performance multi-core Central Processing Unit (CPU) 502 and Random Access Memory (RAM) 504. The data appliance also includes a storage 510 (e.g., one or more hard disks or solid-state storage units). In various embodiments, the data appliance stores (e.g., whether in RAM 504, storage 510, and/or other appropriate locations) information that is used in monitoring an enterprise network and implementing the disclosed techniques, such as for SD-WAN path selection as similarly described above with respect to FIGS. 1A-4. Examples of such information can also include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policy and other configuration information, signatures, hostname/URL categorization information, malware profiles, and machine learning models. The data appliance can also include one or more optional hardware accelerators. For example, the data appliance can include a cryptographic engine 506 configured to perform encryption and decryption operations, and one or more Field Programmable Gate Arrays (FPGAs) 508 configured to perform matching, act as network processors, and/or perform other tasks. The data appliance also includes a network access 514, which can include wired/wireless access including a dual SIM single radio SD-WAN solution as similarly described above, for example, with respect to FIG. 2.

Functionality described herein as being performed by the data appliance can be provided/implemented in a variety of ways. For example, the data appliance can be a dedicated device or set of devices. The functionality provided by the data appliance can also be integrated into or executed as software on a general purpose computer, a computer server, a gateway, and/or a network/routing device. In some embodiments, at least some services described as being provided by the data appliance are instead (or in addition) provided to a client device (e.g., an endpoint device, such as a laptop, smart phone, etc.) by software executing on the client device.

Whenever the data appliance is described as performing a task, a single component, a subset of components, or all components of the data appliance may cooperate to perform the task. Similarly, whenever a component of the data appliance is described as performing a task, a subcomponent may perform the task and/or the component may perform the task in conjunction with other components. In various embodiments, portions of the data appliance are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data appliance, various logical components and/or features of the data appliance may be omitted, and the techniques described herein adapted accordingly. Similarly, additional logical components/features can be included in embodiments of the data appliance as applicable. One example of a component included in the data appliance in various embodiments is an application identification engine which is configured to identify an application (e.g., using various application signatures for identifying applications based on packet flow analysis). For example, the application identification engine can determine what type of traffic a session involves, such as Web Browsing—Social Networking; Web Browsing—News; SSH; Microsoft Office 365 related traffic; and so on.

The disclosed system processing architecture can be used with distinct types of clouds in different deployment scenarios, such as the following: (1) public cloud; (2) private cloud on-premises; and (3) inside high-end physical firewalls. Some processing power can be allocated to execute a private cloud (e.g., using the management plane (MP) in the Palo Alto Networks PA-5200 Series firewall appliances).

FIG. 5B is a functional diagram of logical components of an embodiment of a data appliance. The example shown is a representation of logical components that can be included in network gateway 500 in various embodiments (e.g., such as network gateways/SD-WAN edge devices shown at 102A-C in FIGS. 1A-1B). Unless otherwise specified, various logical components of network gateway 500 are generally implementable in a variety of ways, including as a set of one or more scripts (e.g., written in Go, Java, Python, etc., as applicable).