Abstract: In accordance with an embodiment, described herein is a system and method for autonomous firewall rule management, for use with cloud computing environments or other types of network environments. A firewall rule management automation framework provides rule management for firewalls deployed across availability domains. The system is adapted to automatically determine firewalls that can receive network traffic from a given source subnet or destination subnet; configure the firewalls with required firewall rules; monitor the firewall rules through collection of metrics snapshots and rule hit counts; and purge underused or potentially obsolete firewall rules, for example those having zero hits over a particular period of time or number of snapshots. The system provide generic support for different types of firewall devices, and autonomous management of firewall rules within large heterogeneous computer networks that may include several types of firewalls.

Abstract: In accordance with an embodiment, described herein are systems and methods for use of a suffix tree to control blocking of blacklisted encrypted domains. A suffix tree includes encrypted hash keys corresponding to a plurality of domain nodes. A domain-related request packet is received, and a target domain name extracted from the packet. A pair of hash keys are generated for the request packet and target domain; and a hash table is searched with the generated hash key pair. If a corresponding entry is found in the hash table, then a corresponding hash suffix pointer is determined for the packet, and the suffix tree examined to determine whether the node identified by the query is part of a blacklisted node. If the suffix tree indicates the node to be part of a blacklisted node, then the system can perform a specified action associated with that node.

Abstract: In accordance with an embodiment, described herein is a system and method for providing fault tolerance and resiliency within a cloud network. A cloud computing environment provides access, via the cloud network, to software applications executing within the cloud environment. The cloud network can include a plurality of network devices, of which various network devices can be configured as virtual chassis devices, cluster members, or standalone devices. A fault tolerance and resiliency framework can monitor the network devices, to receive status information associated with the devices. In the event the system determines a failure or error associated with a network device, it can attempt to perform recovery operations to restore the cloud network to its original capacity or state. If the system determines that a particular network device cannot recover from the failure or error, it can alert an administrator for further action.

Abstract: Round-trip times (RTT) values are estimated between meshed data centers serving an internet domain and a local domain name server (LDNS) associated with the data centers. A method initializes a shared database with proactively estimated RTTs and uses distributed DNS reflection to improve the accuracy of an estimated RTT value and update the shared database. RTTs may be proactively estimated by using pings, queries, or local DNS reflection. In local DNS reflection, a reflector sends a request to a collector in the same data center via the LDNS, and the collector measures the RTT. In distributed DNS reflection, a reflector in a first data center sends a request to a collector in a second data center via the LDNS. The collector calculates the latency, retrieves the (first) RTT between the first data center and the LDNS, and calculates the (second) RTT between the second data center and the LDNS by doubling the difference between the latency and half the first estimated RTT.

Abstract: An example method facilitates Global Traffic Management (GTM) and associated selective distribution of computing loads and/or network traffic among different geographically distributed data centers of a particular domain by allocating the servicing of request messages from Local Domain Name Servers (LDNSs) to data centers that are estimated to provide the quickest response times to the LDNSs. Estimates of path latencies or Round Trip Times (RTTs) between the LDNSs and the different distributed data centers are estimated using DNS reflection methodologies and are maintained in a database that may be accessed and collectively managed via the data centers, e.g., via use of a web service that fronts the database. Locations of the LDNSs approximate locations of client devices seeking access to the domain.

Abstract: In accordance with an embodiment, described herein is a system and method for providing fault tolerance and resiliency within a cloud network. A cloud computing environment provides access, via the cloud network, to software applications executing within the cloud environment. The cloud network can include a plurality of network devices, of which various network devices can be configured as virtual chassis devices, cluster members, or standalone devices. A fault tolerance and resiliency framework can monitor the network devices, to receive status information associated with the devices. In the event the system determines a failure or error associated with a network device, it can attempt to perform recovery operations to restore the cloud network to its original capacity or state. If the system determines that a particular network device cannot recover from the failure or error, it can alert an administrator for further action.

Abstract: In accordance with an embodiment, described herein are systems and methods for use of a suffix tree to control blocking of blacklisted encrypted domains. A suffix tree includes encrypted hash keys corresponding to a plurality of domain nodes. A domain-related request packet is received, and a target domain name extracted from the packet. A pair of hash keys are generated for the request packet and target domain; and a hash table is searched with the generated hash key pair. If a corresponding entry is found in the hash table, then a corresponding hash suffix pointer is determined for the packet, and the suffix tree examined to determine whether the node identified by the query is part of a blacklisted node. If the suffix tree indicates the node to be part of a blacklisted node, then the system can perform a specified action associated with that node.

Abstract: An example method facilitates Global Traffic Management (GTM) and associated selective distribution of computing loads and/or network traffic among different geographically distributed data centers of a particular domain by allocating the servicing of request messages from Local Domain Name Servers (LDNSs) to data centers that are estimated to provide the quickest response times to the LDNSs. Estimates of path latencies or Round Trip Times (RTTs) between the LDNSs and the different distributed data centers are estimated using DNS reflection methodologies and are maintained in a database that may be accessed and collectively managed via the data centers, e.g., via use of a web service that fronts the database. Locations of the LDNSs approximate locations of client devices seeking access to the domain.

Abstract: Round-trip times (RTT) values are estimated between meshed data centers serving an internet domain and a local domain name server (LDNS) associated with the data centers. A method initializes a shared database with proactively estimated RTTs and uses distributed DNS reflection to improve the accuracy of an estimated RTT value and update the shared database. RTTs may be proactively estimated by using pings, queries, or local DNS reflection. In local DNS reflection, a reflector sends a request to a collector in the same data center via the LDNS, and the collector measures the RTT. In distributed DNS reflection, a reflector in a first data center sends a request to a collector in a second data center via the LDNS. The collector calculates the latency, retrieves the (first) RTT between the first data center and the LDNS, and calculates the (second) RTT between the second data center and the LDNS by doubling the difference between the latency and half the first estimated RTT.

Abstract: In accordance with an embodiment, described herein is a system and method for autonomous firewall rule management, for use with cloud computing environments or other types of network environments. A firewall rule management automation framework provides rule management for firewalls deployed across availability domains. The system is adapted to automatically determine firewalls that can receive network traffic from a given source subnet or destination subnet; configure the firewalls with required firewall rules; monitor the firewall rules through collection of metrics snapshots and rule hit counts; and purge underused or potentially obsolete firewall rules, for example those having zero hits over a particular period of time or number of snapshots. The system provide generic support for different types of firewall devices, and autonomous management of firewall rules within large heterogeneous computer networks that may include several types of firewalls.

Abstract: In accordance with an embodiment, described herein is a system and method for use of dynamic templates with a network traffic flow information protocol, such as, for example, an Internet Protocol Flow Information Export (IPFIX) protocol. An exporter, that operates an exporting process, generates a capability message that indicates the network traffic flow fields that can be implemented and exported from the exporter (e.g., in an IPFIX data format), and communicates the capability message to a collector that operates a collecting process. The collector examines the network traffic flow fields identified by the capability message, and generates a dynamic template request message indicating (in the manner of a virtual template) a combination of fields for which network traffic flow information is to be provided. The exporter thereafter communicates, to the collector, data messages comprising the network traffic flow fields as indicated by the dynamic template.

Abstract: An example method facilitates Global Traffic Management (GTM) using a combination of passive latency measurements and active latency measurements, including Domain Name System (DNS) server reflection methods, that estimate Round Trip Times (RTTs) between individual geographically distributed data centers (servicing a particular domain) and Local Domain Name Servers (LDNSs) communicating with the data centers. Passive and/or active measurements may initialize a shared database (e.g., accessible by the data centers via a web service). After initialization of the database using static and/or active methods to provide initial estimates of RTTs, different DNS reflection methods then accurately estimate the RTTs and populate the database therewith.

