How to Solve No Boolean Tracking Support on Cisco ASA
Written by Rio Zavarce, Principal Consulting Engineer, Aspire Technology Partners
IntroductionCustomers find themselves in situations that require an Internet backup link without the use of BGP or other routing protocols. Sometimes, BGP is not available as a service, or it is too expensive for the branch office in question. Therefore, and alternatively, some network engineers implement Cisco’s IP Service Level Agreement (IP SLA) as a working solution to monitor the primary Internet link’s up-down state to failover the backup ISP when the primary link goes down. How does the router do this? With IP SLA, a router can ping an IP host, or two, or more hosts on the Internet over the primary ISP. When the router stops receiving ping replies from any or all the target IP hosts, the router declares the primary ISP as down and then redirects all Internet traffic over the backup ISP. An IP host is any device on the Internet with an IP address. IP hosts can reply to a ping message, although, sometimes, ping replies are disabled. This paper will assume that no filtering is in place. When the Internet router sends a ping packet to the host’s IP address, the IP host responds with a ping reply. Simple.
Did you know? Aspire holds a Cisco Master Networking Specialization. validates that Aspire can provide sophisticated, value-added Cisco solutions through their in-depth sales capabilities, technology skills, and service offerings in the USA.
That is how the router knows that there is end-to-end IP reachability and that the targeted IP host is alive. A ping is a small message sent to another IP device. The remote IP device then responds with a ping reply, as if confirming that it is active. If a router pings a remote device located outside of the primary ISP network, one device may go offline. The reason why varies. If a device goes offline, pings will stop returning. As a result, the router will assume that the Internet link went down, though that is not the case. A no ping reply means that the router will trigger a failover despite the primary Internet line and the service provider’s network being fully operational. To mitigate this false alarm, however, an engineer may use the IP SLA to ping two or more remote devices instead of one. The likelihood of those targets becoming unresponsive at the same time is less than just one remote IP host. For example, an engineer will ping two devices over ISP 1, working with Google’s DNS server 126.96.36.199. and Level 3’s DNS server 188.8.131.52, because of its reliability (always up). If IP host 1, or 184.108.40.206, stops responding, and IP host 2, or 220.127.116.11, still responds to pings, the router knows that ISP 1 remains up because the router still receives ping replies from 18.104.22.168. If both IP hosts stop responding, the router behaves as if the Internet link went down on ISP 1 and fail over the backup ISP. Although the Internet link to ISP 1 may still be up, a routing problem might exist on ISP 1’s network, which would render ISP 1 unusable for Internet access. Pinging any reliable public IP will do. ‘Reliable’ means that it is very, very unlikely that that IP will stop responding to pings. Cisco IOS routers use the “enhanced object tracking” feature to monitor the up/down state of every IP SLA session. This tracking feature supports a “Boolean OR” function, which means that both IP SLAs need to be down for the router to declare ISP 1 as down. In other words, if the ISP 1 link were to go down, or there is a routing problem within ISP 1, both pings to 22.214.171.124 and 126.96.36.199 would fail. A failure of both pings strongly indicates that an Internet access problem exists via ISP 1. On the contrary, a “Boolean AND” tracking would notify the router that ISP 1 is down if either of the two IP SLA sessions is not receiving a reply. If one IP SLA session is still receiving ping replies, that means there is still IP routing to a remote host over ISP 1, and therefore routing is good. So, this configuration would not be reliable for our design. We want no replies to both pings for a good indication that there is no Internet access through ISP 1. For instance, an engineer may set up track 10 to monitor IP SLA 1 that pings 188.8.131.52, and IP SLA 2 that pings 184.108.40.206. If the engineer sets up track 10 as Boolean OR, track 10 will switch to down when both IP SLAs switch to down. If IP SLA 1 remains up, and IP SLA 2 goes down because it is not receiving pings from 220.127.116.11, track 10 will remain up, meaning that the primary ISP is up and no failover needs to be triggered.
Case Study: Aspire ramps up network performance with Cisco DNA-enabled refresh.
What happens when a Cisco ASA firewall replaces an IOS device?What happens when a Cisco ASA firewall replaces an IOS device? Luckily, the ASA OS also supports IP SLA and tracking, which means that an engineer may implement IP SLA to ping a reliable host on the Internet over ISP 1 and track its up/down state with the enhanced object tracking feature; however, because relying on one remote IP host is perilous, the engineer will ping two or more devices. Now, pinging only one remote IP may cause flapping on your ASA’s routing, causing a quick switchover of all the Internet traffic over the backup link. There might be occasions in which a ping reply does not come back or is late arriving outside of the wait window. Because the ASA keeps track of all user application sessions, the engineer might experience user disconnections at the time of the quick switchover to the backup link. For example, if an engineer opens an FTP session from his or her computer, and that session is being sent over ISP 1 when the ASA switches over the backup ISP and then back over the primary line, a disconnection might occur. The ASA, like IOS routers, determines whether an ISP went down through a tracking features that monitors IP SLA; however, although the engineer may set up the ASA to ping two or more IP devices on the internet, unlike IOS routers, the ASA tracking feature cannot monitor more than one IP SLA. The tracking feature monitors only one at a time. This might alarm engineers, but the use of other features will obtain the same result. The ‘solution’ section will explain how.
How to determine whether ISP 1 is usable or unusableTo determine whether ISP 1 is usable or not, engineers may associate the ASA’s default route with a tracking instance. Tracking instance configuration shows ‘up-time’, which proves a valid and usable default route to ISP 1. The configuration shows ‘down-time’ as well. If tracking displays ‘down-time’ because the IP SLA session went down, and because ping replies failed to return, the default route to ISP 1 will become invalid, and the secondary default route to the backup ISP will become active. Here is a quick break down on how this works on IOS devices:
- IP SLA 1 pings 18.104.22.168
- The static route forces traffic to 22.214.171.124 out the primary ISP on interface G0/0/1
- IP SLA 2 pings 126.96.36.199
- The static route forces traffic to 188.8.131.52 out the primary ISP on interface G0/0/1
- Track 10 is configured as a Boolean OR and monitors both IP SLA 1 and 2 –> Boolean OR means that both IP SLAs must be down for tracking 10 to switch its state from up to down
- Track 10 really monitors Track 1 and 2. Track monitors IP SLA 1, and Track 2 monitors IP SLA 2. Effectively, track 10 monitors IP SLA 1 and 2
- The default route to ISP 1 is associated to track 10 – if track 10 is up, the default route to ISP 1 is valid
- The administrative distance (AD) on this static route is the default of 1 (AD will be explained below)
- The backup default route pointing to ISP 2 stays in standby (floating) until the primary default route becomes invalid. The primary default route become invalid when track 10 goes down. Once the primary default route becomes invalid, the secondary default route will kick in and Internet traffic will then be redirected to the backup ISP
- The administrative distance on the static default route to ISP 2 is set to 5 – the lower the AD, the better – this is why the static default route to ISP 1 with AD of 1 is preferred over this static default route to ISP 2 with AD of 5
- Again, when track 10 goes down, the default route to ISP 1 becomes invalid and the default route to ISP 2 takes over
- Configure the IP SLAs just like in IOS (the syntax is different)
- outside-1 is the name of the primary interface
- outside-2 is the name of the backup interface
- The static routes to 184.108.40.206 and 220.127.116.11 force pings to those IP addresses to leave ISP 1 and not ISP 2
- Configure tracking
- Track 1 will monitor SLA 1
- Track 2 will monitor SLA 2
- Split the default route into two halves for “longest match routing”
- 0.0.0/1 and associate it to track 1
- 0.0.0/1 and also associate to track 1
- Configure a default route 0.0.0.0/0 and associate it to track 2
- Configure a backup default route with administrative distance 5
- 8.8.8 stops responding to pings over ISP 1 – track 1 goes down – longest-match default routes are removed.
- 2.2.2 is still active and replying to pings – default route to ISP 1 takes over.
- 2.2.2 becomes unresponsive – track 2 goes down – default route to ISP 1 is removed.
- Backup default route to ISP 2 takes over.