The integration between NS1 and Cisco FirePower/Adaptive Security Appliance (ASA) VPN allows enterprises to distribute VPN sessions (for example, from an AnyConnect client) intelligently to your Cisco VPNs. It uses NS1's powerful API and data collected from Cisco VPN appliances to route VPN sessions to the best available Cisco ASA or VPN endpoint. As a Cisco ASA reaches maximum capacity, NS1 automatically steers traffic away from that endpoint to avoid reaching maximum licensed capacity.
A DNS host record (domain or subdomain) contains one or more answers representing each individual endpoint (i.e., appliance/device). In addition to the IP address of an individual endpoint, the NS1 platform allows users to associate metadata with the answer — such as geographic location, up/down status, load average, active sessions, cost metrics, and more.
To achieve configurations like automatic failover or automatic load shedding, users can create a data feed that allows a native or third-party data source (such as a Cisco VPN appliance) to automatically update the answer metadata values. In the NS1 platform, the Filter Chain references the answer metadata values when it is making traffic routing decisions. For example,
The Up filter uses the up/down status listed in the answer metadata to determine which endpoints (answers) are available.
The Shed Load filter analyzes either the number of active connections, load average, or active requests to determine the best endpoint (answer) at the time of each query.
The Cisco VPN appliance has an SNMP interface through which users can request reports for certain metrics, including the number of active sessions initiated by a web client (crasSVCNumSessions) or by a VPN client (crasSVCNumSessions).
During configuration, you will create a data feed from the VPN appliance and connect it to the corresponding answer via the answer metadata. You will configure the metadata to ensure that the value for the number of active sessions is updated automatically by the data feed connected to the VPN appliance. Also, you’ll set low and high watermarks to indicate when the system should slow down or completely stop sending traffic to that endpoint. Finally, you’ll create a Filter Chain for the record that includes the Shed Load filter with “number of active sessions” selected as the key metric to consider. You can use the Shed Load filter in conjunction with other filters to create custom traffic routing policies.
Once this is configured, each DNS query is processed through the Filter Chain at which point the Shed Load filter analyzes all the answers and selects the VPN appliance with the lowest number of active sessions.
Before implementing the integration, ensure you have the following:
at least two Cisco FirePower or ASA VPN appliances.
-
an active NS1 account with the following user permissions settings enabled:
Manage API keys
Allow zone management
Push to data feeds
Manage data sources
Manage data feeds
-
a valid NS1 API key generated configured with the following permissions:
Push to data feeds
Refer to the relevant Cisco documentation for configuring SNMP based on the specific VPN appliance model. The SNMP object IDs (OID) for metrics related to active sessions are:
OID |
Description |
|---|---|
|
crasWEBVPNNumSessions (1.3.6.1.4.1.9.9.392.1.3.38) |
The number of active VPN sessions initiated via the web portal. |
|
crasSVCNumSessions (1.3.6.1.4.1.9.9.392.1.3.35) |
The number of active VPN sessions initiated via the VPN client. |
In the examples below, we will use these SNMP OIDs as the source of data pushed to the data feeds.
Refer to Configuring automatic load shedding for instructions on how to configure DNS records with answers that represent each VPN appliance as well as the data feeds to guide traffic.
The guidelines below are important to consider when configuring this integration:
NS1 recommends setting a low record TTL value (e.g., 30 seconds) to prevent users from getting cached values.
In each answer’s metadata, set the low and high watermarks such that they can effectively distribute load. For example, if you set a low watermark of around 75% and a high watermark of around 90%, then when the load reaches 75% of the device’s maximum capacity for active connections, NS1 starts to shift traffic away from this device. When the number of active sessions reaches 90% of full capacity, NS1 stops directing traffic to that endpoint completely.
Typically, you will create a single data source that represents incoming VPN data, and then add a feed for each VPN appliance. NS1 recommends labeling data feeds using a location name or region.
-
As you create data sources, record the data source ID for each. You will need this later.
-
After applying the Shed Load filter to the record’s Filter Chain configuration, ensure that filter is configured to use the “connections” metadata.
In this step, you will connect the SNMP output from the Cisco VPN appliance and connect it to the NS1 platform—applying the load shedding configuration done in step 2. You do this by creating a script to poll the appliance and push metrics to the NS1 data feeds.
NS1 offers several SDK’s that can be used in conjunction with SNMP modules. For this example, the example below uses a simple Bash script called asa.sh that combines snmpget and cURL.
Run the following script for each site where an VPN appliance is present:
#!/bin/bash
CISCO_IP=$1
CISCO_COMMUNITY=$2
NS1_SOURCE_ID=$3
NS1_FEED_LABEL=$4
NS1_KEY=$5
WEB_OID=1.3.6.1.4.1.9.9.392.1.3.38.0
WEB_CONNS=$(snmpget -Oqv -v2c -c ${CISCO_COMMUNITY} ${CISCO_IP} ${WEB_OID})
curl -X POST -H "X-NSONE-Key: ${NS1_KEY}" -d "{\"${NS1_FEED_LABEL}\":{\"connections\":${WEB_CONNS}}}" https://api.nsone.net/v1/feed/${NS1_SOURCE_ID}
This script can then be run as:
./asa.sh <CISCO_IP> <CISCO_COMMUNITY> <NS1_SOURCE_ID> <NS1_FEED_LABEL> <NS1_KEY>
Parameter |
Description |
|---|---|
CISCO_IP |
This is the IP address of the Cisco appliance to poll. |
CISCO_COMMUNITY |
This is the SNMP community configured in step 1. |
NS1_SOURCE_ID |
This is the data source ID for the data source you created in step 2. |
NS1_FEED_LABEL |
This is the region applied to answer metadata in step 2. |
NS1_KEY |
This is a unique API key created from within the NS1 platform. |
This script can be run as a cron job in a region to periodically poll the VPN appliance and push the connection data to the corresponding feed. The polling frequency is critical to ensure NS1 can make intelligent traffic routing decisions based on the latest information.
This script is meant to be used as a starting point to develop more elaborate scripts, including but not limited to using health checks to drive the data for our Up filter, considering other load metrics, or even centralizing the polling of many devices within a single script.
This is just one example of how you can utilize our data feeds API to optimize DNS traffic steering decisions. The articles below provide additional examples and best practices for leveraging the NS1 Filter Chain: