Cisco ASA5516 - Monitor IP SLA status via SNMP

[SAM MUNZANI]

Hi,

What's best way to monitor the SLA monitor status on the ASA5516? I have dual ISP with failover configured that's based on the SLA monitor. The default through primary ISP is tracked via SLA monitor and when it fails retracts the route so the traffic flows through a floating static through secondary ISP. However I need a way to know when the primary ISP has failed and we are operating off secondary path.

I looked at the supported SNMP MIBs for the ASA and don't see IP SLA MIB support there. What's best way to monitor which ISP we are operating under?

Thanks in advance,

Sam

[Dennis Mink]

Is your SLA icmp based, or based on the status of the actual interface?

if it uses icmp, why dont you use a network monitoring platform that uses icmp polls, same as the SLA on the ASA?

[SAM MUNZANI]

I didn't understand how icmp poll from my NMS platform would help here. From the ASA, I have following configuration.

route outside 8.8.8.8 255.255.255.255 x.x.x.x

sla monitor 1
type echo protocol ipIcmpEcho 8.8.8.8 interface comcast
num-packets 3
frequency 5

sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability

route comcast 0.0.0.0 0.0.0.0 x.x.x.x track 1

route rcn 0.0.0.0 0.0.0.0 y.y.y.y 50

As you can see I am forcing my pings to 8.8.8.8 through Comcast interface. So when Comcast is down, I that ping will fail and I will move to secondary default.

If I ping 8.8.8.8 from the network management station, it will never go down. When Comcast is down, it will go through RCN interface but in either case, I don't know if I am on failover.

Now you may say that why am I pinging 8.8.8.8 not the default GW of the firewall. I had tried that too in past. Comcast has their router at the site and their LAN interface is my default GW. So that would really never fail even though their is upstream connectivity loss. That's why I have to ping something on the internet not the default GW.

NOTE: One would say to monitor syslog for message like "%ASA-6-622001: Removing tracked route... " would work. However that perticular syslog message is informational level. At that level of logging the ASA produces a ton of syslog volume which is what I am trying to avoid.