Abstract: The present disclosure presents systems and methods for obtaining metric information by a multi-core GSLB intermediary device and providing global server load balancing services using the obtained information. A first core of a multi-core GSLB appliance establishes a transport layer connection to a remote load balancer at a site of a plurality of sites. The first core transmits a message to each of the other cores of the multi-core GSLB appliance that the first core is a master core for receiving metric information from the load balancer. The first core receives metric information of the remote site from the load balancer. The first core propagates the metric information to each of the other cores of the GSLB appliance. A GSLB virtual server on a slave core receives a DNS request. The GSLB virtual server determines a DNS resolution for the DNS request based on the metric information.

Abstract: Centralized system for synchronizing a Global Server Load Balancing (GSLB) site hierarchy across a plurality of appliances in a multi-site deployment. With synchronization, differences in configurations across appliances may be determined and changes to configurations may automatically be distributed and applied on each appliance at each site to operate all the sites with a common single GSLB site hierarchy configuration. This reduces the challenging in configuration maintenance for the multi-site deployment.

Abstract: The present invention is directed towards systems and methods for monitoring an access gateway. The systems and methods include monitors on appliances that generate and send requests to logon agents or login page services on access gateways. Based on the responses from the logon agents or login page services, the monitors determine whether the logon agents or login page services are available.

Abstract: Systems and methods for providing one or more GSLB vServers to support both IPv4 and IPv6. The IPv6 support can be provided by permitting both A and AAAA domain name resolution. In other embodiments, the IPv6 support can be provided by modifying data structures to support IPv6 addresses.

Abstract: The present disclosure presents systems and methods for obtaining metric information by a multi-core GSLB intermediary device and providing global server load balancing services using the obtained information. A first core of a multi-core GSLB appliance establishes a transport layer connection to a remote load balancer at a site of a plurality of sites. The first core transmits a message to each of the other cores of the multi-core GSLB appliance that the first core is a master core for receiving metric information from the load balancer. The first core receives metric information of the remote site from the load balancer. The first core propagates the metric information to each of the other cores of the GSLB appliance. A GSLB virtual server on a slave core receives a DNS request. The GSLB virtual server determines a DNS resolution for the DNS request based on the metric information.

Abstract: The present disclosure presents systems and methods for obtaining metric information by a multi-core GSLB intermediary device and providing global server load balancing services using the obtained information. A first core of a multi-core GSLB appliance establishes a transport layer connection to a remote load balancer at a site of a plurality of sites. The first core transmits a message to each of the other cores of the multi-core GSLB appliance that that the first core is a master core for receiving metric information from the load balancer. The first core receives metric information of the remote site from the load balancer. The first core propagates the metric information to each of the other cores of the GSLB appliance. A GSLB virtual server on a slave core receives a DNS request. The GSLB virtual server determines a DNS resolution for the DNS request based on the metric information.

Abstract: The present invention is directed towards systems and methods for providing dynamic proximity load balancing via a multi-core intermediary device. An intermediary device providing global server load balancing (GSLB) identifies a local domain name service (LDNS) entries database and assigns each LDNS entry in the LDNS entries database to one of the plurality of packet processing engine base on a source internet protocol (IP) address of each LDNS entry. The first packet processing engine on the appliance receives a LDNS request for an IP address, determines that the LDNS entry for the IP address is assigned to a second packet processing engine of the plurality of packet processing engines, transmits a request to the second packet processing engine for the LDNS entry for the IP address, and determines a response to the LDNS request based on the LDNS entry for the IP address received from the second packet processing engine.

Abstract: The present invention is directed towards systems and methods for providing dynamic proximity load balancing via a multi-core intermediary device. An intermediary device providing global server load balancing (GSLB) identifies a local domain name service (LDNS) entries database and assigns each LDNS entry in the LDNS entries database to one of the plurality of packet processing engine base on a source internet protocol (IP) address of each LDNS entry. The first packet processing engine on the appliance receives a LDNS request for an IP address, determines that the LDNS entry for the IP address is assigned to a second packet processing engine of the plurality of packet processing engines, transmits a request to the second packet processing engine for the LDNS entry for the IP address, and determines a response to the LDNS request based on the LDNS entry for the IP address received from the second packet processing engine.